DPDP cross border data transfer is permitted. Rule 15 of the Digital Personal Data Protection Rules allows personal data to be transferred outside India, subject to any requirements the Central Government may specify by general or special order regarding making that data available to a foreign State, or to a person or entity under its control or acting as its agency. There is no adequacy list, no standard contractual clauses, and no transfer impact assessment to file.
Most teams arrive expecting the opposite: something like the GDPR Chapter V machinery, or worse, a blanket localisation mandate. Neither is what the Rules did.
The single localisation duty in the Rules sits elsewhere, in rule 13(4), and it reaches only Significant Data Fiduciaries that the Central Government has notified. Conflating the two is the most expensive misreading of DPDP currently circulating, because it sends teams into re-architecture projects they were never obliged to run.
What Rule 15 Actually Says About DPDP Cross Border Data Transfer
Rule 15 is the cross-border provision, and what rule 15 of DPDP does is permit the transfer rather than gate it. Personal data may be transferred outside India, subject to requirements the Central Government may specify, by general or special order, about making that data available to a foreign State or to a person or entity under its control or acting as its agency.
That is materially more permissive than the draft rules that preceded it, which is why summaries written against the draft are still wrong in circulation. If your reference point for rule 15 DPDP obligations is a 2024 explainer, discard it.
The condition concerns onward availability to a foreign government, not geography for its own sake. For a midmarket SaaS company processing Indian personal data, existing US or EU hosting is not by itself a DPDP problem. Notice, consent, security safeguards and breach process are where the work is.
Where DPDP Data Localisation Actually Bites
DPDP data localisation exists in exactly one place: rule 13(4), among the additional duties of a Significant Data Fiduciary. That rule requires a notified SDF to ensure that personal data specified by the Central Government, on a committee's recommendation, together with its traffic data, is not transferred outside India.
Three conditions have to stack up before this touches you, and what teams call DPDP SDF localisation needs all three:
- You have been notified. Significant Data Fiduciary status is conferred by the Central Government under section 10 of the Act, for a fiduciary or a class of them. You do not opt in, and you do not self-assess into it. Until you are notified, rule 13 does not apply to you at all.
- The data has been specified. The duty bites on personal data the Central Government specifies, on the recommendation of a committee. It is not all personal data an SDF holds.
- Traffic data follows the data. It covers the specified personal data together with its traffic data, so keeping records in India while routing metadata abroad does not satisfy it.
The gap between the two rules is the gap between a permission with a conditional overlay and a prohibition on a narrow, named set. An ordinary Data Fiduciary — and there is no size threshold for being one — lives under rule 15 only.
Not sure which of your data flows DPDP actually restricts?
Share your work email and we'll map your current processor and region footprint against rule 15 and rule 13(4), and mark which flows would be affected if your entity were ever notified as significant.
Why Transfer Permission Is Not Transfer Certainty
Transfer permission under rule 15 is not transfer certainty, because it is expressly conditional on orders the Central Government may issue. Nobody can tell you today what such an order would say, how broadly it would be drawn, or how much notice would accompany it.
That uncertainty cuts both ways, and both failure modes are real:
- Rebuilding for localisation now spends capital on a duty that does not apply to you, and in many cases never will.
- Assuming transfer is permanently unconstrained bakes in an architecture that could not comply with an order even if you wanted to — because you do not know where the data is, or the processor holding it offers no Indian region.
The defensible position is neither prediction. Treat a future order the way you treat a customer demanding regional hosting: a requirement you are not meeting yet, but could meet without a rewrite.
Architecting for Optionality Rather Than for a Guess
Architecting for optionality means being able to answer three questions quickly, and being able to act on the answers without a migration project. None of this requires predicting the content of a government order.
Know where the data actually sits. Not where the architecture diagram says it sits — where it is, including where data arrives incidentally: log sinks, error-tracking payloads, analytics warehouses, email and support tooling, backups, and the laptop of anyone who exports a CSV. Incidental copies are where residency claims usually fail, and the hardest to find retroactively.
Be able to pin a workload to a region. The engineering question is whether a service could be deployed into an Indian region without redesign: whether region is a deployment parameter or a hardcoded assumption, whether your data stores support per-tenant placement, and whether anything in the critical path is single-region by construction. Answer it per service, in writing. Discovering it under time pressure turns a configuration change into a quarter.
Keep an inventory of which processors hold what, where. Each Data Processor you engage sits under a contract the Act requires you to have, and that contract is the lever you would use. Record the regions each processor offers, not just the one you use — a processor with no Indian region is a dependency you would replace rather than reconfigure. Teams already maintaining this for SOC 2 data residency commitments have most of it; the DPDP addition is traffic data and the Indian-region question.
The test is a tabletop one. If an order landed naming a category of data you hold, how long until you could say where every copy is, and how long until you could move it? Weeks rather than quarters means you have enough optionality.
Sector Regulators Impose Residency Expectations of Their Own
Sector regulators set their own data residency expectations for the entities they license, independently of DPDP. A regulated fintech, broker or insurer can be under a residency requirement that rule 15 says nothing about, and satisfying rule 15 does not discharge it.
The direction of the error matters. Teams in regulated sectors sometimes read rule 15's permissiveness as relief from a sectoral requirement they already have. The sectoral instrument binds on its own terms, through licence conditions and supervisory expectations, and a privacy statute's silence is not permission.
So put a specific question to counsel: which of our regulator's instruments, as they apply to our licence, constrain where this data can sit? Get that answered against the actual circulars and directions that bind your entity, per data category, rather than inferred from DPDP.
Build a Transfer Register You Can Defend
A transfer register is the artefact that makes all of this answerable, and it is a small one. Four columns carry the weight: data category, destination, the processor holding it there, and the basis you rely on.
| Data category | Destination | Processor | Basis relied on |
|---|---|---|---|
| Customer account records (name, email, phone) | us-east-1 | Primary application database host | Rule 15 — permitted transfer, no specifying order applicable |
| Support ticket contents and attachments | EU (Frankfurt) | Helpdesk SaaS vendor | Rule 15; vendor contract carries the processor safeguards clause |
| Application and access logs, with traffic data | us-east-1 | Log aggregation vendor | Rule 15; retained one year per the security rule's log-retention floor |
| Payroll and HR records for Indian staff | ap-south-1 (Mumbai) | HR platform, Indian region | Resident by choice; sectoral expectations under review with counsel |
Two discipline notes. Name rule 15 explicitly in the basis column where that is what you rely on, so a reviewer can see you considered the question rather than defaulted. And where the honest answer is "resident by choice" or "under review," write that — an unresolved row is more useful than a confident wrong one, and those rows are your work queue.
Build it from the same inventory that feeds your vendor risk mapping work rather than as a separate exercise. Destination and processor are usually already there; what is missing is data-category granularity and the basis.
The Eighteen-Month Tranche Defines Your Planning Window
The eighteen-month tranche sets the planning window, which makes this a dated problem rather than an open-ended one. Rule 1 splits commencement into three parts. The short title, definitions and the provisions constituting the Data Protection Board came into force on Gazette publication, 14 November 2025. Consent Manager registration follows one year after publication, in mid-November 2026. Everything else — rules 3 and 5 to 16, plus 22 and 23, covering notice, consent, security safeguards, breach intimation, retention and erasure, the contact person, children's data, Significant Data Fiduciary duties, data-principal rights, cross-border transfer and research exemptions — commences eighteen months after publication, in mid-May 2027.
Rule 15 and rule 13 both sit in that eighteen-month tranche, and nothing in it phases in gradually: it is a single cliff rather than a ramp.
That buys time to do the inventory calmly, not a reason to defer it. The Board is being constituted ahead of the duties it will enforce, so the enforcing institution will be operational before the window closes.
DPDP Cross Border Transfer Questions Teams Ask
These are the DPDP cross border transfer questions teams ask once they realise the Rules do not impose the localisation regime they expected.
Not as a general rule. Rule 15 permits personal data to be transferred outside India, subject to any requirements the Central Government may specify by general or special order about making that data available to a foreign State or to a person or entity under its control or acting as its agency. The only localisation duty in the Rules is rule 13(4), which applies to Significant Data Fiduciaries for classes of personal data the Central Government specifies on a committee's recommendation. Sector regulators may impose residency requirements on regulated entities separately.
No. The Rules establish no adequacy mechanism, no standard-clauses regime and no transfer impact assessment. That machinery is a GDPR construct, and teams arriving from European compliance work look for an Indian equivalent that does not exist. What the Rules do require of any processor relationship is a valid contract under section 8(2) of the Act and an appropriate provision in it requiring reasonable security safeguards — in India or not.
You will have been notified. Status is conferred by the Central Government under section 10 of the Act, for a fiduciary or a class of fiduciaries. There is no self-assessment test and no threshold to measure yourself against. Until notification, rule 13 does not apply, so neither does rule 13(4). Planning for the possibility is reasonable; treating yourself as bound today is not.
No. A sectoral instrument binds on its own terms, through licence conditions and supervisory expectations, and DPDP's permissiveness on transfer does not displace it. Work out with counsel which of your regulator's requirements apply to which data categories, and keep that answer in the register's basis column so the two regimes are never conflated.
Keep the option open rather than guessing. Find every place personal data lands, including log sinks, warehouses and support tooling. Record per service whether region is a deployment parameter or a hardcoded assumption, and which processors offer an Indian region at all. Then keep the transfer register current.
Keep your transfer register current instead of rebuilding it each audit
Book a demo and we'll show how Konfirmity tracks data categories, processor regions and the basis you rely on, so the cross-border question is answerable the day an order or a buyer asks it.
Book a demo
Decide Now What You Would Do If an Order Arrives
Decide now what you would do if an order arrives, because that decision is cheap today and expensive later. Rule 15 permits transfer outside India. Rule 13(4) restricts it, for notified Significant Data Fiduciaries only, over specified data and its traffic data. Anyone telling you DPDP mandates localisation has merged the two, and acting on that merger costs real engineering time.
So build the register, answer the region-pinning question per service in writing, and know which processors could serve you from an Indian region. None of that depends on predicting an order, and enterprise buyers and your own incident response already want it done. The primary source for the Act and the Rules is the Ministry of Electronics and Information Technology at meity.gov.in — read rule 15 yourself rather than through a summary.
Then put a date on it. Transfer duties commence in the eighteen-month tranche, in mid-May 2027, and the inventory is the long pole rather than the policy drafting. Pair the register with the broader duties in the DPDP compliance checklist, and treat any localisation decision you take before an order exists as a commercial choice rather than a legal one.
