Data localisation is the requirement to store data inside a country’s borders, and in India it is not one rule but several sectoral rules that apply to different kinds of data.
The short answer
Data localisation, also written data localization, means keeping data physically within a jurisdiction. India has no single localisation statute. The strictest rule is the RBI directive of 6 April 2018, which requires payment system data to be stored only in India. CERT-In requires logs to be maintained within Indian jurisdiction. The DPDP Act, contrary to a widespread assumption, does not impose general data localisation. Which rule binds you depends on what data you hold and who regulates your customer.
That distinction matters commercially. Teams routinely over-engineer for a DPDP requirement that does not exist while missing a payment rule that does.
On this page
What data localisation means
Localisation sits on a spectrum. At the soft end, a copy must be kept in-country while the original may travel. In the middle, data may be processed abroad but must return and be deleted overseas. At the hard end, the data may never leave. India uses all three, in different sectors, at the same time.
Which rule applies to which data
| Data | Source of the obligation | Effect |
|---|---|---|
| Payment system data | RBI directive on storage of payment system data, 6 April 2018 | Store in India |
| Security and system logs | CERT-In Directions, 2022 | Maintain in India |
| Insurance records | Insurance record-keeping regulations | Hold in India |
| General personal data | DPDP Act, Section 16 and Rule 15 | Transfer allowed by default |
| Specified categories held by a significant data fiduciary | DPDP Rules, Rule 13 | Blocked once notified |
Section 16 of the DPDP Act also preserves any Indian law that sets a higher bar. The payment rule is not softened by the newer statute. It sits on top.
The DPDP misconception
Early drafts of India’s privacy legislation did contain broad data localisation. The version that became law did not. Under Section 16 and Rule 15, personal data may be transferred outside India except to countries the Central Government specifically restricts, and no such list has been notified. This is a negative-list model, the opposite of an adequacy regime.
What this means in practice
For an ordinary SaaS company, an e-commerce platform or a marketing tool, there is currently no general DPDP obligation to keep personal data on Indian servers. There is also no requirement to adopt standard contractual clauses, binding corporate rules or transfer impact assessments. Those are GDPR constructs with no Indian equivalent, and retrofitting them is wasted effort.
Two caveats keep this from being a free pass. Rule 13 lets the government bar a significant data fiduciary from moving specified categories of personal data offshore, and once notified that is absolute. And the cross-border provisions come into force on a staggered timetable following the notification of the DPDP Rules on 13 November 2025, so the position can change with a single gazette notification. Mapping your flows now is the cheap version of that risk.
Payment data, the strictest rule
The RBI directive covers the full end-to-end transaction detail and any information collected, carried or processed as part of the payment message or instruction. Storage is India-only. Where a transaction has a foreign leg, the data may be processed abroad, but it must be deleted from the foreign systems and brought back within the permitted window.
| What auditors actually check | What satisfies it |
|---|---|
| Where the data physically resides | Region-pinned infrastructure with cloud posture management proving no resource drifted to a foreign region |
| End-to-end data flow, including every third party | Current flow maps that match the running system, not last year’s architecture |
| Backups, replicas and disaster recovery copies | The same residency rule applied to every copy, which is where most teams are caught out |
| Logs, analytics pipelines and monitoring tools | Confirmation that observability vendors are not silently exporting payment fields |
| Deletion after offshore processing | Evidence of purge, not an assertion that purge happens |
| Access from outside India | Controlled remote access with multi-factor authentication and full session logging |
Proving data localisation, not just doing it
Compliance and evidence of compliance are different projects. A payment system operator demonstrates data localisation through a System Audit Report prepared by a CERT-In empanelled auditor and filed annually with the RBI. The auditor is not looking for a policy document. They are looking for storage locations, flow diagrams, deletion records and access trails that agree with each other.
This is where the failure mode lives. Architecture is usually compliant. The evidence for it usually is not, because nobody was generating it while the system was being built.
How Osto gets you audit-ready
Osto covers the technical side of data localisation by default rather than as add-ons. Cloud posture management across AWS, Azure and GCP catches resources created outside an approved region before an auditor does. API discovery surfaces the integrations that quietly move data offshore. Data loss prevention and encryption at rest and in transit handle the protection side, and correlated logging produces the retained trail the CERT-In Directions expect to see held in India.
The evidence layer is purpose-built for this. One control set answers an RBI reviewer, a payment aggregator customer’s vendor questionnaire, SOC 2 and ISO 27001 together. Osto prepares your evidence and gets you through the review. The mandated audit is performed by the empanelled auditor.
Free security assessment
Know where your data actually lives
Osto maps your cloud footprint, catches resources outside approved regions, and holds the evidence an auditor asks for. Cloud posture, VAPT, logging and compliance in one platform.
Get a free security assessment Book a platform walkthroughAudit-ready in days · RBI, SEBI and DPDP mapped · One platform, everything
Frequently asked questions
What is data localisation?
The requirement to store or process data within a defined jurisdiction. Versions range from keeping a mirror copy in-country, through allowing offshore processing followed by return and deletion, to prohibiting the data from leaving at all. India applies different versions to different categories of data.
Does the DPDP Act require data localisation?
Not generally. Section 16 and Rule 15 permit transfer of personal data outside India except to countries the Central Government restricts, and no restricted list has been notified. The exception is Rule 13, under which the government may bar a significant data fiduciary from transferring specified categories of personal data offshore.
What does the RBI payment data localisation rule cover?
All data relating to payment systems operated in India, including the full end-to-end transaction detail and any information collected, carried or processed as part of the payment instruction. It must be stored only in India. Data processed abroad for a foreign leg must be deleted from those systems and brought back within the permitted window.
Do the CERT-In Directions require data localisation for logs?
They require logs of information and communication technology systems to be maintained within Indian jurisdiction for a rolling period, and produced to CERT-In when an incident is being investigated. That is a residency obligation on logs specifically, separate from any payment or privacy rule.
How do you prove data localisation to a regulator?
Through evidence rather than assertion. Storage locations, end-to-end data flow maps, backup and replica configuration, third-party integrations, deletion records and access logs all have to agree. For payment system operators this is assembled into a System Audit Report by a CERT-In empanelled auditor and filed annually with the RBI.