The DPDP data processing agreement: fiduciary or processor, and the contract you need

A DPDP data processing agreement must commit the processor to reasonable security safeguards, the one term the Rules name (Rule 6(1)(f)). To let you meet your own duties, it should also cover processing only on your instructions, breach notice in time for your Rule 7 reports, stopping after a withdrawal (s. 6(6)), erasure on instruction and at the end (s. 8(7)(b)), a year of personal data, traffic data and logs (Rule 8(3)), sub-processors, help with rights requests and transfers abroad. You need one because section 8(2) lets a fiduciary, the party that decides the purpose and means of processing (s. 2(i)), use a processor for activities related to offering goods or services "only under a valid contract". The contract never moves your duty: you stay responsible for your processors "irrespective of any agreement to the contrary" (s. 8(1)). These duties start on 13 May 2027.

Like the Act (s. 2(y)), we say "she" and "her" for every person.

Jump to what you need:

• Legal and procurement: What the DPA must cover, The illustrative addendum, Pushback and positions.
• DPOs: The role test, Joint fiduciaries, Data-sharing agreements, Where the law is unclear.
• NGOs and CSR foundations: Partners, funders and government.
• SaaS vendors on the other side of the table: DPDP for SaaS startups.

The role test: who decides the purpose

A fiduciary "alone or in conjunction with other persons determines the purpose and means of processing" (s. 2(i)). A processor "processes personal data on behalf of a Data Fiduciary" (s. 2(k)). The Act gives no further test, so the questions below are ours. Ask them per purpose, because one company can hold both roles.

1. Who decided this data should be collected at all? That party is likely a fiduciary.
2. Who decides what it is used for? If the vendor can use it for anything other than your instructions, it is a fiduciary for that use.
3. Who chose which fields to collect, and from whom? Deciding the data set is deciding means.
4. Whose relationship with the person is it? The person usually knows the fiduciary's name.
5. Does the party apply its own professional judgement or legal duty to the data? Doctors, insurers, banks, auditors and lawyers usually do, which in our view makes them fiduciaries for that processing.
6. Could the party keep the data after the contract ends and still use it? If yes, it is acting for itself.

Choosing technical means, such as which cloud region or database to use, does not by itself make a vendor a fiduciary. Our view, drawn from how the same distinction has been applied under GDPR, is that a processor may decide such practical details while the fiduciary decides the essential means: what data, about whom, for how long, shared with whom.

Joint fiduciaries: two deciders, one person

The definition covers deciding purpose and means "in conjunction with other persons" (s. 2(i)), so two organisations can both be fiduciaries for the same processing. Unlike GDPR, the Act has no clause on how joint fiduciaries split their duties. Each carries all of its own duties in full, and a penalty can fall on either. The agreement between them decides who does each task, so that nothing falls between them.

The Act has no group exemption, so group companies that run shared purposes on one system may be joint fiduciaries, or one may process for the others, depending on who decides; see DPDP for large companies.

Why the contract cannot move your liability

Section 8(1) keeps the duty with the fiduciary for processing "undertaken by it or on its behalf by a Data Processor", and section 8(5) makes your security duty cover your processors' processing. Both bind the fiduciary; neither puts a duty on the processor as such. A contract therefore decides who pays whose losses and who does which task. It cannot decide who answers to the Board.

Section 8(2) sets the gate: a processor may be engaged for "any activity related to offering of goods or services to Data Principals" only under a valid contract. The Act does not define "valid". Our reading is that it means a contract enforceable under ordinary contract law (Indian Contract Act, 1872, s. 10) whose terms let the fiduciary meet its duties. Processing outside those words, such as payroll for your own staff, may not strictly need one; we recommend a contract for every processor, because sections 8(5) and 8(7)(b) reach all of them and Rule 6(1)(f) asks for security terms "wherever applicable".

The processor's own exposure is narrower. It rarely faces the Board directly for a customer's data, though the residual penalty item covers breach of "any other provision" of the Act or Rules (Schedule, item 7). It is fully exposed for any purpose it decides itself, and it may have its own CERT-In reporting duty. The Act guide sets out the fiduciary duties in full.

What a DPDP DPA must cover, and why

The third column shows whether the Rules name a term or you need it to meet a fiduciary duty.

An illustrative data processing addendum

This addendum is illustrative, written for a fiduciary engaging a processor under Indian law, to adapt with your lawyer. Figures in square brackets are our recommendations; the law sets none of them for processors.

1. Definitions. "In this Addendum, 'Act' means the Digital Personal Data Protection Act, 2023 and 'Rules' means the Digital Personal Data Protection Rules, 2025, each as amended. 'Customer Personal Data' means personal data, as defined in section 2(t) of the Act, that Supplier processes on Customer's behalf under the Agreement. 'Personal data breach' has the meaning in section 2(u) of the Act. 'Processing', 'Data Fiduciary', 'Data Processor' and 'Data Principal' have the meanings in section 2 of the Act. 'Sub-processor' means any person Supplier engages to process Customer Personal Data."

2. Roles and instructions. "Customer is the Data Fiduciary and Supplier is a Data Processor for the processing described in Annex 1. Supplier processes Customer Personal Data only on Customer's documented instructions and only for the purposes in Annex 1. If Supplier believes an instruction breaches the Act or another law, it will tell Customer promptly and may suspend that processing until the instruction is confirmed or changed."

3. No own purposes. "Supplier will not use Customer Personal Data for its own purposes, including product analytics, benchmarking, marketing, or training or fine-tuning any model used for anyone other than Customer, unless Customer agrees in writing. Data aggregated so that no individual is identifiable by or in relation to it is not Customer Personal Data."

4. Security. "Supplier will maintain the measures in Annex 2, consistent with rule 6(1) of the Rules, and will not materially reduce them."

5. Personnel. "Supplier will ensure that every person it authorises to process Customer Personal Data is bound by confidentiality, trained on these obligations, and given only the access her role needs, removed promptly when no longer needed."

6. Breach notice. "Supplier will notify Customer's designated contacts by phone and email within [24] hours of becoming aware of any personal data breach affecting Customer Personal Data, and within [6] hours where the incident may be reportable to CERT-In. The notice will describe, as far as known, the nature, extent, timing and location of the breach and its likely impact. Supplier will provide updates every [12] hours and, within [48] hours, the information Customer needs for its detailed report under rule 7(2)(b) of the Rules: the facts and causes, mitigation, any findings about who caused the breach, and steps to prevent recurrence. Supplier will not notify Data Principals, the Data Protection Board or the public about Customer Personal Data without Customer's agreement, unless the law requires it."

7. Withdrawal of consent. "When Customer tells Supplier, or records through the agreed interface, that a Data Principal has withdrawn consent for a purpose, Supplier will stop processing her personal data for that purpose within [24] hours and confirm, and will cause its Sub-processors to do the same within [48] hours."

8. Rights and accuracy. "Supplier will help Customer respond to requests from Data Principals for access, correction, completion, updating and erasure, and to grievances, within [5] working days of Customer's request. Supplier will apply corrections Customer instructs across all copies it holds, and will pass to Customer within [2] working days any request it receives directly."

9. Sub-processors. "Annex 3 lists each Sub-processor, the Customer Personal Data it receives, its purpose and location. Supplier will give Customer [30] days' notice of a new or replacement Sub-processor. If Customer objects on reasonable data-protection grounds and the parties cannot agree, Customer may terminate the affected service without penalty. Supplier will impose terms on each Sub-processor at least as protective as this Addendum and remains responsible to Customer for each Sub-processor's performance."

10. Locations and transfers. "Supplier will store and allow access to Customer Personal Data only in the locations in Annex 4, will give [60] days' notice before changing them, and will comply with any restriction notified under section 16 of the Act, any requirement specified under rule 15 of the Rules, and the sector rules in Annex 4."

11. Logs and retention. "Supplier will keep the personal data, associated traffic data and logs of its processing of Customer Personal Data for one year from the processing, in a restricted store, for the purposes in rule 6(1)(e) and rule 8(3) of the Rules, and will then erase them unless the data is still needed for the purposes in Annex 1 or a law requires longer retention."

12. Return and erasure. "On Customer's instruction, and within [30] days after the end of the services, Supplier will return Customer Personal Data in [format] and erase it from its and its Sub-processors' systems, and will provide a written certificate of erasure. Backups will expire within [35] days and will not be restored into live use. This clause does not require erasure of what clause 11 or a law requires Supplier to keep, which Supplier will keep restricted and erase when that period ends."

13. Children. "Where Customer Personal Data includes data of children, Supplier will not process it in any way likely to cause a detrimental effect on a child's well-being. Supplier will not use it for tracking, behavioural monitoring or targeted advertising, except tracking or monitoring Customer instructs within an exemption under rule 12 of the Rules."

14. Evidence and audit. "Each year, and on reasonable request after a personal data breach, Supplier will provide its current security certifications or independent audit reports, and answers to Customer's reasonable written questions. Where these do not answer a specific, documented concern, or where a regulator requires it, Customer or its auditor may audit Supplier on [30] days' notice, during business hours, no more than once a year except after a breach."

15. Authorities. "Supplier will tell Customer promptly of any request from a government authority or the Data Protection Board for Customer Personal Data, unless the law prohibits it, and will disclose only what is legally required, recording each disclosure so that Customer can apply section 11(2) of the Act. Supplier will help Customer respond to any inquiry by the Board and any call for information under section 36 of the Act and rule 23 of the Rules."

16. Cost of assistance. "Assistance under clauses 7, 8, 14 and 15 is included in the fees up to [number] requests or [hours] a month; above that, Supplier may charge at the rates in [schedule], but will not delay assistance pending agreement on charges."

17. Customer's responsibilities and liability. "Customer is responsible for its decisions as Data Fiduciary, including the purposes of processing, the notices given, the basis relied on and the lawfulness of its instructions. Customer will indemnify Supplier against third-party claims and penalties to the extent they result from Supplier following Customer's documented instructions. Supplier's liability for breach of this Addendum is subject to the data-protection cap in [clause] of the Agreement." Drafting note: an indemnity for regulatory penalties may be unenforceable; take advice.

18. Precedence and survival. "On matters concerning Customer Personal Data, this Addendum prevails over any conflicting term of the Agreement. Clauses 6, 8, 11, 12, 15 and 17 survive termination for as long as Supplier or any Sub-processor holds Customer Personal Data."

19. Commencement. "Clauses referring to the Act and Rules apply from the date the relevant provisions come into force. Until then, Supplier will comply with the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 as they apply to the processing."

Annex 1: Processing description (example).

Annex 2: Security measures.

Annex 3: Sub-processors.

Annex 4: Locations and sector rules. Storage: [region]. Remote access: [countries]. Sector rules: for payment data, the RBI requirement that payment system data be stored only in India (circular DPSS.CO.OD No.2785/06.08.005/2017-18, 6 April 2018, as of 25 October 2026); otherwise none.

On liability caps from the processor's side of the table, see DPDP for SaaS startups.

What processors push back on, and where to settle

These are our recommendations for a fiduciary negotiating with a mid-sized vendor. A hyperscale cloud provider will not negotiate; read its standard terms against the table above and record the gaps.

A data-sharing agreement for independent fiduciaries

When you disclose personal data to another fiduciary that decides its own purposes, such as an insurer, a bank, a funder receiving named lists for its own monitoring, or a research partner, a DPA is the wrong instrument. An outline of what we would put in a data-sharing agreement instead:

1. Parties and roles: each is a separate Data Fiduciary for its own processing (s. 2(i)).
2. Purpose and data: the specific purpose of the disclosure and the itemised data, kept to what that purpose needs.
3. Basis: each party's basis for its side: consent covering the disclosure, or a named clause of section 7.
4. Notice: who told the person about the disclosure and where the notice text is.
5. Accuracy: the disclosing party keeps shared data complete, accurate and consistent (s. 8(3)(b)) and sends corrections.
6. Onward sharing: none beyond the recipient's processors without agreement.
7. Security: minimum safeguards each keeps (s. 8(5), Rule 6).
8. Breach cooperation: prompt notice to the other party and the facts each needs for its own Rule 7 reports.
9. Rights and grievances: forwarding within a set time, and each party's section 11(1)(b) listing of the other.
10. Retention and erasure: each party's periods; what happens when consent is withdrawn.
11. Transfers and term: locations, termination and return or erasure.

NGO partners, funders and government departments

NGO arrangements rarely fit the vendor model neatly.

• A large NGO and the local partners it sub-grants. If the local partner collects data on the large NGO's forms and app for the large NGO's programme, it is a processor. A one-page annex to the sub-grant agreement is enough (below).
• A CSR foundation and an implementing NGO. If the foundation co-designs the programme and receives named lists, both are fiduciaries and need a joint-fiduciary agreement. The CSR foundations guide covers roles and asking for less data.
• A government department and an NGO delivering a scheme. The department is the fiduciary and the NGO is usually its processor. Section 7(b) is the State's ground; the NGO does not rely on it in its own right. Put purpose, sharing, security, retention and breach notice in the MoU.
• Volunteers and community workers collecting for you. They act on your behalf, so you answer for them (s. 8(1)). A short written undertaking does the job of a contract.

An illustrative one-page sub-grant data annex:

1. Roles. [Lead NGO] is the Data Fiduciary for the programme data. [Partner] collects and handles it only for the programme and only as [Lead NGO] instructs.
2. What is collected. Only the fields on the programme forms in [app]; no other copies.
3. Notice and consent. [Partner] uses the notice and consent script [Lead NGO] provides, in the languages listed, and records each consent in the app.
4. Devices and WhatsApp. No beneficiary data on personal phones outside the app; no photos of forms, ID cards or registers on WhatsApp; screen locks on all devices.
5. Access. Only named staff; [Partner] removes access the day someone leaves.
6. Incidents. [Partner] phones [Lead NGO]'s contact within [6] hours of noticing any loss, wrong disclosure or misuse, and follows its instructions.
7. Requests. [Partner] passes any request or complaint from a beneficiary to [Lead NGO] within [2] working days.
8. Sharing. No sharing with anyone else, including funders or government, without [Lead NGO]'s written agreement.
9. End of grant. Within [30] days, [Partner] hands over or erases all programme data and confirms in writing.

Sub-processors and long chains

The Act does not mention sub-processors. Our reading is that a sub-processor also processes "on behalf of" the fiduciary, so the fiduciary's responsibility (s. 8(1)) and security duty (s. 8(5)) reach it. In practice, you can tell a person who received her data (s. 11(1)(b)) only if each processor tells you its sub-processors; our position on listing them in access answers is in the data mapping guide. Your instructions to stop and to erase (s. 6(6), s. 8(7)(b)) have to travel down the chain, with confirmation coming back. The 72 hours for your detailed report run from the fiduciary becoming aware (Rule 7(2)(b)); whether your processor's awareness counts is unsettled (see below).

Indian processors serving clients abroad

Where a person based in India processes data of people outside India under a contract with a person outside India, Chapter II except sections 8(1) and 8(5), Chapter III and section 16 do not apply (s. 17(1)(d)). That switches off notice, consent, breach notice (s. 8(6)), retention and rights for that data, but leaves responsibility for processors and security. Keep such data logically separate from data of people in India, which the Act covers in full.

Where the law is unclear on roles and contracts

We would rather show our working than leave these blank; each position may move with the first Board orders.

Does section 8(2) cover processing that is not for offering goods or services? Sign a contract anyway. Why: the subsection is limited to "any activity related to offering of goods or services to Data Principals", which may not include payroll for your own staff or internal IT. But Rule 6(1)(f) asks for contract terms "wherever applicable", and your duties for processors' security and erasure apply regardless (s. 8(5), s. 8(7)(b)). Would change if: the Board reads "goods or services" broadly. Confidence: high that you need one in practice.

Does a processor's knowledge of a breach start the fiduciary's 72 hours? Plan as if it does. Why: Rule 7(2)(b) runs from the fiduciary "becoming aware", and the fiduciary answers for processing on its behalf (s. 8(1)). Would change if: the Board says the clock starts only when the fiduciary is told. Confidence: medium.

Do joint fiduciaries share liability for each other's failures? Each answers for its own duties; the Act has no joint-liability clause. Why: the duties in section 8 attach to "a Data Fiduciary", and penalties to the person in breach (s. 33(1)). Would change if: the Board treats a joint arrangement as one fiduciary. Confidence: medium.

Can a processor keep data after the contract for its own legal needs? Only what a law requires it to keep, and only for that purpose. Why: section 8(7) allows retention "necessary for compliance with any law", and Rule 8(3) requires a year of personal data, traffic data and logs for processing done on the fiduciary's behalf. Would change if: guidance treats processor-held logs differently. Confidence: medium.

Is a Consent Manager a processor? No. Why: it is registered with the Board, accountable to the person and acts on her behalf (s. 6(8)–(9)), in a fiduciary capacity towards her (First Schedule Part B, item 8). It keeps its own record of consents, notices and sharing (item 3), for which it is plausibly a fiduciary, and it may not subcontract its obligations (item 6). Registration under Rule 4 opens on 13 November 2026; none is registered as of 25 October 2026. See Consent Managers. Would change if: the Board's onboarding terms say otherwise. Confidence: medium.

Re-papering your vendors before May 2027

Contracts signed now will still be running when the duties start, so draft DPDP terms to apply from 13 May 2027 (clause 19).

1. List them. Pull every vendor that touches personal data from the payments ledger and your data map.
2. Decide each role with the six questions above, per purpose, and record the reason.
3. Tier them. Tier 1: hosting, core platforms, call centres, payroll, anyone holding children's, health or financial data. Tier 2: marketing, survey and logistics tools. Tier 3: low-volume tools.
4. Send Tier 1 your addendum by December 2026. In our estimate, allow four to eight weeks for negotiation.
5. Use renewal riders for Tiers 2 and 3, and standard-terms reviews for vendors that will not negotiate.
6. Sign joint-fiduciary and data-sharing agreements with funders, partners and group companies.
7. Test the clauses. Ask two Tier 1 vendors to join a breach drill and to process a test withdrawal and erasure end to end before April 2027.
8. Keep the evidence: signed addenda, sub-processor lists, audit reports and drill notes, filed against each vendor.

How we wrote this guide. We worked from the Digital Personal Data Protection Act, 2023, the Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), as corrected by G.S.R. 892(E)), the commencement notification G.S.R. 843(E), the SPDI Rules, 2011, the Indian Contract Act, 1872, the Information Technology Act, 2000 and the RBI circular on storage of payment system data, last checked 25 October 2026. The role questions, addendum, annexes, time periods and negotiating positions are our recommendations, not requirements of the law. The clauses are illustrative and must be adapted to your contract. This guide explains the law; it is not legal advice.