Data residency vs data sovereignty: the difference that decides your risk

Ask a cloud provider where your data is stored and you will get a precise answer: a region, sometimes a city, occasionally the building. Ask who can be compelled to open it and the conversation gets vaguer.

That gap between the two questions is the single most common weak point in cloud risk assessments. It has a name in each half: data residency is the first question, data sovereignty is the second. They are routinely used as synonyms in marketing material, and they are not synonyms at all.

The short version

Data residency is a statement of geography. It says your data is physically stored within a defined territory — Canada, the EU, Germany — and usually that it is processed there too.

Data sovereignty is a statement of jurisdiction. It says which country's law governs the data and, by extension, which authorities can compel access to it.

Residency is a fact about a building. Sovereignty is a fact about the operator.

Why the distinction has teeth

A provider headquartered in the United States remains subject to United States law wherever its hardware stands. The Clarifying Lawful Overseas Use of Data Act — the CLOUD Act, in force since 2018 — makes this explicit: a US provider can be ordered to produce data in its possession, custody or control regardless of where that data is stored.

Read that once more. Regardless of where that data is stored. A German region, a Canadian region, a facility with a national flag on the marketing page — none of it changes the obligation, because the obligation attaches to the company, not to the rack.

This is why a "sovereign cloud" offering from a hyperscaler answers the residency question convincingly and the sovereignty question not at all. The data centre may well be in Frankfurt. The company that operates it still answers to a legal system on another continent.

What this means under the GDPR

For European organisations the distinction became concrete with Schrems II (Court of Justice of the European Union, C-311/18, July 2020), which invalidated the Privacy Shield and made clear that standard contractual clauses alone are not sufficient where the law of the destination country permits disproportionate government access. Controllers have to assess the actual legal environment and apply supplementary measures where the assessment demands them.

The EU-US Data Privacy Framework adequacy decision of July 2023 restored a legal basis for transfers to certified US organisations. It did not repeal the CLOUD Act, and it is itself the subject of ongoing legal challenge. Building a ten-year infrastructure decision on the assumption that this particular adequacy decision will outlive it is a bet, and worth recognising as one.

None of this means European organisations cannot use US services. It means the transfer impact assessment has to describe what actually protects the data — and "the data centre is in the EU" is a description of residency, not of protection.

And in Canada

The Canadian version of the question looks the same from a different angle. PIPEDA does not prohibit storing personal information outside Canada; it requires that a comparable level of protection travels with it, and that individuals are told their data may be processed in another jurisdiction and accessible to that jurisdiction's authorities.

So a Canadian organisation using a US-operated cloud with Canadian residency has satisfied the location question and inherited the access question. Public bodies in several provinces face stricter rules again. In practice the honest sentence is: your data is in Canada, and a foreign authority may nonetheless be able to reach it.

Three questions that separate the two

When a provider tells you their offering is sovereign, these three answers tell you which question they have actually answered:

1. Who owns the hardware? Not who rents the capacity, not whose name is on the invoice — who owns the machines. A local reseller of a hyperscaler sells you someone else's capacity with a local bill. The underlying operator, and therefore the jurisdiction, is unchanged.

2. Where is the operating company incorporated, and who controls it? A subsidiary of a foreign parent is generally still reachable through that parent. This is the question the word "sovereign" in a product name never answers.

3. Who holds the encryption keys? If the provider holds keys that can decrypt your content, the provider can be compelled to use them. If the keys never leave your side, an order can only produce ciphertext. This is the one measure that changes what is technically possible rather than what is contractually promised.

What good answers look like

There are two defensible routes, and they are not mutually exclusive.

The first is an operator in your own jurisdiction that owns its infrastructure. That is the position we took: our own hardware in Canada, in independent FiberCentre facilities, operating as a registered ISP, ASP and PAS, without dependency on the major cloud providers. It lets us answer question one and question two with a fact rather than a region name.

The second is encryption with keys you control, for everything that has to stay where it is. Most organisations cannot leave Microsoft 365 or Google Workspace this budget year. A gateway that encrypts before data leaves your network means the provider stores content it cannot read, index or hand over — and the CLOUD Act question becomes moot, because there is nothing readable to produce.

In our experience the second is usually the first step and the first is the destination.

The sentence worth taking away

Residency tells you where the building is. Sovereignty tells you who can be made to open it.

If your risk assessment answers only the first, it has not yet described your risk. That is not a reason to panic — it is a reason to ask the three questions above of whoever is currently holding your data, and to write down the answers.

Wondering what this looks like for your own setup? Our sovereign cloud page describes the infrastructure side, and the encryption page the route for workloads that cannot move yet. Or simply talk to us — including about the cases where the honest answer is that a migration is not worth it this year.