CADA Cloud Sovereignty: The 4 Assurance Levels and Which Cloud Providers Actually Qualify

Post #1567 in the sota.io EU Cloud Compliance Series

The EU Tech Sovereignty Package finalised in June 2026 introduced a structural change to how European public-sector procurement evaluates cloud infrastructure. At its core is a four-tier assurance framework embedded in the Cloud and AI Development Act (CADA): a qualification system that goes beyond GDPR compliance or geographic data residency and asks a more fundamental question — who controls the cloud, and under whose law?

For SaaS developers building products for ministries, health authorities, municipalities, and state-owned enterprises, the four CADA assurance levels determine which cloud providers you can use and still pass procurement requirements. This guide explains each level, which providers qualify, and — critically — why AWS, Azure, and Google Cloud fail at Level 3 despite operating EU-based data centres.

The Problem CADA Solves

Before CADA, EU public-sector cloud procurement operated on a patchwork of national rules, EUCS (EU Cybersecurity Scheme for Cloud Services) certification requirements, and GDPR-derived Data Processing Agreements. The result was confusion: a German municipal authority might require data residency in Germany (satisfied by AWS Frankfurt), while simultaneously discovering that CLOUD Act exposure meant US law enforcement could compel access to that data without any German court order.

CADA centralises and clarifies this. Rather than leaving sovereignty assessment to individual procurement offices — each running their own interpretations — CADA establishes a single, verifiable four-tier assurance ladder for cloud services serving public-sector bodies and critical infrastructure operators across the EU.

The four levels are progressive: a provider that qualifies for Level 3 also satisfies Levels 1 and 2. The levels are defined by the nature of control, not just geography.

The Four CADA Assurance Levels

Level 1 — Data in EU: Geographic Residency

What it requires:

• All customer data is stored, processed, and backed up within EU member states
• Data transfer outside the EEA requires documented GDPR-compliant mechanisms
• Processing infrastructure located in EU data centres operated under EU data protection law

Who qualifies: Virtually every major cloud provider can meet Level 1. AWS, Azure, GCP, OVHcloud, Hetzner, Scaleway, and others all operate EU-based infrastructure and can contractually commit to EU data residency.

Where it falls short: Level 1 does not address jurisdictional control. A cloud provider can store data in Frankfurt while remaining subject to US, UK, or Chinese law regarding disclosure. Data residency without jurisdictional sovereignty is compliance theatre — the data is physically in the EU but legally accessible to non-EU authorities.

Use cases where Level 1 suffices: General public administration services not handling sensitive personal data, non-critical government digital services, internal administrative tools for lower-risk agencies.

Level 2 — Independence from Third-Country Authorities: Jurisdictional Firewall

What it requires:

• The cloud provider demonstrates that no third-country law (outside EU/EEA) can compel access to customer data without an EU court order
• The provider's corporate structure must prevent extraterritorial legal access vectors
• Contractual and technical controls exist to resist third-country law enforcement requests

Who qualifies at Level 2: This is where US hyperscalers encounter the first structural barrier. The US CLOUD Act (18 U.S.C. §2523) gives US law enforcement the authority to compel US-incorporated entities to disclose data stored anywhere in the world. AWS (Amazon.com Inc., Delaware), Microsoft Azure (Microsoft Corporation, Washington), and Google Cloud (Google LLC, Delaware) are all covered by the CLOUD Act.

Their EU subsidiary structures — AWS EMEA SARL (Luxembourg), Microsoft Ireland Operations Ltd, Google Cloud EMEA Ltd (Dublin) — do not create genuine jurisdictional independence. EU courts have consistently held, and the CLOUD Act itself makes clear, that parent company control over the subsidiary is sufficient to extend CLOUD Act obligations globally. The EU subsidiaries are operationally dependent on US-parent systems, tooling, personnel, and ultimately ownership.

EU-headquartered providers such as OVHcloud, Scaleway, Hetzner, and IONOS qualify for Level 2 because their parent entities are incorporated in France, Germany, or Austria — jurisdictions without extraterritorial data access legislation analogous to the CLOUD Act.

Use cases where Level 2 suffices: Personal data processing for EU citizens by regional authorities, health service administrative data, procurement and contracting platforms.

Level 3 — EU Ownership, EU Personnel, EU Jurisdiction: Full Sovereignty

What it requires:

• The cloud provider is owned or majority-controlled by entities incorporated in EU member states
• Key technical and security personnel are EU nationals or EU residents operating under EU employment law
• All access to customer data — including administrative and emergency access — is performed exclusively within EU jurisdiction
• No non-EU entity holds operational control, directorship, or effective veto power over the provider

Why Level 3 is the critical threshold for sensitive public-sector data: Level 3 is where the CADA framework draws the line between "operationally compliant" and "structurally sovereign." Even providers that achieve Level 2 through corporate engineering — creating genuinely independent EU subsidiaries — struggle with Level 3 if their underlying technology stack, support personnel, or ownership structure traces back to a non-EU parent.

Level 3 provider qualification matrix:

The structural failure mechanism for US hyperscalers: The issue is not that US hyperscalers refuse to comply with CADA — it is that their corporate structure makes Level 3 structurally impossible without fundamentally divesting their EU operations to genuinely independent EU entities. A subsidiary with a US parent is, by definition, subject to US parent company control. That control creates an access vector for US law enforcement via the CLOUD Act, and CADA's Level 3 requirements explicitly rule out this structure.

AWS's European Sovereign Cloud (AWS ESC), Azure's EU Data Boundary, and Google's Sovereign Cloud offerings are technical architecture proposals, not ownership restructurings. They may achieve EUCS Substantial certification, but they cannot achieve CADA Level 3 because the parent company structure has not changed.

Level 4 — Full Supply Chain Sovereignty: End-to-End Control

What it requires:

• All hardware, firmware, software components, and network infrastructure in the supply chain must be manufactured or developed within EU/EEA jurisdictions or by verified-trustworthy partners
• No components from jurisdictions with mandatory backdoor requirements or supply-chain manipulation histories
• Full transparency over the hardware bill of materials for all compute, storage, and networking infrastructure

Current market reality: Level 4 is aspirational for 2026. No commercial cloud provider currently holds full supply chain sovereignty — EU providers like OVHcloud and Hetzner depend on hardware from Intel, AMD, and ARM, all US-headquartered semiconductor companies. Network equipment involves Cisco, Juniper, and similar US firms.

Level 4 is primarily relevant for defence, intelligence, and ultra-sensitive critical infrastructure. For most public-sector SaaS use cases, Level 3 is the practical ceiling.

Level 4 pathway: The EU's AI Factories programme and the European Chips Act fund is building towards EU supply chain sovereignty for compute hardware, but this is a 2028–2030 horizon. For procurement in 2026, Level 3 is the target.

CADA vs EUCS: Understanding the Relationship

CADA and EUCS are complementary frameworks that address different aspects of cloud sovereignty:

A cloud provider can hold EUCS High certification and also qualify for CADA Level 3 — these are complementary, not competing. In practice, CADA Level 3 qualification is slightly more demanding than EUCS High because it adds the EU ownership and personnel requirements explicitly.

Practical implication for procurement: Public-sector bodies using EUCS High-certified providers are meeting EUCS requirements but may still fail CADA Level 3 requirements if the provider has a non-EU parent structure. Procurement offices need to verify both.

What CADA Level 3 Means for SaaS Developers

If you build SaaS products for EU public-sector customers — health authorities, regional governments, justice systems, educational institutions receiving public funding, critical infrastructure operators — the infrastructure your application runs on must qualify for the CADA level your customers' procurement requires.

The Tiered Impact on Your Infrastructure Choices

Ministries and federal agencies (high-risk data): Will require Level 3 compliance from cloud infrastructure providers by end of 2026 for new procurement, and during renewal for existing contracts. If your SaaS runs on AWS, Azure, or GCP, you face contract non-renewal risk.

Regional and municipal authorities (medium-risk data): Level 2 is typically sufficient for administrative data, but Level 3 requirements are expanding as member states implement CADA through national procurement rules.

Public sector-adjacent (universities, NGOs, state-funded research): Level 1–2 typically applies, with Level 3 recommended for sensitive research data or when collaborating with federal agencies.

EU AI Act intersection: High-risk AI systems deployed in public-sector contexts face the strictest requirements. An AI system used for public benefits eligibility (Annex III, Point 5), law enforcement (Annex III, Point 6), or justice (Annex III, Point 8) must have its underlying infrastructure qualify for CADA Level 3 to meet the data governance requirements of EU AI Act Article 10.

The Migration Decision Framework

If you currently run on AWS, Azure, or GCP and have public-sector customers, the question is not whether to migrate but when and how. The timeline matters:

Urgency Assessment Matrix

Migration Architecture Patterns

Pattern 1 — Full lift-and-shift to CADA Level 3 provider

Move your entire stack (compute, storage, managed databases, CDN) to an EU-headquartered provider. Appropriate when:

• Your entire business is public-sector focused
• Your SaaS architecture is moderately complex (< 50 managed services)
• You need to achieve Level 3 compliance on a short timeline

Providers: Hetzner, OVHcloud, Scaleway, IONOS, Exoscale

Pattern 2 — Hybrid architecture with CADA-compliant data tier

Keep non-sensitive workloads (build CI, dev environments, analytics) on existing infrastructure while moving customer data and application compute to Level 3 infrastructure. Appropriate when:

• You have mixed public/private sector customer base
• Your architecture has hard dependencies on AWS/Azure/GCP services (ML, managed AI services)
• Full migration is a 12–18 month project

Pattern 3 — EU-native PaaS for the application tier

Deploy your application layer on an EU-native managed platform that runs on CADA Level 3 infrastructure, while managing data sovereignty at the database layer. Appropriate when:

• You want managed deployment without full IaaS management burden
• You need git-based deployment workflows
• Your team lacks deep infrastructure expertise

For Pattern 3, European managed PaaS platforms that run exclusively on EU-headquartered infrastructure (no US parent, no CLOUD Act exposure) satisfy Level 3 requirements for the application tier. sota.io, built on Hetzner Germany, is an example: EU-owned infrastructure from the bare metal up, with no US parent company in the ownership chain.

Provider Deep-Dive: Why Each Major Provider Fails or Qualifies

AWS (Amazon Web Services)

CADA Level 3 status: Fails

The CLOUD Act analysis is the terminal blocker. Amazon.com Inc. (incorporated in Delaware) has global CLOUD Act exposure. AWS EMEA SARL (Luxembourg) is the EU contracting entity, but Amazon.com holds ultimate ownership and operational control.

AWS European Sovereign Cloud (AWS ESC) addresses some technical concerns: data stays in EU, AWS personnel with US security clearances are excluded from sovereign cloud operations, and a "Sovereign Control" layer restricts AWS's internal access. However:

1. Amazon.com Inc. remains the ultimate parent — ownership has not changed
2. US law enforcement can still compel Amazon.com to produce data held by its subsidiaries
3. CLOUD Act supersedes contractual commitments — even if AWS contractually commits not to disclose, the CLOUD Act can override this

EUCS High eligibility: Under active ENISA discussion. ESC may achieve EUCS High through technical controls, but this does not automatically translate to CADA Level 3 because CADA adds ownership requirements that EUCS does not.

Microsoft Azure

CADA Level 3 status: Fails

Microsoft Corporation (Redmond, Washington) has the same CLOUD Act exposure as Amazon. Microsoft Ireland Operations Ltd is the EU contracting entity, but Microsoft Corp. holds control.

Azure's EU Data Boundary restricts certain data flows and personnel access, but like AWS ESC, it is a technical architecture change without ownership restructuring.

Microsoft has explored creating a genuinely independent EU cloud entity (similar to the OpenAI-France structure) but has not completed this as of 2026.

Google Cloud

CADA Level 3 status: Fails

Alphabet Inc. (Delaware), Google's parent, creates CLOUD Act exposure. Google Cloud EMEA Ltd is the EU entity, but Google LLC (Delaware) operates the underlying infrastructure.

Google's Sovereign Cloud offering, operated through partnerships with Thales (for France) and T-Systems (for Germany), represents a more structural approach — data is encrypted with keys managed by the EU partner, and Google personnel cannot access it. This is closer to genuine sovereignty but still involves Google's underlying infrastructure and a complex governance arrangement that CADA procurement offices are still evaluating.

Hetzner Online GmbH

CADA Level 3 status: Qualifies

Hetzner is privately owned, family-held, incorporated in Gunzenhausen, Bavaria. No US parent. No CLOUD Act exposure. German personnel. German jurisdiction for all legal matters. Hetzner is the CADA Level 3 reference implementation for bare-metal and private cloud workloads.

Practical limitation: Hetzner is IaaS — you manage VMs, networking, storage yourself. For teams needing managed PaaS capabilities, Hetzner is the infrastructure layer, not the full stack.

OVHcloud

CADA Level 3 status: Qualifies

OVH SAS (Roubaix, France), publicly traded on Euronext Paris. No US parent. French jurisdiction. OVHcloud offers a broader managed service catalogue than Hetzner, including managed Kubernetes, object storage, and database-as-a-service products.

OVHcloud is pursuing EUCS High certification and is expected to qualify based on its ownership structure and technical architecture.

Scaleway

CADA Level 3 status: Qualifies

Scaleway SAS, a subsidiary of Iliad SA (Xavier Niel's holding, France). French jurisdiction, no CLOUD Act exposure. Scaleway has a narrower managed service catalogue than OVHcloud but strong positioning for CADA Level 3 workloads requiring developer-friendly tooling.

Procurement Language: What to Request

When your customers are EU public-sector bodies, your SaaS proposals increasingly need to address CADA explicitly. Standard language for procurement responses:

For Level 1 requirements:

"[Product name] stores and processes all customer data exclusively within EU member states. Data at rest and in transit does not leave the EEA. Data processing is governed by [EU provider name] DPA, which complies with GDPR Chapter V."

For Level 2 requirements:

"[Product name] runs on infrastructure provided by [EU provider name], a company incorporated in [Germany/France/Austria]. The cloud provider has no parent entity incorporated in the United States, the United Kingdom, or any jurisdiction with extraterritorial data access legislation. Customer data is not subject to third-country law enforcement access without an EU court order."

For Level 3 requirements:

"[Product name] operates on CADA Level 3-qualified infrastructure. Our cloud provider, [EU provider name], is owned and controlled by EU-incorporated entities, operates with EU-resident personnel, and is subject exclusively to EU jurisdiction for all data access decisions. No CLOUD Act exposure exists in our infrastructure stack. Documentation available upon request."

The Timeline: When CADA Level Requirements Go Live

The CADA framework is rolling out through member state implementation of the EU Tech Sovereignty Package. The practical procurement timeline:

SaaS teams serving public-sector clients should treat 2027 as the hard deadline for federal ministry use cases and 2027–2028 for the broader public sector.

Developer Checklist: CADA Level 3 Readiness

Use this checklist when evaluating whether your SaaS architecture qualifies for Level 3 requirements:

Infrastructure layer:

• Primary compute runs on EU-incorporated, EU-owned cloud infrastructure
• No US-headquartered parent company holds ownership or operational control over your cloud provider
• Storage and managed databases operate on the same CADA-qualifying infrastructure
• CDN/edge network does not route customer data through non-EU jurisdiction nodes
• Managed services (email delivery, monitoring, logging) are CADA Level 2+ compliant

Ownership and personnel:

• Your own company is incorporated in an EU member state (or has EU subsidiary for EU operations)
• Access to customer data is limited to personnel operating under EU employment law
• No vendor support personnel operating under non-EU jurisdiction can access your production environment

Documentation:

• Cloud provider can supply CADA Level 3 attestation documentation
• Your DPA explicitly includes jurisdictional sovereignty language
• Sub-processor list includes only CADA Level 2+ entities
• Incident response procedures use only EU-jurisdiction communication channels

Procurement readiness:

• Standard procurement response templates updated with CADA language
• EUCS certification status of your provider documented
• Internal technical assessment completed confirming Level 3 qualification
• Legal review of contractual commitments to customers completed

What This Series Covers Next

This is post #1/5 in the sota.io CADA Cloud Sovereignty series:

• #1 (this post): The four assurance levels and provider qualification matrix
• #2: Level 3 technical requirements in depth — EU HQ, EU personnel controls, legal structure analysis
• #3: CADA vs EUCS — which certification framework matters more for your procurement
• #4: SaaS developer infrastructure sourcing — inheriting CADA compliance through your cloud provider choice
• #5: 25-step CADA compliance checklist for developers building sovereignty-compliant SaaS

The practical summary: if you build for EU public sector, the infrastructure choice is now a compliance decision, not just a performance or cost decision. AWS Frankfurt, Azure Netherlands, and GCP Belgium can hold your data — but under CADA Level 3, they cannot hold your customers' public-sector data.

Regulation references: EU Cloud and AI Development Act (CADA), EU Tech Sovereignty Package (June 2026), ENISA EU Cybersecurity Scheme for Cloud Services (EUCS), CLOUD Act 18 U.S.C. §2523 (March 2018), EU Chips Act (Regulation (EU) 2023/1781), GDPR Chapter V (international data transfers).