You are the IT director at a German health insurer subject to DORA and BaFin oversight. Your board has just forwarded the European Commission’s announcement of the Tech Sovereignty Package, adopted on Tuesday, 3 June 2026, with one sentence: what does this mean for our 2027 cloud procurement? The procurement runs to €18 million over five years. Your CIO wants a one-page note by Friday.

The proposed Cloud and AI Development Act (CADA) is the part of the package that touches your procurement most directly. It will classify cloud providers into four sovereignty tiers. The highest tier — by the legal logic of the proposal — is not reachable by US-headquartered providers because the CLOUD Act creates a structural conflict. Financial, judicial and health data of governments and public-sector organisations will be required to run on infrastructure at the highest sovereignty level. The proposal is a regulation under Article 114 TFEU, which produces directly applicable internal-market effect. If it passes intact, member states cannot weaken its application individually.

It will not pass intact, and it will not pass by 2027. The trilogue will take 18 to 24 months. The first practical effect on your procurement is not the regulation itself; it is the procurement language that smart bidders are already preparing for. Your €18 million tender that closes in autumn 2026 will be read by bidders who are positioning for the CADA classification they assume will arrive in 2028 or 2029. The bidder responses will tell you who is taking the future regulation seriously and who is not.

This article is the audit of what CADA proposes, what the four tiers actually require, what your procurement file should already assume about the regulation’s direction, and the specific question your CIO’s one-page note has to answer before the budget round closes.

What the package proposes

The Tech Sovereignty Package contains four instruments. The first is the Cloud and AI Development Act (CADA) with the sovereignty classification framework. The second is Chips Act 2.0, updating the 2023 statute to raise the EU’s targeted share of global chip production. The third is an Open Source Strategy formalising open source as a structural element of EU digital policy. The fourth is a Strategic Roadmap for Digitalisation and AI in Energy, joined by Commissioner Dan Jørgensen on the dais with Commissioner Henna Virkkunen.

Virkkunen’s framing of the package, at the press conference: “We want to be sure nobody has a kill switch.” Ursula von der Leyen wrapped the politics: “We cannot afford to depend on others for the technologies that keep our hospitals running, our energy grids stable and our services secure.” The political framing was sovereignty. The procurement framing — which is the framing your tender has to engage — is classification, mandatory tier requirements, and the legal basis under Article 114 TFEU that gives the regulation directly applicable internal-market effect.

The cloud component is the most substantive for procurement decisions today. CADA’s four-tier framework is a graded ladder of structural separation from non-EU control: Tier 1 covers minimum data-residency claims; Tier 2 establishes operational independence from non-EU control; Tier 3 requires full architectural separation from non-EU dependencies; Tier 4 claims verifiable continuity under hostile geopolitical conditions. The mandatory-Tier-3 requirement for financial, judicial and health government data is the part that directly affects your procurement. National designated authorities will enforce.

What the four tiers actually require, in operational language

The Commission’s proposal text describes the tiers in regulatory language. The operational translation is what your architecture team needs.

Tier 1 is the data-residency claim. Your provider commits, contractually, to keeping the data on EU soil. This is what most current European-sovereign-cloud offerings claim — Microsoft Azure Sovereign Cloud, AWS European Sovereign Cloud, Google Cloud Sovereign — and what most of those offerings deliver. Tier 1 is consistent with US-headquartered provider operation. Most existing M365 contracts would, with the data-residency clauses already in place, satisfy Tier 1 with no architectural change.

Tier 2 adds operational independence from non-EU control. Your provider commits not just to EU residency but to operational decisions made by EU-headquartered entities. This is the tier where the US-headquartered providers’ sovereign-cloud variants either qualify or do not qualify depending on the contractual structure. Microsoft Sovereign Cloud’s current architecture is engineered to qualify Tier 2 by structuring operational control through Microsoft’s Irish subsidiary with a Polish data-residency option. Whether this qualification survives the trilogue’s interpretation of “operational independence” is one of the open questions.

Tier 3 requires full architectural separation from non-EU dependencies. This is the tier the legal logic of the proposal excludes US-headquartered providers from. The CLOUD Act creates a structural conflict that no contractual structure can eliminate. Tier 3 is the realm of OVHcloud, Outscale, Schwarz Digits’ StackIT, IONOS, T-Systems Open Telekom Cloud, and the federal-government KIPITZ platform. For your health insurer procurement, Tier 3 is the substantive constraint: financial-and-health-data workloads will, on the current proposal, be required to run there.

Tier 4 claims verifiable continuity under hostile geopolitical conditions. The criteria for Tier 4 are not yet enumerated in the public proposal. Continuity under hostility is the property an organisation has when it can continue operating if any single provider, including its primary one, becomes unavailable. Operationally, Tier 4 requires multi-provider portability, off-EU mirror infrastructure for source-distribution dependencies, and a continuity plan that has been exercised. By the working definition the proposal text suggests, Tier 4 is the property no current European provider can yet credibly claim. The criteria definition will be among the most contested elements of the trilogue.

What your procurement file should assume in 2026

Your €18 million tender closing in autumn 2026 will be awarded into a regulatory environment that does not yet exist. Three assumptions, written into the tender and the procurement file, will determine whether the contract awarded in 2026 survives CADA when CADA lands.

Assume Tier 3 for health and financial data workloads. Even if CADA is softened in the trilogue, the German federal procurement layer, the BaFin supervisory layer and the DORA framework are converging on the assumption that sensitive financial-and-health data should not run on US-headquartered cloud infrastructure. A 2026 procurement that locks your health-insurance core systems into a US-provider Tier-1 offering for five years will, by 2028, be operating under a regulatory framework that wants it migrated. Build the migration optionality into the 2026 contract; it is cheaper to negotiate exit clauses at signature than at amendment.

Require bidders to disclose their CADA-tier roadmap. Your tender should ask each bidder, formally, which CADA tier they project being able to certify against by 2028 and what architectural changes they have committed to in order to reach that tier. Bidders that have a serious roadmap will answer in writing with named technical changes. Bidders that have a positioning answer will give marketing language. The difference is the most informative datum your procurement process will extract.

Build EVB-IT and §58 VgV Nr. 4 references into the tender now. The federal procurement-law layer already supports the language you will need when CADA lands. Citing §58 VgV Nr. 4 and the EVB-IT open-source contract terms in the 2026 tender does two things: it establishes precedent on your own procurement file, and it signals to bidders that your procurement office is engaged with the federal sovereignty layer rather than reactive to it.

What CADA does not address

The four tiers cover cloud infrastructure and certain categories of government data. They do not, on the current proposal, address the layers below cloud.

Code hosting infrastructure remains predominantly US-hosted. The European sovereignty stack’s source code lives on GitHub — Microsoft-owned. CADA’s Tier 3 requirement of architectural separation from non-EU dependencies does not, on a strict reading of the proposal text, extend to the build-and-distribution infrastructure of the open-source components the cloud runs on. This is the same gap the Euro-Office launch makes visible elsewhere, and CADA does not currently close it.

Cryptographic trust chains. Certificate authorities and DNS root server operations remain US-dominated. CADA’s sovereignty tiers do not enumerate trust-chain criteria explicitly. A Tier-3-classified provider may still depend on certificate authorities whose root keys are US-controlled.

CI/CD and package distribution. GitHub Actions, npm, PyPI, Docker Hub, Maven Central — the build, package and distribution infrastructure that everything depends on remains predominantly US-hosted. A provider can be Tier 3 on the runtime dimension and Tier 1 on the supply-chain dimension. CADA does not currently distinguish.

This is not a criticism of the drafted scope. It is the observation that CADA does not, on its own, deliver supply-chain sovereignty at the layers below cloud infrastructure. Your procurement file should acknowledge the limit explicitly. A reader celebrating CADA as completing the European sovereignty project will be reading something the proposal does not claim — and which your CIO will benefit from naming in writing before the next regulatory cycle.

What this article is not

It is not a claim that CADA will pass as drafted — the trilogue will modify the proposal; the question is by how much. It is not a claim that the Open Source Strategy is empty — it frames OSS structurally; whether it produces budget is a separate question decided in the next Multiannual Financial Framework cycle rather than in June 2026. It is not a claim that European sovereignty is settled by the package. The package addresses one layer of dependency, leaves others untouched, and depends on a legislative process that runs into 2027 or 2028.

The note your CIO needs by Friday

The one-page note should make three claims and recommend two actions.

The three claims: CADA will be law by 2028 or 2029; the most likely Tier 3 requirement for financial-and-health workloads will survive the trilogue in substantively the form proposed; the supply-chain layer will not be addressed by CADA in this cycle and will require separate procurement attention.

The two recommended actions: write the autumn 2026 tender with mandatory bidder disclosure of CADA-tier roadmap and architectural separation timeline; build supply-chain audit and Codeberg-or-equivalent mirror infrastructure on the customer’s side, regardless of the eventual provider, because that work is required regardless of which CADA tier the provider eventually certifies to.

A note that makes those claims and recommends those actions reads, at the board level, as engagement with the regulatory direction. A note that says “the situation is evolving and we will monitor” reads as the kind of preparation that does not survive a 2029 BaFin compliance audit. The autumn 2026 tender is the file that will be cited in that audit if it goes well, or written about in the regulatory press if it does not.

Sources

Topic overview: Digital Sovereignty in Europe Related articles: How to cite §58 VgV Nr. 4, The vendor wrote the test