What Digital Sovereignty Actually Means

The Reassurance That Is Not What It Seems

The sales call follows a familiar script. You ask about data residency. The vendor confirms that yes, they have an EU region. Your data will be stored in Frankfurt, or Dublin, or Amsterdam. GDPR compliant. Fully certified. Nothing leaves Europe.

It is a reassuring answer. It is also largely irrelevant to the question you should have been asking.

Where your data is stored matters far less than who controls the infrastructure it runs on. And for most organisations running on the major cloud providers, that answer is: an American company, subject to American law.

The CLOUD Act

The Clarifying Lawful Overseas Use of Data Act — the US CLOUD Act — passed in 2018. It gives US authorities the power to compel US-headquartered companies to produce data they control, regardless of where that data is physically stored.

AWS is an American company. Microsoft is an American company. Google is an American company. If any of these companies control the infrastructure your data runs on — and running workloads on their cloud means they do — then the CLOUD Act is relevant to your data, even if it never physically leaves a European data centre.

This is not a theoretical risk. It is a structural feature of how US law works. The US government does not need to enter the data centre. It serves a legal order on the company’s US headquarters, and the company complies. The Frankfurt facility is irrelevant.

Why “EU Region” Is Not the Answer

The logical response from cloud providers was to offer EU-specific regions with additional assurances — data stored only in Europe, processed only by European staff, with restricted US-entity access. These offerings (AWS European Sovereign Cloud, Microsoft EU Data Boundary, and similar) are genuine attempts to address the concern.

But they do not resolve the fundamental issue. The company is still American. The parent entity is still subject to US law. The legal pathway by which US authorities can compel data access still exists. What these products do is make that pathway harder to use and more legally uncertain — which is a real improvement, but not the same as removing it.

More practically: these sovereign cloud tiers come with significant constraints. Not all services are available. Pricing is higher. Moving workloads into them from standard regions is a project. And you are still dependent on a single vendor — you have just traded one kind of exposure for another.

Location Is One Factor. Control Is the Real Question.

True digital sovereignty has three components, and location is only one of them.

Where the data is stored. Data physically located within a jurisdiction is subject to that jurisdiction’s laws and protected from casual access by foreign authorities. This matters, but it is the weakest of the three — a subpoena or legal order can reach data in any jurisdiction if the company controlling it is subject to that jurisdiction’s law.

Who controls the infrastructure. This is the critical question the location conversation tends to skip. If a US-headquartered company controls the compute, storage, and networking your data runs on, that company is a potential vector for compelled access regardless of where the servers are. True sovereignty requires that the controlling entity is not subject to a jurisdiction with extraterritorial data access law.

Whether you can leave. Even if you have good answers to the first two questions today, they can change. A provider can be acquired. A legal framework can shift. A vendor can change their terms, their pricing, or their data access policies. If leaving requires rewriting your application code, you are exposed to those changes whether you want to be or not. Real sovereignty includes the ability to move — without friction, without a migration project, without touching a line of application code.

The Practical Implications

For organisations operating under serious data protection requirements — regulated industries, public sector, defence, healthcare, any organisation handling personal data at scale — this means the question to ask of any infrastructure decision is not “where will my data be stored?” but:

• Is the company controlling this infrastructure subject to extraterritorial access law from a jurisdiction I am not comfortable with?
• If that company is compelled to produce my data, what standing do I have to resist that?
• If I need to move off this infrastructure, what does that cost me — in time, money, and engineering effort?

For most organisations currently running on the major US cloud providers, the honest answers to these questions are: yes, limited, and a lot.

What Sovereignty Looks Like in Practice

An organisation with genuine digital sovereignty has made choices that hold up against all three questions.

They run on infrastructure controlled by entities not subject to unwanted legal reach — European providers, private infrastructure, or a combination. They have not traded one form of dependency for another.

Their application software is portable by design, with no hard dependency on any specific provider’s services or APIs. Switching providers is a configuration change. The cost of moving is near zero. This means their sovereignty is durable — it is not contingent on a specific provider remaining trustworthy or legally protected indefinitely.

And they have a genuine governance model for who can access data within their own organisation — not just protection from external access, but internal access control that is auditable, enforced, and not dependent on manual processes.

This is not the same as “we chose the Frankfurt region.” It is a set of architectural and organisational decisions that make control real rather than nominal.

Why This Matters More Now

The tension between US and EU regulatory frameworks is not resolving. It is intensifying. The EU is expanding data protection requirements, AI governance rules, and critical infrastructure regulations. The US shows no sign of limiting the extraterritorial reach of its surveillance and data access law.

Organisations that have genuinely addressed sovereignty — through portable software, provider-agnostic infrastructure, and real control over their data — are insulated from this tension. Organisations that have addressed it nominally — by choosing a “sovereign” tier of a US cloud provider — are accumulating regulatory and operational risk that they may not fully see yet.

The question is not whether to take sovereignty seriously. It is whether to do it structurally or to keep deferring it.