Since the Digital Personal Data Protection Rules, 2025 were notified in November 2025, a wave of client memos, LinkedIn explainers and even compliance-tool vendors have treated Rule 15 - the provision governing cross-border transfer of personal data - as though it is fully operative. Contract templates are being rewritten. Data processing addenda are being amended. Clients are being told to build “DPDP-compliant” cross-border transfer mechanisms into new vendor agreements, cloud contracts and outsourcing arrangements.

The trouble is that Section 16 of the DPDP Act - and Rule 15, which operationalises it - is not yet in force. The Act's commencement has been staggered across three stages: the first, in November 2025, activated only the Data Protection Board's establishment and a handful of procedural and definitional provisions. The substantive obligations - consent architecture, breach notification, children's data protections and, critically, cross-border transfer conditions - are slated for Stage 3, expected around May 2027.

This is not a pedantic distinction. It has real consequences for how commercial lawyers should be drafting contracts today.

When it does come into force, Rule 15 will adopt a “negative list” model: transfers are permitted to any jurisdiction by default, unless the Central government specifically notifies that jurisdiction as restricted. This is a deliberately more permissive design than the GDPR's adequacy-and-safeguards regime — no mandatory standard contractual clauses (SCCs), no transfer impact assessments, no whitelist of approved countries. A data fiduciary can move personal data outside India freely, subject only to sector-specific restrictions (RBI's payment data localisation mandate being the clearest example) that continue to override DPDP.

No restricted country list has been published and until Stage 3 commences, there is technically no operative cross-border obligation for Rule 15 to attach to.

Yet, the drafting instinct among many in-house teams and even some external counsel has been to over-engineer: importing GDPR-style transfer mechanisms, SCC-equivalent clauses and adequacy language into Indian commercial contracts that don't yet need them under DPDP and won't need them in that form even once the rules activate, given how different India's negative list model is from the EU's approach.

The instinct to reach for GDPR-style clauses is understandable. It's the most familiar cross-border framework to Indian lawyers trained on international transactions and many multinational clients simply hand over their existing SCC templates and ask for a “local wrap.” But transplanting that architecture onto DPDP creates real drafting problems, not just redundancy.

The GDPR's adequacy and safeguards model is transfer-specific: it asks, for every recipient country, whether that jurisdiction (or a contractual mechanism) provides an adequate level of protection. DPDP's negative list model asks the opposite question: is this specific country on a list the government has affirmatively restricted?

Until that list exists, there is no meaningful legal test to draft toward. A clause that says “the parties shall implement standard contractual clauses substantially equivalent to the EU SCCs” is not just premature. It may commit a client to a heavier compliance burden than DPDP will ever actually require for transfers to non-restricted countries, which based on current signals, will be the vast majority of jurisdictions Indian businesses transact with.

There's also a practical enforceability problem. Contracts that hard-code compliance with “applicable data protection law including the DPDP Act and Rules as amended” are fine as a general clause. But templates that go further and specify particular mechanisms - audit rights modelled on GDPR Article 28, breach notification timelines borrowed from the 72-hour GDPR standard rather than the DPDP Board's own (currently undefined) reporting requirements - risk creating obligations that don't map onto anything in Indian law and that counterparties may resist or simply ignore once the actual Rule 15 machinery is confirmed.

1. Stop importing GDPR machinery wholesale: If your outsourcing, SaaS, or cloud contracts are getting Schrems-style transfer risk assessments bolted on in anticipation of DPDP, that's solving for the wrong regime. Draft cross-border clauses to be adaptable. A provision that lets the parties amend transfer terms on notice of a Central government restriction, rather than pre-emptively compliant with a mechanism that doesn't exist yet.

2. Use the runway to map, not to lock in: The 18-month gap between notification and commencement exists precisely so organisations can map data flows, vendor chains and sub-processor arrangements before obligations bite. Contracts signed now should include audit and data-mapping cooperation clauses so the client isn't discovering its actual cross-border footprint only when the restricted list eventually drops.

3. Watch the Stage 2 notification closely: Stage 2, expected around November 2026, activates consent manager registration and the enforcement and penalty machinery. That is a more immediate signal than Stage 3 for gauging how aggressively the Board intends to act once cross-border obligations do commence. And it's a date most cross-border commentary has entirely ignored in favour of speculating about the restricted country list.

There's a quieter issue here too. Firms charging clients for “DPDP cross-border compliance” work today are, in a strict sense, billing for compliance with a law that isn't yet binding. That's defensible as risk-preparation work, but it should be scoped and communicated as exactly that, not sold as a present-tense regulatory requirement. Clients deserve to know the difference between “this is legally required now” and “this is prudent given what's coming in 2027.”

For lawyers actually sitting across the table from a client on this today, a few concrete positions are worth taking:

• In vendor and outsourcing contracts, resist client or counterparty pressure to insert a fixed cross-border transfer mechanism now. Instead, draft a “regulatory change” clause that obligates the parties to negotiate in good faith to amend transfer terms once Rule 15 and any restricted-country notification actually take effect.

• In cloud and SaaS agreements, focus data-location clauses on commercial and operational certainty (which data centres, which regions) rather than DPDP-specific compliance language that may need to be rewritten in 2027 anyway.

• In M&A due diligence, flag cross-border data flows as a forward-looking risk item in the disclosure schedule, not a present-day compliance gap. Conflating the two overstates the target company's current non-compliance exposure and can distort valuation discussions.

• In client advisories, be explicit about the difference between what DPDP requires today (essentially nothing on cross-border transfer) and what is prudent to prepare for. Clients making real-time business decisions - where to host data, which vendors to sign with - deserve that distinction stated plainly, not folded into a generic “DPDP compliance” bucket.

India's cross-border data transfer regime is genuinely liberal by global standards and that's a good story for business. But the rush to comply with a provision that hasn't commenced is creating unnecessary drafting complexity, premature contractual lock-in to mechanisms that may not fit India's eventual approach and, in some cases, clients paying for certainty the law doesn't yet demand. The better use of this window is structural readiness, not simulated compliance.

Pooja Dhumal is a corporate & commercial law practitioner, with a focus on technology and data transactions.