# Data localisation in India: keep the right data here, and prove it

Source: https://dpdp.miravlabs.com/services/data-localisation-india/ · Updated 2026-11-13 · DPDP Ready by Mirav Labs

**Short answer:** The DPDP Act does not impose general data localisation. Section 16 lets the government restrict transfers to notified countries, and none is notified. Rule 13(4) may require significant data fiduciaries to keep government-specified data in India; no list exists yet. Sector rules can be stricter: RBI requires payment system data to be stored only in India. We engineer residency you can prove: region, keys, backups, DR and access.

## In plain words

The DPDP law does not say all personal data must stay in India. The government can block transfers to certain countries later, but it has not blocked any. Some regulators already go further. RBI, for example, requires payment data to be stored only in India. If your data must stay here, every copy and every route counts, not just the main server.

- **None** countries blocked under DPDP so far
- **24 hours** at most for payment data processed abroad to come back (RBI)
- **13 May 2027** when the DPDP transfer rules start

### What it means for you

- Most businesses can still use servers and tools abroad under DPDP today.

- Banks, payment firms, stockbrokers and insurers may have to keep some data in India under their own regulator's rules.

- Very large data handlers may later be told to keep certain data in India. No list exists yet.

- Backups, recovery copies, logs and support staff abroad can all move data out of India without anyone noticing.

- Where your encryption keys sit decides who can really read the data.

**Example:** A payments start-up in Bengaluru hosts its app in an Indian cloud region. A review finds its backups copy to a region abroad and its error-logging tool stores card transaction details overseas. It moves both to India and keeps a short list showing where every copy lives.

### What to do

- Find out which of your data must stay in India, by law or by contract.

- Host that data in India, and block it from being created anywhere else.

- Keep the encryption keys under your control, in India.

- Keep backups and disaster recovery copies in India too, and test them.

- Write down where each copy lives and which vendors can reach it.

The law: section 16 of the DPDP Act and Rules 13(4) and 15 of the DPDP Rules, 2025, plus your sector regulator's rules. The DPDP parts apply from 13 May 2027.

## The detailed guide

## Key takeaways

- DPDP allows transfers abroad unless a country is notified under section 16; none has been notified.
- Stricter sector rules keep applying (section 16(2)): RBI for payment system data, SEBI for regulated entities using cloud, IRDAI for insurance records.
- Residency is more than a region setting: keys, backups, DR, logs, support access and sub-processors all count.
- Classify first, then place, encrypt, back up and prove, in that order.
- Keep a residency evidence pack and vendor list so you can show where data lives, not just say it.

Data localisation is easy to misread. It is tempting to assume the DPDP Act requires all personal data to sit in India, and to spend months moving systems the law never asked you to move. It is just as easy to assume an Indian cloud region settles everything, and to miss the backup replica, the logging tool or the key service that quietly sends copies abroad.

This page sets out what actually requires data to stay in India today, and how our engineering, cloud and privacy team designs and builds residency that holds up when someone asks you to prove it. We work alongside your legal counsel, who confirms which rules apply to you; we turn that answer into architecture, configuration and evidence.

## Does DPDP require data localisation?

Not generally. [Section 16(1)](https://dpdp.miravlabs.com/guides/dpdp-cross-border-data-transfer/) lets the Central Government, by notification, restrict the transfer of personal data to a country or territory outside India. It is a negative list: transfers are allowed unless a destination is notified. As of 13 November 2026, no country or territory has been notified.

Three things can still keep data in India:

- **Stricter laws continue.** Section 16(2) says the section does not limit any other Indian law that gives a higher degree of protection or a stricter restriction on transfers. Sector rules therefore apply alongside DPDP.

- **Rule 15 orders.** Transfers are subject to any requirements the government sets by general or special order on making personal data available to a foreign State or an entity it controls. No order has been issued.

- **Significant data fiduciaries.** Under Rule 13(4), a [significant data fiduciary](https://dpdp.miravlabs.com/guides/significant-data-fiduciary/) must make sure that personal data the government specifies, on a committee's recommendation, and the traffic data about its flow, is not transferred outside India. No SDF and no such list has been notified.

Section 16 and Rule 13 come into force on 13 May 2027. A breach of section 16 has no separate line in the penalty Schedule, so it falls under "any other provision", with a ceiling of ₹50 crore. The official texts are on the [MeitY data protection page](https://www.meity.gov.in/data-protection-framework).

What DPDP does today
- Allows transfers abroad by default
- Keeps you responsible for processors abroad (section 8(1))
- Lets stricter sector laws apply (section 16(2))
- Gives the government powers it has not yet usedWhat can still require India
- Sector rules: payments, securities, insurance
- A future section 16 notification or Rule 15 order
- A Rule 13(4) list, if you are notified as an SDF
- Customer contracts and tender terms

## Which sector rules require data to stay in India?

These are the binding limits for many organisations today. The summary below reflects the official texts we checked; confirm the current version and your exact scope with counsel before you design around it.

| Regulator | Instrument | What it requires | Engineering impact |
|---|---|---|---|
| RBI | Storage of Payment System Data, 6 April 2018 | Authorised payment system operators must store the entire data relating to payment systems they operate in a system only in India. For the foreign leg of a transaction, data may also be stored abroad. | Every store of payment data, including logs, analytics and backups, sits in India |
| RBI | FAQs on the same direction | Processing abroad is allowed, but the data must then be deleted abroad and brought back to India within one business day or 24 hours of processing, whichever is earlier. The data covered includes customer details, payment credentials and transaction details. | Any offshore processing step needs a tested deletion and return path |
| SEBI | Framework for adoption of cloud services, 6 March 2023, with SEBI's June 2025 FAQs | The FAQs say storage and processing of data, including logs, must be in data centres of MeitY-empanelled cloud providers holding valid STQC certification or equivalent audit status, and that encryption keys and key management operations must be handled within India. They also noted that SEBI was consulting on final data localisation guidelines. | Provider and data centre checks, keys in India, sub-contractor clauses |
| IRDAI | Maintenance of Information by the Regulated Entities and Sharing of Information by the Authority Regulations, 2025 | Records of policies issued and claims made in India, including electronic records, must be held in data centres located and maintained in India only (proviso to Regulation 9, as described in an IRDAI agenda note) | Policy and claims systems, their backups and DR in Indian data centres |
| Your customers | Contracts, tenders, security questionnaires | Often ask for hosting, support or keys in India | Treat as a requirement once signed |

Other sectors, government work and telecom can carry their own conditions. We do not interpret them for you; we ask counsel for the answer and record it, with the source, in a residency requirements register. If you are in financial services, the [DPDP for fintech guide](https://dpdp.miravlabs.com/guides/dpdp-for-fintech/) shows how DPDP sits alongside RBI rules.

## Data residency, localisation and sovereign cloud: what is the difference?

The terms get used interchangeably, but they answer different questions, and the design depends on which one you need.

- **Data residency** is where your data is stored and processed. It can be a choice you make for latency, customer trust or a contract.

- **Data localisation** is a legal requirement to keep specified data in India, like the RBI, SEBI and IRDAI rules above.

- **Sovereign cloud** has no single legal definition in India. In practice it adds control: who operates the environment, where the keys sit, who can reach the data for support, and which laws could compel access.

There are three common shapes. An Indian region of a public cloud, with guardrails that stop resources being created elsewhere, suits most needs. A private cloud in Indian data centres gives you more control over operators and hardware, at the cost of running more yourself. A hybrid keeps the regulated core private and runs everything else in a public Indian region. We help you choose on requirements, cost and your team's ability to operate it, without tying the design to any one vendor.

## How we engineer data residency: five steps

Every engagement follows the same five steps, in this order. Skipping the first tends to leave residency work either too broad or full of gaps.

### 1. Classify: which data must stay in India

We start from the requirements register and map data to it: which data sets are covered by law, which by contract, and which you simply prefer to keep in India. The map includes the copies people forget: logs, traces, error reports, analytics events, search indexes, data warehouse extracts, test data copied from production, and files sent to [AI tools and model APIs](https://dpdp.miravlabs.com/services/enterprise-data-readiness-for-ai/). For an SDF, Rule 13(4) also covers the traffic data about the data's flow, so network and flow logs belong on the map.

### 2. Place: Indian regions or private cloud

We design the target architecture and pin covered workloads to Indian regions or your private cloud. Placement is enforced as code: organisation-level policies that refuse to create storage, databases or compute outside approved regions, and checks in the deployment pipeline that fail a change that would. We review the services that are global by default, such as content delivery, DNS, email, monitoring and support tooling, and either configure them for India or keep covered data out of them.

### 3. Encrypt: keys you control

Rule 6(a) lists encryption, obfuscation, masking and virtual tokens among the reasonable security safeguards. For residency, the question is where the keys live and who can use them. We typically design customer-managed keys held in India, in a key service or hardware security module, with separate key administrators, logged key use and a rotation plan. SEBI's FAQs make the point directly: an Indian region that routes key management through another country may not meet its expectations. Tokenising or masking covered fields before they reach analytics or support systems also shrinks the area you have to keep in India.

### 4. Back up: backups and disaster recovery in India

Rule 6(d) names continuity measures such as backups, and Rule 6(e) requires logs and personal data to be kept for one year for detection, investigation and continuity, unless another law says otherwise. Where data must stay in India, we place both the backup copies and the disaster recovery site in India, typically in separate regions or data centres so one event does not take out both. We switch off any default cross-border replication, keep backup keys in India, and run a restore test that measures recovery time against your targets. Our [ransomware readiness](https://dpdp.miravlabs.com/services/ransomware-readiness/) work adds immutable and offline copies on the same design.

### 5. Prove: residency evidence and vendor list

Saying data is in India is easy; showing it is the work. We build a residency evidence pack: the requirements register, the data map, region policy exports, key locations, backup and DR locations, restore test results, and a vendor and sub-processor list with storage and access countries. Section 8(1) keeps you responsible for your processors, so the list sits alongside your [processor contracts](https://dpdp.miravlabs.com/guides/data-fiduciary-vs-data-processor/). Automated checks re-run the region and replication tests on a schedule, so drift shows up as an alert rather than in an audit.

## Who can reach the data? Vendors, support staff and remote access

Data stored in India can still be read from abroad: by a vendor's support engineer, a managed service team, a global security operations centre or your own staff travelling. In our reading, remote access of that kind can amount to data leaving India, so for strict rules we design as if it does, and counsel confirms the position for your sector.

- **Access by default is none.** Administrative and support access is granted just in time, for a stated task, and expires.

- **Location is part of the decision.** Access to covered systems is limited to approved locations and devices, with exceptions logged.

- **Every access is visible.** Rule 6(c) expects visibility of access through logs, monitoring and review; we route these logs to a store in India.

- **Contracts match the design.** Vendor agreements state storage and access locations, sub-processors, notice of changes, and help to move or restrict access if the law changes. Rule 6(f) expects safeguards to be written into processor contracts.

The same controls support the wider [Rule 6 security safeguards](https://dpdp.miravlabs.com/guides/dpdp-security-safeguards/), and the access logs are what you will need if you ever have to report a [personal data breach](https://dpdp.miravlabs.com/guides/dpdp-breach-notification/).

## What does an engagement look like, and what do you get?

A typical engagement starts with discovery: workshops with engineering, security, infrastructure and the owners of regulated systems, a review of your cloud accounts and vendor list, and a requirements session with your counsel. We then design, build with your team, run the restore and region tests, and hand over. Scope depends on the size of your estate, the number of rules that apply and how much is already in place, and we agree it with you at the start.

| Deliverable | What it is | Why it matters |
|---|---|---|
| Residency requirements register | Each rule or contract term, the data it covers and its source, as confirmed by counsel | Keeps the design tied to real obligations, not assumptions |
| Data and copy map | Covered data sets and every copy: logs, backups, analytics, test data, AI tools | Finds the paths that leave India |
| Target architecture | Regions, private cloud or hybrid, network and global-service decisions | One agreed design for the team to build |
| Region guardrails as code | Policies and pipeline checks that block resources outside approved locations | Prevents drift after go-live |
| Key management design | Key locations, custody, roles, rotation and logging | Control over who can read the data |
| In-country backup and DR plan | Backup and recovery locations, replication settings and a restore test report | Evidence for Rule 6(d) continuity measures within India |
| Access model | Just-in-time support access, location limits and access logging | Closes the remote-access route |
| Residency evidence pack | Configuration exports, test results, vendor and sub-processor locations | Lets you show a regulator, auditor or customer where data lives |

We aim to leave you with controls your team runs and evidence that they work. We do not give legal opinions: which rules apply, and how a regulator reads them, is for your business and its counsel. We do not promise any regulatory outcome. Residency often runs alongside our [privacy engineering](https://dpdp.miravlabs.com/services/dpdp-privacy-engineering/) work for the wider DPDP programme; the full list is on the [services page](https://dpdp.miravlabs.com/services/).

## How to start

- Ask counsel which sector rules, contracts and tenders require data to stay in India, and write the answers down with sources.

- List every system and vendor that stores or can access that data, including logs, backups and support tools.

- Check where your encryption keys, backup copies and disaster recovery site actually are.

- Turn on region restrictions for covered workloads, and test that a resource outside India is refused.

- Watch for any section 16 notification, Rule 15 order or Rule 13(4) list, and review the register when one appears.

These steps sit well with the [cross-border transfer guide](https://dpdp.miravlabs.com/guides/dpdp-cross-border-data-transfer/) and your vendor-location register. If you would like us to map your data, design the residency architecture and build the evidence pack with your team, [book a scoping call](https://dpdp.miravlabs.com/#contact).

## Frequently asked questions

### Does DPDP require data localisation?

Not generally. Section 16 allows personal data to be transferred outside India unless the government restricts a country by notification, and none has been notified. Rule 13(4) may require significant data fiduciaries to keep data the government specifies in India, but no fiduciary and no data list has been notified yet.

### What is the difference between data residency and data localisation?

Data residency describes where your data is stored and processed, often a business or contract choice. Data localisation is a legal requirement to keep certain data in a country, such as RBI's direction on payment system data. Sovereignty goes one step further and asks who controls the data and keys, and which laws can reach them.

### Does RBI require data to be stored in India?

Yes, for payment system data. RBI's April 2018 direction requires authorised payment system operators to store the entire data relating to the payment systems they operate in a system only in India. RBI's FAQs allow processing abroad, but the data must then be deleted abroad and brought back within one business day or 24 hours, whichever is earlier.

### Is hosting in an Indian cloud region enough for data localisation?

Usually not on its own. Copies can still leave India through backups, disaster recovery replicas, logs and monitoring tools, global services such as content delivery or email, key management, and support staff abroad. A residency design checks each of these paths and records the evidence.

### Do backups and disaster recovery have to stay in India?

Where a rule requires data to be kept in India, backups and disaster recovery copies are copies of that data, so in our reading they should stay in India too. That usually means a primary and a recovery site both in India, tested restores, and keys that do not depend on systems abroad. Confirm the exact scope of your sector rule with counsel.

### What is sovereign cloud in India?

There is no single legal definition. In practice it means hosting in India with control over who can operate the environment, where encryption keys sit and which laws can compel access. It can be an Indian region of a public cloud with tight controls, a private cloud in Indian data centres, or a mix of the two.