The EU Defined What "Sovereign Cloud" Means. Most Providers Are Hoping You Haven't Noticed.

Every hosting company in Europe now has a sovereignty page. We do not, and having spent a while with the European Commission's framework, we are in no hurry to write one. Those pages mostly say the same thing, which is that your data stays in Europe and this matters enormously, and almost none of them tell you how to verify a single word of it.

That was survivable while "sovereign cloud" meant whatever a marketing department decided it meant. It stopped being survivable in October 2025, when the European Commission published version 1.2.1 of the Cloud Sovereignty Framework and defined the term in assessable detail: eight objectives, forty-eight criteria, a five-level assurance scale, and weights.

The timing is not academic. Gartner forecasts worldwide sovereign cloud IaaS spending at $80 billion for 2026, up 35.6% on 2025, with European spending rising 83% from $6.9 billion to $12.6 billion and Europe on track to overtake North America on this line item in 2027. Cumulative GDPR fines passed €7.1 billion in January 2026, and the Austrian, French and Italian supervisory authorities have all issued decisions against US-based tools on transatlantic transfer grounds. A great deal of money is moving on the strength of claims that, until recently, nobody had an agreed way to check.

The counter-case deserves airtime, because the sovereignty conversation attracts a lot of wishful thinking. Forrester's 2026 European predictions are titled, more or less, that US tech dominance will prevail regardless: their view is that no European enterprise will shift entirely off US hyperscalers this year, and that regulatory pressure and AI maturity gaps will keep the reliance in place. We think they are largely right, and it does not undermine anything below. Most organisations are not trying to leave AWS. They are trying to answer a questionnaire honestly, and for that you need a method rather than a migration.

There is now a structured way to interrogate those claims, and it is free, public, and considerably more rigorous than anything a vendor will hand you. This post is about how to use it as a buyer.

What the framework actually says

The Commission's Directorate-General for Digital Services built it for public procurement, drawing on CIGREF's Trusted Cloud referential, Gaia-X, the ENISA, NIS2 and DORA landscape, France's Cloud de Confiance and Germany's Souveräner Cloud.

This is not a consultation document gathering dust. In April 2026 the Commission used it to award a €180 million contract for sovereign cloud across EU institutions, bodies and agencies, to four providers, under the Cloud III Dynamic Purchasing System. It then published additional clarification in June because, in its own words, it had received many inquiries about how the framework was applied. The Commission explicitly encourages private organisations to use it, and the implementation guidance with the full criteria is public.

Its central insight is that sovereignty is not one property. A provider can be strong on operational independence and weak on ownership, or excellent on legal exposure and hopeless on supply chain. So it splits sovereignty into eight objectives and scores each separately.

Supply chain carries the heaviest weight, at a fifth of the total. That is the Commission quietly conceding that hardware and software provenance is the hardest sovereignty problem in Europe, and the one nobody has solved. Hold that thought, because it matters later.

Alongside that score sits the SEAL scale, for Sovereignty Effectiveness Assurance Level, which measures whether a provider meets defined thresholds rather than how it ranks. It runs from SEAL-0, meaning exclusive non-EU control, up through Data Sovereignty at SEAL-2, Technological Sovereignty at SEAL-3, and Full Digital Sovereignty at SEAL-4, which requires complete EU control with no critical non-EU dependencies. SEAL-2 was the minimum the Commission set for its own tender.

The mechanic that matters: a provider's overall SEAL is the lowest level it achieves on any single objective. Not an average, not a headline. The worst one.

The scoring mechanic is the part worth stealing

Two things happen in a tender, and the difference between them is what makes this worth borrowing.

SEAL levels act as floors. The buyer sets a minimum level per objective, and a provider falling below the floor on even one objective is rejected outright, no matter how strong everything else looks. The weakest objective decides, not the average.

Only then does the weighted Sovereignty Score rank whoever survived.

The practical consequence is that a headline percentage is meaningless on its own. A provider scoring 70% overall while failing one floor loses to a provider scoring 55% that clears them all. If you take one thing from this post, take that: interrogate the weakest objective, not the overall claim.

Four things that are not sovereignty

The framework is unusually blunt about how this gets misrepresented, and each of these maps to a claim you have almost certainly been shown.

Geography is not sovereignty. The framework scores jurisdiction and control, not where servers physically sit. Infrastructure in Frankfurt does not make a service sovereign if decisive authority over it sits elsewhere. "We host in the EU" answers a far smaller question than most buyers think they are asking, and vendors know it.

There is no SEAL certificate. No accreditation body issues SEAL ratings. An official assessment exists only when a contracting authority scores a provider inside a real procurement. So when a vendor tells you they "are SEAL-3," they are citing something that does not exist as a standalone credential, because a SEAL level means nothing without naming the objective and the procurement context. Treat it as a reason to ask harder questions rather than fewer.

Self-assessments are not assessments. They are useful preparation for both sides, and you should ask for one. Just do not mistake it for a result.

Non-EU ownership does not automatically disqualify anyone. This is where a lot of European vendor marketing, including arguments we have made ourselves, runs ahead of what the Commission actually says. The framework deliberately separates ownership (SOV-1) from legal exposure (SOV-2) and operational independence (SOV-4). Its position is that a European-operated provider with non-EU financial ownership can still evidence strong legal safeguards, genuine operational independence, and EU-controlled security operations. Likewise the CLOUD Act disqualifies nobody automatically. It is assessed under SOV-2, which asks whether any legal, contractual or technical channel exists through which a non-EU authority could compel access.

If you have been sold a story that reduces all of this to "American company, therefore not sovereign," that story is simpler than the EU's own framework. The real question is narrower and more answerable: through what specific mechanism could someone outside the EU reach this data, and what stops them.

Which brings us to AWS

We should declare an interest here, and it is not the one you might expect: we run a lot of AWS. Also Azure, also Google Cloud. A meaningful share of our client work sits on hyperscaler infrastructure because that is what those clients need or specifically asked for, and we build and operate it for them. We are not a pure own-metal shop taking shots at the competition, and what follows is written by people who administer these platforms every week.

In January 2026, AWS launched the European Sovereign Cloud, generally available from a region in Brandenburg. It deserves to be taken seriously rather than dismissed. There is a new European parent company with three German subsidiaries, led by EU citizens resident in the EU, independent billing systems, a European security operations centre, and infrastructure physically and logically separate from other AWS regions with no critical dependencies on non-EU infrastructure. AWS states it can keep operating indefinitely even if connectivity to the rest of the world is severed. The commitment is €7.8 billion through 2040, with sovereign Local Zones planned for Belgium, the Netherlands and Portugal.

Scored against the framework rather than against a slogan, that is a real effort. It would plausibly do well on SOV-4, because operations genuinely appear to sit with EU-resident staff, and it addresses SOV-3 and SOV-7 with architecture rather than contract language.

The objection is equally real and lands squarely on SOV-1 and SOV-2. The German parent is a wholly owned subsidiary of Amazon.com Inc, so decisive authority ultimately sits in Seattle, and legal analysts have argued the structure remains CLOUD Act exposed regardless of who holds the keys day to day. Whether independent operation is sufficient mitigation is genuinely contested, and anyone telling you it is obviously settled either way is selling you something.

What the framework gives you is a way to stop arguing about the label. AWS ESC probably clears meaningful floors on several objectives and probably does not clear a demanding floor on SOV-1. Whether that matters depends entirely on the floors you set. For a Berlin startup, likely irrelevant. For a public health authority, likely disqualifying. That is the correct shape of the answer, and it is not one a vendor can give you.

How to actually audit a provider

Borrow the mechanic, not the paperwork. You are not procuring cloud for the European institutions, so you do not need scores. You need floors.

Start by deciding which objectives are non-negotiable for your risk profile, because that decision does most of the work. A fintech under DORA might set meaningful floors on SOV-2, SOV-3 and SOV-7 and legitimately not care about SOV-8. A public body will set more. Most SaaS companies need considerably less than the marketing implies, and there is no prize for over-buying sovereignty you cannot use.

Then ask for evidence against specific objectives rather than for a headline claim. The single most efficient question, and the one we would want asked of us, is this:

Which objectives would you fail a demanding floor on, and why?

A provider who answers that plainly is telling you something real. A provider who responds with a percentage, a certificate that does not exist, or another paragraph about their Frankfurt data centre has answered a different question, and you have learned something anyway.

From there the specifics are unglamorous and checkable:

• Who owns the operating entity, and who owns that owner. Follow it up until you reach a natural person or a listed company.
• Whether any entity in the group sits in a jurisdiction with extraterritorial disclosure law, and through what mechanism it would apply.
• Who holds encryption keys, and whether the provider can technically access plaintext at all.
• Which staff, in which jurisdictions, can reach production systems. Ask for it in the contract if it matters to you, because it is contractible.
• The full sub-processor list, including the boring entries like email delivery, error tracking and payments. This is where EU claims most often quietly break.
• Whether the DPA names any non-EU entity.
• What happens to your data when the relationship ends, and how fast.

Reject on floors first. Compare survivors afterwards.

One certification actually worth looking for

The framework itself produces no badge, but something adjacent now does. CISPE, the trade association for European cloud infrastructure providers and the loudest campaigners against what they call "sovereignty washing," launched a Sovereign and Resilient Cloud Services Framework in April 2026. The first four operators signed up on 30 June: Etix, Phocea DC, Thésée Datacenter and Gigas.

It is worth knowing about for two reasons. It was built by European infrastructure providers rather than by the companies being assessed, and it requires an independent audit covering, in their phrasing, the entire chain from servers to shareholding. That is deliberately broader than a geography claim, since it adds legal, control and ownership criteria on top.

Two caveats before you treat it as a shortcut. The initial cohort is small and at the self-certification stage pending audit, so absence of the badge currently tells you very little. And it certifies the physical and infrastructure layer rather than everything running on top, which means it is a foundation for a sovereignty argument rather than the whole of one.

The objective nobody in Europe passes

One honest note before you take that checklist to market, because it will save you a wasted procurement round.

You do not have to take this from us, which is fortunate, because a hosting company telling you an objective is unwinnable sounds exactly like a hosting company that is losing on it. In the "lessons learnt" section of its own implementation guidance, the Commission writes that SEAL-4, its top level, "is not today relevant in the context of EU Sovereignty considering existing dependence to specific supply chains (chips, hardware)," and suggests relaxing it temporarily so that providers can actually be told apart.

Read that again, because it is a remarkable thing for the authors of a sovereignty framework to publish. The body that defined full digital sovereignty says nobody in Europe can currently reach it, and the reason is silicon.

Supply chain is also the heaviest-weighted objective at 20%, and essentially no European provider scores well on it, ourselves firmly included. We run a mix of x86 and ARM hardware, and the companies that designed all of it are American, British or Japanese-owned. There is no European CPU design available at commercial scale for general-purpose hosting.

The nuance worth knowing, because it is the sort of thing a vendor will use on you: fabrication is no longer the same question as design. Intel's Fab 34 in Leixlip has been in high-volume production since 2023 and builds Xeon server processors in Ireland, with Intel 3 following and roughly €5 billion of further investment committed. So it is now entirely possible for a European provider to run servers whose chips were physically manufactured inside the EU, by a US company, to a US design, on US-owned intellectual property.

Whether that improves your SOV-5 position depends on which part of the chain your risk actually sits in, and that is a real question rather than a rhetorical one. If your concern is physical supply continuity, EU fabrication genuinely helps. If your concern is control and IP ownership, it changes very little.

The framework itself is precise about this, and its SOV-5 criteria are worth borrowing verbatim when you next receive a supply chain claim. It asks separately about the geographic source of physical parts and where hardware is manufactured or assembled; the jurisdiction and provenance of the firmware controlling that hardware; where and by whom software is architected and programmed, plus the jurisdiction governing its packaging, distribution and updates; the degree of reliance on non-EU vendors and proprietary technologies; and whether you have visibility and audit rights across the entire supplier and sub-supplier chain.

That is five distinct questions, and a vendor can answer one of them well while failing the other four. So ask which one they mean. It is usually not the one you were worried about.

None of this is a reason to give up on the framework. It is a reason to set your SOV-5 floor at something achievable and spend your scrutiny on the objectives where providers genuinely differ, which are SOV-1, SOV-2, SOV-4 and SOV-7.

Where we stand, briefly

Since we are asking you to interrogate providers, here is what we tell people who interrogate us.

First, some scoping, because this whole post has been written from a European angle and that is not the whole of what we do. We host and build for clients worldwide, across more than ten countries, and plenty of them have no interest whatsoever in EU sovereignty because it is not a requirement they have. Sovereignty is a constraint some clients carry, not a philosophy we impose on everyone. If your data needs to sit in Singapore or São Paulo, that is a perfectly good conversation and a different one from this post.

For clients who do carry that constraint: EU business runs entirely through Blendbyte GmbH in Berlin, so an EU client's contract, data and legal counterparty are German. There is no US entity, no US parent and no US presence anywhere in the structure, which means no CLOUD Act channel exists. We use EU sub-processors almost exclusively, and Tindra Managed runs EU-only with no US sub-processors at all. Where we host on our own hardware in European data centres, we run our own AS and our own BGP routing, and we build on open standards with full documentation, so leaving us is a decision rather than a project.

The part that complicates any tidy sovereignty pitch, and the reason we are not making one: a significant amount of what we run for clients is on AWS, Azure and Google Cloud. Sometimes because the workload genuinely wants a managed service we would be foolish to rebuild, sometimes because the client already had a relationship, sometimes simply because they asked. We think that is often the right call, and we are not going to talk anyone out of a platform that suits them in order to sell a sovereignty story.

For those workloads, the sovereignty assessment is against the hyperscaler, not against us. Our German contract does not launder an AWS estate into being sovereign, and if we implied otherwise we would be doing precisely what this post is complaining about. What we can do is tell you honestly which of the eight objectives your setup would struggle on, and whether that actually matters for your sector.

One thing we will not pretend about, beyond the supply chain problem we share with the entire continent: we have no office presence anywhere, because the whole team is remote. That means the real question is not where our buildings are but which engineers in which jurisdictions can reach your production systems. It is also contractible, and some clients require EU-only operational access and we run that way for them. If that matters to you, raise it before signing rather than after.

Anything else about our structure, ownership or sub-processors, ask and we will answer it in writing. That offer is the entire point of this post. A provider who will not put their weakest objective in an email is telling you something, and it is not that they do not have one.

Is any of this worth your time?

For most teams reading this, sovereignty matters less than the current volume of noise suggests, and picking an EU region from a hyperscaler is a proportionate response to a proportionate risk. We made a similar argument two weeks ago in There Is a Customer's Email Address in Your Error Tracker Right Now, where the residency question turned out to be the easy part and the harder problem was collecting personal data nobody had decided to collect. The same shape applies here.

For teams in regulated sectors, in the public sector, or with procurement lawyers who have started asking about extraterritorial law, it matters a great deal, and this framework is the most rigorous free tool available for having that conversation properly instead of trading slogans.

And if you are reading this from outside Europe wondering whether any of it applies to you, the specific framework probably does not, but the underlying questions travel. Who owns the entity you are contracting with, which jurisdictions can compel access to your data, who can technically reach production, and what is actually in the sub-processor list. Those are worth asking in any jurisdiction, and the answers are just as revealing.

What has changed is that "sovereign" is no longer an adjective a vendor can apply to themselves unchallenged. There are eight objectives, they are public, and the weakest one is the one that counts.

If a procurement questionnaire just landed on your desk

The most common way people arrive at this problem is not strategy. It is a customer's security team sending over a questionnaire with a question about the CLOUD Act on page four, and a deadline.

We do this work in three shapes. An infrastructure assessment, where we run your existing estate through the eight objectives and tell you what it would actually score and which answers you can defend. Managed hosting, if the assessment concludes you need to move something, whether that is onto our own European infrastructure or into a properly configured hyperscaler region. And ongoing server management or a monthly retainer, if the honest problem is that nobody currently owns this and it will drift again in a year.

If you want a second opinion on any of that, talk to us. The first thirty minutes are free, you will speak to an engineer rather than a salesperson, and if the answer is that your current setup is already fine we will say so and you can have your afternoon back.