Because of geopolitical shifts, sovereignty has become a word European politicians keep stressing. What it means in practice remains somewhat vague, because the debate mostly plays on fears that the US government could request data from cloud providers or force those providers to stop services. That makes it easy to create catchy one liners around sovereignty that work well in the media, but how to put it into contracts remains an open question.

The Cloud Sovereignty Framework that DG DIGIT of the European Commission presented in October 2025 is an attempt to answer that question. The framework is not a label, but a procurement tool for measuring how sovereign a service really is. It assesses eight sovereignty objectives, SOV-1 through SOV-8, and assigns each of them a Sovereignty Effectiveness Assurance Level, SEAL, from 0 to 4:

• SEAL-0 No sovereignty.
• SEAL-1 EU law applies in theory; enforcing it comes with challenges.
• SEAL-2 Data sovereignty: EU law is enforceable over your data, without special effort from the customer.
• SEAL-3 Digital resilience: real EU influence, and no one abroad can flip your off switch.
• SEAL-4 Full digital sovereignty: technology and operations fully under EU control, EU law only, no critical dependencies outside the EU. This last point means that the entire supply chain, from chips to software, must be located in the EU.

The weighting reveals what really matters, because supply chain sovereignty , SOV-5, counts for 20%, the heaviest objective. You cannot reason your way to sovereignty through law or certification. The deciding factor is where the silicon is produced and where the code is written. This may also betray an underlying EU objective, namely a way to give the economy a boost by pushing production of these things into the internal market. Since this partly concerns specialist knowledge that is not available in Europe, the question is how promising that is. An attempt by Taiwan based TSMC to build a chip factory in the United States is, to put it mildly, not going smoothly.

The reality check of April 2026

By now the framework is no longer theory. On 17 April 2026, the European Commission awarded a Sovereign Cloud procurement worth €180 million, over a period of six years, to four providers. The admission threshold was SEAL-2; most winners reached SEAL-3; no one reached SEAL-4. Not a single party. That does not mean the bidders failed, but that the framework honestly reports that Europe has dependencies that cannot currently be avoided.

A small elephant in the room: are these actually hyperscale clouds?

It is also worth pausing here to consider the size of the providers that won the procurement, compared with the American hyperscalers. Hyperscale is not about ambition, but about scale: millions of servers, regions on different continents, and investment budgets that read like defense budgets. By that yardstick, even OVHcloud, Europe’s largest cloud player, is one order of magnitude, or two or three, smaller than any individual American hyperscaler. Those hyperscalers each spend more on infrastructure in Europe in a single quarter than Europe’s own cloud sector turns over in years. The uncomfortable truth: Europe does not have a hyperscale cloud. It has good cloud providers, but no hyperscaler. A SEAL-4 hyperscale cloud would therefore mean building the hyperscale base and making it sovereign at the same time. That is quite an undertaking and requires enormous investment, investment whose return you may wonder about, since it will also take years to build the required scale and the processes that come with it. I will explore that in more depth in the next posts.

Why is hyperscale important?

Sovereignty has two faces: legal, meaning who can lawfully compel or block access, and security, meaning who can technically break in regardless of the rules. The framework assesses these separately through SOV-2 and SOV-7, but in architecture they get in each other’s way. Part of what makes hyperscale hyper is that the security signal is global and consists of trillions of daily signals analyzed by a giant AI driven system based on the most advanced AI models. An attack seen at one customer protects everyone else minutes later. A shielded national cloud sees only a fraction of that signal and patches with less collective wisdom behind it. In addition, the hyperscalers employ thousands of security professionals to keep their cloud as secure as possible, more people than the previously mentioned OVHcloud employs in total.

That means defending against a legal risk can undermine your security and, in practice, your actual sovereignty. Put a workload on a small, relatively lightly instrumented island to avoid a theoretical foreign law, and you may reduce its real resilience against attacks. A hacked sovereign cloud is not sovereign. It has simply exchanged a visible, legal and contestable risk for an invisible, technical, uncontestable and often larger risk. For truly critical systems where legal compulsion is the threat, SEAL-3 or 4 earns its cost; for almost everything else, global scale is what keeps malicious actors out.

Is SEAL-4 really necessary? And for whom?

Although I will go into exactly that in more depth in the next posts, the interesting question is not can it be built? The right question to ask is whether SEAL-4 is required at all, for which systems, and under which circumstances. The war in Ukraine has shown that in wartime the rules go out the window. Even if you have a SEAL-4 cloud running for your crown jewels, a backup in a SEAL-0 cloud might be desirable, so you can keep operating if your SEAL-4 cloud is bombed flat.

For most workloads, even SEAL-2 is excessive. And before we treat foreign legal reach as the monster under every bed: how often does it happen? Rarely. Extraterritorial requests for EU customer data are extremely uncommon and are cited endlessly precisely because they are rare enough to be named. Sanctions that cut off an entire organization are geopolitical exceptions. They are real for a small group of entities that usually already know who they are. Risk is probability times impact, and in these debates people like to pair a frightening impact with the idea that the probability is high, while that is not the case. Anyone who makes a dry risk calculation, without the emotion, will see that SEAL-0 or SEAL-1 commodity cloud is not a compromise for most workloads, but the right and defensible choice.

And then there is the bill

That €180 million procurement means an average of about €7.5 million per provider per year, and because it is a framework contract, even that is a ceiling, not a cheque. Meanwhile, every major American hyperscaler pumps tens of billions annually into European data centers. The Commission procurement is therefore a drop in the ocean: a demand signal, not industrial policy. But an industry signal is not enough. If Europe really wants to bridge the gap, it needs serious investment, think Chips Act and European Processor Initiative.

Without those investments, it is better to look strategically at where dependencies are acceptable and how clouds with different SEAL-levels can be connected to address different threats. We should not forget that supply chain dependencies also work the other way around. With ASML, the Netherlands holds a huge trump card when it comes to the entire supply chain for computer chips.

What we must guard against is using the Cloud Sovereignty Framework dogmatically, because that does far more harm than good. The strength of the Cloud Sovereignty Framework is that it makes visible where the vulnerabilities are, and that makes it an excellent instrument for solid risk management. That is just not very politically sexy and cannot be summarized in a one liner.

The roadmap

By now it should be clear that building a SEAL-4 hyperscale cloud is an enormous undertaking, and that the question is whether it can succeed at all and whether it is the right solution. In the next posts, I will go deeper into what it takes to build a hyperscale cloud. We will climb from bottom to top, along six layers, and ask the same two questions on every floor: what does the supply chain look like when you build it, and when you operate it?

1. Data centers: buildings, power, cooling, fiber.
2. Infrastructure: compute, storage and network hardware.
3. Platform: the control plane that automates and secures everything.
4. Core services: IaaS: VMs, containers, storage, networking, identity, keys.
5. Higher level services: PaaS: messaging, databases, IoT, analytics, AI.
6. Ecosystem: ISVs, integrators and managed service partners.

By asking those questions, we can look at where the gaps are, how much those gaps matter, and if needed what we can do about them.