Written by: Prakhar Rai, Advocate | Founder, My Legal Pal | Enrolled with the Bar Council of India | Contracts and data protection lawyer in India
Last reviewed: 6 October 2026, against the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025
Quick answer
If your business handles personal data in India, a handful of your contracts need new wording before the main DPDP duties start on 13 May 2027. The ones that matter most are your vendor and data processing agreements, your SaaS and client contracts, your employment agreements, your website terms and privacy policy, and anything you sign during a deal that puts personal data in a data room. The clauses that need the most attention are the ones covering who is the fiduciary and who is the processor, security safeguards, breach reporting, deletion and retention, cross-border transfers, and help with data principal requests.
I’ll walk through each agreement below, say what changes, and show you sample wording you can adapt. I’ll also point out a few places where the usual checklist advice online doesn’t match what the law says.
If you want the full phased rollout explained, our DPDP Act guide covers it. This article sticks to only to the contracts.
Before you open any contract: which hat are you wearing?
Almost every clause below depends on one question. In this deal, are you the Data Fiduciary or the Data Processor?
The Act defines a Data Fiduciary in Section 2(i) as the person who decides why and how personal data is processed. A Data Processor is defined in Section 2(k) as someone who processes personal data on behalf of a fiduciary. (A small tip, since I see this wrong a lot: Section 2(j) is Data Principal, the individual the data is about. Some online checklists cite 2(j) for the processor, and it isn’t.)
Here is why it matters so much. Section 8(1) says a fiduciary is responsible for complying with the Act “irrespective of any agreement to the contrary”. You cannot contract your way out of responsibility by pushing it onto a vendor. What the contract can do is give you control, information and a way to recover your losses.
And one business can be both. A SaaS company is a fiduciary for its own employees and a processor for what its customers upload. That means one set of clauses will not fit every agreement you sign. If you haven’t mapped what data you hold and who touches it, start with our guide to data mapping under DPDP, because it makes everything below faster.
Which agreements to update
Here is the short list, in the order I’d tackle them.
| Agreement | Your likely role | Why it needs a look |
|---|---|---|
| Vendor and data processing agreements | Fiduciary | Section 8(2) says a processor can be engaged only under a valid contract. Rule 6 expects security terms in it. |
| SaaS agreements and client MSAs | Processor (for customer data) | Customers will push their DPDP duties down to you. You need clear limits on what you do with their data. |
| Employment agreements and HR policies | Fiduciary | Employee data has its own legal basis and notice needs. Payroll and HR vendors become processors. |
| Website terms and privacy policy | Fiduciary | Notice, consent wording and old consents all need attention. |
| AI and technology vendor contracts | Fiduciary or processor | Training data, model providers and log retention raise new questions. |
| NDAs, consultant and freelancer agreements | Either | Personal data often sits inside “confidential information”. |
| Deal documents and data rooms | Fiduciary (seller side) | Sharing personal data with a buyer or investor during diligence needs a plan. |
Now let me take them one at a time.
1. Vendor and data processing agreements
This is where most of the work is, so I’ll spend the most time here. If you use a vendor to store, send, analyse or otherwise handle personal data for you (cloud hosting, payroll, email tools, CRMs, support software), that vendor is your processor. Our vendor agreement drafting guide covers the commercial side, and our data processing agreement template is a useful starting point. Here are the clauses to fix.
Fix the roles clause
Most older vendor contracts say something vague about “complying with applicable law”. That leaves the key question open.
Before:
The Vendor shall comply with all applicable data protection laws.
After:
For Personal Data processed under this Agreement, the Client is the Data Fiduciary and the Vendor is the Data Processor, as those terms are used in the Digital Personal Data Protection Act, 2023. The Vendor shall process Personal Data only on the Client’s written instructions, only for the purposes in Schedule 1, and for no purpose of its own. If the Vendor decides the purpose or means of any processing, it acts as a separate Data Fiduciary for that processing and must tell the Client before it starts.
The last sentence is the one people forget. Vendors drift into using client data for their own analytics or product training, and this sentence forces that conversation to happen in the open.
Replace “industry standard security” with something you can check
“Industry standard security” sounds fine and means almost nothing in a dispute. Rule 6 of the DPDP Rules lists what reasonable safeguards look like: encryption, masking or tokenisation, access controls, logging and monitoring, backups to keep processing going if systems are compromised, and keeping logs for a set period. Rule 6 also says the fiduciary’s contract with a processor should include appropriate provisions on these safeguards. So say so in the contract.
Before:
The Vendor shall maintain industry standard security.
After:
The Vendor shall maintain reasonable security safeguards to prevent a personal data breach. At a minimum these include: (a) encryption, masking or tokenisation of Personal Data; (b) access controls that limit access to staff who need it; (c) logging and monitoring of access to systems holding Personal Data; (d) backup and recovery arrangements that allow processing to continue if systems are compromised; and (e) keeping logs for the period set out in clause [X]. The Vendor shall give the Client a written summary of these measures on request and after any material change.
Getting this wrong is expensive. The Schedule to the Act allows a penalty of up to ₹250 crore for failing to take reasonable security safeguards. That penalty lands on you as the fiduciary, even if your vendor was the one who got hacked.
Rewrite the breach clause around the 72-hour rule
Here is where a lot of contracts go wrong, so let me explain the logic. Under Rule 7, once you become aware of a breach you must tell the Data Protection Board without delay, and then send a detailed report within 72 hours. You must also tell each affected person without delay. The clock runs from when you become aware.
So if your vendor takes a week to tell you, you may be out of time before you know anything. The contract has to give the vendor a much shorter window. Twenty-four hours is a common choice. I want to be clear that 24 hours is a drafting choice, not a number in the statute. Pick a window that your vendor can realistically meet and that leaves you room to act.
Before:
The Vendor shall notify the Client of any breach promptly.
After:
The Vendor shall notify the Client without undue delay, and in any event within 24 hours, of becoming aware of a Personal Data Breach. The notice shall state, as far as known: the nature, extent, timing and location of the breach; the Personal Data and the categories of Data Principals affected; the likely consequences; the steps taken or planned to contain it; and a named contact. The Vendor shall send updates as facts emerge and shall give the Client the information it needs to meet its own duties to the Data Protection Board and to affected Data Principals. The Vendor shall not notify any Data Principal or regulator itself unless the Client asks it to or the law requires it.
Notice that the clause lists what the vendor must tell you. That list tracks what you will need to put in your own report to the Board.
Fix the deletion clause so it doesn’t collide with retention
This is my favourite catch, because I see it in almost every checklist. The usual advice is “delete all data when the contract ends”. But the Rules also require fiduciaries to keep certain logs and personal data for at least one year. Rule 6 deals with retaining logs, and Rule 8(3) requires retention of personal data, traffic data and logs of processing for a minimum of one year for specified purposes, unless another law says otherwise. A blanket “delete everything on termination” clause can put you in conflict with that.
Some larger platforms also have to warn users 48 hours before erasing their data for inactivity, under Rule 8(2) and the Third Schedule. If that is you, your vendor needs to act on your timetable.
Before:
On termination, the Vendor shall delete all Client data.
After:
On termination or expiry, or earlier on the Client’s written instruction, the Vendor shall return or erase all Personal Data within 30 days and confirm this in writing. This does not apply to (a) logs and Personal Data the Client has asked the Vendor to retain so the Client can meet the retention periods in the DPDP Rules, or (b) data the Vendor must keep under any other law. The Vendor shall keep such data only for that purpose and period. Where the Client tells the Vendor that a Data Principal has withdrawn consent, or that a retention period is ending, the Vendor shall erase the relevant Personal Data within [7] days of the instruction.
Don’t copy a blanket “no transfers outside India” clause
You will see sample clauses that say personal data must never leave India without written consent. That is a legitimate business choice if you want it, but it isn’t what the law requires, and it can make normal tools (global cloud services, support desks, analytics) impossible to use.
Here is what the law actually does. Section 16(1) lets the Central Government restrict transfers to countries it notifies. Section 16(2) says other Indian laws with stricter rules on transfers still apply, which matters for sectors like banking and insurance. Rule 15 says personal data may be transferred abroad, subject to any requirements the government sets by order about making data available to a foreign State or its agencies. Significant Data Fiduciaries can face tighter rules, including localisation for specified data under Rule 13.
So you have two workable options. Choose based on your risk.
Conservative version (data stays in India):
The Vendor shall store and process Personal Data only in India [and in the locations listed in Schedule 2]. It shall not move Personal Data to any other country without the Client’s prior written consent.
Flexible version (transfers allowed, with guardrails):
The Vendor may process Personal Data in the locations listed in Schedule 2. It shall not transfer Personal Data to any country or territory the Central Government has restricted by notification under Section 16 of the DPDP Act, and shall comply with any order under Rule 15 of the DPDP Rules and any sector law that restricts transfers. If a restriction takes effect, the Vendor shall stop the affected transfer within [30] days, or sooner if the law requires.
The flexible version also protects you if the rules change, which is the point of drafting for movement.
Add help with data principal requests
Under Rule 14, you have to publish how people can make requests and respond to grievances within a reasonable period, which cannot be more than ninety days. If a customer’s request lands with your vendor and sits in an inbox, you pay the price.
If the Vendor receives a request or complaint from a Data Principal about Personal Data it processes for the Client, it shall send it to the Client within 2 business days and shall not respond itself. The Vendor shall help the Client act on access, correction, erasure and grievance requests within the timelines the Client reasonably sets, so the Client can respond within the period it has published.
Control sub-processors and audits
Vendors rely on other vendors, and your data goes with them. Add a short clause.
The Vendor shall not appoint a sub-processor without 30 days’ written notice to the Client and a chance to object. Each sub-processor must be bound by terms no less protective than this Agreement, including the security and breach terms. The Vendor remains fully liable for its sub-processors.
Add an audit right too. Once a year, and after any breach, you should be able to review the vendor’s records or have a third party do it, with reasonable notice and without disrupting the vendor’s other clients.
Give data breaches their own liability cap
This is the commercial point most DPDP checklists skip. Most contracts cap a vendor’s liability at a year’s fees. A breach can cost far more than that. Consider a separate, higher cap for data protection breaches, kept outside the general cap.
The Vendor’s liability for breach of its data protection and security obligations is subject to a separate cap of [amount], which does not count towards the general cap. It includes breach notification costs, reasonable investigation and remediation costs, and, to the extent the law allows, amounts payable to regulators.
The words “to the extent the law allows” matter. Whether a regulatory penalty can be passed on by indemnity is not settled in every case, so don’t promise more than the law lets you recover.
2. SaaS agreements and client MSAs
If you run a software business, your customers will increasingly send you their own DPDP clauses. In most of these deals you are the processor, which flips the vendor clauses above in your favour or against you.
Here is what to watch for. First, keep your role clear: you process customer data to deliver the service and nothing else. Second, watch what you promise on breach windows and sub-processors, because you can only promise what you can deliver. Third, check your own use of customer data. If you use it to train models or improve the product, the contract has to say so, or you become a fiduciary for that use.
The Provider shall process Customer Personal Data only to provide the Services and on the Customer’s documented instructions. The Provider shall not use Customer Personal Data to train or improve its own models, products or services, or for analytics unrelated to the Services, unless the Customer agrees in writing.
If you’re drafting or reviewing one of these, our SaaS agreement drafting guide covers the rest of the contract. For AI products specifically, our piece on AI vendor contracts goes deeper on training data, model providers and what happens to prompts and logs.
3. Employment agreements and HR policies
Employment is where I see the most confusion, so here is the short version.
Section 7(i) of the Act lets an employer process personal data for the purposes of employment, and for protecting the employer from loss or liability, such as keeping trade secrets and confidential information safe. For core HR work like payroll, attendance and performance, you generally don’t need to collect consent from every employee. That is a real change from the way many Indian employment contracts are written, which tend to bundle a broad consent into the joining paperwork.
What you do need is a clear notice. And for anything outside the employment purpose (an optional wellness programme, using someone’s photo in marketing, sharing details with a third party for a benefit that isn’t part of the job), ask for separate consent that people can say no to and later withdraw.
The Company will process your personal data for the purposes of your employment, including payroll, benefits, attendance, performance management, compliance with law, and protecting the Company from loss or liability, such as safeguarding confidential information. For any other purpose, such as optional wellness programmes or the use of your photograph in marketing material, the Company will ask for your separate consent, which you may withdraw at any time.
Also look at the vendors your HR team uses. A payroll provider, background verification agency or benefits platform is a processor, and each one needs the clauses from section 1. Keep one eye on how far employee monitoring goes, because “employment purposes” is read tightly and wide surveillance is a risk.
Our employment agreement guide covers the main contract, and we also draft these under our employment contract drafting service.
4. Website terms and privacy policy
Your website terms and privacy policy are where you talk to the people the data is about, so the wording needs to be right. Two things change.
Consent has to meet a higher standard. Under Section 6, consent must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and tied to a stated purpose. Bundling a consent to marketing into your terms of service doesn’t meet that. Keep consent requests separate from the terms people accept to use your product, and don’t make the service depend on consent that isn’t needed for it.
Old consents need a fresh notice. This one catches established businesses. Section 5(2) says that if you collected consent before the Act’s commencement, you may keep processing until the person withdraws consent, but you must give them a notice, as soon as reasonably practicable, covering what data you hold, why, how to exercise their rights, and how to complain to the Board. Email, in-app message or another effective channel all work.
We are updating how we explain our use of your personal data. We hold [categories of data] about you, which we use to [purposes]. You can access, correct or erase your data, withdraw your consent, or nominate someone to act for you by [method]. If you have a complaint, you can contact our grievance contact at [details], and you can also complain to the Data Protection Board of India.
If you run an app or a platform for children, Section 9 adds verifiable parental consent and limits on tracking and targeted advertising, so please get specific advice. Our EdTech lawyer in India page covers that area.
If you need these documents drafted, see our terms and conditions drafting and privacy policy drafting services.
5. NDAs, consultant and freelancer agreements
An NDA doesn’t look like a data protection document, but it often carries personal data: customer lists, employee records, call recordings, user databases shared for a project. A short clause fixes the gap.
Any personal data a party receives under this Agreement is Confidential Information. The receiving party shall use it only for the Purpose, protect it with reasonable security safeguards, tell the other party of any breach within 48 hours, and return or erase it on request, subject to any retention required by law.
If you’re reviewing NDAs, our NDA drafting service is the place to start. For consultants and freelancers who handle your data, treat them like vendors and give them the processor clauses.
6. Deals and data rooms
This is the part almost nobody writes about, and it matters if you raise money, buy a business or get acquired.
In due diligence, the seller opens a data room full of employee contracts, customer lists and sometimes user data. That is personal data being shared with a third party. Section 17(1)(e) of the Act exempts processing needed for a merger, amalgamation, demerger or similar scheme, but only where a court, tribunal or other competent authority approves it. A typical private share purchase or investment round isn’t obviously covered by that exemption. I haven’t seen anything that clearly settles it, so the careful approach is to treat the data room as regulated.
In practice that means:
- Share anonymised or aggregated data wherever you can (salary bands instead of names, for example)
- Limit access to named people on the buyer’s side
- Use the purpose limit in the NDA so the data is used only to assess the deal
- Delete or return everything if the deal falls through
The Buyer shall use any personal data disclosed in the data room only to evaluate the Transaction. It shall limit access to named advisers who need it, keep the data secure, notify the Seller of any breach within 48 hours, and return or erase the data if the Transaction does not complete, subject to any retention required by law.
In the final deal documents, expect to see DPDP compliance warranties from the seller and an indemnity for past non-compliance. Our M&A due diligence checklist shows where data protection fits into the wider review.
A quick map: clause to law
If you want the whole thing on one page, here it is.
| Clause | Where it comes from |
|---|---|
| Roles (fiduciary and processor) | Section 2(i), 2(k), Section 8(1) |
| Valid contract with the processor | Section 8(2) |
| Security safeguards | Section 8(5), Rule 6 |
| Breach reporting | Section 8(6), Rule 7 |
| Erasure and retention | Section 8(7), Rule 6, Rule 8 |
| Data principal requests | Rule 14 |
| Cross-border transfers | Section 16, Rule 15, Rule 13 |
| Old consents | Section 5(2) |
| Employment processing | Section 7(i) |
| Children’s data | Section 9 |
| Penalties (up to) | Schedule to the Act |
Mistakes I see most often
Copying a clause that says “delete everything on termination”. It sounds tidy and it clashes with the retention rules. Add the carve-outs.
Treating 24 hours as the law. It’s a good contract number, but it comes from you, not the statute. Say so internally, so nobody defends it as a legal requirement.
Assuming a vendor contract protects you from the penalty. Under Section 8(1), the responsibility stays with the fiduciary. The contract gives you recourse, not immunity.
Using one DPA for every vendor. A payroll provider and a cloud host carry different risks. Fit the security list and transfer terms to the real service.
Forgetting your processor side. If you’re a SaaS company, your customers’ clauses are aimed at you, and promising a 24-hour breach window you can’t meet creates its own problem.
Leaving the clauses fixed to one date. Dates may move, and rules get supplemented. Add a change-in-law clause so a single amendment keeps working.
If the DPDP Act or the DPDP Rules are amended, or a notification, order or direction takes effect that affects the processing under this Agreement, the parties shall in good faith agree any changes needed to comply, and the Vendor shall not unreasonably refuse them.
A simple order of work
- List every contract where personal data changes hands.
- Mark your role in each one: fiduciary, processor or both.
- Start with the vendors who hold the most data or the most sensitive data.
- Update the six core clauses: roles, security, breach, erasure and retention, transfers, and help with requests.
- Send an amendment and not a full re-draft where you can, to save time.
- Update your employment template and your privacy notice, and plan your notice to existing users.
- Add the change-in-law clause to everything new.
- Re-check the dates once a quarter until 13 May 2027 has passed.
If you’d like a quick way to see where you stand, try our free DPDP compliance checker.
Frequently asked questions
Do I need to update my existing contracts, or only new ones? Both. Your older contracts will still be running when the main duties start on 13 May 2027, so the ones that involve personal data need amending before then. Start with your highest-risk vendors and most important customers.
Is a data processing agreement mandatory under the DPDP Act? Section 8(2) says a Data Fiduciary may engage a Data Processor to process personal data on its behalf, for activities related to offering goods or services to Data Principals, only under a valid contract. Rule 6 also expects the contract to include appropriate provisions for security safeguards. In practice, that means you need a written agreement with each processor.
How fast must a vendor report a breach to me? The Act and Rules don’t set a number of hours for a vendor. They set your own duties: tell the Board and affected people without delay, and send a detailed report to the Board within 72 hours. So your contract should give the vendor a short window, such as 24 hours, that leaves you time to meet yours.
Can I send personal data outside India under a vendor contract? Generally yes, unless the government has restricted transfers to a particular country or imposed conditions by order, or a sector law you follow says otherwise. Significant Data Fiduciaries can face stricter rules. Whether to keep data in India by contract is a business decision, and not something the law forces for every business.
Does my employment contract need employee consent for processing? Not for the purposes of employment. Section 7(i) allows processing for employment purposes and for protecting the employer from loss or liability without consent. You should still give a clear notice, and ask for separate consent for anything outside those purposes.
What are the penalties, and who pays them? The Schedule to the Act sets maximum penalties, including up to ₹250 crore for failing to take reasonable security safeguards, up to ₹200 crore for failing to notify a breach, and up to ₹50 crore for most other breaches. The penalties apply to the fiduciary, which is why your contracts should give you a way to recover your losses from vendors.
Need help with your contracts?
If you’d like a lawyer to review your vendor, SaaS, employment or deal documents against the DPDP Act, our team can do it. We’ll tell you which contracts need changes, draft the amendments and flag anything that depends on your role in each deal. Start with our contract lawyers in India page, which covers drafting, review and negotiation.
Related reading:
- DPDP Act 2023: The Complete 2026 Compliance Guide
- Data Mapping Under DPDP: A Practical Guide for Indian Businesses
- What Is a DPIA, and When Does Your Company Need One Under DPDP?
- Consent Management Rules under the DPDPA, 2023
This article is general information, not legal advice. The sample clauses are starting points and need to be adapted to your facts, your role in each deal and the current state of the law, which may change as further notifications and orders are issued. For advice on your own contracts, speak to a qualified lawyer. Authored and reviewed by Prakhar Rai, Advocate, founder of My Legal Pal, enrolled with the Bar Council of India.
