· Last updated: October 15, 2026
The DPDP Act lets a Data Fiduciary engage a Data Processor only under a valid contract (Section 8(2)). It does not prescribe the contract's content, and it keeps you responsible for what your processor does (Section 8(1)). The 2025 Rules add security, breach, retention and transfer obligations that your contracts should support. Sharing with another fiduciary has no specific contract requirement, but you should still document purpose and responsibilities. Most obligations, including the processor-contract rule, apply from around May 2027, so put agreements in place now.
If you share personal data with a vendor, partner or group company and India's Digital Personal Data Protection (DPDP) Act applies to you, you need to know when the law demands a DPDP agreement and what it should say. This guide separates what the law requires from what is good practice, and gives you a clause checklist.
Where the law stands (October 2026)
| Date | What happens |
|---|---|
| Nov 13-14, 2025 | DPDP Rules, 2025 notified on Nov 13 and published on Nov 14. The Data Protection Board provisions took effect immediately. |
| Nov 13, 2026 | Consent-manager framework begins (Section 6(9), Rule 4). |
| About May 13, 2027 | Most of the Act and Rules begin: Sections 3 to 5, 6(1) to 6(8), 6(10), 7, 8 and 9 to 17, the penalty provisions, and Rules 3 and 5 to 16. The Gazette and the government's own backgrounder differ by a day on the publication date, so some sources say May 14. |
The processor-contract rule in Section 8(2) is therefore not in force yet. It starts with the rest of Section 8 at the 18-month mark. That list of commenced sections comes from law-firm summaries of the commencement notification, which we did not read directly. Sign agreements before May 2027 anyway: renegotiating a vendor contract takes longer than most teams expect.
Two caveats on dates. First, the government has reportedly considered shortening some timelines, but nothing has been notified, so re-check the Gazette before relying on a date. Second, the Data Protection Board is established in law, but the latest reports we found (August 2026) said no Chairperson or Members had been appointed. Consent managers must register with the Board, so check that it is operating before you plan around the November 2026 milestone.
What is a data sharing agreement?
A data sharing agreement is a written contract that sets out why, how and on what conditions one party gives personal data to another: the purpose, the data involved, security, how long it's kept, what happens when the arrangement ends, and who is responsible if something goes wrong. In India it's used both for vendor arrangements and for sharing between businesses. The DPDP Act doesn't define the term, but it does require a valid contract when you share data with a processor working on your behalf.
Data sharing agreement, data processing agreement, NDA, MOU: what's the difference?
- Data sharing agreement (DSA): an everyday term for a contract that sets the terms on which data moves between parties. It is not a defined term in the DPDP Act.
- Data processing agreement (DPA): a contract between a Data Fiduciary and a Data Processor acting on its behalf. This is the contract Section 8(2) refers to.
- NDA: covers confidentiality of information generally. It doesn't address purpose, security, retention or deletion of personal data, so it is not a substitute for a DPA.
- MOU: a framework for a relationship, often with government bodies. It may carry data terms, but for personal data you still want enforceable processing terms.
Do you legally need a contract?
| Situation | Contract required by the Act? | What to do |
|---|---|---|
| You engage a vendor to process data for you (cloud hosting, analytics, SaaS tools, outsourced support) | Yes: a valid contract under Section 8(2), from about May 2027 | Sign a DPA covering the points below |
| You share data with another business that decides its own purposes (a partner, an independent recipient) | No specific contract requirement. Section 8(3) still requires you to make sure data likely to go to another fiduciary is complete, accurate and consistent | Document purpose, lawful basis and each side's role; a contract is strongly advisable |
| Sharing between companies in the same group | No specific exemption | Treat as sharing or processing depending on roles; document it |
| Sharing during due diligence for an acquisition | The Act exempts processing needed for a court- or tribunal-approved merger, demerger or transfer of an undertaking (Section 17(1)(e)). It does not cover pre-signing diligence | Limit data, use confidentiality terms, check your lawful ground |
| Transfer to a vendor outside India | Same Section 8(2) rule if the recipient is a processor, plus the transfer rules below | DPA plus transfer clauses |
The Act ties the contract requirement to processing "for any activity related to offering of goods or services to Data Principals". Employment-related processing, such as payroll, may rest on a different ground (Section 7(i)), so ask your lawyer how to treat HR vendors. In practice most businesses will use one standard DPA for all processors.
Whatever the contract says, you stay responsible. Section 8(1) makes the Data Fiduciary responsible for processing done on its behalf, irrespective of any agreement to the contrary. A DPA gives you contractual remedies and controls, not a way to hand off the legal liability.
What the Act and Rules say your agreement should support
The Act doesn't list clauses, but its obligations on you flow down into the contract. Rule numbers follow the text of the DPDP Rules, 2025 (G.S.R. 846(E)).
- Security safeguards (Section 8(5), Rule 6). You must protect personal data, including data held by processors. The Rules list measures at the minimum: encryption, masking or obfuscation, access controls, monitoring and logging, and backups. Rule 6(1)(e) also refers to keeping logs and data for one year unless another law requires otherwise, and Rule 6(1)(f) calls for appropriate provision in your contracts for these safeguards. Your DPA should require the processor to meet them.
- Breach notification (Section 8(6), Rule 7). You must report breaches to the Data Protection Board and affected people. People are told without delay. The Board gets an intimation without delay, followed by a detailed report within 72 hours. Your processor needs to tell you fast enough for you to meet that clock.
- Retention and erasure (Section 8(7), Rule 8). The Act requires you to erase personal data when consent is withdrawn or the purpose is no longer served, and to make your processors erase it too (Section 8(7)). Rule 8(1) and (2) add fixed retention periods for large e-commerce, online gaming and social media platforms (Third Schedule, with 48 hours' notice before erasure). Rule 8(3) requires keeping certain data and logs for at least one year, including data processed by processors.
- Data principal rights. Processors need to help you respond to access, correction, erasure and grievance requests. See our guide to the DPDP Act and data principal rights.
- Consent and lawful use. The Act allows processing on consent or for specified legitimate uses (Section 7). Consent must be free, specific, informed, unconditional and unambiguous, and given by a clear affirmative action (Section 6). Your agreement should record which basis you're relying on and who is responsible for collecting and recording it. For consent on websites, see DPDPA cookie consent requirements.
Cross-border transfers
India's Act uses a negative-list model, not the GDPR's adequacy approach. Section 16 allows transfers outside India unless the Central Government restricts a specific country by notification. Rule 15 adds a separate condition: you must meet any requirements the government specifies about making personal data available to a foreign state or an entity under its control. Both are expected to take effect around May 13, 2027, and we found no restricted-country list notified as of mid-October 2026.
Three cautions:
- Stricter sector rules still apply. Section 16(2) preserves existing laws with higher protection or localization requirements, such as those from the Reserve Bank of India for payment data. Check your sector regulator.
- Significant Data Fiduciaries can face localization. Rule 13(4) lets the government, on a committee's recommendation, require a notified Significant Data Fiduciary to keep specified personal data and its traffic data in India. We found no such specification yet.
- There is no general rule that sensitive data must stay in India. Don't copy localization clauses from older guides unless a sector rule or an SDF specification requires them.
Practical clause: say that the processor will follow any restriction or condition notified under Section 16 or Rule 15 and tell you about foreign-authority access requests.
Clause checklist for a DPDP data processing agreement in India
Use this as a starting point and have an Indian-qualified lawyer review it. Items marked (recommended) are good practice, not statutory text.
- Parties and roles. Identify the Data Fiduciary and the Data Processor, and state that the processor acts only on the fiduciary's documented instructions.
- Purpose, data and duration. List the purposes, categories of personal data, categories of Data Principals, and term.
- Lawful basis and consent. State the basis relied on and who collects and records consent. If you use a registered consent manager, say how its signals are handled.
- Security safeguards. Require the technical and organizational measures from Rule 6 (encryption or masking, access control, logging, monitoring, backups) and log retention.
- Breach notification. Require notice to you within a fixed number of hours of the processor becoming aware (set the window your processors can realistically meet), with the details you need to report to the Board and to affected people. Keep it short enough that you can meet the 72-hour report.
- Data principal requests. The processor forwards requests promptly and helps you respond within the deadlines.
- Sub-processors. Require prior written approval and flow-down of the same obligations. (Recommended: the Rules refer to contract provisions for security safeguards but do not mention sub-processors.)
- Retention and deletion. Delete or return data at the end of the contract or on instruction, certify deletion, and keep any logs the Rules require.
- Cross-border transfers. Name permitted locations, and require compliance with any Section 16 or Rule 15 restriction and prompt notice of government access requests.
- Audit and assurance. Provide for information requests, audits or attestations. (Recommended.)
- Confidentiality. Bind the processor's personnel.
- Liability and indemnity. Allocate responsibility for processor-caused breaches. Remember this doesn't remove your statutory responsibility.
- Termination and governing law. Set termination rights for breach, and specify governing law and dispute resolution.
Working with an Indian lawyer
Many businesses will want an Indian-qualified lawyer to draft or review the agreement, especially for cross-border vendors and sector-regulated data. You'll get more from the engagement, and spend less, if you bring:
- Your vendor and partner list, with what data each receives and why.
- Your classification of each one (processor, independent fiduciary or joint).
- Any sector regulator that applies to you (banking, insurance, securities, telecom, health).
- Your existing contracts and any template you use today.
- The clause checklist above, marked with what you need and what you already have.
Penalties
The Act sets maximum penalties in a Schedule, enforced by the Data Protection Board. The caps are "may extend to" amounts:
- Failing to take reasonable security safeguards (Section 8(5)): up to ₹250 crore.
- Failing to give notice of a personal data breach (Section 8(6)): up to ₹200 crore.
- Breaching obligations for children's data: up to ₹200 crore.
- Breaching Significant Data Fiduciary obligations: up to ₹150 crore.
- Other breaches: up to ₹50 crore.
Because you remain responsible for processor failures, a weak vendor agreement is a compliance risk, not just a contract risk.
Common mistakes
- Copying a GDPR processor agreement unchanged. Article 28 terms are a useful structure, but the DPDP terms and regulator differ ("Data Protection Board", not "supervisory authority").
- Treating an NDA as a data processing agreement.
- Assuming the contract moves liability to the processor.
- Adding a blanket data-localization clause that the Act doesn't require.
- Leaving old vendor contracts unchanged until May 2027.
- Not planning for sub-processors and overseas vendors.
Action plan before May 2027
▢ List every vendor and partner that receives personal data of people in India.
▢ Classify each as processor, independent fiduciary or joint role.
▢ Sign or update a DPA with every processor.
▢ Add breach-notification timing that lets you meet the 72-hour report.
▢ Check cross-border transfers and any sector-specific localization rules.
▢ Decide whether you'll use a registered consent manager (the framework starts Nov 13, 2026, once the Board is operating).
▢ Build vendor contract checks into onboarding. Our DPDP Act Phase 1 compliance guide covers the wider vendor and data principal obligations.
Other Indian laws that may apply
The DPDP Act is new and works alongside sector rules (banking, insurance, securities, telecom, health). The 2019 Personal Data Protection Bill was withdrawn and the DPDP Act is a separate law. The Digital Information Security in Healthcare Act (DISHA) was never enacted, and the Non-Personal Data Governance Framework was a proposal. Check sector rules separately.
FAQ
Can personal data be shared with third parties under the DPDP Act?
Yes, if you have a lawful ground (consent, or one of the specified legitimate uses), the sharing fits the purpose people were told about, and you keep it to what's needed. If the third party processes data on your behalf, a valid contract is required from about May 2027. You remain responsible for what they do with it.
What is a DPDP agreement?
It usually means the contract a Data Fiduciary signs with a Data Processor, or a data sharing agreement with another business, setting purpose, security, breach notification, retention and deletion in line with the DPDP Act and Rules.
Is a data sharing agreement mandatory under the DPDP Act?
A valid contract is mandatory when you engage a Data Processor for activities related to offering goods or services to Data Principals (Section 8(2)). For sharing with another independent fiduciary there's no specific contract requirement, but documenting purpose and roles is strongly advised.
When do the DPDP Rules take effect?
The Rules were published on Nov 14, 2025. The consent-manager framework starts on Nov 13, 2026, and most obligations, including Section 8 and the security, breach and retention rules, around May 13, 2027.
Does the DPDP Act require data localization?
No general localization rule. Transfers are allowed unless a country is restricted by government notification. Sector regulators can impose stricter rules, and the government can require certain Significant Data Fiduciaries to keep specified data in India.
Who enforces the DPDP Act?
The Data Protection Board of India, not a "Data Protection Authority".
Is my processor liable if it causes a breach?
You can allocate responsibility by contract, but the Act keeps you, the Data Fiduciary, responsible for processing done on your behalf.
Can I use a GDPR DPA for DPDP?
It's a useful starting structure, but adapt it to the DPDP Act's terms, the Rules' security, breach and retention requirements, and Indian law.
What's the difference between a DSA and an NDA?
An NDA protects confidential information. A DSA or DPA sets purposes, security, retention and deletion for personal data. You need the latter for data sharing.
Next step
Take your vendor list and mark which contracts lack processor terms. Our DPDP Phase 2 guide and Phase 1 compliance guide cover the wider timeline, how Secure Privacy supports Indian data fiduciaries explains our approach, and the Secure Privacy platform can help you record consent and manage vendor and data-principal requests.



