How to Review a Data Processing Agreement (DPA) in India

A Data Processing Agreement, usually shortened to DPA, is the contract that governs what a vendor is allowed to do with the personal data you hand it. You rarely sign a standalone document called "DPA." It is almost always a schedule to your SaaS or Master Services Agreement, or a set of clauses buried inside a vendor's Terms of Service you never separately negotiated. (This guide is published by Adira, which makes contract review and CLM software, so we have a commercial interest in you reading DPAs carefully, but it is written to stand on its own whether or not you ever use our product.) Here is a clause by clause walk through what an Indian DPA must cover, what the DPDP Act actually requires, where GDPR asks for more, and a checklist to run before you sign.

Why a DPA exists at all under Indian law

The DPDP Act does not use the word "DPA." What it requires is a contract. Section 8(2) says:

"A Data Fiduciary may engage, appoint, use or otherwise involve a Data Processor to process personal data on its behalf for any activity related to offering of goods or services to Data Principals only under a valid contract." Source: Section 8, Digital Personal Data Protection Act, 2023

That line is the entire statutory basis for the document you are reviewing. "Only under a valid contract" means a vendor handling personal data on your instructions, with no written agreement covering that processing, is a gap the DPDP Act does not let you fix after the fact.

Roles first: who is the Fiduciary, who is the Processor

Everything else in a DPA turns on getting the roles right. Section 2 of the Act defines them:

• Data Fiduciary: the person who, "alone or in conjunction with other persons, determines the purpose and means of processing of personal data."
• Data Processor: a person who "processes personal data on behalf of a Data Fiduciary."

If you decide why and how the data is processed, you are the Fiduciary. If you process on someone else's instructions for their purposes, you are the Processor, for that same data. A payroll vendor is a Processor for the salary data it runs but a Fiduciary for its own employee records. Get this backwards and every downstream obligation, security, breach notice, deletion, points at the wrong party. Deeper background: data protection clauses under the DPDP Act.

The Act does not let a Fiduciary contract away the underlying liability. Section 8(1) makes the Fiduciary responsible for compliance "in respect of any processing undertaken by it or on its behalf by a Data Processor," regardless of what the DPA says. That is why a well-built DPA matters commercially: it cannot shift the fine, but it can shift the cost back onto the vendor through indemnity, a contract mechanic, not a statutory one.

Clause by clause

Processing scope and instructions. The DPA should list, specifically, what personal data is processed, for what purpose, for how long, and state the Processor may only act "on the Fiduciary's documented instructions." "Processor may process data as needed to provide the Services" hands the vendor discretion the statute never gave it. Watch for language letting the vendor use data for its "own business purposes," model training, or analytics, unless you intend to permit that.

Security safeguards. Section 8(5) requires the Fiduciary to "protect personal data in its possession or under its control, including in respect of any processing undertaken by it or on its behalf by a Data Processor, by taking reasonable security safeguards to prevent personal data breach." Because that duty runs through the Processor's conduct, the DPA is where a vague statutory phrase becomes something checkable: encryption at rest and in transit, access controls, a named framework like ISO 27001 or SOC 2, and a right to see evidence of it, not just a promise.

Sub-processor consent and flow-down. This is where Indian DPAs are commonly weaker than they should be. The DPDP Act imposes no sub-processor consent requirement the way GDPR Article 28(3) does: a processor there "shall not engage another processor without prior specific or general written authorisation of the controller," and under a general authorisation must "inform the controller of any intended changes concerning the addition or replacement of other processors," so the controller can object. A DPA silent on sub-processors leaves an Indian vendor free to hand your data to a hosting provider or offshore support desk without telling you. Insist on a named sub-processor list, consent for new ones, and flow-down obligations at least as strict as the head DPA.

Breach notification timing. Section 8(6) sets the Fiduciary's own duty: on becoming aware of a breach, give notice to the Data Protection Board and affected Data Principals "in such form and manner as may be prescribed." Rule 7 of the DPDP Rules, 2025 fills that in: an immediate intimation to the Board, a fuller report within 72 hours, and notice to Data Principals also without delay. That clock does not include time for your Processor to tell you a breach happened. Without a short internal window, commonly 24 to 48 hours from Processor to Fiduciary, you are chasing a regulator's clock that starts before you even know there is a problem.

Data-principal request assistance. Data Principals hold rights, access, correction, erasure, grievance redressal, and requests can land on the Fiduciary even when the Processor holds the data operationally. The DPA should require the Processor to assist promptly, at a stated turnaround, not leave you to extract cooperation clause by clause after a request lands.

Cross-border transfer. Section 16(1) lets the Central Government "notify that the transfer of personal data by a Data Fiduciary to any country or territory outside India shall not be made," a negative-list model: transfer is allowed by default except to countries specifically named. As of this writing none has been named, so cross-border transfer under the Act is largely unrestricted. That does not mean the DPA should be silent. State where the Processor stores and processes data, and require notice before that changes; a statute allowing transfer is not the same as you knowing it happened. Sector rules layer on top regardless, RBI's payment-data localisation directive among them.

Audit rights. A DPA without an inspection right leaves the Fiduciary carrying Section 8(1) accountability with no way to verify the Processor deserves the trust. GDPR sets the fuller bar: Article 28(3)(h) requires the processor to "make available to the controller all information necessary to demonstrate compliance" and to "allow for and contribute to audits, including inspections." An Indian-only DPA should borrow this mechanic even though the Act does not mandate it by name. Full treatment: audit rights clauses explained.

Deletion or return on termination. Section 8(7) requires the Fiduciary to erase personal data once its purpose is served or consent withdrawn, "unless retention is necessary for compliance with any law," and to "cause its Data Processor to erase any personal data that was made available by such Data Fiduciary for processing" on the same trigger. Mirror this with a stated timeline, commonly 30 to 90 days, and written confirmation of deletion, not an assumption.

Liability and indemnity for data breaches. This clause converts the statute's Fiduciary-only liability into something recoverable. Since the Board fines the Fiduciary, not the Processor, a DPA without an indemnity covering breach costs, fines, and third-party claims from the Processor's own negligence leaves the Fiduciary carrying someone else's failure. Check whether this indemnity sits inside or outside the general liability cap; one capped at a month's fees is close to worthless on a real incident. Full mechanics: limitation of liability clauses and indemnity clauses explained.

Red flags

Normal	Red flag	Why it matters
Processing limited to "documented instructions"	Data used "as needed" or for the vendor's "own purposes"	Vendor gets discretion the statute never gave it
Named security standard (encryption, ISO 27001, SOC 2), with evidence rights	Only "reasonable" or "appropriate" measures, undefined	Nothing concrete to hold the vendor to
Sub-processors listed; consent required for new ones; flow-down obligations	Silent on sub-processors, or "at Processor's discretion"	Your data reaches parties you never approved
Processor must notify Fiduciary of a breach within 24-48 hours	No stated window, or "promptly" left undefined	Cannot meet the Board's 72-hour clock if you learn late
Fiduciary has an audit right, with reasonable notice	No audit right, or one the Processor can simply refuse	No way to verify the safeguards actually exist
Deletion within a stated period post-termination, with written confirmation	"Processor may retain data as necessary," undefined	Data lingers indefinitely with no visibility
Breach indemnity carved out of, or set above, the liability cap	Breach costs folded into a low general cap	Real breach cost dwarfs the recoverable amount
Data location stated, with notice before it changes	No statement of where data is hosted	Cannot assess exposure to an undisclosed move
Fiduciary/Processor roles named explicitly	Vague "Company" and "Vendor" with no DPDP mapping	Ambiguity over who answers to the Board

Bad clause, better clause

Bad (a composite of language common in vendor-drafted schedules): "Vendor may process Customer Data as reasonably necessary to provide the Services and to improve Vendor's products, and may engage subcontractors at its sole discretion. Vendor will maintain appropriate security measures. In the event of a security incident, Vendor will notify Customer within a commercially reasonable time. Upon termination, Vendor may retain Customer Data for such period as it deems necessary."

Better: "Processor shall process Personal Data only on the Fiduciary's documented written instructions, and shall not use it for Processor's own product development, model training, or analytics without separate prior written consent. Processor shall not engage a sub-processor without the Fiduciary's prior written consent, and shall bind every approved sub-processor to obligations at least as protective as this Agreement. Processor shall maintain security safeguards including encryption at rest and in transit and need-to-know access controls, and shall provide evidence of compliance, including audit reports, on fifteen (15) business days' written notice. Processor shall notify the Fiduciary of any Personal Data Breach within twenty four (24) hours of becoming aware of it. Within thirty (30) days of termination, Processor shall, at the Fiduciary's election, return or securely delete all Personal Data and confirm deletion in writing. Processor shall indemnify the Fiduciary against losses, regulatory fines, and third-party claims arising from Processor's breach of this Schedule, and this indemnity shall not be subject to the general limitation of liability cap in the Agreement."

What changed: open discretion became instruction-only processing with a named carve-out for model training; silent sub-processing became consent-plus-flow-down; "commercially reasonable time" became a fixed 24-hour clock; open-ended retention became a 30-day deletion obligation with written confirmation; and the breach indemnity moved outside the general liability cap.

How it interacts with related clauses

A DPA rarely stands alone. It sits inside a SaaS or services agreement whose main-body limitation of liability clause will try to cap everything, DPA included, unless the DPA's indemnity is expressly carved out. That breach indemnity is a specific application of the general indemnity clause mechanics, drafted for this one risk, and the audit rights clause is often the only way a Fiduciary can verify the Processor's promises. For the parent agreement's full walk-through: how to review a SaaS agreement in India. For the portfolio-wide checklist: the DPDP Act for contracts and data processing agreement clauses explained.

Checklist

• Fiduciary and Processor roles named explicitly for this engagement
• Processing scope, purpose, and retention period stated, not open-ended
• Processor limited to documented instructions; no silent use for its own purposes
• Named security standard with evidence or audit rights, not just "appropriate measures"
• Sub-processors named, with consent for new ones and binding flow-down obligations
• Processor-to-Fiduciary breach notice window is a stated number of hours, comfortably inside the 72-hour clock
• Assistance with Data Principal requests is a stated, timed obligation
• Data location disclosed, with notice before it changes
• Deletion or return of data on termination, within a stated period, with written confirmation
• Breach indemnity is present and sits outside, or above, the general liability cap
• If EU personal data is involved, GDPR Article 28 terms are layered in specifically for that data

India execution notes: DPDP first, GDPR only where it applies

Do not draft an Indian-only DPA as if it were a GDPR Data Processing Addendum by default. GDPR Article 28 imposes obligations, mandatory sub-processor authorisation, detailed audit rights, specific breach-notice content, the DPDP Act does not require for a purely domestic engagement, and dragging all of it into a contract with no EU nexus just slows negotiation for no added protection. Draft to the DPDP Act's requirements first, valid contract under Section 8(2), security under Section 8(5), breach notice inside the Rule 7 clock, deletion under Section 8(7), and layer GDPR language in only where EU Data Principals are genuinely part of the deal. Watch also for sector overlays: an RBI-regulated vendor relationship carries outsourcing and data-localisation rules on top of the DPDP Act, and these can be stricter than either.

You can mark up a DPA schedule clause by clause, for free, in Weave, before you push back on a vendor's standard terms.

US and global contrast

The US has no single federal law comparable to the DPDP Act. Data processing terms are shaped by sector statutes (HIPAA, GLBA) and state privacy laws like the California Consumer Privacy Act, with their own "service provider" definitions that do not map onto India's Fiduciary and Processor split. A US-style "Data Processing Addendum" bolted onto an Indian contract without adjustment often under-protects, missing the DPDP-specific deletion and breach-notice mechanics, or over-specifies terms India's regulator has not asked for. If your vendor is a US company serving Indian customers, expect to negotiate the DPDP-specific clauses in separately.

FAQ

Do I need a document literally titled "Data Processing Agreement," or can this sit inside my main contract? The DPDP Act does not mandate a standalone document. Section 8(2) requires "a valid contract," and the terms can sit as a schedule or as clauses inside the main agreement. Higher-risk engagements, payroll, health data, large datasets, usually get a dedicated DPA for clarity.

Who is liable if my Processor causes the data breach, me or them? As a matter of regulatory liability, you are, as Data Fiduciary, under Section 8(1), regardless of whose systems failed. A well-drafted indemnity clause inside the DPA is what lets you recover that cost from the Processor afterward; the statute does not create that recovery route on its own.

Does the DPDP Act require my Processor to get my consent before using a sub-processor? Not by default, unlike GDPR Article 28(3). If the DPA is silent, an Indian Processor is generally free to engage sub-processors without telling you; write the consent and flow-down obligation into the contract yourself.

How fast must my Processor tell me about a breach? The DPDP Act does not fix this leg at all. Rule 7 of the DPDP Rules, 2025 fixes only the Fiduciary's own clock, immediate alert, detailed report within 72 hours. The Processor-to-Fiduciary window has to be negotiated into the DPA, or you may not learn in time to meet your own deadline.

Can personal data be sent outside India under a DPA? Yes, by default. Section 16 restricts transfer only to countries the government specifically names, and none have been named as of this writing. State where the Processor stores and processes the data and require notice before that changes.

Is a GDPR-style DPA safe to use for an India-only contract? Not wrong, but often mismatched. It adds obligations, formal sub-processor authorisation, Article 32-style documentation, with no matching DPDP requirement. Draft to the DPDP Act first and layer in GDPR clauses only for the slice of data that involves the EU.

This guide gets you to a working understanding of what an Indian DPA should contain and where Indian law stops short of GDPR's fuller requirements. It does not tell you whether a specific clause in your specific DPA is enforceable, or adequate for your risk and data volume, that depends on the exact wording, the sector, and the facts, and is not legal advice. Talk to a lawyer before you sign a DPA involving sensitive personal data, large volumes, or cross-border processing that departs from what this guide describes as normal.