Skip to main content

The 3rd and main DPDP commencement date is computed as 13 May 2027, which is interpretation until officially confirmed.

Sources last verified on 23 September 2026. Methodology

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

Vendors

By · Primary sources verified by dpdprules.orgPublished · Last reviewed 7 min read

What clauses need to be included in a Data Processing Agreement (DPA) under the DPDP Act?

The short answer

Only a few points are official, and none of them binds anybody yet. Section 8(2) lets a Data Fiduciary engage a Data Processor for activity related to offering goods or services only under a valid contract, section 8(1) keeps the fiduciary responsible for processing done on its behalf irrespective of any agreement to the contrary, section 8(7)(b) requires the fiduciary to cause the processor to erase data, section 6(6) requires it to cause its processors to cease processing when consent is withdrawn, and Rule 6(1)(f) requires appropriate contract provisions for reasonable security safeguards. Everything else in a typical DPA, such as instruction limits, subprocessor approval, audit rights, indemnity, return of data and fixed notification windows, is sensible drafting that operationalises the fiduciary's own duties, not statutory text. No provision fixes a processor to fiduciary breach notification deadline; the 72 hour clock under Rule 7 is the fiduciary's own duty to the Board. Section 6, section 8 and Rules 6 and 7 all sit in 18 month commencement groups, G.S.R. 843(E) paragraph (c) for the sections and Rule 1(4) for the Rules, computed as 13 May 2027 and interpretation until officially confirmed, so no clause listed here is required of anybody today.

More answered questions →

Summary infographic headed 'DPA clauses under the DPDP Act: what the law requires vs good drafting'
On the required side the infographic states that the Data Fiduciary stays responsible even when a processor is used, that processor contracts should include appropriate security safeguard obligations, and that the contract should support the fiduciary's compliance and control. On the good drafting side it lists processing scope, instructions and confidentiality; sub processors, breach help, audit cooperation and deletion or return; and indemnities and liability allocation based on risk. It closes by stating that the Act prescribes no single template for every case. Status as at 25 September 2026: the duties described here are not in force yet; they sit in the 18 month commencement group, computed 13 May 2027 and interpretation until officially confirmed.

Search this question and you will find lists of 10 or 15 "mandatory DPA clauses under the DPDP Act", often including a duty for the processor to notify the fiduciary of a breach within 24 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. This article is the clause by clause view; for the prior question of whether you need a contract with your processor at all, see do you need a contract with your Data Processor.

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:

DPDP Act 2023, s. 8, (1) · General obligations of Data Fiduciary · verbatim

"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

4 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 2 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 72 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 1 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 1 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(3) names 90 days for grievances in a sentence printed with no object for "publish", so what the 90 days caps is not stated on its face; this site reads it as the response period you must publish, which is the treatment set out in the grievance redressal guide. Whichever period you publish, the processor is where your turnaround is won or lost, so 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 24 hour "requirement" circulating online has no basis in the official text. The only 72 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

ClauseBasis in the official textClaim type
Valid contract in placesection 8(2)Official requirement
Security safeguards provisionRule 6(1)(f)Official requirement
Erasure and cessation on instructionsections 8(7)(b) and 6(6)Official duties on the fiduciary; the clauses discharge them
Breach detection, notification and cooperationsection 8(6) and Rule 7Explanation; the notification window itself is your negotiated term
1 year retention of data and logsRule 8(3)Explanation of an official duty that reaches processing done on your behalf
Accuracy and correction supportsection 8(3)Explanation
Rights and grievance supportsections 11 to 13, and Rule 14(3), which names 90 days without stating what they capExplanation of official rights duties; the 90 day reading is this site's interpretation
Instruction limits, subprocessor approval, audit rights, indemnity, return of data, a fixed notification window, cross border cooperationnone in the official textRecommendation

Timing and next steps

Section 8 sits in the 18 month commencement group of notification G.S.R. 843(E) paragraph (c), and Rules 6, 7, 8, 14 and 15 in the 18 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.

Processor contract checklist template →Section 8, official text →DPDP processor contracts: what must be in them →DPDP for legal and privacy counsel →

ContractsData ProcessorVendorsDPA

Share this: