Data localisation in India: which rules apply, and how to check your own systems
Data localisation means a law or regulator requires certain data to be stored, and sometimes processed, only in India. Payment data under RBI rules is the best-known case. The DPDP Act adds powers to restrict transfers, and the data usually leaks abroad through backups, support tools and cloud services, not the main system.
Most companies believe their data is in India because their main servers are. Then someone checks the backups, the email tool, the helpdesk and the analytics platform, and finds copies in three other countries.
That is the gap data localisation rules are written to close. This guide explains what the term means, which Indian rules apply today, and how to check your own systems.
What data localisation means
Data localisation is a legal requirement that certain data stays inside a country. It is stricter than data residency, which only describes where data happens to be stored, often by choice. And it is narrower than data sovereignty, which is about whose laws apply and who can reach the data. Our guide to sovereignty, residency and localisation explains all three with a short quiz.
Localisation rules come in two strengths:
- Store only in India. The data must live here. Copies abroad are not allowed, or must be brought back quickly.
- Restrict transfers. Data can leave, but not to certain countries, or only under conditions.
The Indian rules that apply today
RBI: payment system data
Since the April 2018 circular, payment system operators must store the full data about payment transactions only in India. Processing abroad is allowed, but the data must come back to India.
CERT-In: system logs
The April 2022 directions require service providers and companies to keep logs of their ICT systems for 180 days, within Indian jurisdiction.
DPDP Act, Section 16
The government may block transfers of personal data to countries it notifies. Stricter sector rules, like the RBI's, still apply on top.
DPDP Rules, Rules 13 and 15
Significant Data Fiduciaries can be told to keep named categories of data in India. Other transfers follow conditions the government may set.
Two things follow from this. First, there is no single "localisation law" in India. The rules depend on your sector and the type of data. Second, the DPDP Act uses a "negative list": transfers are allowed unless the government blocks a country. That list can change, so your setup needs to be able to change with it.
If you may be named a Significant Data Fiduciary, read that guide too. Rule 13 is where the strictest localisation duty for personal data sits.
Where data quietly leaves the country
The main database is rarely the problem. These are the usual leaks:
- Backups and disaster recovery. A second region chosen for safety is often in another country.
- Software-as-a-service tools. CRM, email, helpdesk and survey tools may store data abroad by default.
- Support access. A vendor's support team abroad that can log in and see records.
- Logs and monitoring. Error trackers and log platforms copy request data, sometimes including personal data.
- AI and analytics services. Sending records to an outside model or analytics API sends the data with them.
- Spreadsheets and email. An export emailed to a colleague or partner abroad.
Check your own setup
Tick a line only if you can show the proof, such as a contract clause, a region setting or a log.
Does a local cloud region solve it?
Partly. An Indian cloud region keeps the data stored here, which meets most "store in India" rules. But the provider may still be subject to another country's laws, and its support teams may sit elsewhere. Whether that matters depends on your regulator and your risk appetite. For data you must control fully, running on your own servers or a private cloud removes the question.
A simple plan
- List the data that has a rule. Payment data, logs, and any personal data your regulator names.
- Trace every copy. Use the checklist above, system by system.
- Fix the leaks in order of risk. Backups and support access usually come first.
- Write it down. A dated map of where each type of data lives is the proof an inspector asks for.
- Recheck when tools change. A new SaaS tool can undo the work in a day.
Where Samvrik fits
Samvrik runs entirely inside your own environment: your servers or your private cloud, air-gapped if needed. RUSH never hosts your data and the platform needs no outside connection to work. Data that must stay in India stays there, and every access is logged inside your walls. See how Samvrik works.
Sources: RBI circular on Storage of Payment System Data (6 April 2018) and its FAQs; CERT-In directions under Section 70B(6) of the IT Act (28 April 2022); Digital Personal Data Protection Act, 2023, Section 16; DPDP Rules, 2025, Rules 13 and 15. Plain summary, not legal advice.
Common questions
What is data localisation?
A legal requirement that certain data is stored, and sometimes processed, only inside a country. In India, payment system data under RBI rules is the best-known example.
Does the DPDP Act require all personal data to stay in India?
No. Section 16 lets the government block transfers to countries it notifies, and stricter sector rules still apply. Significant Data Fiduciaries can also be told to keep named categories of data in India.
What is the difference between data localisation and data residency?
Residency describes where data is stored, often by choice. Localisation is a rule that says it must be stored in the country.
Does using an Indian cloud region meet localisation rules?
It usually meets "store in India" rules. But backups, support access and outside tools can still send copies abroad, so check each of them too.
How long must logs be kept in India?
The CERT-In directions of April 2022 require logs of ICT systems to be kept for 180 days, within Indian jurisdiction.