The EU Gave Cloud A Sovereignty Score. Here Is How To Read Yours Honestly

By Micky Irons

For years, "sovereign cloud" was a marketing phrase that meant whatever the vendor in the room wanted it to mean. On 20 October 2025 that stopped. The European Commission published the Cloud Sovereignty Framework, and for the first time there is an official way to put a number on how sovereign a cloud service actually is. That number is already shaping 2026 public procurement across the Union, and it sits alongside a EUR 180 million sovereign-cloud tender that European buyers are watching closely.

I run Mickai, a sovereign intelligence operating system that regulated organisations own and run inside their own walls. So I have a stake in this. But I want to read the framework honestly rather than sell you a panic, because the honest reading is the more useful one. Most of what the framework measures, a good hyperscaler can pass. There is exactly one line where that stops being true, and it is worth understanding precisely.

What the score actually is

The framework defines eight sovereignty objectives. Each is graded from 0 to 4 on the SEAL scale, the Sovereignty European Assurance Levels. Zero means no sovereignty, foreign control from one end to the other. Four means full digital sovereignty, complete EU control across contract, technology and operations. You score every objective, apply the Commission's weightings, and get a single figure out of 100 percent.

The eight objectives cover strategic, legal and jurisdictional, data and AI, operational, supply-chain, technological, security and compliance, and environmental sovereignty. The weightings are not equal. The Commission set them so that a provider can score well overall while scoring weakly on one axis. That is by design. The framework is a diagnostic, not a pass-or-fail gate, and the smartest thing you can do is read it that way.

The line that does not move

The objective people misread is SOV-2, legal and jurisdictional sovereignty. It answers one question. Which country's legal system can compel access to your service, your data, or the people running it. And the framework does something unusually blunt for an official document. It names the laws. It quotes the US CLOUD Act of 2018, including the clause that matters, which reaches a US-controlled provider's data "regardless of whether" that data "is located within or outside of the United States." It names the Chinese Cybersecurity Law in the same breath.

This is the part no 2026 law repeals. The CLOUD Act shifts the question from where the data sits to who controls the provider. A US-parented provider remains reachable by a US warrant even when the servers are in Frankfurt, even when the data is encrypted, even when the contract is written under Irish law. That is not a claim I am inventing. It is the mechanism the statute describes and the framework quotes back at you.

Here is how SOV-2 grades in practice. A cloud region inside the EU, operated by a US-parented company, lands around the lower assurance levels. EU law formally applies, but the CLOUD Act exposure remains. Add customer-held encryption keys and a bespoke data-processing agreement and you insulate the data better, but the parent is still legally reachable. Higher up the scale you need an EU-incorporated provider with an EU legal chain. The top of this axis, no foreign-law exposure in contract, technology or operations, is the level a foreign-controlled service cannot reach here, no matter how good its engineering is, because the exposure lives in the corporate ownership, not in the datacentre.

That is the honest core of the whole thing. Almost everything else on the scorecard is achievable with money and effort. This one line is decided by who ultimately controls the entity.

What this does not mean

Now the part the sovereignty industry keeps overselling, so I will say it plainly. This framework does not bar anyone from using the cloud.

Almost every European regime that touches regulated data permits cloud with controls. GDPR permits it. The Digital Operational Resilience Act, in force since 17 January 2025, does not prohibit cloud outsourcing at all. It requires contractual audit rights, exit strategies and resilience testing, and financial entities that meet those terms use hyperscalers every day. The EU AI Act works the same way. None of these say "no cloud." They say "cloud with evidence."

The genuine no-cloud position exists, but it is narrow and it is workload-level, not organisation-level. Classified material at SECRET and above, ITAR-controlled defence data, isolated operational technology on a plant floor, a specific processing activity that fails its data-protection impact assessment. Those workloads should not sit on a foreign-controlled shared cloud. Most of the workloads around them can. If someone tells you your whole institution is legally barred from the cloud, they are selling you fear, and the framework does not support them.

So the real market here is not a legal wall. It is a sovereignty preference, and now it is a preference with a number attached, which is what makes it procurement-relevant rather than philosophical.

Where an owned deployment scores differently

This is where I stop being neutral, because it is the reason Mickai exists.

When you own the deployment, run it inside your own walls, air-gap it where you need to, and hold the keys and the operations yourself, SOV-2 stops being a compromise. There is no foreign parent to compel, no cross-border channel to close, no US warrant that reaches an entity you fully control. That is the one objective a foreign-controlled service cannot match at the top of the scale, and it is exactly the objective the framework spent the most ink naming.

Mickai is built and live. It runs as an owned intelligence system with a cryptographically signed audit record on every action, so the operational and jurisdictional evidence the framework wants is produced automatically rather than assembled for an auditor after the fact. My patent position sits behind it. I have 104 UK applications across 13 families, roughly 2,340 claims, filed under my own name and moving toward examination. I am not telling you to move every workload. Most of yours can stay exactly where it is. I am telling you that for the workloads where SOV-2 has to read four and not one, ownership is the thing that gets you there.

If you want the wider picture around this, my writing on data sovereignty and on jurisdictional risk in AI systems works through the same logic for machine-learning workloads specifically, where the model weights and the inference path add their own exposure.

The takeaway

Score yourself honestly. Run all eight objectives, not just the scary one. Accept that a hyperscaler will pass most of them and serve most of your workloads well. Then look hard at SOV-2 for the handful of workloads where foreign-law reach is genuinely unacceptable, and be honest that no engineering control closes that gap while a foreign entity owns the operator. For those, owned and sovereign is not a slogan. It is the only configuration that reads four.

Frequently asked questions

What is the EU Cloud Sovereignty Framework?

It is a reference the European Commission published on 20 October 2025 that grades cloud services against eight sovereignty objectives, each scored from 0 to 4 on the SEAL scale, producing a single weighted sovereignty score out of 100 percent. It is designed to guide EU public procurement rather than to ban anything.

Does a high sovereignty score mean I cannot use hyperscalers?

No. Hyperscalers can score well on most objectives and lawfully serve most workloads under GDPR, DORA and the AI Act with the right controls. The framework is a diagnostic and a procurement preference, not a legal prohibition on cloud.

Why can a US-parented provider not reach the top legal score?

Because the SOV-2 legal objective measures foreign-law reach, and the US CLOUD Act of 2018 lets US authorities compel a US-controlled provider to produce data regardless of where it is stored. That exposure sits in corporate ownership, so no datacentre location or encryption setting removes it, and no 2026 law repeals it.

When does an owned deployment actually matter?

For the narrow set of workloads where foreign-law reach is unacceptable. Classified data, ITAR-controlled material, isolated operational technology, or any processing that fails its impact assessment. For those, an owned and air-gapped system like Mickai reaches the top of the legal objective because there is no foreign entity left to compel.