At a glance
Yes — an Indian business can host data on AWS, Google Cloud or Azure in foreign regions under the DPDP Act. There’s no general data-localisation mandate; the Act’s negative-list model (Section 16) permits it unless the government restricts a destination, and none is restricted. The catches are specific: sectoral rules (RBI payment-data localisation) can force some data to stay in India, a future Significant Data Fiduciary notification could too, and you stay accountable for the data wherever the region sits. When in doubt, an Indian cloud region removes the question.
Educational resource only. This explains how choosing a foreign cloud region for Indian personal data sits under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice.
The situation
You’re picking a cloud region for an app that holds Indian users’ data, and someone has told you DPDP means it all has to live in India. It’s one of the most persistent myths about the Act, and it drives teams into costly re-architecture they may not need. The accurate picture is more permissive — with a few specific exceptions that, if they apply to you, genuinely do force India-only storage. Knowing which camp you’re in before you choose a region saves both the myth-driven overspend and the exception-driven mistake.
The localisation myth: what DPDP does and doesn’t require
DPDP does not impose blanket data localisation — the enacted Act deliberately stepped back from a “store everything in India” rule. Earlier drafts of India’s data-protection framework flirted with hard localisation and data-mirroring mandates, and that history is why “DPDP requires local storage” is still repeated. The law that actually passed does not. There is no general provision requiring personal data to be stored on Indian soil, and no requirement to keep a local mirror of data hosted abroad. So the starting position for a cloud-region decision is not “it must be in India” — it’s “it can be abroad unless something specific says otherwise.” Getting this right matters because the myth leads businesses to either over-engineer for a rule that doesn’t exist or, worse, assume the whole area is unregulated and miss the exceptions that do bite.
Foreign cloud regions under the negative-list default
Hosting Indian data in a US, EU or Singapore cloud region is permitted under Section 16’s negative-list model, because no destination is currently restricted. Section 16 of the DPDP Act lets the government name countries to which transfer is barred or conditioned; until it names one, everything is open. No such restriction has been notified, so an AWS Mumbai vs AWS Frankfurt vs AWS Singapore choice is, at the DPDP-transfer level, unrestricted today. What doesn’t change with the region is your accountability: wherever the bytes physically sit, you remain the Data Fiduciary responsible for their security, purpose-limitation, retention and breach handling. Choosing a foreign region is a permitted infrastructure decision, not a way to offload the obligations — those stay with you and follow the data into whatever region you pick.
When India-only storage is actually forced on you
Two specific things can override the permissive default and require Indian storage — if either applies, the region choice is made for you. The first is sectoral regulation, which Section 16 expressly leaves intact: the clearest case is the Reserve Bank of India’s payment-data localisation directive, under which payment-system data must be stored only in India. A fintech or payments business can be fully within DPDP’s general allowance and still bound by RBI to keep that data onshore — the sectoral rule wins for the data it covers. Other regulated domains (broader finance, insurance) carry their own storage and record-keeping expectations worth checking. The second is Significant Data Fiduciary status: a business the government notifies as an SDF can be separately directed to keep specified categories of data within India. That isn’t self-assigned and isn’t yet notified for any class, but if your scale or data sensitivity puts you plausibly in SDF territory, treat it as a live possibility rather than a settled non-issue.
Step by step: choosing your cloud region under DPDP
Clear the exceptions first; if none apply, the region is a normal engineering choice.
- Identify what personal data the workload holds, and whether any of it is a regulated class (payment data especially).
- Check your sector’s localisation rules — if you’re in payments, finance or insurance, confirm whether a regulator requires that data to stay in India before you look at foreign regions.
- Assess whether SDF status plausibly applies to you, and treat India-storage as a possible future requirement if it does.
- If no exception applies, choose the region on ordinary grounds — latency, cost, availability — because DPDP’s default doesn’t constrain it.
- Keep the DPDP safeguards attached regardless of region — encryption, access control, retention limits, breach processes — since accountability doesn’t move with the data.
- Document the decision, including why the region is permissible for the data it holds, so it’s defensible later.
- Re-check periodically — the restricted-country list and SDF localisation are both still open and would arrive by notification.
Why an Indian region is often the simpler call
Even though foreign regions are allowed, an India region can be the lower-friction choice — it moots the whole question and hedges what’s still unsettled. This isn’t a legal requirement; it’s a pragmatic one. All three major cloud providers offer Indian regions, so choosing one removes the cross-border question entirely, pre-satisfies any sectoral localisation rule you’re subject to, and insulates you from a future restricted-country notification or SDF localisation directive without a migration. For data you already know is regulated onshore, it’s the obvious default. For everything else it’s a judgement call against latency and cost — but “keep Indian users’ data in an Indian region unless there’s a reason not to” is a defensible, low-drama posture that ages well against a framework whose cross-border edges are still moving. Choose a foreign region when you have a real reason; choose India when you don’t.
FAQ
Does DPDP require Indian data to be stored in India?
No, not as a general rule. There’s no blanket localisation mandate in the enacted Act. Foreign cloud regions are permitted under the negative-list default — subject to sectoral rules and possible future SDF-class restrictions that can require India-only storage for specific data.
Can I host Indian customer data on AWS or Google Cloud outside India?
Generally yes, under the current default — no destination is restricted under Section 16. You remain accountable for the data’s security and handling regardless of region, and you should confirm no sectoral rule (like RBI’s for payment data) forces it onshore.
Do I need to keep a copy of the data in India?
No general data-mirroring requirement exists under DPDP. That was part of earlier drafts, not the enacted Act. Specific regulators may have their own rules, but there’s no across-the-board local-copy mandate.
When must Indian data stay in India?
When a sectoral regulator requires it (RBI payment-data localisation is the clearest example), or if you’re a notified Significant Data Fiduciary directed to keep specified data classes onshore. Outside those, the region is an ordinary engineering choice.
Is choosing an Indian cloud region a way to simplify DPDP compliance?
It can be. It removes the cross-border transfer question, pre-satisfies sectoral localisation you may be subject to, and hedges against future restrictions — without changing your other obligations, which apply wherever the data sits.