Skip to content
Blog · Sovereignty · 26 August 2026 · 8 min read

The sovereign cloud, explained: why you need one — and why it isn't anti-American

"EU region" is a location. Sovereignty is a jurisdiction, an operator and a key. Here is what changed in 2026, the four questions to ask any provider, and how a service on either side of the Atlantic can give European customers a sovereign data layer without moving a single engineer.

For most of the last two decades, choosing a cloud meant choosing between a handful of very good platforms that all happen to answer to the same legal system. That was fine while "the cloud" was mostly a hosting decision. It stopped being fine when the data in it became the thing regulators, procurement officers and customers hold you accountable for — and when they started asking a question that a region dropdown cannot answer: whose law governs this data, and who can be compelled to hand it over?

This post is about that question. It is not an argument against American technology. It is an argument for being precise about what "sovereign" means, because the imprecise version is now costing European buyers real money and costing non-European vendors real deals.

What "sovereign" actually means

People use "sovereign cloud" to mean at least four different things. They are related, but they are not the same, and a provider can satisfy one while failing the other three.

LayerThe questionWhat "yes" looks like
Data residencyWhere are the bytes physically stored?Inside the EU, verifiably, with no replication elsewhere.
Legal jurisdictionWhich law governs the contract and the operator?An EU-incorporated provider, EU governing law, EU courts.
Operational controlWho runs the platform, and whose obligations do they carry?An operator with no foreign parent that can be ordered to act against its customers.
Technical controlWho can read the data?Encryption where the provider does not hold the key, and access rules enforced at the data itself.

Data residency is the easy one, and it is the one most providers sell. Selecting "Frankfurt" tells you where the disks are. It tells you nothing about the other three rows, and it is the other three rows that a regulator or a court will care about.

An EU region operated by a company under another country's law is a location. Sovereignty is a jurisdiction.

Why the question got sharper in 2026

1. The legal collision is structural, not hypothetical

The GDPR requires that personal data of people in Europe be protected under European rules wherever it goes. The United States CLOUD Act, in force since 2018, allows US authorities to compel providers under US jurisdiction to produce data they control, regardless of where that data is stored. Both laws are legitimate expressions of what each jurisdiction wants. The problem is not that either one is wrong; it is that a provider caught between them has to break one of them, and a European customer has no say in which.

It is worth being fair here: most large jurisdictions have some legal mechanism for compelled access. The point is not that one country is uniquely intrusive. The point is that your European customers' regulators recognise their own law, and only their own law, as the one that should govern their citizens' data. If your provider answers to another one first, the customer cannot sign.

2. The institutions stopped talking and started buying

On 17 April 2026 the European Commission awarded its first sovereign cloud framework contract — worth up to €180 million over six years — to four European consortia: Post Telecom with CleverCloud and OVHcloud, STACKIT, Scaleway, and Proximus with S3NS, Clarence and Mistral. What matters more than the money is how the winners were assessed. The Commission applied a Cloud Sovereignty Framework that scores providers across eight objectives — strategic, legal and jurisdictional, operational, supply chain, technological, security, compliance and environmental — with graded "SEAL" levels, and the Commission has said it will apply the same criteria to its own internal digital services and make the framework available to any organisation that wants to adopt it.

Read that framework and one thing is unmistakable: server location is a single criterion among dozens. The framework is built to distinguish between a datacentre in Europe and a provider that answers to Europe. Proposals now on the table would go further and require public authorities across the member states to carry out sovereignty risk assessments before signing cloud and AI contracts. Whether or not every proposal passes, the direction of procurement is set.

3. It has moved from the legal department to the RFP

Five years ago, "where is our data" was a question a lawyer asked after the deal. Today it is a checkbox before the deal, and increasingly the checkbox reads "under EU jurisdiction", not "in an EU region". Vendors selling into public sector, healthcare, defence-adjacent and regulated finance in Europe are losing on that checkbox — including excellent vendors whose product would otherwise win.

Why this is not anti-American

It would be easy to turn sovereignty into a protectionist story. It would also be wrong, for two reasons.

First, European buyers want to keep using American software. Much of the best software in the world is American, and nobody in a European procurement department is looking for an excuse to rip out a tool their teams love. What they cannot accept is the customer data underneath that tool sitting where their own law cannot reach it.

Second, the principle is symmetric. An American hospital group would be just as uncomfortable with its patient records under a foreign court's reach as a Swedish one is. Sovereignty is not a European preference; it is what every serious buyer wants once the question is put to them plainly.

Which means the right answer for a US SaaS company is not "give up on Europe" and it is not "become a European company". It is to separate the product from the data: keep the application, the team and the roadmap where they are, and put the European customers' data on a layer that is European by construction — stored in the EU, operated by an EU company under EU law, and encrypted so that the key stays with the user. The service stays American. The data stays the customer's, in Europe.

The bridge, in one sentence. A sovereign data layer lets a non-European service pass a European sovereignty assessment on the part of the stack that the assessment is actually about.

Where the key lives is the whole game

Encryption at rest and in transit is table stakes; every serious provider has it. It protects you from a stolen disk and from a tapped cable. It does not protect you from a lawful order served on the provider, because the provider holds the key and can be told to use it.

Client-side encryption changes the shape of the problem. If data is encrypted inside the application, on the user's device, before it is sent, then what the provider stores is ciphertext and what the provider holds is nothing that can open it. An order served on the provider yields ciphertext. There is nothing to compel, because there is nothing the provider can do.

This is the technical-control row of the table above, and it is the row that makes the other three robust. A provider under EU law, operating in the EU, storing in the EU, and unable to read the data is a provider that cannot be turned against its customers by anyone — including, one day, by a European government that changes its mind.

Two honest caveats. Client-side encryption means the provider cannot search the encrypted content for you, so applications keep searchable fields in the clear (or in indexed metadata) and encrypt the sensitive payload. And key management becomes the user's responsibility: lose the key, lose the data. Both are design decisions, not deal-breakers, and they are the same trade-offs every end-to-end-encrypted product makes.

Seven questions to ask any provider

  1. Where is the data stored, and can it be replicated outside the EU under any circumstances?
  2. Which entity is the contracting party, where is it incorporated, and which law governs the agreement?
  3. Does the operator have a parent, shareholder or affiliate that could be legally compelled to direct its actions from outside the EU?
  4. Who holds the encryption keys, and is there a mode in which the provider provably cannot read the data?
  5. Is access control enforced at the data itself, or only at the application boundary?
  6. Which sub-processors touch what — and specifically, which ones are under non-EU jurisdiction and what do they hold?
  7. How does an individual exercise the right to erasure, and is it a product feature or a support ticket?

Question six is the one that separates honest providers from the rest. Every real service uses some vendors — for email delivery, SMS, payments, analytics. A provider that says "everything is in the EU, no exceptions" is either running an unusually pure stack or not reading its own contracts. A provider that tells you exactly which vendor holds exactly what is the one whose other answers you can trust.

How the Singularity Database answers them, today

We build a database platform for SaaS teams, so we answer these questions for a living. In present tense, with the roadmap kept separate:

  • Residency. All data is stored within the EU by local cloud service providers. Our core datacentre is in Linköping, Sweden.
  • Jurisdiction. The contracting party is CloudBackend AB, incorporated in Sweden. The Tenant License Agreement is governed by Swedish law, with disputes settled in Linköping.
  • Operations. A Swedish company running its own platform on servers it controls in Europe.
  • Technical control. Every access is authenticated and authorised by an access control list on the data itself, down to the individual object. Each user has a private database that the tenant — the SaaS business — cannot read into; that separation is architectural. Data is encrypted at rest and in transit, and applications can add client-side encryption so that only the user holds the key.
  • Sub-processors, named. We use SendGrid for transactional email, Twilio for SMS and Mixpanel for usage analytics. They are US-based, they are declared in our terms, and the limited contact and usage information they hold is under US law. They never receive database contents. The AI assistant in our console uses OpenAI and only when you open it.
  • Erasure. A user can delete their identity from the account panel. It is a button.
  • Roadmap, stated as roadmap. A policy module for setting rules on where and how data is physically stored is planned. It is not shipped, and we do not sell it as if it were.

The short version

Sovereignty is not a flag on a map. It is a jurisdiction you can name, an operator you can hold to it, and a key the operator does not have. Buyers in Europe have learned to ask for all three. Vendors on both sides of the Atlantic can give it to them — and the ones who do will find that "where is our data" has quietly turned from an objection into a reason to buy.

How sovereignty works here

CloudBackend teamLinköping, Sweden. The Singularity Database is in early access ahead of general availability.

Sources