Data Processing Agreement (DPA) Clauses Explained for India

A Data Processing Agreement (DPA) is the contract, or the schedule bolted onto a master services agreement, that governs how one company (the processor: a payroll vendor, a cloud host, a CRM tool, an analytics provider) is allowed to handle another company's personal data. In India, the Digital Personal Data Protection Act, 2023 (DPDP Act) makes this contract mandatory: a Data Fiduciary can hand personal data to a processor "only under a valid contract." The one thing most people get wrong: they treat a DPA as a privacy-policy formality, or bolt on a GDPR-style addendum by default even when only Indian law applies, pulling in cost the deal does not need. This guide (published by Adira, which makes contract review and CLM software, so we have a commercial stake in you getting this right, but the explainer stands on its own) covers what a DPA has to address under Indian law, where GDPR Article 28 asks for more, and what to check before you sign.

Plain meaning

A DPA answers one question in contract form: when may the processor touch the data, and what must it do while it holds it? At minimum, a working DPA says the processor may process data only on documented instructions, must keep its staff under confidentiality obligations, must run reasonable security safeguards, must not bring in a sub-processor without permission, must report incidents quickly, must help the fiduciary meet its own regulatory obligations, must delete or return the data when the engagement ends, and must let the fiduciary verify all of this. None of this is exotic. It has the same shape as an indemnity or confidentiality clause, a promise, a trigger, a mechanism, except the subject is personal data, and Indian statute now requires the contract to exist in the first place.

Who it protects and what triggers it

A DPA protects the Data Fiduciary, the company that decides why and how personal data is processed, and by extension the Data Principals, the individuals whose data it is. The processor is the one taking on obligations. This split matters because the fiduciary cannot use the DPA to escape its own regulatory exposure; it can only use the DPA to push the economic consequences of a processor's failure back onto the processor. The clause triggers the moment personal data starts flowing to a vendor for any processing on the fiduciary's behalf (HR data to a payroll processor, customer data to a support tool, transaction data to an analytics platform), and it stays live for as long as the vendor holds or can access the data, including after the commercial contract ends, until deletion or return is confirmed.

What to look for

Five mechanics decide whether a DPA is a real control or paper cover:

1. Instruction-only processing. Can the processor use the data for its own purposes (training a model, benchmarking, selling aggregated insights), or strictly on the fiduciary's documented instructions?
2. Sub-processor consent and flow-down. Does the processor need permission before bringing in a sub-processor, and does that sub-processor pick up the same obligations?
3. Breach notice with a real deadline. Is there a stated number of hours or days for the processor to tell the fiduciary, fast enough to meet the fiduciary's own regulatory clock?
4. Deletion or return, provable. Must the processor actually delete or return the data at the end, including backups, and certify it?
5. Audit rights. Can the fiduciary actually verify compliance, on-site, by questionnaire, or by third-party certification?

The Indian position: Section 8 of the DPDP Act

The DPDP Act does not use the words "Data Processing Agreement," but it makes the underlying obligation a statutory requirement. 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, DPDP Act, 2023

Two Section 2 definitions set up the parties. A Data Fiduciary is, under Section 2(i), "any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data." A Data Processor is, under Section 2(k), "any person who processes personal data on behalf of a Data Fiduciary." Source: Section 2, DPDP Act, 2023.

The part that changes how you should draft a DPA is Section 8(1), read with Section 8(2). Section 8(1) says the fiduciary "shall, irrespective of any agreement to the contrary or failure of a Data Principal to carry out the duties provided under this Act, be responsible for complying with the provisions of this Act and the rules made thereunder in respect of any processing undertaken by it or on its behalf by a Data Processor." In plain terms: you cannot contract your way out of regulatory liability for what your processor does. The Schedule backs this with real numbers: a failure to take reasonable security safeguards under Section 8(5) can draw a penalty of up to ₹250 crore, and a failure to notify the Board and affected individuals of a breach under Section 8(6) can draw up to ₹200 crore, both landing on the fiduciary unless its contract lets it recover that exposure from the vendor who caused it.

That is the real function of a DPA under Indian law: it cannot shift regulatory liability to the Board, but it can shift the economic loss, through indemnity, tight notice obligations, and a liability structure that makes the processor pay for its own failure. DPDP is also deliberately lighter on prescriptive processor mechanics than GDPR. The statute does not spell out sub-processor consent chains, audit rights, or a fixed breach-notice deadline for the processor-to-fiduciary leg (only the fiduciary-to-Board leg is addressed). That gap is what a well-drafted DPA has to fill on its own.

A named Indian case: Karmanya Singh Sareen v Union of India

There is no reported Indian judgment yet interpreting a DPA under the DPDP Act itself; the Act is too new. The closest useful precedent predates DPDP and was decided on contract and constitutional grounds, not a data-protection statute, but it shows the risk a DPA is meant to control.

In Karmanya Singh Sareen and Anr v Union of India and Ors (Delhi High Court, 23 September 2016), users challenged WhatsApp's 2016 privacy policy update, which let WhatsApp share account data with Facebook and its group companies. The court declined to strike down the policy outright, holding the relationship was contractual rather than a matter for writ jurisdiction, but drew a specific line: data of users who deleted their account before 25 September 2016 had to be deleted from WhatsApp's servers and not shared with Facebook, and existing data up to that date could not be shared either. See the judgment on Indian Kanoon.

Why this matters for a DPA: the court restrained downstream sharing of personal data absent a clear, bounded consent basis, even outside a data-protection statute. A DPA's sub-processor and purpose-limitation clauses exist to make that boundary explicit up front.

Red flags

Normal	Red flag	Why it matters
Processor acts only on the fiduciary's documented instructions	Processor may use data for its "own legitimate business purposes," or clause is silent	Opens the door to the processor training models or reselling insights on data given only to service you
Sub-processor engagement needs the fiduciary's prior written consent	Processor is free to appoint any sub-processor without notice or consent	Every hop in the chain is a new place data can leak, with no visibility or recourse
Sub-processors bound, in writing, by the same obligations as the head DPA	DPA is silent on flow-down, or just says sub-processors must "comply with applicable law"	A vague flow-down clause is unenforceable; the sub-processor never actually agreed to your terms
Breach notice within a stated, short window (commonly 24-72 hours of the processor becoming aware)	No timeline stated, or notice "without undue delay" left undefined	The fiduciary's Section 8(6) clock to notify the Board starts running regardless; a vague processor notice eats into it
Explicit obligation to delete or return all personal data, including backups, with written confirmation	Deletion is "at the processor's discretion," or backups are carved out	Data that should be gone keeps sitting on a vendor's systems indefinitely
Fiduciary has a real audit right, on-site, via questionnaire, or a recognised certification (ISO 27001, SOC 2)	No audit right, or audit needs "processor's prior consent" every time	The audit clause becomes words on paper; the processor can decline whenever inconvenient
DPA terms scoped to the processing at hand, GDPR-style language layered on only where EU data is involved	Full GDPR Article 28 boilerplate on a purely domestic engagement, or the reverse	Mismatched terms over-promise what nobody can meet, or under-protect data a different law actually governs

Bad clause → better clause

Bad: "Processor shall process Personal Data in accordance with applicable data protection laws and shall take appropriate measures to protect such data."

What is wrong: no instruction-only limit, no sub-processor mechanism, no breach-notice deadline, no deletion obligation, no audit right, and "appropriate measures" is undefined.

Better: "Processor shall process Personal Data solely on the Fiduciary's documented written instructions and for no other purpose. Processor shall not engage any sub-processor without the Fiduciary's prior written consent, and shall impose obligations on any approved sub-processor no less protective than those in this Clause. Processor shall implement and maintain reasonable technical and organisational security safeguards, including [encryption at rest and in transit, access controls, and logging], and shall notify the Fiduciary in writing within 24 hours of becoming aware of any actual or suspected personal data breach, providing all information reasonably necessary for the Fiduciary to meet its obligations under Section 8(6) of the DPDP Act, 2023. On termination or expiry of this Agreement, Processor shall, at the Fiduciary's election, delete or return all Personal Data, including copies held by any sub-processor, and provide written confirmation of deletion within 30 days. Fiduciary may audit Processor's compliance with this Clause, on reasonable notice, no more than once per year absent a suspected breach."

What changed and why: processing is scoped to written instructions, sub-processing needs consent and flow-down, there is a concrete 24-hour breach-notice deadline tied to Section 8(6), deletion is a stated obligation with proof, and the audit right is real but frequency-limited, so it is neither a dead letter nor a constant burden.

How it interacts with related clauses

A DPA rarely stands alone in a contract:

• Data protection clause. The broader clause allocating fiduciary-versus-processor roles, consent, and cross-border transfer sits above the DPA; the DPA is where operational detail, instructions, security, breach notice, deletion, audit, gets written down.
• Indemnity. A breach caused by the processor should be a named trigger, so the fiduciary can recover a regulatory penalty or third-party claim from the processor, rather than absorbing the ₹250 crore or ₹200 crore exposure alone.
• Limitation of liability. Check whether data-breach liability sits inside the general cap or is carved out with a higher one. A processor capped at fees paid for a small tool is a poor match for the exposure a breach of customer data creates.
• Confidentiality. Confidentiality protects information generally; the DPA's confidentiality-of-personnel obligation is narrower, specific to who inside the processor may touch the data.

You can mark up a DPA schedule clause by clause, free, in Weave, flagging missing deadlines or sub-processor gaps before you send it back.

US and global contrast: GDPR Article 28

Where DPDP sets the requirement and leaves most mechanics to the parties, GDPR Article 28 writes the mechanics directly into the statute for any processing involving EU personal data. Article 28(1) requires controllers to use only processors "providing sufficient guarantees to implement appropriate technical and organisational measures." Article 28(3) then lists, as mandatory contract terms, that the processor:

"processes the personal data only on documented instructions from the controller"; "ensures that persons authorised to process the personal data have committed themselves to confidentiality"; "takes all measures required pursuant to Article 32" (security); "respects the conditions referred to in paragraphs 2 and 4 for engaging another processor"; assists with data-subject rights requests; "deletes or returns all the personal data to the controller after the end of the provision of services... and deletes existing copies"; and "makes available to the controller all information necessary to demonstrate compliance." Source: Article 28, GDPR

Article 28(2) is explicit on sub-processors in a way DPDP is not: "The processor shall not engage another processor without prior specific or general written authorisation of the controller." Under DPDP, sub-processor control exists only if the DPA puts it there, which is why sub-processor consent belongs on every red-flags checklist for an Indian DPA. The US has no single federal equivalent; state laws like the CPRA in California use their own term, "service provider," and impose a similar obligation, but only where that state's law applies. Do not import CPRA or GDPR language wholesale into a purely Indian engagement, and do not rely on DPDP-only terms where EU or California residents' data is involved.

FAQ

Is a DPA legally required for every vendor that touches personal data in India? Yes, in substance. Section 8(2) says a Data Fiduciary may engage a Data Processor "only under a valid contract." A separate document called a "DPA" is not mandated, the terms can sit inside a broader services agreement, but a valid contract covering the processing must exist before data flows.

Does the DPDP Act fix a breach-notification deadline from processor to fiduciary? Not in Section 8 itself. Section 8(6) sets the fiduciary's own duty to notify the Board and affected Data Principals "in such form and manner as may be prescribed," but the processor-to-fiduciary leg is left to the contract. A DPA without a short, stated deadline (commonly 24 to 72 hours) leaves the fiduciary unable to meet its own statutory clock.

Can I just use a standard GDPR Data Processing Addendum for an Indian-only contract? You can, but it usually adds obligations (fixed sub-processor mechanics, Article 32-style documentation, transfer assessments) Indian law does not require domestically, slowing negotiation for no benefit. Draft to DPDP first and layer GDPR terms in only where EU data principals are involved.

If my processor causes a data breach, does the penalty land on me or on them? On you, as a matter of regulatory liability. Section 8(1) makes the fiduciary responsible for processing done on its behalf "irrespective of any agreement to the contrary." Your DPA cannot change that with the Board, but a well-drafted indemnity clause lets you recover that cost from the processor afterward.

What should a DPA say about sub-processors? That the processor needs the fiduciary's prior written consent before engaging any sub-processor, and that the sub-processor is bound, in writing, by obligations at least as protective as the head DPA. DPDP does not impose this by default; GDPR Article 28(2) does. A silent DPA leaves the processor free to sub-process without telling you.

This guide gets you to understanding what a DPA needs to cover under Indian law and where GDPR asks for more. It does not tell you whether a specific DPA in front of you is adequate for your risk profile, that depends on facts specific to your engagement and is not legal advice. Talk to a lawyer before you sign or rely on a DPA in a live negotiation.