Digital Sovereignty & EU Policy  ·  28 June 2026

The Letterbox Test

The EU's new sovereignty framework is the most serious attempt yet to define what sovereign cloud actually means. It then flinches.
By Alan Wright  ·  The Haunted Lighthouse Limited  ·  Peel, Isle of Man

On 3 June 2026, the European Commission published the Tech Sovereignty Package -- the legislative outcome of roughly four years of delay, diplomatic pressure, and internal argument about what European digital sovereignty is supposed to mean in practice. At its core is the Cloud and AI Development Act, a framework that finally moves the conversation beyond data residency. The people who wrote it understood the problem. Then they wrote Level 1.

That matters, because CADA is going to be the reference point for public sector cloud procurement across 27 member states for the next decade. Getting the diagnosis right is not academic. Neither is getting the treatment right.


What CADA gets right

Start with the genuine achievement. The four-tier Union assurance framework -- Levels 1 through 4 -- is a substantive attempt to codify what sovereign cloud actually requires. Previous efforts, including the long-stalled EU Cloud Cybersecurity Certification Scheme, collapsed partly because nobody could agree on whether sovereignty was about data location, ownership, law, or operational control. CADA answers: all of the above, in escalating combination.

At Level 2, providers must demonstrate a complete and up-to-date software bill of materials, documented dependency chains, controls to block remote tamper mechanisms in third-country software components, source code audit rights, and evidence that customer data is not being used to train AI systems operated by third-country entities. At Level 3, personnel must be EU citizens, support operations must be performed by EU residents, and third-country control becomes presumptively disqualifying. At Level 4, third-country control is an absolute bar -- no Commission carve-out available -- and the control standard extends to effective influence over technical evolution, maintenance priorities, and security remediation of software components.

This is not sovereignty washing. The Annex II criteria, and the forty pages of audit evidence requirements in Annex III, were written by people who know what the CLOUD Act does and why data residency alone does not neutralise it. The supply chain transparency requirements at Level 2 are more operationally demanding than anything in NIS2. The ownership and control audit at Level 3 requires tracing shareholding structures to ultimate beneficial owners, identifying veto rights, and demonstrating that no third-country entity can exercise strategic influence over the provider -- even through commercial or financial dependency rather than direct ownership.

For the first time, a major EU legislative proposal has defined sovereignty in terms of operational substance rather than contractual geography. That is worth acknowledging before pulling it apart.


The foundation

Annex II, criterion (a), Union assurance Level 1:

"the cloud computing service provider is established in the Union"

That is the entry requirement. Everything else in the framework -- the SBOM, the supply chain controls, the citizenship requirements, the ownership audit -- sits on top of that single criterion. And that criterion is assessed by legal incorporation under the law of a Member State.

The consequences are immediate and concrete.

A cloud computing service provider incorporated in Delaware, with a registered office in Dublin established in 2019, clears criterion (a) at Level 1. It is established in the Union. Its infrastructure can be wherever the customer does not object to. Its personnel need not be EU citizens. Its cybersecurity posture need only meet "state of the art" -- a phrase that does considerable work without a defined standard attached to it. It self-certifies. No auditor reviews the claim. SMEs get automatic mutual recognition across all member states on the strength of that self-certification alone.

A cloud computing service provider incorporated in the Isle of Man -- a Crown Dependency with EEA-equivalent data protection, a Cyber Essentials certification programme, and infrastructure hosted on servers in Nuremberg -- fails criterion (a). It is not established in the Union. For the purposes of CADA, it is a third country. So is the United Kingdom. So is a sole trader in Leeds running a sovereignty-first infrastructure stack with no US cloud exposure, no CLOUD Act surface, and better operational hygiene than most entities that will self-certify Level 1 next year.

The framework does not distinguish between them. The Delaware company with the Dublin letterbox and the Manx operator with the Nuremberg rack occupy different positions in the CADA hierarchy. The Delaware company is inside. The Manx operator is not.


The CLOUD Act problem CADA cannot name

Here is what the Dublin letterbox does not change.

A Delaware corporation with a European subsidiary is still a US person under federal law. 18 U.S.C. § 2713 -- the CLOUD Act -- requires providers to preserve, backup, or disclose electronic communications and data regardless of where that data is stored. The text is unambiguous: providers must comply with obligations to disclose data "regardless of whether such communication, record, or other information is located within or outside the United States." The parent company's obligation attaches to the data. The subsidiary's address does not sever it. Customer data sitting in a Frankfurt data centre, operated by an Irish-registered entity, remains accessible to US law enforcement via a warrant served on the Delaware parent. The Frankfurt location is a fact. The CLOUD Act exposure is also a fact. CADA Level 1 certification does not alter either of them.

The Commission knows this. The Annex II criteria at Level 2 require providers to demonstrate "necessary legal, technical and organisational measures" to prevent compelled access to customer data by third-country authorities. The audit evidence requirements in Annex III specify contractual clauses, access controls, and architectural separation. What they cannot require -- because no EU regulation can -- is that those measures actually work against a US federal warrant. You cannot contract your way out of a federal statute. The subsidiary's articles of association are not a defence to 18 U.S.C. § 2713. The auditor can verify the measures exist. The auditor cannot verify they are effective against the specific legal instrument they are designed to resist.

This is why the words "CLOUD Act" do not appear anywhere in COM(2026) 502. Not in the regulation. Not in the recitals. Not in the 200-page impact assessment. The Commission's chosen language is "extraterritorial laws" and "immunity from extraterritorial application of third-country law" -- technically neutral phrasing that describes, in practice, almost exclusively the legal exposure created by US federal statute. The omission is not an oversight. Naming the CLOUD Act would be a diplomatic incident. Euphemising it is policy.


The Level 2 hole

The middle tier -- where most commercially realistic sovereign cloud procurement will eventually land -- compounds the problem.

At Level 2, EU citizenship of personnel is not a default requirement. The criterion reads that if the public sector body determines citizenship requirements are necessary, the provider should ensure that personnel meeting those requirements are available. Opt-in for the customer. Providers have no obligation to volunteer it. Most public sector procurement teams will not know to specify it. A Level 2 certified service can, within the rules, be staffed by nationals of countries with their own compelled-access legal regimes -- provided they are physically located in the Union.

More fundamentally, Level 2 is where US-parent providers with European subsidiaries are expected to operate -- and Level 2 is precisely where the CLOUD Act exposure the framework cannot name remains live. The ownership and control audit at Level 2 requires demonstrating that third-country control cannot compel access to customer data. But for a US-parent provider, the mechanism of compulsion is not corporate control. It is federal law. The audit can establish that the Dublin subsidiary's board has no instruction from Delaware to hand over data. It cannot establish that a US District Court cannot issue a warrant requiring the Delaware parent to do so regardless.

Level 2 certifies the architecture. It cannot certify the legal environment the architecture operates in.


Two frameworks, one document

Read the regulation honestly and CADA is not a single sovereignty framework. It is two different frameworks bolted together and presented as a continuum.

Levels 1 and 2 are a commercial accommodation. They accept CLOUD Act exposure, tolerate US-parent providers, make citizenship optional, and rely on self-certification at the entry tier. They exist because the Commission cannot build a functional procurement framework that excludes the three companies providing the majority of European enterprise cloud infrastructure without triggering a trade confrontation with Washington that nobody in Brussels wants to have.

Levels 3 and 4 are the actual sovereignty framework. They work not by neutralising CLOUD Act exposure but by excluding the providers who carry it. No US-parent provider can reach Level 3 without a Commission implementing act confirming that the US has implemented specific safeguards -- a political determination, not a technical one, and one the Commission has no obligation to make. Level 4 is an absolute bar. The framework's answer to the CLOUD Act, at the tiers where it matters, is exclusion.

This is the conclusion the Commission's own regulation encodes but will not state. Commission President von der Leyen said in the package launch statement that Europe "cannot afford to depend on others for the technologies that keep our hospitals running, our energy grids stable and our services secure." The regulation she signed off on certifies that dependence as Level 1 compliant, tolerates it at Level 2, and addresses it only at Level 3 and above -- tiers that most public sector procurement will never reach.

The gap between the rhetoric and the mechanism is not a drafting error. It is a political choice. The Commission has concluded that genuine sovereignty and US-parent cloud infrastructure are incompatible -- and encoded that conclusion in certification language at Levels 3 and 4 rather than stating it as policy. The result is a framework that tells European public sector bodies, in effect, that their hospital records and energy grid management systems should not run on AWS or Azure -- while simultaneously providing those providers with a certification pathway for the systems that do.


What procurement will actually do

The framework assumes public sector bodies will conduct rigorous sovereignty risk assessments, correctly identify which activities require Level 2 or above, and specify accordingly in procurement. The history of public sector compliance with similarly structured EU frameworks suggests otherwise. GDPR gave controllers discretion on legitimate interest assessments; most defaulted to consent. NIS2 gave member states flexibility on implementation; transposition quality varied by order of magnitude. CADA gives public sector bodies discretion on assurance level selection; most will default to Level 1, because Level 1 requires a self-certified form and nothing else.

Level 1 self-certification is the path of least resistance, and the framework's risk assessment requirement -- the mechanism intended to push procurement toward higher tiers -- is assessed nationally, inconsistently, and without binding methodology. The Commission has reserved the right to mandate specific assurance levels for NIS2-regulated sectors via implementing acts, which is the strongest lever in the regulation. Whether it is used, and how quickly, will determine whether CADA produces genuine procurement change or a new generation of sovereignty badges on unchanged infrastructure.


The structural verdict

CADA is the most serious legislative attempt yet to engage with what European digital sovereignty actually requires at an operational level. The Annex II criteria at Levels 3 and 4 are substantive. The supply chain transparency requirements are more demanding than anything previously codified in EU law. The ownership and control audit framework, applied rigorously, would exclude providers that current "sovereign cloud" marketing has successfully positioned as compliant.

But the framework flinches at the moment of commitment. It builds genuine sovereignty requirements at Levels 3 and 4, then constructs Levels 1 and 2 in a manner that ensures most procurement never gets there. It euphemises the CLOUD Act into invisibility while encoding the only honest response to it -- exclusion of US-parent providers -- at tiers most public sector bodies will not reach. It allows a Delaware corporation with a Dublin address to self-certify sovereignty while a Manx operator with a Nuremberg server and no US cloud exposure fails the entry criterion.

Recital 61 of the Commission proposal states that the framework's policy objectives "should be understood as the Union's capacity to act autonomously where necessary, while remaining engaged with its international partners." That is an accurate description of what CADA delivers. It is not an accurate description of what von der Leyen promised.

The letterbox passes the test. The hospitals are still on AWS. The framework knows this and has decided, for now, that this is acceptable.

Whether the European Parliament agrees when it reads Annex II is the next question.


Cross-reference: The Gatekeeper is in Washington · The Theatre Pulldown · Your Data in Dublin Isn't as Irish as You Think · The 5:21 PM Proof


Questions about this analysis, or interested in working with The Haunted Lighthouse?
contact@haunted.lighthouse.co.im

The Sovereign Auditor covers digital sovereignty, cybersecurity governance, and data protection policy—with particular focus on Isle of Man jurisdiction and Crown Dependency issues.

Support independent analysis. Subscribe directly—or scan on your phone.

Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.