TheDPDPAct.com -
Official WhatsApp Channel
Stay updated with the latest DPDP Act news, compliance insights, updates, and resources.
Join Our WhatsApp Channel →For most Indian organizations running on cloud infrastructure, the question of where data physically lives has historically been an operational and cost decision — which region, which availability zone, which provider — made by engineering teams without significant involvement from legal or compliance functions.
The Digital Personal Data Protection Act changes that. Not by imposing blanket data localization requirements — India's framework deliberately avoided that path — but by creating a structure in which the government retains the power to restrict cross-border data transfers to specific countries at any time, without advance notice, and in which sector-specific regulators have already imposed localization requirements that sit alongside the DPDPA's more permissive general framework.
The practical implication: data residency is no longer purely an infrastructure decision. It's a compliance decision that requires legal, security, and engineering to be in the same room.
What the DPDPA Actually Says About Cross-Border Transfers
Section 16 of the DPDPA establishes what legal analysts are describing as a "negative list" approach — the philosophical opposite of how GDPR handles international transfers. Under GDPR, transfers outside the European Economic Area are prohibited by default unless the destination country has received an adequacy decision or specific safeguards (Standard Contractual Clauses, Binding Corporate Rules) are in place. Under the DPDPA, transfers are permitted by default unless the Central Government has specifically restricted the destination country or territory.
As of mid-2026, the Central Government has not notified any restricted countries or territories under Section 16. This means that as of today, Indian organizations can lawfully transfer personal data outside India without any additional DPDPA-specific mechanism — no adequacy decision required, no contractual safeguard mandated, no prior authorization needed.
That current permissiveness is real. But it is not permanent, and it is not unconditional.
The Architecture of Future Restrictions
Rule 15 of the DPDP Rules, 2025 establishes the government's transfer restriction toolkit in detail. It gives the Central Government two distinct instruments: a general order that applies broadly to all Data Fiduciaries or broad categories of transfers — equivalent to a blacklist of countries deemed adversarial on national security, sovereignty, or data protection grounds — and a special order that can target specific sectors, categories of data, or individual entities without affecting other cross-border flows.
This dual-instrument design is worth understanding precisely because it is asymmetric. The government can restrict data flows to a specific country for health data or children's data while leaving other categories of transfers unrestricted to the same country. It can restrict a particular foreign entity from receiving any data while leaving the broader country transfer framework unchanged. And it can do any of this without providing advance notice or transparent criteria for the restriction decision, with organizations expected to comply from the point of notification.
This isn't a policy criticism — it's a practical compliance observation. The Act does not prescribe criteria for restriction decisions or require advance notice to organizations before a restriction takes effect. An organization whose entire data architecture depends on data flowing continuously to a single foreign cloud provider in a single jurisdiction has structured itself in a way that is inherently fragile against a future restriction notification, however unlikely that specific restriction may seem today.
The Sector-Specific Layer That Already Applies
The DPDPA's permissive baseline on cross-border transfers coexists with sector-specific localization requirements imposed by India's financial, insurance, and payments regulators — and those requirements are already in force, independently of anything that changes under the DPDPA.
The Reserve Bank of India requires that payment system data be stored exclusively within India. This requirement applies to all payment aggregators, payment system operators, and banks processing payment data — and it is not superseded or modified by the DPDPA's more permissive general framework. The IRDAI has localization requirements for insurance data. SEBI has requirements for securities market data. The Department of Telecommunications has requirements for certain telecom data categories.
Rule 15 itself acknowledges this explicitly: stricter requirements under other Indian laws continue to apply, and the DPDPA's general permissiveness on cross-border transfers does not dilute sector-specific localization mandates.
The result is a patchwork regime — Section 16's general permissiveness for most personal data, sitting alongside sector-specific mandates that apply regardless of the general framework. For organizations operating across multiple regulated sectors, or for organizations that haven't specifically mapped which data categories their sector regulator requires to be localized, assuming the DPDPA's general permissiveness covers everything is a compliance gap.
Significant Data Fiduciaries Face Additional Restrictions
Rule 12 of the DPDP Rules imposes specific data handling restrictions on Significant Data Fiduciaries that go beyond what the general transfer framework requires. SDFs processing categories of data that the government designates as sensitive from a national security or sovereignty perspective face restrictions on transferring that data outside India, regardless of whether the destination country has been placed on a general restricted list.
For large platforms, financial services firms, health data processors, and telecom operators — the organizations most likely to receive SDF designation — this creates a data architecture planning requirement: understanding which data categories might be subject to these restrictions, and building infrastructure that can accommodate localized storage for those categories, before the designation forces a retrofitting exercise.
Retrofitting data residency into an existing cloud architecture that wasn't designed for it is expensive and disruptive. Building for the possibility from the start is considerably more straightforward.
What This Means for Vendor Relationships
Every cloud provider, SaaS platform, or data processor an organization uses that stores or processes personal data outside India is a cross-border transfer under the DPDPA. The permissive baseline means that transfer is currently lawful. The negative list structure means that lawfulness could change, and when it changes, it changes without advance notice.
This has a specific implication for vendor contracts. ELP Law's DPDP cross-border analysis recommends that organizations include contingency clauses in vendor agreements that permit migration of data to India or to non-restricted countries, with defined timelines for vendor support of that transition and explicit commitments to comply with DPDP obligations. These provisions convert what would otherwise be a regulatory compliance emergency — a restriction notification triggering an immediate obligation to move data that is contractually locked into a foreign platform — into a managed, planned process with a vendor who is contractually obligated to support it.
Most existing vendor contracts for Indian organizations don't contain these provisions, because nobody thought to put them there before data residency became a compliance question. Updating key vendor agreements to include this language is a compliance activity that is easy to do proactively and considerably harder to do reactively.
The Infrastructure Question Most Compliance Programs Haven't Asked
DPDPA compliance programs typically begin with notice and consent architecture, data principal rights workflows, and breach notification procedures. These are the obligations that compliance and legal teams find easiest to engage with, and they're genuine requirements.
What they frequently don't include is a systematic mapping of where personal data physically resides across an organization's full technology stack — which cloud regions, which provider data centers, which vendor-operated infrastructure — and an assessment of whether that infrastructure could accommodate changed transfer requirements on the timeline a government notification would create.
Addressing this requires a different kind of conversation than most DPDPA compliance programs are having. It requires engineering and infrastructure teams to map data flows and residency across the full stack. It requires vendor management to assess existing contracts against the contingency provision gap described above. It requires security teams to assess whether the security safeguards applied to data in foreign infrastructure meet the DPDPA's Section 8(5) reasonable safeguards standard — because the accountability for a processor's security practices remains with the Fiduciary regardless of where the processor operates.
Building for a Regime That Is Evolving, Not Settled
The clearest way to describe India's current DPDPA data sovereignty position is as a framework that is permissive today and directionally uncertain tomorrow. Cross-border transfers are currently unrestricted. Sector-specific localization requirements already apply in several sectors. Significant Data Fiduciary restrictions add another layer for the largest organizations. And the government retains the power to issue restriction notifications at any time, to any country, for any category of data, on geopolitical or national security grounds that may not be visible in advance.
Organizations building on the assumption that the current permissive baseline will remain unchanged indefinitely are making a bet about regulatory stability that the framework's own design explicitly cautions against making. The organizations best positioned for this regulatory environment are the ones that have mapped their data flows, built flexibility into their vendor contracts, planned for potential localization scenarios before they're forced, and ensured that their security safeguards travel with the data regardless of where it lives.
At ILLUME, data flow mapping, vendor security assessments, and the cloud security reviews that DPDP's Section 8(5) obligation requires are core components of how we approach DPDP readiness engagements. If your organization's data residency picture hasn't been mapped as part of your compliance program, that's worth addressing before a government notification makes the urgency external rather than internal. Reach out to Illume to scope that conversation.
