Cross-Border Transfers Are Allowed by Default — Until a Regulator Says Otherwise

One of the more counterintuitive things about the DPDPA is that cross-border data transfer is permitted by default. The Central Government retains the power to restrict transfers to specific countries or for specific types of processing, but absent such a restriction, the baseline position is permissive — a notably different starting point from regimes that require case-by-case justification for every transfer.

The blocklist model, not an adequacy list

Section 16 of the Act is where this default lives. Rather than requiring every destination country to be pre-approved before data can move there — the "adequacy decision" model GDPR uses — DPDPA flips the logic: transfer is permitted everywhere except countries the Central Government specifically restricts by notification. That's a materially lighter compliance burden on paper, but it also means the list of restricted destinations can change, and a transfer that's compliant today needs to stay on your radar rather than being cleared once and forgotten.

Significant Data Fiduciaries face one further layer: the Act allows the government to require that certain sensitive categories of personal data be processed only on servers or systems located in India, on the recommendation of a designated committee. If your organisation has been notified as an SDF, cross-border transfer isn't purely a Section 16 question anymore — it's worth checking whether any of your processing falls into a category the government has flagged this way.

Where sector rules override the default

That permissive default doesn't apply uniformly. Regulated entities — banks, NBFCs, and others under RBI oversight — are bound by RBI's data localization requirements, which mandate that personal data be stored and processed within India regardless of what DPDPA itself permits. DPDPA doesn't dilute or override sector-specific rules that are stricter than its own baseline; it operates alongside them, not instead of them.

What compliance actually requires

In practice, that means maintaining logs of where your data assets actually reside, disclosing any offshore subprocessors involved in your data flows, and using consent language that explicitly names international transfer as one of the things being agreed to — not folding it silently into generic boilerplate. It also means running Transfer Impact Assessments before moving data across borders, and defaulting to localized storage wherever a sectoral rule requires it, rather than treating DPDPA's general permissiveness as license to skip that check.

Always check for the override before you assume the default

The single most important habit here is treating "DPDPA allows this" as the start of the analysis, not the end of it. Track data residency deliberately, tag jurisdiction at the point of collection so it's never a retroactive question, and build the compatibility check for target countries into the same process you use for assessing broader processing risk. Cross-border freedom under DPDPA is real — it's just not unconditional, and the sector-specific exceptions are exactly where the risk concentrates.

Our cross-border transfer documentation service builds exactly this kind of residency tracking and transfer-impact assessment into a standing process, rather than a one-off check.