Data residency is the physical location where your organization's data is stored and processed, down to the country or cloud region. For a SaaS company serving German customers, that might mean production databases in Frankfurt. It also means the snapshots, replicas, and log exports sitting behind them.
Most teams get the first part right. Somebody picks eu-central-1 during setup, and the architecture diagram says "EU." The trouble shows up later, when an auditor asks where the 90-day backups live, or a geo-redundant vault turns out to be copying data to a paired region nobody chose.
We build cloud data protection at Eon, so we spend most of our time on the copies residency plans tend to forget: backups, cross-region replicas, and restore targets.
What is data residency?
Residency is a commitment about geography: the country, and usually the specific cloud region, where a dataset is stored and processed. It covers the original data and every copy made from it, for as long as that copy exists.
The commitment can come from three places. A law can mandate it, a customer contract or security questionnaire can promise it, or your own team can choose it for latency or simpler compliance.
Whichever one applies, an auditor asks the same thing: where does each copy physically sit today, and can you prove it?
What residency covers in a cloud environment
Residency covers every place a dataset is written, copied, or read from. In a typical cloud estate, that list is longer than the architecture diagram suggests:
- Primary storage: Databases, object buckets, and VM disks
- Replicas: Read replicas and failover copies in other zones or regions
- Backups: Snapshots, vault copies, and long-retention archives kept under a backup retention policy
- Operational data: Logs, telemetry, and analytics exports
- Temporary copies: Data staged during restores, migrations, and support cases
Key characteristics
A few traits define residency in practice, and each one changes how you design for it.
- It's physical: Residency is about the data center or cloud region that holds the bytes. Cloud providers expose it as a region choice at resource creation.
- It's often voluntary: Plenty of companies keep data in-region because a customer contract, security questionnaire, or latency target calls for it, even where no law does.
- Access counts, too: Regulators treat remote access as a transfer. Ireland's Data Protection Commission fined TikTok €530 million in May 2025 over EEA user data that staff in China could access remotely.
- Every copy inherits the rule: A backup of regulated data is regulated data, with the same location limits as the original.
Data residency vs. data sovereignty vs. data localization: What's the difference?
Residency is where data physically lives, sovereignty is whose laws govern it, and localization is a legal requirement to keep it inside a country. People use the three terms loosely, but they answer different questions, and mixing them up leads to the wrong controls.
The three overlap more than the labels suggest. A Frankfurt region can meet a residency commitment while the provider stays subject to another country's legal orders. The US CLOUD Act, for example, covers data held by US-based providers wherever it happens to be stored.
AWS answered that concern with a separate European Sovereign Cloud launched in January 2026. It runs in Brandenburg, Germany, operates independently from other AWS Regions, and is staffed by EU residents.
Residency is the question you'll face in most vendor security reviews. Sovereignty comes up in regulated industries and board-level cloud strategy. Localization is the strictest, since a law picks the location for you, and it only applies in countries that mandate it (the laws section below lists the big ones).
Does GDPR require data to stay in the EU?
No. GDPR doesn't require personal data to be stored in the EU. Chapter V of the regulation allows transfers outside the European Economic Area when one of these applies, as the European Data Protection Board lays out:
- Adequacy decision: The European Commission has found the destination country's protection adequate
- Standard contractual clauses (SCCs): Approved contract terms between exporter and importer
- Binding corporate rules (BCRs): Approved internal rules for transfers within a corporate group
- Derogations: Narrow exceptions like explicit consent or contract necessity
For the US, the EU-US Data Privacy Framework has carried an adequacy decision since July 10, 2023. The EU General Court dismissed a challenge to it on September 3, 2025.
GDPR's strict rules apply to the transfer. Transfer violations sit in the higher fine tier of Article 83(5): up to €20 million or 4% of worldwide annual turnover, whichever is higher. Ireland's regulator fined Meta €1.2 billion in May 2023 over transfers of EU user data to the US.
So why do so many vendors sell "GDPR-compliant EU hosting"? Keeping a copy inside the EEA removes the transfer question for that copy, and procurement teams prefer a single-location answer. It's a sensible design choice, and it's easier to defend in an audit. The regulation itself governs transfers, and your customer contracts can go further than it does.
Residency and localization laws by country
Laws fall into three rough buckets: strict localization, sector-specific localization, and transfer controls. Here's how the major ones break down. (Treat this as a planning summary and bring in counsel before you design around any single row.)
Strict localization: Russia and China
Russia has required localization since September 1, 2015. Operators must record, store, and update Russian citizens' personal data through databases located in Russia. An amendment that took effect on July 1, 2025 bans using foreign databases to collect that data and extends the rules to processors.
China's rule is narrower but heavier where it applies. PIPL Article 40 requires critical information infrastructure operators, and processors above a volume set by the Cyberspace Administration of China (CAC), to store personal information collected in China within China.
Separately, the CAC's March 2024 provisions set thresholds for sending data abroad. Exporting personal data of 1 million or more people a year, or sensitive data of 10,000 or more, needs a CAC security assessment. Non-sensitive data of fewer than 100,000 people is exempt.
Sector rules: India's payment data and Australia's health records
India's central bank requires that "the entire payment data shall be stored in systems located only in India." If payments are processed abroad, the RBI directive says the data must be deleted there and brought back within one business day or 24 hours, whichever is earlier.
Australia's My Health Records Act 2012 includes a section 77 requirement not to hold or take records outside Australia. It covers the national My Health Record system, and it's a good example of residency rules that only switch on for one type of data.
Transfer controls: Saudi Arabia and India's DPDP Act
Several newer privacy laws follow the GDPR pattern. Saudi Arabia's PDPL doesn't mandate localization, and its 2024 Transfer Regulations allow transfers based on adequacy, Saudi SCCs, or BCRs.
India's DPDP Act takes a blocklist approach: personal data can leave India unless the government restricts transfers to a specific country. The DPDP Rules keep that permissive default, and sector rules like the RBI directive still apply on top.
The United States
The US has no general residency law. HIPAA lets a covered entity use a cloud provider that stores ePHI outside the US, according to HHS, as long as a business associate agreement is in place and the HIPAA Rules are followed. (Our guide to HIPAA backup requirements covers what that means for backups.)
The bigger recent change is the Department of Justice's bulk data rule, 28 CFR Part 202, in effect since April 8, 2025. It restricts transactions that give countries of concern, including China and Russia, access to bulk US sensitive personal data. That puts vendor access and support arrangements in scope alongside storage location.
How residency works on AWS, Azure, and Google Cloud
All three hyperscalers make the region the unit of residency. You choose where resources live, and each provider commits to keeping your content there. The exceptions mostly show up in replication and backup settings, which teams often don't review after setup.
AWS
AWS's data privacy FAQ says it "will not move or replicate your content outside of your chosen AWS Region(s)," except as needed to provide services you initiated or to comply with the law.
Cross-region copies in AWS Backup are opt-in. You add them through a copy rule in a backup plan or run them on demand. That's good for residency, since nothing leaves the region by accident. It also means AWS backups stay in the source region unless someone adds a copy rule (more on why that's risky below).
For guardrails, AWS Control Tower's Region deny control blocks access to services outside approved Regions. Global services like IAM and AWS Organizations are exempt, so it won't catch everything.
Azure
Microsoft's residency page commits that it won't store or process customer data outside the customer-specified Geo without authorization. It also lists services, such as Azure Machine Learning and Azure Data Explorer, that may store some data types elsewhere.
The bigger catch is geo-redundant storage (GRS). GRS copies data to a paired secondary region you can't change. Almost every pair sits inside one geography, but Brazil South pairs with South Central US, outside Brazil.
Backups make this easy to miss. A Recovery Services vault defaults to GRS, and the setting locks once you configure backups. A Brazil South vault left on defaults can end up with a copy in Texas.
On the European side, Microsoft completed its EU Data Boundary in February 2025. It keeps customer data, pseudonymized personal data, and support data like logs and case notes inside the EU and EFTA for Microsoft 365, Dynamics 365, Power Platform, and most Azure services. Some Azure services need extra customer action to get the support-data commitment.
Google Cloud
Google's resource locations constraint limits where new resources can be created. It only applies to newly created resources, doesn't affect global resources, and Google is clear it isn't a data storage commitment.
Backups default wider than you might expect. Cloud SQL stores backups "in the multi-region that is geographically closest" to the instance unless you set a custom location. Compute Engine snapshots are global resources by default, and you can set a default storage location per project. A multi-region like "eu" stays inside the EU, but it won't satisfy a single-country rule.
Backups and disaster recovery: the residency blind spot
Backups widen the residency footprint by design, because their job is to put data somewhere else. Production resources usually get a region review at launch, while backup settings stay on their defaults for years.
Here are the most common ways a backup copy leaves its intended scope:
- Geo-redundant defaults: GRS vaults and multi-region backup locations replicate data before anyone decides where it should go.
- DR copies: Cross-region copies added for resilience can cross a border if the second region sits in another country. (Our replication vs. backup guide covers how those copies differ.)
- Restores and restore drills: A test restore into a shared account in another region creates a new copy of regulated data.
- Long retention: A backup kept for seven years outlives the architecture review that placed it, and the original owner may be long gone.
- Keys and access: Where the encryption keys live and who can reach them count as much as where the ciphertext sits. Our cloud encryption guide covers key placement in more detail.
When residency and resilience pull in opposite directions
The opposite failure is real, too. In September 2026, AWS said it was unable to restore access to "resources and data hosted exclusively" in its Bahrain region after drone strikes damaged its facilities. Teams whose only backups sat in that region lost both copies at once, as we covered in our Bahrain region breakdown.
That's the tension residency creates in countries with one cloud region. Keep everything in-country, and a regional loss can take the backups with it. Copy data abroad, and you may be breaking the rule you were trying to follow.
We recommend picking your DR region inside the same legal boundary whenever one exists. The EU, for example, has several regions on each major cloud.
Where there's only one in-country region, settle the out-of-country backup question with legal before an incident, and document it as an approved transfer with its own key and access controls.
When strict residency is worth the cost
Strict residency, where every copy stays in one jurisdiction, buys you faster reviews. In-region copies don't need a transfer mechanism. A buyer can verify "all copies in the EU" in one call, and users near the region get lower latency.
The price is flexibility. Your DR options shrink, especially in countries with a single cloud region, and not every cloud service launches in every region. You'll also run separate accounts, vaults, and guardrails per jurisdiction, which pushes up both storage and operations spend.
Strict, every-copy residency is usually worth it if you:
- Operate in a localization country like Russia or China
- Sell to customers whose contracts promise in-region storage for every copy
- Handle payment or health data in markets with sector-specific rules
A lighter setup often works if you:
- Only need GDPR coverage and already have SCCs or an adequacy basis for transfers
- Mainly face questionnaires asking where production data lives, with no contractual backup commitments
How to comply with data residency requirements
A residency program that holds up in an audit comes down to seven steps. Most of the work sits in steps two, four, and seven, since those cover the copies that drift.
1. Map which rules apply to each dataset
Start with the data itself. For each dataset, note which laws, sector rules, and customer contracts apply. A single product can carry EU personal data, Indian payment data, and a customer contract promising US-only storage.
2. Inventory every copy
List where each dataset lives across production, replicas, snapshots, backups, logs, and analytics exports. Include copies made by third-party tools. Auditors usually start here, asking where a specific backup or snapshot lives.
3. Set guardrails at the organization level
Block resource creation outside approved regions before anything gets built. Use AWS Control Tower's Region deny control, Google Cloud's resource locations constraint, or Azure Policy's built-in Allowed locations definition. Remember each one has gaps (global services, existing resources), so they don't replace an inventory.
4. Pin backup and replica locations explicitly
Don't leave backup location to defaults. Set Azure vault redundancy before the first backup, choose custom Cloud SQL backup locations, set Compute Engine snapshot storage locations, and review every AWS Backup copy rule. Tagging helps here, but cloud resource tagging drifts fast at scale.
5. Keep keys and access in scope
Store encryption keys in the same jurisdiction as the data, and restrict who can decrypt it. Check where vendor support teams sit and whether they can reach production or backup data remotely. The TikTok fine shows regulators count that access.
6. Choose DR regions inside the same boundary
Pair each residency zone with a second region in the same country or legal area where one exists. Where it doesn't, get the out-of-country copy approved and documented before you need it.
7. Prove it continuously
Environments change every week, so a residency check at launch goes stale fast. Collect evidence of where every copy lives, flag new resources that land outside policy, and keep an audit trail of restores.
Our guides to cloud security compliance and cloud compliance tools cover how teams automate that evidence.
How Eon keeps backup residency provable
Backup ownership is usually spread across teams, accounts, and regions, so nobody can see every copy or prove where it sits.
We built Eon around that problem, and it's why we created the Cloud Backup Posture Management (CBPM) category. CBPM treats location as part of backup posture, alongside coverage, retention, and recoverability.
Here's how the pieces fit together for residency:
- Discovery and classification: Eon continuously discovers resources across accounts, regions, and clouds, and classifies what's in them, including PII, financial data, and PHI. You don't have to hand-tag which datasets carry residency rules.
- Policy-driven placement: Backup policies select resources by region, data class, environment, or tags, and each schedule writes to the vault you choose. EU PII can go to an EU vault, and new resources that match the policy follow automatically.
- Posture controls: Rules for retention and for copies in another account or region are checked against your policies, so you can enforce resilience inside the boundary you define. Violations and drift show up on one dashboard.
- Isolated vaults: Eon-managed vaults are immutable and logically air-gapped from production, so a compromised account can't delete your in-region copies.
- Granular recovery: Global Search finds files and database records in seconds, and you can restore just a table or file into a restore account you choose. Answering an audit request doesn't require rehydrating a full environment in some other region.
Ready to prove where your backups live?
Picking a region settles where production data sits. The harder part is every copy made after that: backups, DR replicas, restore targets, and the support access around them.
Eon's CBPM keeps track of those copies across accounts, regions, and clouds, routes each one to the vault you choose, and flags policy violations as your environment changes.
If you can't show an auditor where a backup lives, you can't call it resident. Book a demo to see where yours actually live.
Frequently asked questions
What does data residency mean?
Data residency means the physical location where an organization stores and processes its data, usually a specific country or cloud region. It applies to every copy of that data, including replicas, backups, and logs.
How is residency different from data sovereignty?
The main difference is that residency describes location, while sovereignty describes legal control. Data stored in Germany is resident there, but a provider's home-country laws can still reach it. That's why some teams look at both the region and the provider's jurisdiction.
Does GDPR require data to be stored in the EU?
No, GDPR doesn't require personal data to be stored in the EU. It allows transfers outside the EEA with an adequacy decision, SCCs, BCRs, or a narrow derogation, and fines unlawful transfers up to 4% of worldwide annual turnover.
Are backups covered by residency requirements?
Yes, backups are covered by the same residency requirements as production data. A snapshot or DR copy of regulated data is still regulated data, so its region, retention, and restore targets need the same controls.
Does using a local cloud region guarantee compliance?
No, a local cloud region covers primary storage but doesn't guarantee compliance on its own. Replication defaults, backup copies, restore locations, key management, and support access can all move data or access outside the region.
How does Eon help with backup residency?
Eon helps by discovering, classifying, and placing cloud backups through policy. Its CBPM layer routes each resource's backups to the vault you choose, flags posture violations as environments change, and shows where protected copies live across accounts and regions.
