Technology Law

Data Processing Agreements Under the DPDP Act: A Practical Checklist for SaaS Buyers

The compliance risk in a silent SaaS contract sits with you, not your vendor. Here's what to check before you sign.

India's Digital Personal Data Protection Act (DPDP Act, 2023) has moved from a future compliance date to a present operating reality for any business processing customer or employee personal data — and for most companies, that data first passes through a SaaS vendor before it touches an internal system. A SaaS agreement silent on data processing terms isn't a minor gap anymore. It's the single most common compliance blind spot buyers carry into 2025.

Why This Sits With the Buyer, Not Just the Vendor

A common misconception is that data protection obligations are the SaaS vendor's problem to solve. Under the DPDP Act's structure, the entity that determines the purpose of processing — typically the buyer, as the "Data Fiduciary" — carries primary accountability, even when a vendor is the one actually processing the data as a service provider. If your vendor mishandles customer data, the regulatory exposure lands on your business first.

That makes the data processing terms in a SaaS contract a buyer-protection mechanism, not vendor paperwork to skim past.

The Checklist: What to Verify Before You Sign

1. Purpose limitation

The agreement should state explicitly that the vendor may use your data only for the purposes you've contracted for — not for the vendor's own product improvement, analytics, or resale, unless you've separately and knowingly agreed to that.

2. Breach notification timelines

Look for a specific number of hours or days within which the vendor must notify you of a security incident involving your data. "Promptly" or "without undue delay" is not a timeline — it's an invitation to a dispute about what "prompt" meant. Push for a defined window, commonly 24–72 hours.

3. Sub-processor flow-down obligations

Most SaaS vendors rely on their own vendors — cloud hosting, analytics, customer support tools. Your contract should require that any sub-processor is bound by the same data protection commitments the primary vendor made to you, and that you're notified before a new sub-processor is added.

4. Audit rights

The ability to request evidence of the vendor's security practices — certifications, penetration test summaries, or a right to audit on reasonable notice — even if you never exercise it, signals that the vendor takes the obligation seriously and gives you recourse if something goes wrong.

5. Data localisation and cross-border transfer terms

Where your data is actually stored and processed matters under the DPDP Act's cross-border transfer provisions. Confirm where servers are located and what transfer safeguards apply if data leaves India.

6. Data return and deletion on termination

When the contract ends, what happens to your data? A working clause specifies a defined period for data export and a confirmed deletion timeline afterward — not an indefinite retention with no obligation to purge.

Most SaaS agreements are drafted by the vendor, for the vendor. Reading one as a buyer means checking not just what it promises, but what it conveniently leaves silent.

What to Do If Your Current Vendor Contracts Are Silent

If you're already using SaaS tools under older agreements that predate this level of scrutiny, a data processing addendum (DPA) can usually be added without renegotiating the whole contract. Most established vendors now have a standard DPA available on request — ask for it, read it against the six points above, and don't assume "we take security seriously" in a marketing page is a substitute for contractual commitment.

Facing this exact situation?

Get a straight answer on your specific contract or compliance question — no jargon, no obligation.

Book a Free 30-Minute Call →
RS
Written by RS

20+ years in commercial & corporate practice — in-house at BT, Oracle and Dell before founding AstraLex.