DPDP Act for CLM: What In-House Legal Teams Must Update

Most in-house teams treat the Digital Personal Data Protection Act, 2023 (DPDP Act) as a drafting problem: add the right clause to the next contract you sign. That misses the harder problem. Your portfolio is not the next contract, it is the four hundred contracts already signed, sitting in a shared drive or an old CLM, most written before anyone in the building had heard of the Act. Fixing DPDP compliance one new contract at a time leaves that entire back book exposed. This is a playbook for finding and fixing it at scale. (Adira, which publishes this guide, makes contract management software, including the search and obligation-tracking features described below, so we have a commercial interest in you believing CLM helps here. The checklist stands on its own regardless of what tool you use.)

For clause-level detail, see The DPDP Act for Contracts: What Changes in Your Agreements and Data Protection Clauses in Indian Contracts Under the DPDP Act. This page is about the portfolio: which contracts to pull, what to check in each, and how to close the gaps without renegotiating everything from scratch.

Where the compliance clock actually stands

The DPDP Act and the Digital Personal Data Protection Rules, 2025 are not commencing on one date. They are commencing in three tranches, and knowing which tranche you are in changes how urgent this is. Rules 1, 2, and 17 to 21, covering definitions and the constitution of the Data Protection Board, took effect on 13 November 2025, and the Board is now operational and can already receive complaints. Rule 4, covering registration of Consent Managers, commences on 13 November 2026. The substantive obligations that actually bind a contract portfolio, notice and consent standards under Rules 3 and 5 to 6, security safeguards, breach reporting under Rule 7, retention and erasure, children's data, and the cross-border conditions, commence together on 13 May 2027.

That means a services agreement signed today for a three-year term will still be running when the full obligations land. Renewing it in 2027 with DPDP terms bolted on at the last minute is not a plan, it is a scramble under a live deadline, for every contract in the portfolio at once. The remediation described here is meant to happen before that date, not after it.

Step one: find every contract that actually touches personal data

You cannot run a compliance check on a document you cannot locate. The DPDP Act's contract requirement sits in 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." Source: Section 8, Digital Personal Data Protection Act, 2023

In a typical mid-size company, that reaches further than the legal team's mental list of "data vendors." Pull, at minimum: SaaS and cloud-hosting agreements, payroll and HR vendor contracts, background-verification vendors, marketing and analytics agencies, customer support and CRM tool vendors, IT outsourcing contracts, insurance and benefits administrators, and any franchise or channel-partner agreement under which the partner collects customer data on your behalf. A pure equipment-supply or construction contract with no personal data in it does not need this exercise.

This is a search problem before it is a legal problem. In a CLM repository, run a full-text search across active contracts for terms like "personal data," "customer data," "employee data," and "Data Fiduciary," then cross-check against a filter on counterparty category (SaaS, payroll, marketing, outsourcing). Contracts that return zero hits, despite being with a vendor category that obviously touches personal data, are your highest-priority blind spot: nobody has looked at them through a DPDP lens at all. Spot-check any single contract for this free, clause by clause, in Weave, before committing to a full portfolio pull.

Step two: check the role allocation, not just its existence

A contract that mentions "personal data" once, in a boilerplate confidentiality clause, is not a compliant contract. Section 2 sets up two roles. A Data Fiduciary "determines the purpose and means of processing of personal data" (Section 2(j)); a Data Processor "processes personal data on behalf of a Data Fiduciary" (Section 2(k)). Source: Section 2, Digital Personal Data Protection Act, 2023. For each flagged contract, ask: does it actually say, in words, which party is which for this engagement? Silence is common, and silence is the gap, because Section 8(1) will not let you argue your way out of it after the fact:

"The 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."

A contract that never names a fiduciary and processor has not shifted anything; it has just made the argument about who owes what harder to have after a breach, which is exactly when you cannot afford that argument to be hard.

Step three: search for the specific terms that are usually missing

Role allocation is the first gap. The operational terms are the second, and a keyword search across a portfolio finds these fastest, because their absence is a pattern, not a one-off drafting slip. Check each flagged contract for six things:

1. Instruction-only processing scope. Does the processor's right to use the data stop at the fiduciary's documented instructions, or is it open-ended ("as needed to provide the Services")?
2. A named security standard. Section 8(5) requires "reasonable security safeguards," undefined in the statute. A contract that just repeats "reasonable" adds nothing to the statutory floor; look for a named control, encryption, access controls, ISO 27001.
3. A breach-notice deadline in hours, not adjectives. Rule 7 of the DPDP Rules, 2025 requires an immediate, without-delay alert to the Board, a detailed report within 72 hours, and without-delay notice to affected Data Principals. Source: Rule 7, Digital Personal Data Protection Rules, 2025. None of that reaches the processor-to-fiduciary leg; that deadline exists only if the contract puts it there.
4. Sub-processor consent. Unlike GDPR, DPDP does not require this by default. A silent contract leaves the processor free to hand your data to a fourth party you never vetted.
5. Deletion or return on exit, with a stated number of days and written confirmation.
6. A stated processing location, with notice before it changes.

This does not scale as a manual read-through of four hundred PDFs. A CLM's clause library and obligation-tracking layer can search the whole active portfolio for the presence or absence of these six elements, tag every contract that fails on one or more, and export a gap list ranked by value or counterparty risk, rather than one lawyer opening documents in sequence.

Step four: build the cross-border watch list, even though nothing is restricted yet

Section 16(1) permits transfer of personal data outside India by default:

"The Central Government may, by notification, restrict the transfer of personal data by a Data Fiduciary for processing to such country or territory outside India as may be so notified." Source: Section 16, Digital Personal Data Protection Act, 2023

As of this writing, no country or territory has been notified as restricted. That is not the same as "nothing to do." A negative list can be published at any time and would apply immediately to whatever contracts route data through a newly listed country. Record, for every processor contract, where the data is actually processed, not where the vendor is headquartered, since a US-headquartered vendor may process through a data centre anywhere. That record is what lets you answer "which of our contracts are exposed" in hours if a restriction lands. Sector rules can already be stricter regardless of Section 16, the RBI's payment-data localisation mandate being the clearest example, so a payments or fintech vendor contract needs that check even now.

Step five: check who owns consent and notice upstream

Sections 5 and 6 sit upstream of most vendor contracts but shape them anyway. Section 6(1) sets the bar for valid consent as "free, specific, informed, unconditional and unambiguous," and Section 5 requires a notice to accompany or precede every consent request. If a contract concerns a vendor that collects data directly from your end customers or employees, add one more question the clause-level search will not catch: does the contract say who drafts and hosts that consent notice, you or the vendor? A vendor's marketing tool that silently pre-fills consent language your legal team never reviewed is a Section 6 problem wearing a vendor-contract disguise. This traces back to the constitutional foundation the DPDP Act was built to operationalise, the Supreme Court's recognition of privacy as a fundamental right in Justice K.S. Puttaswamy (Retd.) v Union of India ((2017) 10 SCC 1), which is why consent cannot be assumed just because a checkbox exists somewhere in a vendor's flow. Judgment on Indian Kanoon.

Fixing it at scale: addendum, not always renegotiation

Reopening every non-compliant master agreement is neither realistic nor necessary. For a contract mid-term with no near-term renewal, the practical fix is a short Data Protection Addendum: a standalone document that amends the existing agreement, adds the six operational terms, and states its own effective date, rather than a full renegotiation of commercial terms nobody wants to reopen. Reserve full redlining for contracts already up for renewal, where adding DPDP terms costs nothing extra in negotiation cycles.

Prioritise the addendum queue by risk, not alphabetically. Push to the front any vendor that could make either party a Significant Data Fiduciary under Section 10, triggered by the volume and sensitivity of data processed, since an SDF needs an India-based Data Protection Officer, an independent auditor, and a Data Protection Impact Assessment every twelve months under Rule 13; any vendor handling health, financial, or biometric data; and any vendor with the largest data volume, regardless of contract value. A small payroll processor holding every employee's bank details outranks a large contract for office supplies.

Track the rollout the way you would track any other obligation: who owns each contract, addendum sent, redlined, signed, filed against the original agreement. A gap sitting in a spreadsheet with no owner is not a fix, it is a documented risk with your name on the audit trail.

Portfolio-level red flags

Normal	Red flag	Why it matters
Every active contract tagged "processes personal data: yes/no"	No visibility into which contracts touch personal data at all	You cannot run a Section 8(2) check on a document you cannot find
Role allocation search returns a hit on every data-vendor category	Search returns zero role-allocation clauses across an entire vendor category	Ambiguity about who is fiduciary and who is processor becomes an argument only after a breach
Breach-notice deadline tracked as a live obligation with an alert	Deadline exists only as text in a signed PDF, no calendar reminder	A vendor's notice arrives, but nobody is alerted before the fiduciary's own 72-hour clock under Rule 7 runs out
Processing location named and logged per contract	No record of where each vendor actually processes the data	If a restricted-country notification lands under Section 16, the exposed contracts cannot be found quickly
Gaps closed by a signed, dated addendum, tracked to completion	Gap flagged in an audit, but remediation left informal or unassigned	The finding sits in a spreadsheet forever; nothing in the actual contract changes
SDF-risk vendors (health, financial, biometric, children's, or high-volume data) flagged separately	Every vendor treated the same regardless of data sensitivity or volume	Audit-cooperation and DPIA-input clauses are missing exactly where Section 10 risk is highest
Consent-notice ownership named in the contract for customer-facing vendors	Contract silent on who drafts and hosts consent notices shown to end users	Invalid upstream consent under Section 6 undermines the whole downstream data flow, with no clear owner to fix it

A legacy clause, and its retrofit

Bad (found, unchanged, in a 2019 vendor MSA): "Vendor will maintain reasonable confidentiality of Customer information and comply with applicable law."

Defensible drafting in 2019. It says nothing DPDP now requires: no role allocation, no instruction-only limit, no security standard, no breach-notice deadline, no sub-processor control, no deletion obligation, no processing location.

Better (retrofit, as a standalone addendum rather than a full renegotiation): "This Data Protection Addendum amends and supplements the Master Services Agreement dated [date] between [Company] and [Vendor] (the 'Agreement'), with effect from [effective date]. For the purposes of the Digital Personal Data Protection Act, 2023, [Company] is the Data Fiduciary and [Vendor] is the Data Processor for personal data processed under the Agreement. Vendor shall process such data solely on Company's documented instructions and for no other purpose, shall implement reasonable security safeguards including encryption at rest and in transit and role-based access controls, and shall not engage a sub-processor without Company's prior written consent. Vendor shall notify Company without delay, and in any event within 24 hours, on becoming aware of any personal data breach, with sufficient detail for Company to meet its obligations under the breach-notification requirements of the Act and rules made under it. Vendor shall process personal data only within [location] and give 30 days' written notice before processing it elsewhere. On termination of the Agreement, Vendor shall delete or return all personal data and confirm deletion in writing within 30 days. This Addendum applies to personal data already in Vendor's possession under the Agreement as of its effective date, and to all further processing. Where this Addendum conflicts with the Agreement on a data protection matter, this Addendum prevails."

What changed and why: it attaches to the existing agreement rather than replacing it, states its own effective date, applies retrospectively to data already in the vendor's hands, and the last sentence resolves any conflict with the older, silent MSA language in favour of the new terms.

How CLM and obligation tracking help, and what they don't

Search and tagging find the gaps faster than a manual read-through; they do not decide whether a contract's language is actually adequate for your risk. Adira's clause library and obligation-tracking features can flag contracts missing any of the six operational elements above across a whole repository, and can turn a breach-notice deadline into a tracked obligation with a reminder rather than a sentence nobody revisits until it matters. A tool can tell you a clause is absent; it cannot tell you whether the security standard you did write in is adequate for the sensitivity of the data involved, and it cannot file the addendum or negotiate a vendor who pushes back.

DPDP and GDPR together: tag, don't merge

Many portfolios have both an Indian entity and either EU customers, EU employees, or an EU parent. Do not draft one clause meant to satisfy both regimes by default; DPDP and GDPR diverge in contract-relevant ways. GDPR Article 28(3) writes sub-processor consent, audit rights, and data-subject-assistance obligations directly into the statute as mandatory terms. Source: Article 28, GDPR. DPDP leaves most of that to the contract itself, and cross-border transfer is the sharpest divergence: GDPR restricts transfer unless a safeguard applies, DPDP permits transfer unless a country is specifically restricted, none are yet. The portfolio fix is a tag, not a merged clause: flag each contract DPDP-only, GDPR-only, or both, and layer GDPR-specific mechanics only onto the contracts that need them. A GDPR-style addendum applied by default to a purely domestic vendor adds negotiation friction for no legal benefit.

FAQ

How do I find out which of my existing contracts need DPDP terms added? Pull every active contract in a vendor category that plausibly touches personal data, SaaS, payroll, marketing, outsourcing, support tools, then run a text search for "personal data," "Data Fiduciary," and related terms. Contracts in a data-touching category that return no hits are your first remediation batch.

Do I need to renegotiate every non-compliant contract right away, or can I use an addendum? A standalone Data Protection Addendum works for most mid-term contracts and is faster than reopening full commercial terms. Reserve full redlining for contracts already up for renewal.

What is the fastest way to check a large portfolio for missing DPA terms? A keyword and clause-presence search across the repository, checked against six elements: instruction-only scope, security standard, breach-notice deadline, sub-processor consent, deletion, processing location. A CLM's clause library can run this across hundreds of contracts at once; Weave can spot-check one document at a time, free.

Our vendor already has a GDPR DPA. Is that enough for DPDP? Usually more than enough on substance, since GDPR Article 28 is more prescriptive than DPDP on paper. Confirm it still names an Indian role allocation and cites the DPDP Act specifically, since a purely GDPR-referencing document can leave ambiguity about which regime applies to an Indian engagement.

What should we prioritise first if we can't fix everything before May 2027? Vendors that could trigger Significant Data Fiduciary status under Section 10, vendors handling health, financial, or biometric data, and vendors with the largest data volume, regardless of the contract's commercial size.

Does CLM or obligation tracking automatically make our contracts DPDP compliant? No. It finds gaps faster and tracks the remediation that follows. Whether the specific security standard, breach-notice window, or role allocation you write in is adequate for your actual risk is a judgment the software does not make.

This guide gets you to a method for finding and fixing DPDP gaps across a contract portfolio. It does not tell you whether your specific contracts, or your specific data flows, meet your compliance obligations, that depends on facts a lawyer needs to review, including data actually processed, and is not legal advice. Talk to a lawyer before you finalise a remediation plan for a portfolio that matters.