"Where does the data live?" used to be a question for the ops team. If you build software in India, it's now a board-level one. The short answer under the Digital Personal Data Protection Act is more relaxed than most people expect, but it has sharp edges. So let's get into how Rule 15's negative-list model for cross-border transfer works, when data really does have to stay in India, and how to architect your identity and verification stack so residency is a setting, not a rewrite.

This is general information, not legal advice. Talk to qualified counsel about your specific obligations.

The permissive default in Rule 15

The headline most engineers get wrong: by default, the DPDP Act doesn't force you to keep personal data inside India.

Section 16 of the Digital Personal Data Protection Act, 2023 lets the Central Government restrict transfer of personal data to countries it notifies. The drafting is a "blacklist" or negative-list approach, not a whitelist. In plain terms: transfers are allowed unless the destination is specifically called out as off-limits.

The draft Digital Personal Data Protection Rules, 2025 carry this forward. Rule 15 deals with cross-border transfer and sets the operating model: a Data Fiduciary may transfer personal data outside India, subject to any restrictions the Government notifies for specific countries or categories of personal data. There is no general "store everything in India" mandate baked into the base law.

This matters because India's earlier draft bills floated hard localization, including "mirror a copy in India" and "critical data stays in India" language. The 2023 Act stepped back from that. The default posture for ordinary personal data is now permissive, which is a meaningful shift for any team that learned data residency under the older Personal Data Protection Bill drafts.

So the starting point is: you can transfer, until told otherwise. The rest of this post is about the "otherwise."

How the negative list works

A negative list flips the usual compliance question. Instead of asking "is this country approved?", you ask "is this country on the restricted list?" If it is not, the transfer is permitted under DPDP, provided you still meet every other obligation in the Act (lawful purpose, consent or a legitimate use, notice, security safeguards, and so on).

Here is the practical difference between the two models.

Model	Question you ask	Default outcome	Examples
Whitelist (allowlist)	Is this destination explicitly approved?	Blocked unless approved	EU adequacy decisions under GDPR
Negative list (blocklist)	Is this destination explicitly restricted?	Allowed unless restricted	DPDP Rule 15 cross-border transfer

A few things follow from the negative-list design:

The restricted list is not yet populated in the way you might expect. Until the Government notifies specific countries or categories, the operative restriction is light. You should track MeitY notifications, because the list can change with a gazette notification rather than a fresh statute.
Sectoral and contractual restrictions still apply on top. DPDP being permissive does not override a sector regulator that says otherwise, and it does not override a contract clause you signed with a customer or a foreign data exporter. More on the sector angle below.
The transfer must still be lawful end to end. A permitted destination does not excuse a missing consent, a vague notice, or weak encryption. Localization is one dimension; the rest of the Act still governs.

If your stack already separates "may we process this?" from "where may it physically sit?", the negative list slots in cleanly. If those two questions are tangled together in your code, now's a good time to pull them apart.

Stricter rules for significant data fiduciaries

Not every organisation is treated the same. The Act creates a heavier-duty class called the Significant Data Fiduciary (SDF).

Under Section 10 of the Act, the Central Government can designate an entity, or a class of entities, as an SDF based on factors such as the volume and sensitivity of personal data processed, risk to data principals, risk to electoral democracy, security of the State, and public order. SDFs carry extra duties: appointing a Data Protection Officer based in India, appointing an independent data auditor, and conducting periodic Data Protection Impact Assessments.

The draft Rules add a sharper edge for residency. Reporting around the Digital Personal Data Protection Rules, 2025 indicates the Government may specify certain personal data, and traffic data about that data, that an SDF must keep within India even where transfer would otherwise be permitted. In other words, the permissive default can be narrowed for SDFs by notification, and a committee mechanism is contemplated to identify which categories carry that constraint.

The takeaway for architecture: if there is any chance your organisation is or becomes an SDF, do not bake a "data can live anywhere" assumption into immovable infrastructure. Design so that a future notification saying "this category stays in India" is a configuration change, not a migration project. Whether you are a fiduciary or a processor changes who carries which duty here, and that distinction is worth getting right early. We cover it in data fiduciary vs data processor.

Sectoral rules (RBI and payments)

DPDP is the general-purpose law, but it sits alongside sector regulators that already impose hard localization. Payments is the clearest example.

The Reserve Bank of India's 2018 directive on Storage of Payment System Data requires that the entire payment data of system providers be stored only in India. End-to-end transaction details and the information collected, carried, or processed as part of the message or payment instruction must sit on systems located within the country. For cross-border transactions involving a foreign leg, a copy may be stored abroad, but the India-resident copy is mandatory.

This is genuine, in-force localization, and it predates DPDP. DPDP's permissive cross-border posture does not relax it. If you touch card data, UPI, wallets, or any regulated payment flow, RBI's rule is the binding constraint, and it is stricter than the DPDP default.

The same pattern shows up elsewhere. Sector-specific guidance from regulators in telecom, insurance, and government data handling can each impose storage or processing constraints that are tighter than the Act. The mental model to keep:

DPDP sets the floor for personal data generally. A sector regulator can raise that floor for the data it governs. You comply with whichever is stricter.

Practically, that means your residency policy cannot be a single global switch. It has to be data-category aware. Payment instrument data follows RBI. General profile data follows DPDP. Verification artefacts may follow their own issuing-authority rules. You want one mechanism that can express all three.

Penalties and risk

The reason this is not academic: DPDP has teeth.

Schedule to the Act sets monetary penalties for breaches, adjudicated by the Data Protection Board of India. The standout figure is up to ₹250 crore for failure to take reasonable security safeguards to prevent a personal data breach, and up to ₹250 crore for breach of obligations in connection with certain duties, with other categories carrying their own caps. Penalties are per instance of breach, and the Board weighs the nature, gravity, and duration of the violation when it decides the amount. You can read the penalty structure in the Act text.

Two risk dimensions matter for residency specifically:

Transfer to a restricted destination after notification. Once the Government notifies a restricted country or category, continuing to transfer there is a compliance failure. If your data flows are opaque, you will not even know you are exposed.
Breach response obligations. A localization mistake often surfaces during a breach, when regulators ask exactly where the data was and who could reach it. Your breach notification clock and your audit trail both get scrutinised. We cover the timeline in DPDP breach notification within 72 hours, and the records you need in DPDP audit trail requirements for engineers.

The cheapest insurance is knowing, at any moment, where each category of personal data physically resides and being able to prove it. That is an architecture problem, which brings us to the last section.

Architecting for residency

Residency is easiest when it is a property of your system rather than a heroic one-off. A few principles, and then how NamoID is built to support them.

Make residency a per-tenant setting, not a global constant. Different customers, and different data categories, may carry different obligations. If "where does this live?" is hard-coded, every new requirement is a re-platforming. If it is a setting, it is a config change.

Separate the issuer from the data plane. A single OpenID Connect issuer URL can front authentication and India verification rails while the underlying data is partitioned by region. Your apps integrate once against standard OIDC discovery and JWKS; residency decisions happen below that surface.

Minimise what you store, especially for verification. The strongest residency posture is not storing sensitive data at all. For Aadhaar offline e-KYC, for example, you can verify a signed XML in memory and persist only a masked result rather than the full document.

NamoID is built around these ideas:

One OIDC issuer URL for OAuth 2.1 authorization-code flows, OIDC discovery, and a JWKS endpoint. PKCE is enforced on every flow, including first-party, with no implicit grant. If that flow is unfamiliar, start with PKCE explained and OAuth 2.1 vs 2.0.
A data-residency hint per organisation, designed so that India data can be kept in India and a future "this category stays in India" notification is a setting rather than a migration.
Multi-tenant isolation scoped by organisation, so one customer's data is never reachable from another's.
Masked India verification by design. For Aadhaar offline XML, only the last four digits, a name-hash, and the signature-verification result are stored; the full XML is processed in memory and never persisted. See our walkthrough of Aadhaar offline e-KYC XML verification.
An append-only events table that records every state change, giving you a DPDP-grade audit trail and a Data Subject Access Request export of a user's full event history plus connected providers. Deletion cascades a soft-delete and writes a tombstone event, so you can prove what happened and when.
Encryption at rest for provider tokens using AES-256-GCM, so the credentials that connect downstream services are not sitting in plaintext.

Because your apps only ever talk to standard endpoints, a residency change does not ripple into client code. A minimal OIDC discovery call looks the same regardless of where data sits:

curl https://issuer.example.com/.well-known/openid-configuration

And a standard authorization-code request with PKCE is just the spec, per oauth.net:

GET /authorize?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https://app.example.com/callback
  &scope=openid%20profile
  &code_challenge=BASE64URL_SHA256_OF_VERIFIER
  &code_challenge_method=S256
  &state=xyz

The point is that residency, audit, and verification live behind the issuer. Your integration does not change when the policy does.

For the broader case of consolidating auth, India rails, and DPDP duties behind one issuer, see one OIDC issuer URL for India, and for the full compliance picture, the DPDP compliance checklist for SaaS.

FAQ

Does DPDP require all personal data to be stored in India?

No. The base law and the draft Rule 15 use a negative-list model: cross-border transfer is permitted unless the Government notifies a specific country or category as restricted. The exceptions are sector rules, such as RBI's payment-data directive, and any future notification narrowing residency for certain data or for Significant Data Fiduciaries. This is general information, not legal advice.

What is the negative list in Rule 15?

It is the list of countries or data categories the Central Government may notify as off-limits for transfer. Anything not on that list is permissible under DPDP, provided every other obligation in the Act is met. The list is set by notification, so it can change without a new statute.

Do RBI payment localization rules still apply under DPDP?

Yes. RBI's 2018 Storage of Payment System Data directive requires the full payment data to be stored only in India and is unaffected by DPDP's more permissive default. Where two rules apply, you follow the stricter one.

How should I design for India data residency?

Treat residency as a per-tenant, per-category setting rather than a global constant, separate your issuer from the data plane so apps integrate once, and minimise stored sensitive data. NamoID is built to support this with a per-organisation residency hint, masked verification, and an append-only audit trail.

Talk to us

NamoID is built to make residency, audit, and India verification a setting rather than a rewrite. If you want to see how the single-issuer model fits your stack, book a 30-minute demo or reach the team at hello@namoid.in. We are pre-launch and happy to walk through the architecture before you commit to anything.