The received wisdom about AI data residency in India is that the country “requires data localisation”. As a general statement about the Digital Personal Data Protection Act, that does not match how the Act is drafted — and building around it costs real money. The rules that actually apply are older, narrower, sectoral, and considerably more demanding about what you have to prove.
Not legal advice — please check the primary sources yourself.
This article is a map of the published Indian instruments that carry data location or evidence requirements, with a link to each primary source in the table below so you can read the text rather than take our summary for it. Cloud Assert is not a law firm. Nothing here is legal advice, nothing creates an advisory relationship, and none of it should be relied on as a compliance opinion.
Positions are summarised as at 8 September 2026 from the sources linked throughout. Several of these instruments are still commencing, at least one open question has no authoritative answer yet, and all of them are subject to change. Whether any of this applies to your business, and how, is a question for you and your own advisers.
Table of Contents
- The Localisation Myth, Corrected
- What DPDP Actually Does, and When
- AI Data Residency: The Seven Rules That Actually Apply
- The One Nobody Has Priced In
- Why This Is an Architecture Problem, Not a Paperwork One
- What It Looks Like in a Platform
- What “Sovereign AI” Means in India
- Where Hybr® Fits
- Frequently Asked Questions
- References
The Localisation Myth, Corrected
The DPDP Act does not, on its face, impose a general data localisation mandate. Section 16 of the DPDP Act is a negative list: cross-border transfer is permitted by default, and the government may restrict transfer to a country it specifically names. No country has been named. Section 16 has not even commenced. This is the settled reading among Indian data-protection practitioners rather than a contrarian one — the shift from a localisation debate to a negative list has been the standard practitioner analysis since the Rules were notified.
This matters commercially because the myth produces the wrong architecture. Teams building for AI data residency in India routinely over-provision — pinning every workload to an Indian region, refusing every managed service with a foreign control plane, forgoing capabilities they were legally free to use — on the strength of a rule that does not exist. Others do the reverse: they read “no localisation mandate”, conclude they are unconstrained, and walk straight into RBI or SEBI obligations that have been in force for years.
The statutory text is short enough to quote. Section 16(1) says the Central Government “may, by notification, restrict the transfer of personal data by a Data Fiduciary for processing to such country or territory outside India as may be so notified”. That is the reverse of the EU’s adequacy model. There is no whitelist to get onto. There is a list of restricted destinations which, as at 8 September 2026, is empty.
And then Section 16(2), which is the clause that actually governs infrastructure decisions: nothing in Section 16 restricts the application of “any law for the time being in force in India that provides for a higher degree of protection for or restriction on transfer”. In other words, DPDP explicitly leaves the sectoral rules standing. Those sectoral rules are the ones teams generally find themselves designing against.
What DPDP Actually Does, and When
The DPDP Rules were notified on 13 November 2025 with a three-stage commencement. Stage one was immediate and procedural. Consent manager registration opens on 13 November 2026. Every substantive obligation — notice, security, breach notification, children’s data, significant data fiduciary duties, cross-border transfer — commences on 13 May 2027.
As of September 2026, the Data Protection Board has been constituted as an entity but has no chairperson or members appointed — MeitY invited applications for those posts in May 2026 and none have been announced since, a position Indian legal commentary has described as established in law but absent in fact. No Significant Data Fiduciaries have been designated — that status is assigned by government, not self-declared. No enforcement action has been taken and no orders published.
Within DPDP itself, the localisation hook practitioners point to is Rule 13(4), and it is narrow. Rule 13(4) requires a Significant Data Fiduciary not to transfer outside India certain personal data that the government has notified, plus related traffic data. No categories have been notified and no SDFs designated, so it is a reserve power rather than a live obligation. It commences with everything else in May 2027.
None of which is an argument for ignoring DPDP. The penalties are serious — up to ₹250 crore for failing to take reasonable security safeguards, up to ₹200 crore for failing to notify a breach — and the breach-notification clock is tight: notify affected data principals without delay, give the Board an initial intimation without delay, and file a detailed report within 72 hours. What it is an argument for is not confusing DPDP with a residency regime, because the residency regime lives elsewhere.
AI Data Residency: The Seven Rules That Actually Apply
Seven separate Indian instruments carry location or evidence requirements, on their published terms, that reach cloud and AI workloads. Each row below links to its primary text — read it against your own facts rather than relying on the summary. They have different scopes, different triggers and different proofs, and conflating them into “India requires localisation” produces architecture that is simultaneously over-built and non-compliant.
| Instrument | Who it applies to | What must sit in India | Primary source |
|---|---|---|---|
| RBI — Storage of Payment System Data, 6 Apr 2018 | All payment system operators | End-to-end payment transaction data, customer identifiers, credentials. Processing abroad is allowed, but the data must be deleted from foreign systems and brought back within 24 hours or one business day, whichever is earlier. Assurance via a System Audit Report from a CERT-In empanelled auditor. | RBI FAQ |
| IRDAI — Maintenance of Information Regulations, 1 Jan 2025 | Insurers and IRDAI-regulated intermediaries | All records of policies issued and claims made in India, held in data centres located and maintained in India only. Note: this repealed the 2015 regulations that most commentary still cites. | IRDAI regulations |
| SEBI — Cloud Services Framework, 6 Mar 2023 | Exchanges, clearing corporations, depositories, brokers, AMCs, QRTAs, KRAs | Data resides and is processed within India’s legal boundaries, and cloud may be taken only from MeitY-empanelled CSPs with valid STQC audit status. SEBI reserves rights of audit, inspection, and search and seizure of CSP resources. | SEBI circular |
| CERT-In — Directions under s.70B(6), 28 Apr 2022 | Everyone, including data centres, cloud, VPS and VPN providers | Logs of all ICT systems for a rolling 180 days, maintained within Indian jurisdiction. Cyber incidents reported within 6 hours. Providers retain subscriber KYC for 5 years. Clocks synced to NIC or NPL NTP. | CERT-In directions |
| DoT — Telecom Network Authorisation Rules, 20 Jul 2026 | Six authorisation categories including the new cloud-hosted telecommunication network provider | The systems themselves, together with all associated data, logs and information, inside India. No copy routed, shared or made available abroad. Offshore remote access only with government approval. No exemptions. | DoT rules |
| MeitY — empanelment and MeghRaj | Government departments, PSUs, nationalised banks | Data stored in India in MeitY-approved regions; ISO 27001/27017/27018/20000-1; initial and annual STQC audit. For government workloads, export of any data including backups is prohibited. | Empanelment scope |
| DPDP — Rule 13(4) | Significant Data Fiduciaries, once designated | Notified categories of personal data and related traffic data must not leave India. Reserve power; live 13 May 2027. | DPDP Rules (gazette) |
Read that table as an engineer rather than a lawyer and a pattern falls out. Only one of the seven is a blanket storage mandate. Two turn on which provider you buy from, not merely where the bytes sit. Three turn on evidence — logs, audits, reports — more than on geography. And one, the newest, is about the location of the running systems rather than the data at all.
The One Nobody Has Priced In
The Department of Telecommunications notified the Telecommunications (Authorisation for Telecommunication Network) Rules on 20 July 2026, and Rule 25(3) is, on its face, the most restrictive of the seven. As drafted, it requires every system forming part of an authorised entity’s telecommunication network — together with all associated data, logs and information — to sit inside India, with no copy routed, shared or made available outside.
Two things make it consequential for AI data residency in India. First, it created a new authorisation category for cloud-hosted telecommunication network providers, which pulls a class of cloud workload directly into telecom licensing. Second, it applies without exemption across all six authorisation categories.
The unresolved question, and it is a live one, is whether an Indian subsidiary of a foreign cloud provider satisfies the test, or whether compliance turns on where the servers physically sit. Nobody has an authoritative answer yet. For this class of workload, the general “no localisation mandate” summary no longer holds — a point the practitioner analysis of the new rules makes as well.
Why This Is an Architecture Problem, Not a Paperwork One
In practice, each of the seven turns on being able to show what happened to one specific customer’s data — which region processed it, who accessed it, when, and for how long the record has been kept. A clause in a master services agreement asserts that. It does not evidence it.
That distinction is the whole article. If you operate a multi-tenant AI platform — a GPU cloud, a managed AI service, an internal platform serving business units — then residency is a property of each tenant, not of your estate. Tenant A is a payments company and falls under the RBI circular. Tenant B is an insurer under IRDAI. Tenant C is a broker under SEBI and can only be served from a MeitY-empanelled region. Tenant D is a government department and cannot have a backup leave the country. Tenant E is an unregulated SaaS startup with none of these constraints and no wish to pay for them.
Serving all five from one estate means the platform has to know, per tenant, which regions are permissible, which catalogue items may even be offered, how long logs are retained and where, and what evidence can be produced on demand. The alternative — a separate deployment per compliance profile — is how operators end up with five half-idle clusters and no margin. The utilisation arithmetic behind that is in GPU-as-a-Service in India.
What It Looks Like in a Platform
Four controls, applied per tenant, cover all seven instruments.
- Region pinning per tenant. A tenant’s workloads, data and backups run only where their policy allows, enforced at provisioning time rather than audited afterwards.
- Catalogue scoping. A regulated tenant is only offered services from compliant providers and regions. If SEBI says MeitY-empanelled CSPs only, the non-empanelled options are not in that tenant’s catalogue at all. This is the same scoping mechanism described in the customer self-service portal.
- Log retention inside India, per tenant. Access and activity records held for the required window in the required jurisdiction — 180 days for CERT-In, five years of KYC if you are the provider.
- Per-tenant evidence on demand. A residency record, an access trail, an audit pack, a breach timeline. Queryable, not reconstructed from logs the week the auditor arrives.
For AI workloads specifically, the same controls have to reach the model layer. Which tenant’s prompts and completions went to which model, in which region, through which endpoint, at what spend — that is the residency question restated for inference, and it is what a gateway layer exists to answer. See LLM Gateway for how per-tenant endpoints, keys, entitlements and spend attribution fit together.
Watch the two-minute version. The per-tenant controls described above, shown in a working multi-tenant console. See how the service layer works →
What “Sovereign AI” Means in India
In Indian policy, “sovereign AI” means indigenous capability, not a compliance regime. The distinction matters because the two are constantly conflated in vendor marketing.
The IndiaAI Mission has backed twenty indigenous models — twelve large and eight small — including BharatGen from an IIT Bombay consortium, Sarvam, Gnani and others, with model sizes from two billion to a trillion parameters. The India AI Governance Guidelines released on 15 February 2026 frame the ambition as building “the full AI stack” with culturally representative models trained on local datasets.
Two facts about those Guidelines are worth holding onto. They are explicitly voluntary — industry is asked to comply with existing law and adopt voluntary principles, codes and standards, and regulators are advised against compliance-heavy requirements unless necessary. And India has no AI statute at all: drafting only began after MeitY’s Secretary announced a stakeholder consultation on 9 July 2026.
So sovereignty in India is currently an industrial-policy objective, funded through compute subsidies and model grants, rather than a set of rules you can fail an audit against. The rules you can fail an audit against are the seven above. We looked at the general architecture question in sovereign AI architecture beyond data residency; this article is that argument applied to one jurisdiction, and the market context for it is in India’s AI data centre build-out.
Where Hybr® Fits
Hybr® is the control plane above the infrastructure, and residency is one of the things it controls per tenant. It provides the controls and the evidence trail; whether a given configuration satisfies a given obligation is a determination for you and your advisers, not something a platform can certify. It registers the Kubernetes and GPU clusters you already run rather than provisioning them, and connects to the LLM gateway you already operate rather than hosting models — so the estate stays yours while the policy, scoping, metering and evidence become platform capabilities rather than spreadsheet exercises.
If AI data residency in India is currently a constraint you are managing by hand, the useful test is narrow: pick your most regulated tenant and your least regulated one, and ask whether your platform can currently offer them different catalogues, pin them to different regions, and produce a per-tenant access trail for either on demand. Start at AI Factory.
Frequently Asked Questions
Does India require data localisation for AI workloads?
Not as a general rule. On the face of the DPDP Act, cross-border transfer runs on a negative list: cross-border transfer is permitted by default and the government may restrict transfer to a named country. No country has been notified and the relevant section has not commenced. AI data residency in India is instead governed by sectoral rules from RBI, IRDAI, SEBI, CERT-In, DoT and MeitY, which apply to specific industries and specific data types.
When does the DPDP Act actually take effect?
The DPDP Rules were notified on 13 November 2025. Procedural provisions took effect immediately, consent manager registration opens on 13 November 2026, and every substantive obligation — notice, security safeguards, breach notification, children’s data, significant data fiduciary duties and cross-border transfer — commences on 13 May 2027.
Which Indian rules actually require data to stay in the country?
Seven instruments carry location or evidence requirements on their published terms: RBI’s 2018 circular for payment system data, IRDAI’s 2025 regulations for insurance records, SEBI’s 2023 cloud framework for regulated market entities, CERT-In’s 2022 directions for logs and KYC, the DoT authorisation rules of July 2026 for telecom networks, MeitY empanelment and MeghRaj for government workloads, and DPDP Rule 13(4) as a reserve power from May 2027.
What changed for AI data residency India in July 2026?
The Department of Telecommunications notified rules requiring the systems themselves — not merely the data — to sit inside India for authorised telecommunication networks, and created a new cloud-hosted telecommunication network provider category. It applies without exemption and is, on its face, the most restrictive of the seven currently in force. Whether an Indian subsidiary of a foreign cloud provider satisfies it is unresolved.
Can one platform serve tenants with different residency obligations?
Yes, provided residency is enforced per tenant rather than per estate. That requires region pinning at provisioning time, catalogue scoping so non-compliant options are never offered to a regulated tenant, log retention inside India for the required window, and per-tenant evidence that can be produced on demand. Running a separate deployment per compliance profile works, but destroys utilisation.
Does “sovereign AI” in India mean data must stay in India?
No. In Indian policy, sovereign AI refers to indigenous capability — the twenty models backed under the IndiaAI Mission, trained on Indian data and languages. The India AI Governance Guidelines of February 2026 are explicitly voluntary and India has no AI statute. Sovereignty is an industrial-policy objective; residency obligations come from the sectoral rules.
References
- MeitY — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) (gazette PDF)
- Reserve Bank of India — FAQ on Storage of Payment System Data
- SEBI — Framework for Adoption of Cloud Services by SEBI Regulated Entities
- CERT-In — Directions under Section 70B(6) of the IT Act, 28 April 2022
- MediaNama — DoT notifies Telecommunications (Authorisation for Telecommunication Network) Rules, 2026
- Press Information Bureau — India AI Governance Guidelines, 15 February 2026
- Press Information Bureau — IndiaAI Mission backgrounder
- MeitY / PIB — DPDP Rules explainer, including penalty tiers
- AWS — MeitY empanelment requirements and scope
- Google Cloud — MeitY empanelment, Mumbai and Delhi regions
- Mondaq — From localisation debates to a negative list: cross-border data transfers under India’s DPDP Act
- Mondaq — DoT notifies Telecom Network Authorisation Rules, 2026: what has changed
- LiveLaw — India’s Data Protection Board: established in law, absent in fact