Data residency is about where data is physically stored and processed. Data sovereignty is about whose laws and whose access apply to it. Meeting both comes down to pinning workloads and data to approved locations, controlling who can reach them, and keeping evidence, while still running in more than one location so an outage does not take you down.
TL;DR
Customers and auditors now ask where the data lives, who can access it, and how it stays available during an outage.
- Define the requirement first. Residency, sovereignty, and localization are different obligations. Name the framework, the data class, and the jurisdiction before choosing a region.
- GDPR restricts transfers outside the EEA. It does not by itself require EU storage. Contracts, sector rules, and national laws often add stricter location terms.
- Primary data is the easy part. Backups, replicas, logs, traces, metrics, keys, support access, and AI inference are where data leaves the approved boundary by accident.
- One region per jurisdiction answers residency but creates an availability risk. Run active-active across two or more approved locations in the same jurisdiction, so failover stays inside the boundary.
- Match the pattern to the requirement: single region, multi-region in one jurisdiction, per-tenant cells, on-premises or local-provider locations, or a hyperscaler sovereign offering.
- Keep evidence current: location configuration, access logs, an audit trail, data flow diagrams, subprocessor lists, and certifications.
- Confirm obligations with counsel. This guide describes architecture and links primary sources. It is not legal advice.
Control Plane runs each workload active-active in every location of a Global Virtual Cloud, so you build one GVC per jurisdiction and failover never leaves it. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations, which can be two regions in the same jurisdiction.
Residency vs sovereignty vs localization
Data residency is a location constraint: a regulation, contract, or policy says a dataset must be stored or processed in a defined geography, such as a country or the EU.
Data sovereignty adds legal jurisdiction and operational control: which country’s laws apply, which authorities can compel access, and who can administer the systems that hold the data. Data can be resident in the EU and still be subject to another country’s legal reach if the provider or operator is based elsewhere.
Data localization is residency required by law rather than by contract, usually national, and it is often stricter than contractual terms, for example by prohibiting offshore copies or processing.
A sovereign cloud is an architecture and operating model built to enforce a named set of residency, jurisdiction, access, and operational requirements together. A design that satisfies one public-sector framework may not satisfy a financial-services requirement.
| Term | What it controls | What drives it | What it means for architecture |
|---|---|---|---|
| Data residency | Where data is stored and processed | Contracts, customer requirements, regulations | Pin workloads, databases, backups, and logs to approved locations |
| Data sovereignty | Which laws apply and who can compel or perform access | Jurisdiction of the provider, operator, and data location | Control administrative access, keys, and the legal exposure of every party in the stack |
| Data localization | Mandatory in-country storage or processing | National law or sector regulator | Use in-country locations, sometimes on infrastructure you operate or a local provider |
| Sovereign cloud | A bundle of residency, jurisdiction, access, and operational controls | A named framework, data class, and jurisdiction | Design placement, isolation, keys, access, telemetry, and operations together, then map each control to evidence |
The rules that shape architecture
Each row states what the primary source says. Confirm your obligations with counsel.
| Rule | What the primary source says | Architecture implication |
|---|---|---|
| GDPR, Chapter V | Article 44 says a transfer of personal data to a third country takes place only if the conditions in that chapter are met. Article 45 allows a transfer where the Commission has decided the country ensures an adequate level of protection, with no specific authorisation required. | GDPR conditions transfers; these articles do not say data must be stored in the EU. Map every flow that leaves the EEA and name its legal basis. |
| Adequacy decisions | The Commission’s list includes Canada (commercial organisations), Japan, the United Kingdom, and the United States for commercial organisations participating in the EU-US Data Privacy Framework. Personal data can flow to those countries without further safeguards. | Adequacy can make a transfer lawful. Check that US vendors participate in the framework, and keep a fallback transfer mechanism. |
| Standard contractual clauses | Contractual clauses ensuring appropriate safeguards can be a ground for transfers to third countries. The Commission issued modernised SCCs on 4 June 2021. | SCCs govern the transfer; they do not change where data sits. |
| UK GDPR transfers (ICO) | The ICO publishes guidance on restricted transfers, adequacy regulations, and safeguards including the UK IDTA and Addendum. | UK customers may need UK-specific transfer paperwork in addition to EU paperwork. |
| GDPR Article 48 (EDPB Guidelines 02/2024) | The European Data Protection Board explains how foreign court judgments and administrative decisions requiring disclosure interact with GDPR transfer rules. | Data center location and provider jurisdiction are separate variables. |
| EU Data Act | Applicable from 12 September 2025, with switching charges, including certain data-egress charges, phased out from 12 January 2027 (Article 29). Article 32 requires providers to take all adequate technical, organisational and legal measures, including contracts, to prevent third-country governmental access to non-personal data held in the Union where it would conflict with EU or Member State law. | Expect questions about government access controls and switching. Portability planning matters. |
| US CLOUD Act | The DOJ describes the Act, enacted in March 2018, as speeding access to electronic information held by US-based global providers and authorizing bilateral agreements; it lists agreements with the UK and Australia. | Sovereignty reviews ask about the legal jurisdiction of every provider in the stack, not only the data center location. |
| HIPAA and cloud (HHS) | A covered entity or business associate may use a cloud service for ePHI with a business associate agreement, and both must conduct risk analyses. A provider holding only encrypted ePHI without the key is still a business associate. | Location decisions belong in your documented risk analysis and your BAA. |
| PCI DSS | A baseline of technical and operational requirements to protect payment account data, for entities that store, process, or transmit cardholder data. Validation requirements are set by payment brands, acquirers, or other program managers. | Scope the cardholder data environment tightly and ask your acquirer and assessor whether any location requirement applies. |
| Australia, My Health Records Act 2012, s77 | Prohibits the System Operator and registered repository, portal, and contracted service providers that hold My Health Record records, or have access to related information, from holding, taking, or processing them outside Australia, or causing or permitting another person to do so, with a narrow exception for non-identifying data. | An example of localization written into health law, applying to the providers the Act names. |
| India, RBI payment data directive | The 6 April 2018 directive requires payment system providers to store the entire data relating to the payment systems they operate only in India; data for the foreign leg of a transaction can also be stored abroad. | An example of localization in payments that needs in-country locations. |
A requirement to keep data in the EU can apply even where GDPR does not impose it. Customer contracts, public-sector procurement rules, sector regulators, and Member State laws can all set stricter location terms, so read the contract, not just the regulation.
Data residency checklist: what has to stay in region
Teams pin the production database to an approved region and consider the job done. Auditors then find copies in other places. Check each item for every workload covered by a residency requirement:
- Primary data: databases, object storage, and file stores.
- Backups and snapshots: backup targets and disaster recovery copies can move regulated data outside the boundary even when primary storage is correct.
- Replicas: read replicas, cross-region replication, and caches.
- Logs and traces: application logs, request traces, and error reports often contain personal data, tokens, and query parameters.
- Metrics and analytics: product analytics, session replay, and metrics with user identifiers.
- Secrets and encryption keys: where keys are held and who can authorize decryption is a sovereignty question.
- Support and administrative access: who can reach production, from where, under what approval, and with what logging.
- Processing: compute location matters as much as storage, including AI inference and embedding calls that send customer data to a model endpoint.
Logs, backups, and observability pipelines are frequent sources of accidental cross-border transfers. A centralized logging or monitoring service in another jurisdiction can create a transfer even when production data never moves, so check where each telemetry pipeline sends data first.
Architecture patterns
Single-region deployment per jurisdiction
Run the full stack in one region inside the approved jurisdiction, with a separate copy for each other jurisdiction.
When to use it. Early-stage products, small footprints, and workloads where a short regional outage is acceptable.
Tradeoffs. The simplest way to prove residency and the weakest on availability: a regional outage takes the whole jurisdiction down, and backups kept in the same region share that risk.
Multi-region within one jurisdiction, active-active
Run the same workload in two or more regions inside one jurisdiction, for example two EU regions, and serve live traffic from all of them.
When to use it. Production workloads with both a residency requirement and an availability commitment.
Tradeoffs. It needs data replication that stays inside the boundary, health-based routing, and headroom in each location to absorb a failed one. Every location serves live traffic, so you are not paying for a standby that serves nothing. The active-active high availability guide covers the design.
Cell-based or per-tenant deployments
Deploy independent cells, each holding a set of customers, and route each customer to the cell in their jurisdiction.
When to use it. B2B software with customers in several regulated regions, where some customers contractually require a specific location.
Tradeoffs. Cells give a clear residency story per customer and limit the blast radius of a failure, but every cell needs deployment, monitoring, and upgrades, and a misrouted request is a residency incident. Run all cells with the same tooling.
Hybrid, on-premises, and local-provider locations
Run the strictest workloads in your own data centers or with a national or local provider, and join those locations to cloud regions under one management layer.
When to use it. Localization laws, highly sensitive data, customers who require infrastructure under their own control, and regions where hyperscalers have no suitable location.
Tradeoffs. You gain control over who operates the hardware and where it sits, and you take on capacity planning unless a provider handles it. The common failure is running those locations as a separate stack; see adding a neocloud without running a second stack and hybrid cloud platforms.
Hyperscaler sovereign offerings
Each major provider publishes sovereignty options, described here from their own pages:
- AWS: the AWS European Sovereign Cloud is described as a new, independent cloud for Europe for stringent data residency, operational autonomy, and resiliency requirements, alongside Dedicated Local Zones placed in a customer-specified location.
- Microsoft: the EU Data Boundary commits to processing and storing EU and EFTA customer data in region, and Microsoft Sovereign Cloud includes a Sovereign Private Cloud for hybrid or fully disconnected environments with Azure Local.
- Google Cloud: Google Cloud’s sovereign cloud offerings include a Data Boundary that stores core customer data in the chosen region with logged administrative access, Google Cloud Dedicated run by a local partner (S3NS in France), and Google Distributed Cloud for on-premises use, connected or air-gapped.
Tradeoffs. These address placement and operations inside one provider’s ecosystem. If you also need other providers or your own data centers, you still need a layer that manages them together; see how to avoid cloud vendor lock-in.
Data residency and high availability together
A single-region deployment is a residency answer and an availability risk. When that region fails, the options are to wait or to fail over somewhere that may break the residency commitment, and teams under pressure often choose the second. Active-standby inside the jurisdiction helps, but the standby bills for capacity that serves no traffic and is often not tested under real load.
Active-active across two or more approved locations in the same jurisdiction removes that tradeoff. Every location is proven under production load, and when one becomes unhealthy, traffic shifts to locations that are already inside the boundary, so a failover never becomes a residency exception. Keep replication, backups, logs, and keys inside the same boundary. For what each design can deliver, see five nines availability architecture.
Proving it
Auditors and customer security teams ask for evidence, and they ask repeatedly, so build the evidence trail as you build the system.
| Evidence | What it shows | How to keep it current |
|---|---|---|
| Location configuration | The approved locations each workload can run in | Store it as code and review changes like any other change |
| Access logs | Who accessed systems and data, and from where | Centralize inside the boundary and set retention to match contracts |
| Audit trail | Every administrative action, tamper-resistant | Generate it automatically |
| Data flow diagrams | Where data moves, including backups, logs, and third parties | Update with each architecture change and review quarterly |
| Subprocessor list | Every vendor that touches the data and where it operates | Review on onboarding and vendor changes, and notify customers as contracts require |
| Certifications and reports | Independent assessment of controls | Track expiry, scope, and version, and confirm the scope covers the service you use |
Treat the location configuration as the source of truth and generate diagrams from it where you can. Then test the boundary: try to deploy a workload to an unapproved location in staging and confirm it is refused.
How Control Plane helps with data residency and sovereignty
Control Plane is the platform for running unbreakable apps and agents. It combines any cloud, neocloud, on-premises, and bare-metal location into one Global Virtual Cloud (GVC).
- You choose the locations. A workload deployed to a GVC runs only in that GVC’s locations, active-active in every one, and a global endpoint routes each request to the nearest healthy location. Build each GVC from locations in one jurisdiction, and use separate GVCs for separate jurisdictions.
- Residency and resilience in one design. Every location in a GVC serves live traffic, so you get active-active failover inside your boundary without paying for idle standby capacity. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations, and those locations can be two regions in the same jurisdiction, on one provider or on different providers.
- Proven in an outage. During the October 2025 AWS us-east-1 outage, 20% of Control Plane customers had us-east-1 in their Global Virtual Clouds. Their workloads were active and running in healthy locations within 10 seconds, with no customer downtime, according to Control Plane internal incident telemetry.
- Infrastructure you control. Bring Your Own Kubernetes (BYOK) and Managed Kubernetes let your own clusters, your own servers, on-premises data centers, or a local or national provider join a GVC as locations, managed alongside cloud regions.
- Use regional cloud services in place. Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code, so workloads can use databases and key management services you keep in the same jurisdiction.
- Controls that produce evidence. Mutual TLS between workloads, secrets management, fine-grained access policies, and a tamper-proof audit trail, plus autoscaling, readiness-gated rollouts, automatic TLS certificates, and unified logs, metrics, and traces, with no Kubernetes cluster you have to operate.
- Compliance. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant, so the platform layer comes with its own compliance evidence to add to yours.
FAQ
What is data residency?
A requirement that data be stored or processed in a specific geography, such as a country or the EU. It comes from regulations, contracts, or internal policy, and it applies to every copy of the data, including backups, replicas, and logs.
What is the difference between data residency, data sovereignty, and data localization?
Residency is where data is stored and processed, sovereignty is which laws apply and who can compel access, and localization is residency required by national law.
What is a sovereign cloud?
An architecture and operating model that enforces a named set of residency, jurisdiction, access, and operational requirements together. AWS, Microsoft, and Google Cloud publish sovereign offerings, and you can also assemble one from regional locations, local providers, and infrastructure you operate.
Does a sovereign cloud require dedicated, single-tenant infrastructure?
Not always. The framework, data class, jurisdiction, and threat model decide whether shared regional infrastructure is acceptable or dedicated infrastructure under your control is required.
How do I keep customer data in the EU on AWS, GCP, or Azure?
Choose EU regions for every workload and data store, apply the same rule to backups, replicas, telemetry, and keys, and use each provider’s policy controls to block deployment outside approved regions. On Control Plane, a GVC built from EU locations keeps every workload replica in those locations, across one provider or several.
Does GDPR require data to stay in the EU?
GDPR’s transfer articles set conditions for moving personal data to third countries, such as adequacy decisions and standard contractual clauses; they do not require EU storage. Contracts, sector rules, and national laws can.
Can I have data residency and high availability at the same time?
Yes. Run active-active across at least two approved locations in the same jurisdiction so failover stays inside the boundary. Control Plane’s 99.999% availability SLA applies to workloads running at least two replicas in at least two locations, which can be two regions in the same jurisdiction.
What data residency requirements apply to healthcare and payments data?
HIPAA guidance centers on a business associate agreement and a documented risk analysis, and PCI DSS sets security requirements with validation set by acquirers and payment brands. Some countries add localization law, such as Australia’s My Health Records Act and India’s RBI payment data directive.
How do I prove data residency to an auditor or customer?
Provide location configuration, data flow diagrams that include backups and telemetry, access logs, an audit trail of administrative actions, a subprocessor list with locations, and current certifications, matched to the framework being tested.
Can I add a region for a new market without rebuilding my application?
Yes, if your platform treats locations as configuration. On Control Plane you add an approved location to a GVC or create a new GVC for that jurisdiction, and the workload definition does not change. Plan data replication and telemetry for the new jurisdiction.
Next step: bring your residency requirements and current architecture, and the Control Plane team will map them to a GVC layout per jurisdiction that stays up when a region fails. Talk to the Control Plane team or sign up free.
Originally published on the Control Plane blog.
