CADA vs EUCS: Which Cloud Certification Actually Matters for EU Public Sector Procurement

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

EU public-sector procurement teams now face two parallel cloud certification frameworks, and SaaS developers building for government, health, defence, or critical infrastructure clients need to understand both. The EU Cloud Scheme (EUCS), managed by ENISA under the EU Cybersecurity Act, focuses on cybersecurity assurance. The Cloud and AI Development Act (CADA), adopted as part of the EU Tech Sovereignty Package in June 2026, focuses on sovereignty and jurisdictional control.

They address different questions and should not be treated as alternatives. A cloud provider can achieve EUCS High — the top cybersecurity tier — while still failing CADA Level 3 on sovereignty grounds. AWS, Azure, and GCP are the concrete example: their engineering capabilities are sufficient for EUCS High certification, but their US parent corporate structures disqualify them from CADA Level 3 regardless of how many EU-based data centres they operate.

For SaaS developers, the practical consequence is this: understanding which framework your public-sector customers require — and at which tier — determines which cloud infrastructure you can use.

The Two Frameworks at a Glance

EUCS — EU Cloud Scheme

The EUCS is a voluntary (transitioning to mandatory for regulated sectors) cybersecurity certification scheme developed by ENISA under the EU Cybersecurity Act (Regulation 2019/881). It certifies cloud services against three assurance levels — Basic, Substantial, and High — based on the security controls the provider has implemented.

EUCS High, the top tier, requires:

• Comprehensive security control implementation across infrastructure, access management, cryptography, incident response, and supply chain security
• Independent third-party auditing by accredited conformity assessment bodies
• Continuous monitoring and re-certification on a defined cycle
• Strong data protection by design and operational transparency

EUCS is primarily a cybersecurity framework: it certifies that a provider has implemented security controls appropriate for handling sensitive data. What it does not certify is the jurisdictional structure of the provider — who owns it, who can be compelled under which national law to disclose data, or whether an extraterritorial legal order from a non-EU government can reach the provider's infrastructure.

CADA — Cloud and AI Development Act

CADA is a structural sovereignty framework. Its four assurance levels — established in the EU Tech Sovereignty Package (2026) — define the degree to which a cloud provider is insulated from non-EU jurisdictional control. The four levels are:

• Level 1: Data physically located in EU member states
• Level 2: No extraterritorial non-EU legal access vector (no CLOUD Act exposure)
• Level 3: EU ownership, EU personnel, EU jurisdiction throughout the operational stack
• Level 4: Full supply chain sovereignty including hardware, software, and staffing

CADA is primarily a sovereignty framework: it addresses who controls the infrastructure and under whose law, not whether the security controls are sufficiently mature.

The Overlap and the Gap

The confusion in procurement discussions arises because EUCS and CADA overlap at the top — but the overlap is partial and asymmetric.

CADA Level 3 providers effectively satisfy EUCS High in practice. A provider that is EU-owned, staffed exclusively with EU-resident personnel, operates no non-EU access vectors, and controls its full operational stack has already implemented the organisational and access controls that EUCS High requires. The sovereignty constraints of CADA Level 3 are a superset of the access control requirements in EUCS High.

EUCS High providers do not automatically satisfy CADA Level 3. A provider can have impeccable cybersecurity controls — independently certified, continuously monitored, passing every EUCS High audit — while still being majority-owned by a US or non-EU parent entity. AWS has world-class security engineering and could qualify for EUCS High through those controls. It cannot qualify for CADA Level 3 because Amazon.com Inc. (Delaware, USA) owns AWS EMEA SARL, creating the CLOUD Act exposure that CADA Level 3 is specifically designed to eliminate.

This is the central asymmetry every procurement team and SaaS developer needs to internalise: EUCS certifies what a provider does; CADA Level 3 certifies what a provider is.

Comparison Table

Which Framework Applies When

The practical question for SaaS developers is: which framework will your public-sector customer specify in their procurement requirements? The answer depends on the sensitivity of data handled and the type of public-sector body.

Low-sensitivity public administration

Applicable frameworks: EUCS Basic or Substantial. CADA is not typically mandated.

Examples: municipal websites, digital administrative forms, non-personal-data-processing services, internal communication tools for non-sensitive departments.

For this category, major cloud providers including AWS and Azure remain eligible. EUCS Basic certification (or an equivalent national scheme equivalent) is typically sufficient.

Personal data processing by public authorities

Applicable frameworks: EUCS Substantial minimum; EUCS High strongly recommended for health, social services, and educational data. CADA Level 1-2 increasingly required under national implementation frameworks.

Examples: regional health authority patient portals, social benefit processing systems, municipal identity verification services.

The GDPR intersects heavily here: personal data processed under public task legal bases (GDPR Art. 6(1)(e)) requires appropriate security measures. For sensitive categories (health, biometric, criminal justice data), EUCS High is the pragmatic minimum. CADA Level 2 is becoming a default requirement in several EU member states' updated procurement frameworks.

Critical infrastructure and national security-adjacent

Applicable frameworks: EUCS High required. CADA Level 3 typically mandatory. CADA Level 4 under consideration for highest-sensitivity applications.

Examples: power grid control systems, water treatment plant SCADA monitoring, defence logistics platforms, national identity infrastructure, judiciary case management systems.

This is the category where the CADA-EUCS divergence becomes operationally significant. EUCS High alone is not sufficient: the ownership and personnel access requirements of CADA Level 3 are independently mandated. AWS, Azure, and GCP are excluded from this procurement category under CADA Level 3 requirements, regardless of their EUCS certification status.

EU Institutional data

Applicable frameworks: EU institutions follow their own procurement rules (EUCC/EUCS) but are increasingly adopting CADA Level 3 for cloud infrastructure procurement.

Examples: European Commission data processing services, European Parliament IT infrastructure, EU Agency cloud deployments.

Practical Implications for SaaS Developers

If you are building a SaaS product targeting EU public-sector customers, the choice of cloud infrastructure is a certification decision, not just a technology decision.

Scenario 1: Your SaaS targets general government efficiency tools

Your cloud infrastructure needs to support EUCS Substantial (likely to become mandatory in most EU member states by 2027 for services handling personal data). Both hyperscalers and EU-native providers qualify. You have maximum infrastructure choice, but you should position your offering as EUCS-compliant-ready rather than just GDPR-compliant, as procurement language is shifting.

Scenario 2: Your SaaS targets regulated public-sector verticals (health, social services, justice)

Your cloud infrastructure needs EUCS High capability and increasingly CADA Level 2. This is where AWS Frankfurt with contractual EU data residency ceases to be a simple answer: CADA Level 2 requires demonstrating that CLOUD Act compelled access is genuinely blocked, which AWS cannot credibly demonstrate because of Amazon.com Inc.'s US incorporation.

EU-native providers (Hetzner, OVHcloud, Scaleway, IONOS) satisfy CADA Level 2 by corporate structure. If your target customer segments include regional health authorities in Germany, France, or the Netherlands, migrating your infrastructure to an EU-native provider is no longer optional — it is becoming a procurement prerequisite.

Scenario 3: Your SaaS targets critical infrastructure or national security-adjacent sectors

Your cloud infrastructure must qualify for CADA Level 3. AWS, Azure, and GCP are excluded. Your infrastructure choices are constrained to EU-owned, EU-staffed providers: Hetzner, OVHcloud, Scaleway, IONOS, Deutsche Telekom/T-Systems, and a small number of national cloud providers.

For developers currently running on AWS or Azure, this means migration planning is urgent. Procurement cycles in this sector run 12-24 months. If your infrastructure is not CADA Level 3-capable today, you will be excluded from tenders that begin evaluating now.

The Infrastructure Selection Decision Tree

Is your public-sector customer handling critical infrastructure or defence?
├─ YES → CADA Level 3 required → EU-native only (Hetzner/OVHcloud/Scaleway/IONOS)
└─ NO → Is it regulated vertical (health/social/justice)?
         ├─ YES → EUCS High + CADA Level 2 recommended → EU-native preferred
         └─ NO → Is personal data involved?
                  ├─ YES → EUCS Substantial → major clouds eligible but EU-native reduces risk
                  └─ NO → EUCS Basic → broad provider eligibility

The Certification Roadmap: EUCS and CADA Together

For SaaS developers building compliance-conscious products, treating EUCS and CADA as complementary rather than competing frameworks is the correct mental model. A well-positioned EU cloud deployment achieves both:

1. EUCS High certification — validates that your infrastructure provider's security controls meet the EU's highest cybersecurity assurance standard. Provides procurement documentation for security-focused evaluation criteria.

2. CADA Level 3 qualification — validates that your infrastructure provider's corporate structure and operational model eliminate CLOUD Act exposure and extraterritorial access risks. Provides procurement documentation for sovereignty-focused evaluation criteria.

EU-native managed PaaS providers running on EU-owned infrastructure (Hetzner, OVHcloud) occupy a unique position: they inherit CADA Level 3 qualification from their providers' corporate structures while being capable of achieving EUCS High through their security controls. SaaS developers building on this stack can offer both certifications to procurement teams without architectural changes.

Timeline: When Each Framework Becomes Mandatory

Understanding the enforcement trajectory helps developers prioritise infrastructure decisions:

2024-2025 (past): EUCS published as ENISA scheme. Voluntary adoption in most member states. Major cloud providers begin EUCS Basic/Substantial compliance programmes.

2026 (current): CADA adopted as part of EU Tech Sovereignty Package (June 2026). 4-level framework established. Member states begin transposing CADA into national procurement law. EUCS High increasingly referenced in public-sector tender requirements across DE, FR, NL, SE.

2026-2027 (near-term): CADA Level 1-2 mandatory for new public-sector cloud contracts involving personal data in early-adopting member states. EUCS High mandatory for health, finance, and justice verticals under NIS2-derived procurement rules.

2027-2028 (medium-term): CADA Level 3 mandatory for critical infrastructure cloud procurement EU-wide. Full EUCS High certification cycle established across major EU-native providers. Hyperscalers develop structural workarounds (e.g., genuinely independent EU subsidiaries) to compete for CADA Level 2 contracts — but CADA Level 3 remains structurally off-limits.

2028+ (long-term): CADA Level 4 requirements defined for highest-sensitivity applications. EU Cloud Certification Authority (ECCA, proposed) begins issuing CADA conformance certificates. Integrated EUCS-CADA procurement frameworks standard across EU member states.

sota.io's Position in the CADA-EUCS Landscape

sota.io is a managed PaaS running exclusively on Hetzner infrastructure (Hetzner Online GmbH, Gunzenhausen, Germany). In terms of CADA-EUCS positioning:

• CADA Level 3: Qualifies. Hetzner Online GmbH is privately held and family-owned in Germany. No US parent. No CLOUD Act exposure. All operational personnel EU-based.
• EUCS: Hetzner is working through EUCS certification; the underlying infrastructure already meets the technical security control requirements for EUCS High. EUCS certification is a third-party audit process, not a technical capability gap.
• GDPR: Default position — no transfers outside EU/EEA, Hetzner Germany as processor.

For SaaS teams building for EU public-sector clients who need to document their infrastructure sovereignty posture, running on sota.io means the CADA Level 3 qualification of the underlying infrastructure is inherited by default.

Summary: The Five Things Developers Need to Know

1. EUCS and CADA are not the same framework. EUCS certifies security controls. CADA certifies sovereignty structure. You may need both.

2. EUCS High does not imply CADA Level 3. AWS can (likely) achieve EUCS High. AWS cannot achieve CADA Level 3 because of its US parent ownership structure.

3. CADA Level 3 does imply the equivalent of EUCS High in practice — EU-only ownership and staffing requirements are a superset of the access control requirements in EUCS High.

4. Your procurement target determines which framework is required. General government tools → EUCS Substantial. Regulated verticals → EUCS High + CADA L2. Critical infrastructure → CADA Level 3.

5. Infrastructure selection is now a certification decision. If your SaaS targets CADA Level 3 procurement, running on AWS or Azure is a structural barrier, not a configuration question. Migrating to EU-native infrastructure is the only path.

The next post in the CADA series examines how SaaS developers choose cloud infrastructure to inherit the CADA compliance chain — and what due diligence questions to ask providers before committing to a sovereignty-sensitive deployment.