DPA clauses under the DPDP Act: what the law requires versus good drafting

Search this question and you will find lists of ten or fifteen "mandatory DPA clauses under the DPDP Act", often including a duty for the processor to notify the fiduciary of a breach within twenty four hours. Read the Act and the Rules and you will not find that list. The official text says remarkably little about contract content and nothing at all about a processor notification deadline. Here are the honest layers: what the law requires in terms, what your own duties force into the contract in practice, and what is simply good drafting.

Start with what a Data Processor is

Section 2(k) defines a Data Processor as "any person who processes personal data on behalf of a Data Fiduciary". The Act then addresses its obligations to the Data Fiduciary, and section 8(1) routes everything the processor does back to you:

"A Data 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."

Responsibility never transfers. That sentence is why the contract matters: the framework imposes almost nothing on the processor directly, so the contract is the legal mechanism through which your duties reach the vendor.

The three layers of a DPDP Data Processing Agreement: the official anchors are section 8(2) requiring a valid contract, section 8(1) keeping the fiduciary responsible, section 8(7)(b) requiring the power to make the processor erase, section 6(6) requiring cessation on consent withdrawal, and Rule 6(1)(f) requiring security safeguard provisions in the contract; a second layer of clauses is implied by the fiduciary's own duties such as the Rule 7 breach clocks; the third layer, including audit rights, subprocessor approval and indemnity, is recommended drafting the statute never prescribes.

What the official text actually requires

Four points, and only four, are explicit.

1. A valid contract must exist. Section 8(2): "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." No valid contract, no lawful engagement. The Act does not define validity beyond ordinary contract law and prescribes no clause list.

2. The contract must provide for security safeguards. Rule 6(1) lists the minimum reasonable security safeguards, and item (f) is "appropriate provision in the contract entered into between such Data Fiduciary and such a Data Processor, wherever applicable, for taking reasonable security safeguards". This is the one place in the framework where the official text prescribes content for the fiduciary to processor contract.

3. You must be able to make the processor erase. Section 8(7)(b) requires you, unless retention is necessary for compliance with law, to cause your Data Processor to erase any personal data you made available to it. The duty sits on you, not the processor; an erasure on instruction clause is how you discharge it.

4. You must be able to make the processor stop when consent is withdrawn. Section 6(6) requires you, within a reasonable time of a Data Principal withdrawing consent, to cease and cause your Data Processors to cease processing her personal data, unless processing without consent is required or authorised under the Act, the rules or another law. Again the duty sits on you; a cease processing on instruction clause discharges it.

That is the complete set of official anchors. Everything else in a standard DPA is either an operational consequence of your own duties or negotiated protection.

What your own duties push into the contract

These clauses are not named in the statute, but without them you cannot meet duties that are. Their legal basis is your obligation; the clause is the mechanism. We label them explanation, not official requirement.

Breach support. Rule 7 starts two clocks the moment you become aware of a breach: intimation to each affected Data Principal and to the Board without delay, and detailed information to the Board within seventy two hours of awareness, unless the Board allows longer on a written request. Both duties are yours under section 8(6) and Rule 7. If a breach happens inside a processor's systems and the processor has no contractual duty to detect it, tell you fast and hand over the facts Rule 7(2)(b) demands, you will miss clocks you cannot lawfully miss.

Security in practice. Section 8(5) requires you to protect personal data "including in respect of any processing undertaken by it or on its behalf by a Data Processor". Rule 6's minimum measures, techniques of the encryption or masking class, access control, logs and backups, therefore have to be real at the processor, and Rule 6(1)(f) makes the contract carry them.

Log and data retention. Rule 8(3) requires retention of personal data, associated traffic data and logs of processing for a minimum of one year, and expressly covers processing done on your behalf; its own illustration has a company ensuring its cloud service provider retains the data and logs. A retention clause matching the one year floor is the practical reading.

Accuracy support. Where data held at the processor feeds decisions affecting a Data Principal or is disclosed to another Data Fiduciary, section 8(3) makes you ensure its completeness, accuracy and consistency, so the contract should oblige the processor to correct data on your instruction.

Rights and grievance support. Rights requests land on you, and Rule 14 caps your published grievance response period at ninety days. Where the processor holds the data, contract for retrieval, correction and erasure turnarounds that leave you room inside your own window.

Prudent drafting the statute never asks for

The following are recommendations. They appear in most competent DPAs and the processor contract checklist template includes them all, but no provision of the Act or the Rules prescribes them; articles presenting them as legal requirements are dressing drafting advice as law.

• Processing only on documented instructions. The framework nowhere obliges a processor to act only on the fiduciary's instructions; the discipline follows sensibly from your retained responsibility, but it is a negotiated term.
• Subprocessor approval. The Act is silent on subprocessing. Approval rights and flow down obligations are protection you draft in.
• Audit and inspection rights. Nothing in the framework grants or requires them.
• A fixed processor notification deadline. Neither the Act nor the Rules fixes any deadline for a processor to tell its fiduciary about a breach; the twenty four hour "requirement" circulating online has no basis in the official text. The only seventy two hour clock in the framework is Rule 7(2)(b), your deadline to the Board. Fix a short contractual window, in hours rather than business days, precisely because the statute will not do it for you.
• Return of data on exit. Section 8(7)(b) speaks of erasure, not return. If you want your data back in a usable format when the engagement ends, write it in.
• Indemnity and liability allocation. Because section 8(1) applies "irrespective of any agreement to the contrary", an indemnity cannot move the compliance duty off you; it can only move money afterwards. Draft it, and understand what it does.
• Cross border cooperation. Rule 15's condition on transfers outside India, meeting any Central Government requirements on making personal data available to a foreign State, sits on you; obliging an offshore processor to cooperate with such requirements is sensible drafting.

The clause list, mapped

• Valid contract in place. Basis: section 8(2). Official requirement.
• Security safeguards provision. Basis: Rule 6(1)(f). Official requirement.
• Erasure and cessation on instruction. Basis: sections 8(7)(b) and 6(6). Official duties on the fiduciary; the clauses discharge them.
• Breach detection, notification and cooperation. Basis: section 8(6) and Rule 7. Explanation; the notification window itself is your negotiated term.
• One year retention of data and logs. Basis: Rule 8(3). Explanation of an official duty that reaches processing done on your behalf.
• Accuracy and correction support. Basis: section 8(3). Explanation.
• Rights and grievance support. Basis: Rule 14's ninety day ceiling. Explanation.
• Instruction limits, subprocessor approval, audit rights, indemnity, return of data, a fixed notification window, cross border cooperation. Basis: none in the official text. Recommendation.

Timing and next steps

Section 8 sits in the eighteen month commencement group of notification G.S.R. 843(E) paragraph (c), and Rules 6, 7, 8, 14 and 15 in the eighteen month group of Rule 1(4), both computed to 13 May 2027, interpretation until officially confirmed. That is the window in which to paper, or repaper, every processor engagement. Run each vendor through the vendor and processor checklist, fold the results into a tracked plan with the company compliance plan tool, and read the official text at Section 8. For a shorter treatment of the statutory anchors, see what must be in processor contracts.