The data localisation matrix: where each rule actually bitesPremium

Practitioner reference for CTOs, DPOs, privacy counsel, infrastructure architects, and the compliance lead about to discover that "we host in AWS Mumbai" does not answer the localisation question · 2026-05-25 · Written from twelve years of architecting data residency across India, the EU, China, the US, and assorted other jurisdictions, and untangling the same architecture two years later when the regulator changed the rules

Why this guide exists

Data localisation is not one rule. It is a patchwork of overlapping rules from multiple regulators, in multiple jurisdictions, applying to different categories of data, with different definitions of what counts as “localised.” When a multinational SaaS asks “do we comply with data localisation?” the honest answer is: depends on which data, going to which customer, under which regulator, in which year.

I have helped maybe forty organisations work through their localisation architecture in the last twelve years. The mistakes are predictable. They assume hosting region equals data residency. They miss the sectoral overlay because their privacy lawyer focuses on the general privacy law. They build a “store everything in country X” architecture and then discover their backup vendor replicates outside the country. They satisfy one regulator’s localisation rule and inadvertently violate another’s cross-border transfer rule. The architecture decisions in the localisation space have a five-to-ten-year tail; getting them wrong is expensive to unwind.

This guide is a per-jurisdiction map of what localisation means in 2026, where each rule actually bites, what the common architectural patterns look like, and what the recurring procurement and audit findings are. It is the consolidated view I wish I had been able to hand to clients in 2018 when localisation went from a niche concern to a board-level architectural question.

The vocabulary problem

“Data localisation” can mean any of several things, and which version applies is the first thing to settle:

Storage-only localisation. Data must be stored in country X. Processing can happen anywhere. Common in older rules; rare in modern ones.

Storage-and-processing localisation. Data must be stored AND processed in country X. Processing-outside-country is a violation, even if storage is local. This is the typical modern formulation.

Primary-copy localisation. A copy of the data must reside in country X. Other copies elsewhere are permitted, sometimes subject to additional rules. This is the most common pattern in payment-and-financial-services rules.

Mirror localisation. A continuously-updated mirror must be maintained in country X. Used in some financial supervisory regimes for audit and inspection access.

Pure data residency. The data lives in country X, with no further restrictions on processing operations elsewhere. A common SaaS marketing claim that is operationally weaker than “localisation” but often conflated with it.

Cross-border transfer restriction. Not strictly localisation; rather, a restriction on the flow of data out of the country, with permitted mechanisms (consent, adequacy, contracts). The general privacy laws (GDPR, DPDPA, PIPL, etc.) use this model.

These categories are not mutually exclusive. A single dataset can be subject to all of them simultaneously under different regulators. The architectural design has to satisfy the strictest applicable rule, not the average.

India — multiple regulators, overlapping rules

India has the most layered localisation architecture of any major jurisdiction in 2026. The applicable rules:

RBI payment data localisation (the 2018 circular)

The most stringent localisation rule in Indian regulation, predating DPDPA by five years and still in force. The April 2018 Reserve Bank of India circular on Storage of Payment System Data requires that all data relating to payment systems operated in India must be stored only in India. The data is permitted to be processed abroad if necessary for the payment transaction, but a copy must be stored in India and the data must be brought back to India after processing within 24 hours.

In practice this means: if you are a payment service provider, payment aggregator, payment gateway, prepaid payment instrument issuer, payment system operator, or any vendor providing services to one of these entities such that you process payment data, your payment data must live in India.

What counts as “payment data” is interpreted broadly by RBI to include end-to-end transaction details, customer data linked to the transaction, beneficiary data, and the data the payment system needs to function. Card numbers, transaction amounts, merchant identifiers, terminal identifiers, customer phone numbers, addresses associated with the transaction — all in scope.

The recurring architecture mistake: organisations comply on the primary database, miss it on the analytics database, the backup, the log storage, or the fraud-detection vendor. RBI inspections look at the data flow end-to-end. If the analytics pipeline ships transaction records to a Snowflake instance in US-East, that is a violation even if the operational database is in Mumbai.

RBI account aggregator and lending data

The RBI Digital Lending guidelines and the Account Aggregator framework add their own data-handling rules. Account aggregator entities and the lenders consuming aggregated data are required to handle financial data per RBI specifications, with most processing required to be local. Digital lending entities must handle borrower data in compliance with the 2025 Digital Lending Directions; data localisation requirements are not as explicit as the payment circular but are interpreted similarly by RBI inspectors.

SEBI for capital markets

SEBI’s framework for cloud-based services and the broader CSCRF 2024 require capital markets intermediaries to handle customer data with sectoral specificity. The SEBI cloud framework specifies that critical data must be storable and accessible within India; cross-border cloud arrangements require explicit risk assessment and regulatory comfort.

IRDAI for insurance

The IRDAI Information and Cyber Security Guidelines 2026 include data-handling rules for insurance regulated entities. Customer data, claims data, and certain categories of operational data are expected to be storable in India. Specific localisation requirements are less explicit than RBI’s but are growing more prescriptive.

TRAI for telecom

Telecom subscriber data has been subject to localisation-style rules since the original Unified Access Service Licence conditions. The current framework, supplemented by the Telecommunications Act 2023, treats subscriber identity, location, and call detail records as data that must be storable and accessible to Indian authorities.

DPDPA Section 16 cross-border transfer

This is the general privacy regime’s cross-border rule. Section 16 follows a negative-list structure: cross-border transfer is permitted unless the Central Government has notified a restriction on a specific country or territory. As of May 2026 the Central Government has not issued the restriction notification. This is the most permissive of the Indian rules; sectoral rules override it where stricter.

MeitY IT Rules 2021/2026

The Intermediary Guidelines and Digital Media Ethics Code Rules impose data-handling requirements on significant social media intermediaries and certain digital intermediaries, including requirements around data accessibility to Indian authorities. The 2026 amendments around AI-generated content add marking and traceability requirements that intersect with data residency for AI workloads.

The CERT-In Direction 70B layer

CERT-In Direction 70B (April 2022, refreshed in 2024) requires 6-hour incident reporting, 180-day log retention, and KYC verification for VPN and cloud services. Not strictly localisation, but it creates strong incentive to keep logs and KYC data accessible from India.

Section 38 of DPDPA — the conflict-of-laws rule

When sectoral rules are stricter than DPDPA, the sectoral rules apply. Section 38 codifies this. For Indian SaaS operating across regulated sectors, the operational consequence is that the strictest applicable rule from any sectoral regulator becomes the binding constraint, and DPDPA is the baseline floor.

The Indian architecture pattern that works

For Indian SaaS handling multiple data classes, the architecture that survives audit is segmented: payment data in a dedicated Indian region with no cross-border egress, general PII in an Indian region with controlled cross-border transfer mechanisms for specific purposes, employee data in the region the employee resides (most likely India), analytics on de-identified or aggregated data with the identification keys kept local. Logs in India with 180-day retention minimum. KYC data accessible from India under CERT-In Direction 70B.

The single largest implementation gotcha: backup and disaster recovery. If your primary is in India and your DR is in Singapore, your “payment data is in India” claim is false. The DR site holds payment data outside India. Either DR is also in India (often Mumbai-Hyderabad or Mumbai-Pune pairs), or you have a problem.

European Union — adequacy, SCCs, Schrems II

The EU approach is cross-border transfer restriction, not strict localisation. GDPR Chapter V permits transfer outside the EEA only via:

• Adequacy decision (Article 45). The Commission has declared the destination country provides essentially equivalent protection. Active adequacy decisions as of May 2026 include the UK, Switzerland, Japan, South Korea, Israel, the US (via the EU-US Data Privacy Framework, in force July 2023, currently challenged in court), and several others. India does not have adequacy.
• Appropriate safeguards (Article 46). Standard Contractual Clauses (the 2021 Commission Implementing Decision SCCs), Binding Corporate Rules, certification mechanisms, codes of conduct.
• Derogations (Article 49). Explicit consent, contract performance, vital interests, important reasons of public interest, legal claims, vital interests of incapable persons. Narrow; not a general transfer mechanism.

The Schrems II decision (CJEU, July 2020) added a transfer impact assessment requirement on top of SCCs: even with SCCs in place, the transferor must assess whether the destination country’s surveillance regime undermines the protection in practice. The US transfer regime has been the most contested; the EU-US Data Privacy Framework (DPF) is the current mechanism, and it has critics who argue it does not survive Schrems-style challenge. Plan for the DPF being either upheld or struck down on a multi-year horizon; build optionality.

EU sectoral overlays

GDPR is the base; sectoral and national rules sometimes add localisation requirements:

DORA (Digital Operational Resilience Act). In force January 2025 for EU financial services entities and their critical ICT service providers. Includes provisions on third-party risk, but not strict localisation in itself. Indirectly drives EU-data-handling preferences through critical-ICT-third-party designation.

NIS 2. Cybersecurity directive for essential and important entities. Like DORA, drives EU-handling preferences via risk-management requirements but not strict localisation.

National security and intelligence laws. Each EU Member State has national security and intelligence regimes that can require local data accessibility. Germany’s BSI law, France’s ANSSI requirements, and similar national-level provisions intersect with localisation decisions for entities in critical sectors.

The EU architectural pattern

For EU customers, the operational pattern that survives Schrems-style scrutiny is to keep EU customer personal data in the EEA where possible, use SCCs plus transfer impact assessment for any necessary transfers outside the EEA, document the necessity for each cross-border flow, and prefer EU-based sub-processors where available. The increasing customer demand is “EU data stays in the EU,” which is operationally stricter than GDPR requires but reflects market preference.

The EU does not have payment-data localisation in the Indian style. EU payment regulation (PSD2, the Payment Services Directive, succeeded by PSD3 negotiations) focuses on operational requirements and customer protection rather than data residency. Card payment data is governed by PCI DSS at the contractual level rather than EU regulation at the statutory level.

United States — sector-specific, no general localisation

The US has no general data localisation law. Data residency is sector-specific or contract-specific:

Federal contracting. ITAR (defence-related technical data) and EAR (export administration) restrict cross-border movement of certain controlled data categories. CMMC (Cybersecurity Maturity Model Certification) for DoD contractors imposes data-handling requirements that effectively require US-based data handling for Controlled Unclassified Information.

HIPAA. No localisation; covered entities and business associates can host healthcare data anywhere, subject to standard HIPAA requirements. Cross-border arrangements are contractual.

State-level rules. Most US state privacy laws are silent on localisation. California’s CCPA/CPRA imposes cross-border transparency requirements (consumers can know whether their data is being sold or shared) but not residency mandates.

Critical infrastructure. CISA’s frameworks and sector-specific rules (NRC for nuclear, FERC for electric, TSA for pipelines and rail) impose residency-style requirements for specific data classes in regulated infrastructure.

The US operational pattern: for federal contracting and DoD work, US-based handling is effectively required. For commercial work, contractual data-handling commitments are the typical mechanism, not statutory localisation.

China — PIPL plus sectoral plus security review

China has the most complex localisation regime of any major jurisdiction. Three overlapping rules:

The Personal Information Protection Law (PIPL). In force November 2021. Personal information of individuals in China is subject to PIPL. Cross-border transfer requires one of: security assessment by the Cyberspace Administration of China (CAC), professional certification, standard contract with the foreign recipient (per the 2023 CAC standard contract), or individual consent for certain narrow categories.

The Data Security Law (DSL). In force September 2021. Data classification regime requiring “important data” and “core data” to receive heightened protection. Cross-border transfer of important data requires CAC security assessment regardless of personal information content.

The Cybersecurity Law (CSL). In force June 2017. Critical Information Infrastructure (CII) operators must store personal information and important data collected during operations in mainland China. Cross-border transfer requires CAC security assessment.

The 2023 PIPL implementation rules and 2024 CAC clarifications have created the operational architecture: routine personal-information cross-border transfer can rely on the CAC standard contract, with thresholds above which security assessment is required. Important-data transfers always require security assessment.

For non-Chinese SaaS serving Chinese customers, the architectural pattern is to host the China-customer data in mainland China (commonly via a partnership with a Chinese cloud provider — Alibaba Cloud, Tencent Cloud, AWS China via Sinnet, Azure China via 21Vianet), with carefully-architected egress for limited cross-border processing requirements. The complexity is sufficient that many smaller SaaS choose not to serve China rather than build the architecture.

United Kingdom, Canada, Australia, Singapore, Japan

A faster summary for jurisdictions where the architectural pattern is less complex:

United Kingdom. UK GDPR plus Data Protection Act 2018. Substantially similar to EU GDPR for cross-border transfer. UK adequacy with the EU is currently in effect (renewed 2025; up for review again 2029). UK has its own adequacy decisions for outbound transfers. Sectoral overlays (FCA for financial services, ICO for general privacy) mirror EU patterns.

Canada. PIPEDA (federal) plus provincial laws (Quebec’s Law 25, BC PIPA, Alberta PIPA). Cross-border transfer is permitted with accountability and contractual protections; no general localisation. Quebec’s Law 25 strengthens cross-border requirements with explicit risk assessment. Federal contracting under PSPC has data residency requirements for sensitive contracts.

Australia. Privacy Act 1988 with Notifiable Data Breaches scheme. Cross-border transfer is permitted with accountability principles; the Australian Privacy Principle 8 requires the disclosing entity to take “reasonable steps” to ensure the foreign recipient does not breach the APPs. Government data has stricter residency requirements via PSPF and IRAP.

Singapore. PDPA permits cross-border transfer subject to comparable protection (deemed comparable list, contracts, certifications). MAS (Monetary Authority of Singapore) imposes financial-sector residency expectations through TRM guidelines. Singapore frequently functions as an APAC data hub because of its relatively permissive regime.

Japan. APPI permits cross-border transfer with consent or comparable protection. Japan has reciprocal adequacy with the EU. Sectoral overlays in financial services and healthcare.

For each of these jurisdictions, the pattern is “cross-border transfer with conditions” rather than strict localisation, with sectoral overlays adding residency in specific industries.

The synthesis: building the matrix for your organisation

For any organisation processing personal data across jurisdictions, the localisation analysis takes a predictable form. The matrix that works:

Each row produces an architectural decision. The combinations produce the segmented architecture. The mistake is treating “where do we host” as a single decision; it is six to twelve decisions, one per data class per jurisdiction.

The architectural patterns that work in practice:

Regional segmentation. Separate deployments per region, with each region holding only the data of customers in that region. Cross-region operations are limited and explicitly designed. This is the cleanest architecture; it is also the most expensive operationally.

Single global instance with data-locality controls. One application instance, with the database layer partitioned by region. Each customer’s data lives in a specific regional shard. Cross-region access is governed by application-layer controls. Simpler than full regional segmentation; relies on engineering discipline holding the controls.

Hybrid with regulated-class isolation. General SaaS data in one architecture (often global or major-region-segmented), with regulated classes (payment data, healthcare data) isolated in compliant sub-environments. Complex but allows a single product line to serve regulated and non-regulated customers without forcing the architecture to the lowest-common-denominator.

Vendor-hosted regional instances. Outsource the regional deployment to a regional provider (China via Alibaba, India via local-managed AWS or Yotta, Russia historically via Yandex). Avoids the operational complexity of running your own regional infrastructure; introduces vendor dependency.

The choice depends on customer mix, regulated-class exposure, operational budget, and the strategic importance of each jurisdiction.

The recurring findings

Across hundreds of localisation reviews, the same findings recur. Five worth naming:

1. Backups outside the residency region. The primary database is correctly located; the backup vendor replicates to a US region by default. Finding rate: roughly 40% of organisations on first review.

2. Logs and telemetry shipped to a global observability tool. Datadog, New Relic, Splunk Cloud — these tools default to a US or EU region regardless of the source data’s residency. Logs of customer activity contain personal information; the residency claim does not survive review.

3. Analytics or business intelligence on the unsegmented dataset. The operational data is partitioned; the analytics warehouse is not. A single Snowflake instance with global data violates the segmentation.

4. Third-party SaaS in the data flow. Email service providers, support ticketing, fraud detection, customer-success platforms, AI/ML inference services. Each one is a data egress that may breach residency. The pattern: customer data flowing into Intercom, Zendesk, HubSpot, Pendo, Mixpanel, etc., often in default US regions.

5. Disaster recovery in a different jurisdiction. Primary in country X, DR in country Y. The DR site holds customer data. Residency claim is false during normal operations and grossly false during a DR event when traffic shifts.

Each of these has standard remediations. The point is to find them before the auditor or regulator does.

What this guide does not cover

Three areas worth their own treatment:

1. Specific cloud-provider regional architectures. I have not recommended specific AWS regions, Azure regions, or GCP regions for specific jurisdictions. The right choice depends on the provider’s regulator-specific certifications, the local supervisory authority’s known positions on the provider, and the customer’s existing cloud investments.

2. Russian and other restricted jurisdictions. Russia’s data localisation regime (Federal Law 242-FZ) is operationally significant for organisations with Russian customers but has been largely superseded for most Western SaaS by 2022-era sanctions and operational disengagement. Vietnam, Indonesia, and other emerging-market localisation regimes are growing in importance and deserve dedicated treatment.

3. Specific sector-deep dives. Healthcare data localisation, financial services localisation, defence and government contracting localisation, telecom localisation — each is its own architectural domain with regulators and conventions that this overview surface-touches. Treat this guide as the index; the depth is per-sector.

This guide is a practitioner reference, not legal advice. It reflects the regulatory landscape as of 25 May 2026 across India, the EU, the US, China, the UK, Canada, Australia, Singapore, and Japan. Compliance teams should validate specific obligations against current regulator notifications, current jurisprudence (especially Schrems-related EU-US transfer developments), and counsel review.

ControlForge synthesises data residency and cross-border transfer requirements across DPDPA, GDPR, UK GDPR, PIPL, CCPA/CPRA, US state privacy laws, RBI sectoral rules, SEBI CSCRF, IRDAI, and the major sectoral regulators globally. The synthesis surface helps trace which residency rules apply to which data class for which customer base.