Data Residency & Localization: Where Your Data Lives Matters

When Russia's Federal Service for Supervision of Communications blocked LinkedIn in 2016 for failing to store Russian user data on servers within the country, it was a wake-up call for global technology companies. Since then, data localization requirements have expanded to over 60 countries, and the trend is accelerating. In 2025, India finalized rules requiring certain categories of personal data to be stored exclusively within Indian borders, and the EU's emerging data sovereignty framework is reshaping how even European companies think about cloud infrastructure.

For companies operating across borders --- which includes any business with a website, SaaS application, or eCommerce store serving international customers --- understanding where data physically resides is no longer a technical curiosity. It is a compliance imperative.

Key Takeaways

• Over 60 countries now have some form of data localization requirement, ranging from soft preferences to hard mandates
• Data residency requirements affect cloud region selection, backup strategies, and disaster recovery architecture
• The distinction between data localization (must store locally), data residency (may store anywhere but must have a local copy), and data sovereignty (subject to local law) is critical
• Cross-border transfer mechanisms (SCCs, BCRs, adequacy decisions) allow data to flow internationally under specific conditions

---

Understanding Key Concepts

Three related but distinct concepts govern where data can live and move.

Definitions

Data Localization: A legal requirement to store and/or process data within a specific country's borders. The data cannot leave the country at all, or can only leave under strict conditions. Example: Russia's Federal Law 242-FZ requires personal data of Russian citizens to be stored on databases located in Russia.

Data Residency: The geographic location where data is stored. Data residency may be a contractual commitment (the customer requires data to be stored in a specific region) rather than a legal requirement. The data may be processed elsewhere as long as the primary storage is in the specified location.

Data Sovereignty: The principle that data is subject to the laws and governance structures of the country where it is collected or stored. Even if data physically resides in Country A, it may be subject to Country B's laws if it belongs to Country B's citizens (as with GDPR's extraterritorial reach).

Why It Matters for Cloud Infrastructure

When you store data in AWS us-east-1, that data physically resides in Virginia, USA, and is subject to US law (including potential access under the CLOUD Act). If that data belongs to EU citizens, you must ensure adequate protection under GDPR. If it belongs to Russian citizens, you may be violating Russian data localization law regardless of what protections you have in place.

---

Country-Specific Data Residency Rules

Country to Data Residency Rules

| Country/Region | Requirement Type | What Data | Key Law | Enforcement | |---------------|-----------------|-----------|---------|-------------| | EU/EEA | Transfer restriction | All personal data | GDPR Art. 44-49 | Transfers to non-adequate countries require safeguards (SCCs, BCRs) | | Russia | Hard localization | Personal data of Russian citizens | FZ-242 | Must be stored on Russian servers; violations lead to blocking | | China | Hard localization | Personal information, "important data" | PIPL, DSL, CSL | Must undergo security assessment for cross-border transfers | | India | Conditional localization | Sensitive personal data (mirror copy), critical data (full localization) | DPDP Act 2023 + rules | Government can designate countries where data cannot be transferred | | Indonesia | Soft localization | Electronic system data | GR 71/2019 | Public electronic systems must have local data center; private systems exempted | | Vietnam | Hard localization | User data from online services | Cybersecurity Law 2018 | Must store data in Vietnam if requested by authorities | | Turkey | Transfer restriction | Personal data | KVKK (Turkish DPA) | Explicit consent or adequacy decision required for transfers | | Brazil | Transfer restriction | Personal data | LGPD Art. 33 | Transfers allowed to adequate countries or under contractual safeguards | | Saudi Arabia | Conditional localization | Certain categories of data | PDPL 2022 | Government entities have stricter requirements | | Nigeria | Soft localization | Personal data | NDPR 2019 | Data must be processed in Nigeria; transfers require adequacy assessment | | South Korea | Transfer restriction | Personal information | PIPA | Consent or contractual necessity for transfers; notification required | | Australia | Transfer restriction | Personal information | Privacy Act 1988, APP 8 | Transferor remains liable for overseas recipient's handling | | Canada | Provincial variation | Personal information | PIPEDA + provincial laws | BC and NS require notification of foreign transfers; Quebec requires DPIA | | UAE | Conditional localization | Health data, financial data | Various sector regulators | DIFC and ADGM have separate frameworks |

---

Cloud Region Selection Strategy

Choosing the right cloud regions is one of the most impactful decisions for data residency compliance. Get it right and compliance is built into your architecture. Get it wrong and you face costly re-architecture or regulatory penalties.

Multi-Region Architecture Patterns

Pattern 1: Single Region (Simple)

All data stored in one cloud region. Simplest to manage but limits your ability to serve global customers with low latency and may not satisfy localization requirements if you have customers in countries with hard localization mandates.

Best for: Companies operating primarily in one country or region with no hard localization requirements elsewhere.

Pattern 2: Regional Hubs (Balanced)

Deploy in 2-4 strategic regions that provide geographic coverage while keeping operational complexity manageable:

| Hub | Cloud Region | Covers | |-----|-------------|--------| | Europe | AWS eu-west-1 (Ireland) or eu-central-1 (Frankfurt) | EU/EEA, UK, Turkey, Middle East | | Americas | AWS us-east-1 (Virginia) or ca-central-1 (Canada) | US, Canada, Latin America | | Asia-Pacific | AWS ap-southeast-1 (Singapore) or ap-south-1 (Mumbai) | Southeast Asia, India, Australia | | China | AWS cn-northwest-1 (Ningxia) or Alibaba Cloud | China (requires separate legal entity) |

Best for: Most international businesses. Provides good latency, regulatory coverage, and manageable complexity.

Pattern 3: Per-Country Deployment (Maximum Compliance)

Deploy in every country with hard localization requirements. Highest compliance but highest operational cost and complexity.

Best for: Heavily regulated industries (banking, healthcare, government) operating in countries with strict localization mandates (Russia, China, India).

Cloud Provider Region Availability

| Provider | Total Regions | Key Regions for Compliance | |----------|-------------|---------------------------| | AWS | 34 | Frankfurt, Ireland, London, Mumbai, Sao Paulo, Singapore, Canada, Bahrain, Jakarta | | Azure | 60+ | Netherlands, Germany, France, UK, India, Brazil, UAE, South Africa, Canada | | GCP | 40 | Belgium, London, Frankfurt, Mumbai, Sao Paulo, Singapore, Sydney | | Alibaba Cloud | 28 | China (multiple), Singapore, Indonesia, India, UAE, Germany |

---

Cross-Border Data Transfer Mechanisms

Even with data residency requirements, cross-border data transfers are often necessary for business operations. Several legal mechanisms enable compliant transfers.

Transfer Mechanisms Under GDPR

Adequacy Decisions. The European Commission determines that certain countries provide adequate data protection. Transfers to these countries are treated like intra-EU transfers. Currently adequate countries include: Andorra, Argentina, Canada (commercial), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, UK, Uruguay, and the US (under the EU-US Data Privacy Framework for certified companies).

Standard Contractual Clauses (SCCs). Pre-approved contractual terms that data importers must agree to. The 2021 updated SCCs include four modules for different transfer scenarios (controller-to-controller, controller-to-processor, processor-to-processor, processor-to-controller).

Binding Corporate Rules (BCRs). Internal policies approved by EU data protection authorities that allow multinational companies to transfer data within their corporate group. BCRs are expensive and time-consuming to implement (12-18 months) but provide a durable solution for large enterprises.

Explicit Consent. Data subjects can consent to cross-border transfers, but this must be specific, informed, and truly voluntary. It is not a viable mechanism for systematic or large-scale transfers.

Contractual Necessity. Transfers necessary for the performance of a contract between the data subject and the controller (e.g., booking a hotel in another country). Limited to transfers directly necessary for the contract.

Transfer Impact Assessments

Since the Schrems II decision, organizations using SCCs must conduct a Transfer Impact Assessment (TIA) for each transfer:

1. Identify the specific transfer (data types, purpose, recipient, destination)
2. Assess the destination country's legal framework (surveillance laws, government access rights)
3. Evaluate whether supplementary measures are needed (encryption, pseudonymization, contractual restrictions)
4. Document the assessment and make it available on request

For a comprehensive view of privacy regulations that govern cross-border transfers, see our data privacy comparison guide.

---

Implementation Checklist

Steps to Data Residency Compliance

1. Inventory your data. Map all personal and sensitive data, identify where it is stored, and determine which jurisdictions' laws apply based on the data subjects' locations.

2. Identify applicable requirements. For each jurisdiction where you have data subjects or customers, determine the specific data residency or localization requirements.

3. Assess your current architecture. Document your current cloud regions, backup locations, CDN edge caches, and any third-party services that process or store data.

4. Identify gaps. Compare your current architecture against requirements. Common gaps include: backups stored in non-compliant regions, CDN caches replicating data globally, SaaS vendors storing data in non-compliant locations.

5. Select target architecture. Choose a multi-region pattern that satisfies all identified requirements while balancing cost, performance, and operational complexity.

6. Implement data routing. Configure your application to route data to the appropriate region based on the data subject's jurisdiction. This may require database sharding by region, separate storage buckets per region, or a data routing layer.

7. Update vendor agreements. Ensure all third-party vendors store data in compliant regions. Update DPAs and SCCs as needed. Review vendor sub-processors.

8. Configure backups and DR. Ensure backup and disaster recovery infrastructure complies with residency requirements. Cross-region replication for DR must stay within compliant regions.

9. Document everything. Maintain records of data flows, storage locations, transfer mechanisms, and compliance decisions. This documentation is required by GDPR (ROPA) and expected by auditors.

10. Monitor continuously. Data residency is not a one-time project. New services, new vendors, new customers, and new regulations can change your requirements. Build data residency checks into your procurement and architecture review processes.

For details on building the audit trails needed to demonstrate data residency compliance, see our audit trail compliance guide. For the broader compliance context, refer to our enterprise compliance handbook.

---

Frequently Asked Questions

Does data residency apply to backups and disaster recovery copies?

Yes. If a regulation requires data to be stored within a specific country, backup and DR copies must also reside within that country. This creates a tension with best practices for disaster recovery, which typically involve geographically distant backups. The solution is to use multiple availability zones within the compliant country (AWS has multiple AZs in most regions) or, where regulations permit, use backup locations in countries with equivalent data protection (e.g., backing up German data in France is generally acceptable under GDPR).

How do we handle data residency with a global CDN?

CDNs like Cloudflare and AWS CloudFront cache content at edge locations worldwide. For static content (images, CSS, JavaScript), this is generally not a data residency concern. However, if your CDN caches responses that contain personal data, those cached copies may reside in non-compliant jurisdictions. Solutions include: disable caching for responses containing personal data, use a CDN with geo-restriction capabilities to limit caching to compliant regions, or ensure personal data is never included in cacheable responses.

Can we use encryption to satisfy data residency requirements?

Generally, no. Most data localization laws focus on the physical location of the data, not whether it is encrypted. Encrypted data stored in a non-compliant location is still stored in a non-compliant location. However, encryption can be a supplementary measure for cross-border transfers under GDPR (especially post-Schrems II) and may satisfy some transfer impact assessment requirements.

What about data processed in transit --- does routing matter?

Some regulations are ambiguous about data in transit. The general consensus is that transient routing of encrypted data through a non-compliant jurisdiction (e.g., internet routing) does not constitute storage or processing in that jurisdiction. However, if data is meaningfully processed (decrypted, analyzed, transformed) in a non-compliant jurisdiction, that processing violates localization requirements.

How do multi-tenant SaaS platforms handle data residency?

Multi-tenant SaaS platforms face the most complex data residency challenges. Common approaches include: deploying separate instances per region (most compliant but most expensive), database-level tenant isolation with region-aware routing (balanced approach), or application-level data routing that directs specific tenants' data to specific storage regions (most flexible but most complex to implement).

---

What Is Next

Data residency requirements will continue to expand as more countries enact data sovereignty laws and existing regulations are strengthened. Building data residency compliance into your architecture from the start is far less expensive than retrofitting it later.

ECOSIRE helps companies design data-residency-compliant architectures for their ERP and eCommerce systems. Our Odoo ERP implementations support multi-region deployments with compliant data routing, and our cloud infrastructure services include data residency assessment and architecture design. For AI-powered data flow mapping and compliance monitoring, explore our OpenClaw AI platform. Contact us to discuss your data residency strategy.

---

Published by ECOSIRE — helping businesses scale with AI-powered solutions across Odoo ERP, Shopify eCommerce, and OpenClaw AI.