An EU region tells you where data is stored. Sovereignty depends on every path that can reach it. Five questions to check in the contract and in operation.
Data residency is a fact about storage: the region, country and data centre where your data sits. Data sovereignty is a fact about control: who and what can reach that data, under which law, and what you can enforce and prove. An EU region settles the first and leaves the second open. The gap is closed in two places most residency reviews skip: the contract and day-to-day operation. The five questions below test both.
What the residency map misses
Every sovereignty review starts with a map. Which workloads run where, down to the data centre. Auditors will ask for it, and you should be able to produce it per workload within a day, because a regulatory audit does not give you weeks to prepare. The map is necessary. It is also the part a provider can answer for you. Pick an EU region and the map is green.
Two findings shape the rest of this article.
Jurisdiction attaches to companies, not to regions. A legal order is served on the operator, not on the data centre. US law says so in writing: under 18 U.S.C. § 2713, the section the CLOUD Act added, a provider must meet its obligations to preserve or disclose data within its "possession, custody, or control, regardless of whether" that data is located inside or outside the United States. A region changes where the data rests. It does not change who the order reaches.
Every subprocessor change notice is a change to your access paths. Under GDPR Article 28(2), a processor working under a general written authorisation must tell you about intended changes to its subprocessors, so that you can object. That notice usually lands with whoever signed the contract. The residency map does not move, yet another company now has a path to your data, with its own location and its own legal exposure. If nobody reads the notice as an architecture change, the right to object exists on paper only.
That is the line we draw: residency describes where data rests; sovereignty is decided by every path that can reach it. Each path has two checks, one in the contract and one in operation, and each check should leave evidence.
1. Where does every copy go, not just the primary?
A residency review usually starts from the workload list. The copies that matter are often not on it.
Without explicit network controls, cloud traffic takes the most efficient path, which may cross borders. Without explicit configuration, providers can route data across regions by default. And shared services such as logging pipelines, secret management and container registries are easy to forget during discovery, even though every workload depends on them. A log line can carry the same personal data as the database it came from.
- In the contract: does the residency commitment name the data it covers? Ask whether it includes logs, backups and the copies the provider makes to run the service, not just the primary storage you configured.
- In operation: egress rules that define what traffic can leave the sovereign environment and where it can go. Treat egress as a compliance control, not just a cost control. Network segmentation should prevent cross-border flows by default, not as an advanced setting.
- Evidence: a per-workload residency map that includes shared services, regenerated from code rather than drawn by hand.
2. Who and what can reach the data, and from where?
Location controls protect the data at rest. Access controls decide who can read it. Even if your data is EU-resident, privileged access from personnel outside the EU may constitute a transfer under GDPR. Operational access controls are as important as data location controls.
People are the smaller part of the problem. CI/CD pipelines, monitoring agents and third-party integrations all hold credentials, and in a migration this is where access tends to break first: single sign-on works for human users, and the pipelines fail because their API keys were tied to the old environment. Each of those keys was an access path that nobody had listed.
- In the contract: where privileged and support access to your environment can come from, and how you are told when that changes.
- In operation: identity is the perimeter. Inventory every non-human identity during discovery, not after the first broken pipeline. Restrict privileged roles to the people and locations the contract allows.
- Evidence: every action on the infrastructure logged with who did what, when and from where, with logs stored immutably and a security auditor role that has read-only access to all logs, policies and configurations.
3. If an order reaches the operator, what could it hand over?
This is where the first finding bites. Moving to an EU region may not eliminate CLOUD Act exposure, because the control plane, the layer that manages your region, can still sit under US jurisdiction. Under GDPR Article 48, an order from a court or authority outside the EU to transfer or disclose personal data may only be recognised or enforceable if it is based on an international agreement. How either law applies to a given request is a question for your legal team, not your architecture.
The architecture question is narrower: if the order arrives, what could the operator actually produce? Our migration playbook is direct about it: if the provider holds the keys, a legal order to the provider can compel decryption. So "customer-managed keys" is not the end of the answer. The next question is where the key lives.
- In the provider's key management service, with your own key (BYOK). You own the key, set its rotation and can revoke it. The service that stores it and performs decryption is still run by the provider, which is the company the order reaches.
- In a hardware security module you control, outside the provider. Decryption depends on a system the provider does not operate.
Our playbook accepts both for encryption at rest. They are not the same answer to this question, and the review should record which one each Tier 1 workload uses, and why.
Neither is a complete answer on its own. Keys protect what is encrypted under them. Data that a service decrypts in order to process it, and anything stored outside your keys, such as the shared-service copies from question 1, are not settled by where the key lives. Whether an arrangement is enough for a given workload is a judgement for your risk, legal and DPO teams. Your job is to give them an accurate picture of where the keys sit and who runs that system.
- In the contract: which jurisdictions the provider and its parent company answer to; what the provider commits to do when it receives a disclosure request; and, if your keys sit in its key service, what that commitment says about them.
- In operation: customer-managed keys for every Tier 1 workload, with the key location chosen and recorded per workload.
- Evidence: a key register showing where each Tier 1 key lives and who operates that system. Key management audit logs show that your keys are in use. They do not, on their own, show who else could reach them.
4. What does the contract let you enforce?
A data residency commitment without financial penalties is a marketing statement, not a legal obligation. Penalties are what make the commitment enforceable.
Subprocessors are the clause an architect should own, for the reason in the second finding above. Standard cloud contracts are often not sufficient as GDPR data processing agreements, so check the subprocessor list and the transfer mechanisms, not just the headline terms. Then decide who reads the change notices, and what they check in each one: which data the new subprocessor touches, where it operates and which jurisdiction it answers to.
Service levels deserve the same attention. Cloud provider SLAs typically offer service credits, not compensation for business impact. For a regulated entity that may be insufficient, and negotiated enterprise agreements with stronger penalties are achievable.
- In the contract: residency commitments with penalties; a subprocessor list with change notification and the right to object; SLAs with penalties that match the impact.
- In operation: a named owner who reviews every subprocessor and policy change notice as a change to the access paths, and decides whether to object.
- Evidence: a register of those notices, what each one changed and the decision taken.
5. Can you prove all of this, and could you leave?
Sovereignty you cannot demonstrate does not survive an inspection, and evidence packs cannot be assembled in 48 hours. The workable model is evidence as a by-product of the platform: policy as code that checks residency, egress, keys and access on every change, so regulators see evidence, not assurances.
The last check is the exit. For financial entities, DORA makes it explicit: "For ICT services supporting critical or important functions, financial entities shall put in place exit strategies" (Article 28(8)). Ask the question plainly: could you migrate away from your primary provider within 12 months if required? If not, the provider's jurisdiction is effectively yours for as long as you stay. Infrastructure defined as code is what turns that move from months of manual work into something you can plan.
- In the contract: exit assistance, data return formats and timelines.
- In operation: infrastructure as code for everything in scope, and no proprietary managed service on a Tier 1 path without a documented alternative.
- Evidence: a continuously generated evidence pack, and an exit plan that has been modelled, not just written.
The access path review
Put the five questions into one table and run it for every Tier 1 workload. The residency map fills the first row. The rest is where sovereignty is decided.
| Path to the data | On the residency map? | Check in the contract | Check in operation | Evidence |
|---|---|---|---|---|
| Primary storage | Yes | Residency commitment with penalties | Approved EU regions only | Per-workload residency map |
| Copies: logs, backups, shared services | No | Commitment names the data it covers | Egress rules, segmentation by default | Map includes shared services |
| People with privileged access | No | Where privileged and support access comes from | Privileged roles limited to agreed locations | Immutable access logs: who, what, when, where |
| Machine identities | No | Third-party integrations under the same terms | Inventory of every non-human identity | Identity inventory, reviewed |
| The operator and its jurisdiction | No | Jurisdictions, disclosure requests, what applies to keys in its service | Customer-managed keys, location recorded per workload | Key register: where each key lives, who runs it |
| Subprocessors | No | Written authorisation, change notice, right to object | Each notice reviewed as a path change: data, location, jurisdiction | Register of notices and decisions |
| The exit | No | Exit assistance, data return | Infrastructure as code, no unbacked lock-in | Modelled exit plan |
When residency is enough
Sovereign cloud is not always the answer. It may not be necessary when your workloads process only non-personal, non-sensitive data, when your regulatory framework accepts Standard Contractual Clauses or adequacy decisions as sufficient safeguards, or when your data classification shows no Tier 1 or Tier 2 workloads. Running the access path review is also how you find out that a workload does not need more than residency. That is a useful result, and it is cheaper than over-building.
FAQ
What is the difference between data residency and data sovereignty? Residency is where the data is stored. Sovereignty is who can reach it, under which law, and what you can enforce and prove. An EU region gives you the first. The second depends on access, keys, contracts and evidence.
Does keeping data in an EU region make us GDPR compliant? No single setting does. Residency is one input. Privileged access from outside the EU may itself constitute a transfer, and data classification is a legal decision, not a technical one: your DPO and legal team must validate it. Use the questions above to give them an accurate picture of the architecture.
Do customer-managed keys solve sovereignty on their own? No. They matter, and where the key lives matters more. In the provider's own key service, the provider still runs the system that holds your key. In a hardware security module you control, it does not. Either way, keys do not control where copies go, who holds privileged access, or what the contract lets you enforce.
Where should we start? Classify your data first. In our playbook, personal data under GDPR, financial data under DORA and health data go into Tier 1: the workloads we keep in-jurisdiction with no extraterritorial access risk. Your DPO and legal team confirm which workloads are Tier 1. Run the access path review on those before anything else.
Test your own setup. Our Sovereign Cloud Checklist covers 25 questions across data residency, compliance, provider independence, security and governance. Interactive, no signup required. Take the Sovereign Cloud Checklist →
Related: Sovereign Cloud · Platform Engineering · Sovereign Cloud Migration in 90 Days
Architecture questions, not legal advice.
Sources (checked in November 2026):
- Regulation (EU) 2016/679 (GDPR), Articles 28 and 48, and Chapter V: EUR-Lex
- Regulation (EU) 2022/2554 (DORA), Article 28(8): EUR-Lex
- 18 U.S.C. § 2713, Required preservation and disclosure of communications and records: Cornell Law School, Legal Information Institute
- Out.Cloud, Sovereign Cloud Migration Checklist: out.cloud/sovereign-cloud-checklist
- Out.Cloud, Sovereign Cloud Migration in 90 Days: A Practical Playbook (March 2026): out.cloud/resources/sovereign-cloud-migration-in-90-days
- Out.Cloud, Sovereign Cloud: out.cloud/sovereign-cloud