DPDP Cross-Border Data Transfers: Can Indian Businesses Store Customer Data Outside India After May 2027?
The short answer is yes, mostly, and with conditions that almost nobody is reading correctly. The Digital Personal Data Protection Act, 2023 does not require Indian businesses to keep personal data in India. Your customer database can sit on AWS, Azure or Salesforce infrastructure outside India today, and nothing in the DPDP framework changes that by default on 13 May 2027. But the proposition that "DPDP allows overseas storage" is not the end of the analysis, and treating it as such is how businesses will walk into avoidable exposure. Three corrections frame everything in this article: India has not copied the GDPR's Chapter V transfer machinery, it has not imposed blanket data localisation, and it has not given businesses an unconditional right to send personal data anywhere.
What the framework actually contains is four distinct legal questions that generic commentary keeps collapsing into one: Section 16's restricted-destination power, Rule 15's separate foreign-State-access mechanism, the Significant Data Fiduciary localisation power in Rule 13(4), and the sectoral laws that Section 16(2) expressly preserves. Each has a different trigger, a different scope and a different status today. The cross-border obligations sit in the eighteen-month commencement tranche of the DPDP Rules, 2025 and become enforceable on 13 May 2027, eighteen months after gazettal on 13 November 2025, which from the date of this article is 215 days away. For the overall statutory frame, the pillar reference is Data Privacy Compliance in India: The DPDP Act Framework. This article maps the international layer of that framework.
Does DPDP Require Indian Personal Data to Stay in India?
No. Unlike the debates that surrounded earlier drafts of Indian privacy legislation, the enacted DPDP Act contains no general data-residency mandate. The default position for an ordinary Data Fiduciary is that personal data may be transferred and processed outside India. What businesses routinely confuse is the location question with the legality question. Wherever the server sits, the full weight of the Act travels with the data: the processing still needs a valid basis under the consent or legitimate-use provisions, the security-safeguards obligation still applies, the Data Fiduciary remains responsible under Section 8(1) for everything its processors do, breach reporting follows the data, and the retention and erasure discipline applies in exactly the same way. A company that moves its database to Frankfurt has changed its latency and its hosting bill, not its obligations.
The genuinely legal part of the cross-border analysis is the four-question architecture, and each question has a different answer today:
| Question | Instrument | Status as of 10 October 2026 |
|---|---|---|
| May Government restrict transfers to particular countries? | Section 16(1) | Power exists; no restricted destination notified |
| What conditions may attach to foreign-State access to transferred data? | Rule 15 | Mechanism exists; no general or special order issued |
| Can specified data of Significant Data Fiduciaries be localised? | Rule 13(4) | Power exists; no SDF designated, no data category specified |
| Does another Indian law impose stricter localisation? | Section 16(2) preservation | Yes, already live in regulated sectors, e.g. payments data |
The sections below take each question in turn.
Section 16: India's Restricted-Destination Model
Section 16(1) gives the Central Government the power, by notification, to restrict the transfer of personal data by a Data Fiduciary for processing to a notified country or territory. The architecture is a negative list: transfer is permitted by default, and a restriction must be affirmatively imposed. As of the date of this article, no country or territory has been notified as restricted, so the operative position is that transfers may proceed to all destinations. That position can change on any day the Government chooses, which is why a monitoring discipline, not a one-time legal opinion, is the correct compliance posture.
The contrast with the GDPR matters, both legally and for how multinational teams should think:
| Element | GDPR Chapter V | India DPDP Framework |
|---|---|---|
| Default position | Transfer prohibited unless a gateway applies | Transfer permitted unless a destination is restricted |
| Country assessment | Adequacy decisions (whitelist) | Restricted-destination notifications (blacklist power) |
| Contractual machinery | Standard Contractual Clauses, Binding Corporate Rules | None prescribed |
| Individual transfer assessment | Transfer impact assessments in practice | None statutorily required |
| Residual government-access power | Addressed through safeguards and case law | Rule 15 foreign-State-access mechanism (distinct power) |
Two practical conclusions follow. First, any content describing India as having "adequacy decisions," an approved-country whitelist or SCC requirements is describing a law that does not exist; businesses should be careful about building compliance papers on such descriptions. Second, the permissive default is a policy choice, not a permanent guarantee: the notification power is precisely the kind of instrument that can be exercised quickly in a geopolitical moment, and the companies that will cope are the ones that already know which data flows touch which countries.
Rule 15 Is Not the Restricted-Country List
This is the provision that secondary sources most often misdescribe, so it deserves direct treatment. Rule 15 of the DPDP Rules, 2025 provides that personal data processed by a Data Fiduciary under the Act may be transferred outside India subject to requirements the Central Government may specify, by general or special order, concerning the making available of such personal data to a foreign State, to a person or entity under the control of a foreign State, or to an agency of such a State. No such order has been issued as of the date of this article.
Notice what Rule 15 is and is not. It is not the country blacklist; that power lives in Section 16(1). Rule 15 addresses a different risk entirely: not where the data goes, but who can reach it once it is there. The unit of analysis is the foreign State and its controlled or agency entities, which means the questions a company should ask about an overseas hosting or processing arrangement include the ownership and control chain of the provider, the legal exposure of that provider to its home government's access powers, and whether any Indian requirement, once issued, would be triggered by that exposure. A general order under Rule 15 could apply broadly; a special order could target a particular sector, entity or data category. The design gives the Government a surgical instrument that operates independently of the Section 16 country list, and treating the two as one mechanism is the error most explainers make. For companies running global cloud architecture, the practical upshot is that "our server is in a permitted country" will not, by itself, be a complete answer if and when Rule 15 requirements arrive. The time to understand your providers' control structures and government-access posture is before an order exists, not after.
Your SaaS Stack Is Already Transferring Data Internationally
For most Indian businesses, cross-border transfer is not a future decision; it is the current, unaudited reality. A typical mid-sized company's stack looks something like this:
| Business Function | Typical Tooling | Typical Data Flow |
|---|---|---|
| CRM and sales | Global SaaS platforms | Customer records replicated to US or EU cloud regions |
| Product and marketing analytics | Overseas analytics providers | Behavioural data processed on foreign infrastructure |
| Email and marketing automation | Foreign mailing platforms | Contact lists and engagement data stored abroad |
| HR and payroll | Multinational HRMS providers | Employee personal data synced to group entities overseas |
| Customer support | Global helpdesk tools | Ticket data handled by worldwide subprocessors |
| Core hosting | Hyperscale cloud | Databases replicated across regions for resilience |
The correct compliance exercise is therefore data-flow mapping, not a server-location question. "Is our own server in India?" tells you almost nothing if your CRM replicates to Oregon, your support tool subprocesses in three countries and your payroll provider shares with a foreign parent. The full vendor-governance framework for this stack, breach timelines, sub-processor controls, audit rights, deletion on exit, is mapped in The Hidden Liability in Your Tech Stack: Why Your SaaS Vendors Expose You Under the DPDP Act; this article adds the international-transfer layer that sits on top of it.
DPDP Is Not the Only Localisation Law
Here is the qualification that matters most for regulated businesses. Section 16(2) provides that nothing in Section 16 restricts the applicability of any other Indian law that imposes a higher degree of protection or restriction on the transfer of personal data outside India. DPDP's permissive default therefore does not dilute a single sectoral rule. The established example is the Reserve Bank of India's Storage of Payment System Data directive of April 2018, which requires payment system data to be stored in India; financial-sector outsourcing, record-keeping and cloud frameworks maintained by Indian regulators impose their own residency and oversight conditions in addition. The same logic extends forward to Rule 13(4) of the DPDP Rules: if and when Significant Data Fiduciary designations arrive, specified categories of personal data, together with the traffic data describing their flow, can be barred from leaving India for those entities [LINK NOTE: point this reference to the published VCL Significant Data Fiduciary guide once live].
The discipline that follows is a two-question test for every dataset: does DPDP permit this transfer, and does any other law governing this data or this entity impose something stricter? A fintech that answers only the first question is planning on half the law. One further carve-out deserves mention because it shapes India's outsourcing economy: under Section 17(1), processing carried on in India of personal data of Data Principals outside India, under a contract with a person outside India, is exempted from key obligations including Section 16, which is why an Indian BPO or GCC handling foreign customers' data operates under a different analysis from an Indian company exporting Indian customers' data.
What Multinational Companies Should Put into Vendor and Intra-Group Arrangements
India's framework prescribes no Standard Contractual Clauses, and importing GDPR contractual machinery wholesale into Indian agreements is both unnecessary and sloppy drafting: it papers over the questions Indian law actually asks. What cross-border vendor and intra-group arrangements do need is operational protection built around the framework as it exists:
- Data-location transparency: a contractual record of where personal data is stored and processed, including disaster-recovery regions
- Sub-processor disclosure: an inventory of every downstream entity touching the data, with objection rights
- Relocation and exit rights: the contractual ability to move data out of a jurisdiction if it becomes a notified restricted destination under Section 16(1)
- Government-access handling: defined obligations for notifying, challenging and documenting foreign government access requests, calibrated to the Rule 15 exposure analysis
- Security obligations: technical and organisational measures that travel with the data
- Breach escalation: timelines measured in hours, aligned to the fiduciary's own reporting clocks
- Deletion and return: certified erasure across regions and backups at exit, consistent with the retention architecture in our DPDP data retention and erasure rules guide
- Compliance with future orders: an express covenant to comply with Section 16 notifications and Rule 15 general or special orders when issued, so the contract does not need renegotiation the week the Gazette moves
Intra-group arrangements deserve the same rigour as vendor contracts. An Indian subsidiary feeding employee or customer data to a foreign parent is making a cross-border transfer, and the group data-sharing agreement should carry the same location, access and relocation architecture as any third-party DPA.
Build the Cross-Border Data Map Before May 2027
Cross-border architecture cannot be renegotiated, migrated or rebuilt in the week obligations commence, and 13 May 2027 is the point at which the transfer framework becomes enforceable rather than theoretical. The working instrument is a data map built flow by flow:
| Step | Question | Output |
|---|---|---|
| 1. Dataset inventory | Which personal-data datasets does the business hold? | Dataset register |
| 2. Data Principal mapping | Whose data is it: customers, employees, users, foreign persons? | Principal category per dataset |
| 3. Purpose check | Is there a valid consent or legitimate-use basis for the processing? | Lawful-basis record per flow |
| 4. Recipient mapping | Who receives the data: vendors, group entities, platforms? | Recipient register |
| 5. Processor and sub-processor chain | Who processes downstream, including fourth parties? | Complete processing chain |
| 6. Country mapping | Which countries does the data or its replicas touch? | Destination list per flow |
| 7. Hosting-location verification | Do contracts disclose actual storage and DR regions? | Verified location record |
| 8. Sectoral overlay check | Does RBI, another regulator or another statute impose residency on this data or entity? | Sectoral restriction flags |
| 9. Foreign-State exposure review | What are the ownership, control and government-access characteristics of each provider? | Rule 15 exposure notes |
| 10. Contract gap analysis | Do agreements carry the eight protections from Section VI? | Remediation list |
| 11. Relocation capability | Could each flow be moved if a destination or requirement changed? | Documented exit and migration options |
Two disciplines make the map real. Build it per flow, not per company: a single business may have one flow that is wholly domestic, one that is permissibly offshore and one that sits squarely inside a sectoral localisation rule. Keep it alive: the Section 16 list, Rule 15 orders, SDF designations and data-category specifications all arrive through future instruments, and the map is the asset that lets the business absorb each one in days rather than quarters.
The Bottom Line
India's cross-border position in 2026 is more permissive than the rumour mill suggests and more conditional than the cloud brochures imply. There is no blanket localisation mandate, and there is no GDPR-style adequacy machinery; there is a restricted-destination power that has not yet been exercised, a foreign-State-access mechanism that has not yet been triggered, an SDF localisation power that has not yet been activated, and a set of sectoral laws that are very much already in force. The businesses that will be compliant on 13 May 2027 are not the ones that guessed the right answer to "is overseas storage allowed?" They are the ones that can already answer the harder questions: which flows go where, which providers can be reached by which governments, which datasets are trapped by sectoral rules, and which contracts let them move when the notifications start arriving. Build the map in the 215 days that remain, on the strength of the statute as gazetted.
This article is published for general informational purposes and reflects the DPDP Act, 2023, the DPDP Rules, 2025 as gazetted, and the notification position as at 10 October 2026. It does not constitute legal advice on any specific set of facts.
Strategic Legal Counsel
Discuss the implications of this briefing for your specific corporate or cross-border operations.