Sovereign Until Proven Otherwise: The EU SEAL Levels Decoded

Digital sovereignty is having a moment. Everyone from procurement officers to CTOs is suddenly asking a question that used to live in the legal department's bottom drawer: when push comes to shove, whose rules actually apply to your data?

Not where the servers hum. Not whose name is on the invoice. Whose courts. That's the whole game, and it's the question the EU's Cloud Sovereignty Framework, adopted by the Commission in October 2025, was built to answer. The framework hands every cloud service a grade from 0 to 4 on something called SEAL, the Sovereignty Effectiveness Assurance Levels. The trap it's gently trying to save you from: moving everything into a Frankfurt region, feeling the warm glow of having "gone sovereign," and not clocking that an American provider in Frankfurt is still an American provider. Location was never the thing that mattered.

A quick heads-up before we dive in, because it caught me out too. Search "EU SEAL" and you'll trip over a STEP Seal, which is a quality badge the Commission gives to innovation projects chasing funding. Different beast entirely. Same four letters, completely unrelated day job. We want the cloud one.

Two things are really being measured

Strip away the official language and SEAL comes down to two questions that move together as you climb the ladder.

First, whose law can reach your provider. A company headquartered outside the EU can be reached by that country's law wherever it parks its servers. For US providers, the CLOUD Act lets US authorities compel them to produce data regardless of where it's stored. A provider that's genuinely European-owned and European-run answers to European courts and nobody else's.

Second, who holds the encryption keys. Say someone does come knocking for your data. Can they actually read it? If your provider holds the keys, the answer is yes, they can hand over something legible. If you hold the keys yourself, in a vault you control, the request smacks into a wall.

That's it. Jurisdiction and keys. Keep those two in your head and the five levels stop looking like a compliance chart and start looking almost obvious.

The five levels

SEAL-0, no sovereignty. Your data's on a non-EU provider, governed entirely by non-EU law, and you've handed over the whole question without quite meaning to. A foreign legal system is the only one in the room and you've no real way to know about access, let alone stop it. That startup that spun up in a US region last Tuesday because it was cheap and quick? Right here. And honestly? Often totally fine. For experiments, R&D, anything with nothing sensitive in it, SEAL-0 is simpler and cheaper and nobody's going to wag a finger at you.

SEAL-1, jurisdictional sovereignty. This is the Frankfurt move from the top of the piece. Data physically in the EU, GDPR taken seriously, a data processing agreement signed and filed away. EU law formally applies. But the provider is still a non-EU company, so when a foreign legal order shows up, they comply, and that lovely "EU law applies" turns out to be limited in the way that actually counts. You've ticked the localisation box. You haven't changed anything structural. The thing to remember is that the reach follows the company, not the postcode: a subsidiary running a data centre in Dublin doesn't break the parent's chain of control. If you're only ever handling personal data covered by the EU-US transfer arrangements and your risk appetite genuinely allows it, fine. Just don't tell yourself it's sovereignty when it's really compliance in a sovereignty costume.

SEAL-2, data sovereignty. Same provider, but now you've pulled up the drawbridge. EU law is applicable and enforceable, and you hold the encryption keys yourself in an EU vault. The non-EU company still owns the iron underneath you, so outside control hasn't vanished, it's gone indirect. But a data demand now hits keys the provider simply can't produce. They have to come and ask you for them, and that's not nothing: it's a moment where lawyers get involved and you get to say "hang on." It's contractual-and-technical sovereignty rather than the full legal kind, and for plenty of regulated work it's exactly where the risk stops keeping you up at night. Setting it up properly costs real time and money, mind. Key management and contract wrangling are not a Friday-afternoon job.

SEAL-3, digital resilience. You've moved to an actual EU-sovereign provider: a European legal entity, European-controlled, running in European data centres, audited by a recognised European authority. Jurisdiction is now simply EU. A foreign government can't just rock up with a warrant; it has to go through EU courts and EU due process, which changes everything. There's a fun wrinkle, though. The framework lets a little non-EU involvement survive at this level. Some of these providers run on licensed American technology, or live inside joint ventures, and still qualify, because the controlling ownership, the operations, and the certification are all European. That's on purpose. Ripping every last trace of non-EU tech out of the supply chain today just isn't realistic, so the framework asks for strategic control rather than monastic purity.

In France this maps onto ANSSI's SecNumCloud qualification, and the line-up makes the spectrum nicely concrete. At the purist end you've got OVHcloud, which qualified its Bare Metal Pod platform under SecNumCloud 3.2 in 2025 on an entirely European stack; Outscale, Cloud Temple and Worldline keep it company. Scaleway is partway through the same gauntlet. And then, this is the fun one, there's S3NS, a French company fully controlled by Thales but running on Google Cloud technology, which bagged its SecNumCloud 3.2 qualification in December 2025. Bleu, the Orange-Capgemini venture built on Microsoft Azure tech, is chasing the same badge but hasn't crossed the line yet.

Which raises an eyebrow-worthy question worth sitting with: when a "trusted cloud" built on American hyperscaler tech can earn France's strictest sovereignty stamp, what does that tell you? The cheerful reading is that it's pragmatic. You get hyperscaler-grade managed services and a genuine legal firewall, with strategic control sitting firmly with a European entity. The raised-eyebrow reading is that "strategic control" is doing a fair bit of heavy lifting in that sentence. Both have a point, and where you land is mostly a question of how much you trust the firewall. Just go in with eyes open.

SEAL-4, full digital sovereignty. SEAL-3 plus zero critical non-EU dependencies anywhere: keys, staff, monitoring, CDN, DNS, the lot, all European. Complete EU control, EU law only, an audited supply chain top to bottom. It's as restrictive as it sounds. Whole categories of everyday tooling quietly drop off the menu because the vendor isn't European. In practice this is government, defence, and classified territory. For nearly anyone running a commercial workload it's overkill, and SEAL-3 is the realistic ceiling.

If you want the whole ladder on one screen:

Level	Whose law reaches you	Who holds the keys	Roughly who's here	Good fit for
SEAL-0	Non-EU only	Provider	Non-EU provider, non-EU region	Experiments, R&D, nothing sensitive
SEAL-1	EU on paper, non-EU in practice	Provider	Non-EU provider, EU region	Personal data under EU-US transfer rules, and not much more
SEAL-2	EU enforceable, non-EU parent remains	You (EU vault)	Non-EU provider plus your own keys	Regulated work you want to keep on a hyperscaler
SEAL-3	EU only	You or no-access provider	OVHcloud, S3NS, Outscale, Scaleway (in progress)	DORA / NIS2 / PSD3 workloads needing demonstrable sovereignty
SEAL-4	EU only, zero non-EU deps	You / HSM-only	Government & defence builds	Classified, national-security, defence

Don't reflexively climb to the top

Here's the mistake to watch for, and it's the mirror image of the Frankfurt one. People see a ladder and assume the job is to get everything to the top rung. It is not. Hauling a workload up to SEAL-4 when it doesn't need to be there just buys you more cost, fewer choices, and a fresh pile of self-inflicted friction.

The framework itself treats SEAL as a minimum. A tender names the lowest acceptable level for each objective and rejects anything below it. The skill is matching the level to what's genuinely at stake. A public brochure site doesn't need what a payments platform needs, which doesn't need what a classified government system needs. The brochure site sitting happily on a low rung isn't a failure, it's good judgement. Health records, payments, defence-adjacent systems, core government: that's where you climb toward SEAL-3 and mean it.

So, rule of thumb: figure out the lowest level you can comfortably defend to whoever's going to ask, and aim there. Higher isn't better. Fit is better.

SEAL is only half of what the framework does

One more thing, because it's easy to wander off thinking SEAL is the whole show. It isn't. Sitting right beside the SEAL rating is a separate Sovereignty Score, a weighted percentage spread across eight objectives covering strategy, legal, data and AI, operations, supply chain, technology, security, and sustainability.

The two do different jobs. SEAL is a floor: does this service clear the bar, yes or no? The Sovereignty Score is a ranking: among the ones that cleared it, which is most sovereign? In a procurement, the first decides who's even allowed to bid, and the second helps decide who wins. Supply chain carries the heaviest weight in that score, which, if you fancy reading the tea leaves, hints at where Europe reckons it's most exposed.

Where does your own setup actually sit?

Four questions, answered honestly.

• Where does your provider's parent company answer to the law? Non-EU puts you at 0 or 1. EU puts you in 3 territory. If you genuinely don't know, assume 0, because uncertainty isn't neutral here.

• Who holds the keys to your most sensitive data? If it's the provider, 0 or 1. If it's you, in an EU vault, 2 or 3.

• Do you have an exit plan you've actually tested? Not a hopeful paragraph in a runbook, a migration you've really rehearsed. If yes, you're 2 or above. If you've done precisely nothing, 0 or 1.

• And the one that cuts through all of it: if a non-EU court ordered your provider to hand over your data tomorrow, would you even find out? "No idea" is a 0-or-1 answer. "It'd take an EU court order, we'd know, and we have a procedure" is a 3 answer.

If those made you wince a little, that's the post doing its job. SEAL really does boil down to two things: whose law can reach your provider, and who holds the keys. Everything else is detail. Go find out what your cloud's level actually is.

This explains SEAL as defined in the European Commission's Cloud Sovereignty Framework, v1.2.1, October 2025. It's not legal or compliance advice. What you're actually obligated to do depends on your jurisdiction and how your organisation is classified, so talk to qualified counsel before making architecture calls off the back of a self-assessment.