Updated: June 30, 2026
Most summaries of India's data-protection law tell you the same thing: your data must now stay in India. That is not what the law says. The gap between what DPDP actually requires and what a careful enterprise should do anyway is where the real decision lives, and it is an infrastructure decision long before it is a legal one.
This is for the CISO who has read the headlines, suspects they oversimplify, and needs to know what to actually build before the clock runs out. The short version: DPDP does not impose blanket localisation, but it makes where your data lives, how you secure it, and whether you can prove all of it, into questions your architecture has to answer. Treating it as a memo for the legal team to file is how you arrive at May 2027 unprepared.
Not as a general rule. The Digital Personal Data Protection framework takes a "negative list" approach: personal data may be transferred outside India to any country except those the government specifically restricts. There is no blanket localisation mandate of the kind many summaries imply. That is the accurate starting point, and getting it wrong in either direction leads to bad architecture.
The caveats are where it gets real, though. Sector rules already localise some data, the RBI requires payment data to be stored only in India. Organisations classified as Significant Data Fiduciaries can be barred from transferring certain notified categories of personal data offshore. And the government can add countries or restrictions at any time. So the law is permissive today, conditional tomorrow, and stricter for the largest data handlers. Building as if "transfer is always fine" is as risky as building as if "everything must stay home".
Because compliance is mostly about controls and provability, and those are architectural, not legal. Even where a transfer is permitted, DPDP holds you accountable for securing the data, detecting and reporting breaches, and demonstrating that you did. Significant Data Fiduciaries carry more still: annual data-protection impact assessments, independent audits, and the standing possibility of localisation for notified data. None of that is satisfied by a clause in a contract. It is satisfied by where the data sits, how it is segmented, who can reach it, and whether every access is logged.
For AI specifically, this lands hard. A model that trains or runs inference on personal data inherits the obligations attached to that data. If you cannot say where your training data physically sits, who accessed it, and how you would contain a breach, you do not have an AI compliance problem you can paper over. You have an infrastructure gap. Could you, today, show an auditor exactly where your AI pipeline's data lives and who touched it?
The Rules were notified in November 2025, and the substantive obligations, including the cross-border and Significant Data Fiduciary provisions, become fully operational around 13 May 2027, eighteen months later. That is not a long runway for an enterprise that has to map its data, classify it, possibly re-architect where sensitive workloads run, and stand up audit and breach-response capability.
The trap is reading "2027" as "later". Data mapping alone, knowing what personal data you hold and where it flows, takes most large organisations months, and everything else depends on it. The enterprises that will be comfortable in 2027 are the ones treating 2026 as the build year. What is your data map's completeness today, honestly?
Where its sensitivity and its regulatory exposure require, which means classifying first and placing second. The disciplined answer is neither "cloud everything" nor "localise everything". It is to sort data by risk and put each class where it belongs, with a bias toward residency for anything sensitive or likely to fall under SDF or sector rules.
| Data class | Recommended placement | Why |
|---|---|---|
| Public / non-personal | Public cloud | No residency or sensitivity constraint; cheapest for bursty work |
| Internal personal data, lower sensitivity | Cloud with controls, or hybrid | Permitted today, but keep it governed and portable in case rules tighten |
| Regulated / sector data (e.g. payment) | In-India, controlled | Sector rules already require localisation |
| High-sensitivity or SDF-likely categories | On-premises / sovereign | Pre-empts notified localisation; maximum control and provability |
| AI training data drawn from the above | Follows the most sensitive class it contains | A model inherits the obligations of its data |
The last row is the one most AI programmes miss. Training data is a blend, and it inherits the strictest rule among its sources. Place the model environment accordingly, not by convenience.
Five things, in order. Map your personal data and its flows so nothing is a surprise. Classify it by sensitivity and regulatory exposure. Assess whether you are likely to be designated a Significant Data Fiduciary, because that changes the localisation calculus. Architect residency for the sensitive and SDF-likely classes, on-premises or sovereign where provability matters most. And build the breach-response and audit trail that turns compliance from a claim into evidence.
Do this while any wider data center or AI build is already open on the table, and you touch the estate once instead of three times. The residency decision, the AI-infrastructure decision and the security architecture are the same conversation.
DPDP's permissive default can lull an enterprise into building for today's rule rather than the one it will plausibly face. A government that can restrict transfers by order, and localise SDF data by notification, has told you which way the ratchet turns. Architecting sensitive workloads for residency now is cheaper than re-architecting them under a notification later.
Proactive Data Systems designs and builds that architecture for Indian enterprises, on-premises, hybrid and sovereign. We are a Cisco Preferred Cloud and AI Partner, Dell Platinum Partner and NetApp Preferred Partner, with 35 years in enterprise IT, more than 1,500 organisations served, and a 24/7 service desk in India. We help you classify the data, place each workload where its risk and the rules require, and build the residency, segmentation and audit capability that makes compliance provable rather than hopeful.
Bring us your data map, or the gap where it should be, and we will design the residency architecture around it. Ask us for a data-residency and DPDP-readiness assessment.
Disclaimer: This article provides general information on the DPDP Act and Rules and their infrastructure implications. It is not legal advice, and the law and its notifications are evolving. Provisions, timelines and Significant Data Fiduciary designations may change. Confirm your specific obligations with qualified legal counsel before making compliance or architecture decisions.
Rokendra Singh Product Manager, Data Center, Proactive Data Systems
We'll get back to you shortly.
