EUCS Cloud Assurance Levels 2026: Why AWS, Azure, and GCP Cannot Reach the Highest EU Certification

Post #1 in the sota.io EU Cloud Sovereignty Series

Cloud procurement in the European public sector is changing. The EU Cloud Scheme (EUCS) — ENISA's cybersecurity certification framework for cloud services — is moving from candidate scheme to formal adoption. When it becomes enforceable, it will determine which cloud providers EU governments, regulated industries, and sovereignty-conscious enterprises are allowed to use for sensitive workloads.

The three assurance levels look deceptively similar on the surface. Dig into the High level requirements, and a structural problem emerges: cloud providers owned by US-parent corporations cannot claim full compliance, regardless of where their data centers sit. The CLOUD Act reaches them everywhere.

This is the post where we map the landscape — what each EUCS level actually requires, which providers currently qualify or are disqualified, and what it means for SaaS developers building on cloud infrastructure today.

What Is EUCS?

The European Union Cloud Scheme (EUCS) is a cybersecurity certification framework developed by ENISA (European Union Agency for Cybersecurity) under the EU Cybersecurity Act (Regulation EU 2019/881). It defines standardized security requirements that cloud providers must meet to be certified at each assurance level.

EUCS is not a data residency rule alone. It covers the full stack of cloud security: access controls, cryptography, incident response, supply chain security, and — critically — legal jurisdiction. A cloud provider can have servers in Frankfurt and still fail EUCS High Level certification if its parent company is incorporated in the United States.

The EUCS candidate scheme has been in development since 2021. As of 2026, the European Commission is finalizing adoption under the cybersecurity certification framework. Public sector procurement rules across EU member states are already referencing EUCS levels in tenders, and regulated industries (banking under DORA, healthcare under NIS2, defense) are incorporating EUCS requirements into their vendor evaluation criteria.

The Three EUCS Assurance Levels

Basic Level

Who it targets: Cloud services handling low-risk data where public data breaches would have limited impact.

Key requirements:

• Standard security controls (ISO/IEC 27001 equivalent)
• Documented incident response procedures
• Vulnerability management program
• Data residency in the EU is NOT required at this level

Who qualifies: Virtually every major cloud provider — AWS, Azure, GCP, Hetzner, Scaleway, OVHcloud. This level sets a floor, not a ceiling.

SaaS developer relevance: If you are building consumer-facing tools handling non-sensitive data (public APIs, open datasets, anonymous analytics), Basic Level cloud is sufficient.

Substantial Level

Who it targets: Cloud services handling sensitive data where breaches could have significant impact on individuals or organizations — personal data under GDPR, health records, financial data.

Key requirements:

• Advanced access controls with multi-factor authentication enforced across all administration
• Encryption at rest and in transit with provider-managed key separation
• Regular penetration testing and third-party security audits
• EU data residency: data must be processed and stored within EU/EEA borders
• Incident notification to competent authorities within defined timeframes
• Supply chain security assessment for critical dependencies

Who qualifies: AWS (with specific region lockdown configurations), Azure (with EU Data Boundary commitment), GCP (with Data Residency controls), Hetzner, Scaleway, OVHcloud.

The asterisk: US-owned hyperscalers can technically meet Substantial Level requirements through technical controls. But enforcement-side questions remain — CLOUD Act subpoenas can still reach US companies' EU data, creating a gap between technical compliance and legal compliance. For GDPR Art.44 cross-border transfer risk, this distinction matters.

SaaS developer relevance: Most B2B SaaS tools handling EU customer data should target Substantial Level cloud at minimum. This covers GDPR-regulated personal data under standard risk profiles.

High Level

Who it targets: Cloud services handling highly sensitive data — classified government information, critical infrastructure, defense, healthcare at national scale, systemically important financial infrastructure.

Key requirements beyond Substantial:

• EU-parent ownership: the cloud provider must be incorporated and controlled from within the EU/EEA with no non-EU ultimate beneficial owner who could be subject to foreign government access orders
• EU personnel for privileged access: all personnel with administrative access to customer data infrastructure must be EU citizens/residents subject to EU employment law — no US or third-country personnel with privileged access
• EU-only legal jurisdiction: the provider must operate under EU law exclusively. No parent company, subsidiary, or operational entity must be subject to laws of third countries that could compel disclosure (this is the explicit CLOUD Act exclusion)
• Hardware supply chain in EU: critical hardware components sourced from EU-trusted suppliers
• Qualified Trust Service Provider alignment for cryptographic operations

Who cannot qualify:

The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713) requires US companies to comply with US government lawful access orders regardless of where data is physically stored. This means AWS, Azure, and GCP cannot contractually guarantee that EU customer data stored in Frankfurt will never be accessed by US law enforcement under a sealed court order — because that guarantee would require them to violate US law.

This is not a theoretical risk. US government data access orders under the CLOUD Act and its predecessor (the Electronic Communications Privacy Act) have been used to reach data in EU cloud data centers. Several high-profile cases have established that physical location is legally irrelevant for US-owned providers.

EUCS High Level explicitly addresses this. The requirement for EU-parent ownership and EU-only legal jurisdiction is designed specifically to close the CLOUD Act gap.

The Sovereignty-Aware Cloud Stack

For SaaS developers building for EU public sector, regulated industries, or sovereignty-conscious enterprise customers, the cloud choice now has certification implications.

Hyperscaler sovereign clouds: the workaround attempt

AWS has responded to EU sovereignty requirements with "AWS European Sovereign Cloud" (EUSC). Microsoft has "Microsoft Cloud for Sovereignty." Google has "Assured Workloads for Europe."

These offerings attempt to address the EUCS High Level problem by:

• Creating EU-only operational entities with EU personnel for privileged access
• Implementing data boundary controls that technically restrict access from US operations
• Deploying EU-based key management that limits cryptographic access

The problem: these are contractual and operational controls, not structural ones. The parent company remains a US corporation subject to CLOUD Act jurisdiction. A sealed US court order directed at Amazon.com Inc. does not care about contractual restrictions between Amazon and its EU sovereign cloud subsidiary. Legal opinions differ on whether these offerings actually close the High Level eligibility gap — ENISA's working group has not formally certified any of them at High Level as of 2026.

European sovereignty advocates like GAIA-X and EUCLIDIA have been explicit: contractual sovereignty ≠ legal sovereignty. Only providers with EU-parent ownership can make the legal sovereignty claim without asterisks.

The EU-native provider stack

For High Level EUCS requirements, the field narrows to EU-owned providers:

Infrastructure layer:

• Hetzner Online (Germany) — bare metal + cloud
• Scaleway (France, Iliad Group)
• OVHcloud (France, OVH SAS)
• IONOS (Germany, United Internet AG)
• Exoscale (Switzerland, A1 Telekom Austria Group)

Managed platform layer:

• sota.io — EU-native managed PaaS on Hetzner Germany. No US parent, no CLOUD Act exposure. EU jurisdiction throughout.

Database layer:

• Supabase with self-hosted EU deployment on Hetzner
• Neon.tech (consider parent company jurisdiction)
• Tembo.io on EU infrastructure

What EUCS Means for Your SaaS Architecture Decisions

Decision 1: What assurance level does your customer require?

Decision 2: Does your cloud provider qualify?

If your customer requires High Level and your infrastructure runs on AWS, Azure, or GCP, you have a structural problem that technical controls cannot fully resolve. You need to migrate to EU-native infrastructure or architect a hybrid where sensitive workloads run on EU-native providers while commodity compute remains on hyperscalers.

Decision 3: How to document your compliance posture

EUCS certification is performed by accredited conformity assessment bodies (CABs). As of 2026, the EUCS certification ecosystem is developing — not all providers have formal EUCS certificates yet. Until certificates are widely available, your documentation should reference:

1. EUCS Candidate Scheme v1.1 requirements (publicly available from ENISA)
2. ISO/IEC 27001 certification of your cloud provider (covers much of Substantial Level)
3. Parent company jurisdiction documentation (showing EU ownership for High Level claims)
4. Data Processing Agreements that include EUCS-aligned commitments
5. GDPR Art.44 transfer impact assessments (especially relevant for Substantial/High gap)

CLOUD Act and GDPR: The Legal Double Bind

For Substantial Level providers with US parentage, SaaS developers face a specific legal tension:

GDPR requires: Data transferred out of the EU must have equivalent protection. US law doesn't provide equivalent protection. Schrems II (C-311/18) established this.

CLOUD Act creates: A mechanism for US government to access EU data without going through MLAT (Mutual Legal Assistance Treaty) procedures that might allow EU authorities to block the request.

Result: A US-owned cloud provider storing EU personal data faces a legal conflict. If a US court orders them to provide data and they comply, they may breach GDPR. If they refuse to comply, they risk criminal contempt in the US. This is not hypothetical — the original Microsoft Ireland case (which prompted the CLOUD Act's creation) was exactly this conflict.

EUCS High Level solves this by requiring EU-parent-only providers. EU companies are not subject to CLOUD Act jurisdiction. A German court order through MLAT procedures applies German law — which does not require disclosure without EU authority involvement.

For SaaS developers: if your customer's legal counsel runs a CLOUD Act transfer impact assessment on your cloud provider, and the provider is US-owned, expect significant back-and-forth. Building on EU-native infrastructure removes this issue entirely.

Practical Action Checklist

Immediate (0-30 days):

• Identify which EUCS assurance level your target customers require (ask directly or check procurement specs)
• Document your cloud provider's parent jurisdiction for DPA and customer questionnaire responses
• Review your customer contracts — do any include cloud sovereignty requirements that EUCS High Level addresses?

Short-term (30-90 days):

• Conduct a CLOUD Act transfer impact assessment for each US-owned provider in your stack
• Identify which workloads could migrate to EU-native providers vs. which can remain on hyperscalers
• Add EUCS assurance level language to your security documentation and trust center

Medium-term (90+ days):

• For High Level requirements: architect migration path to EU-native infrastructure
• Engage with your current cloud providers to understand their EUCS certification roadmap
• Update your ISMS (if you have ISO 27001) to reference EUCS requirements

For SaaS platforms specifically:

• If you offer multi-cloud or cloud-agnostic hosting, document which infrastructure options qualify at which EUCS level
• Create customer-facing documentation explaining your EUCS posture
• Consider EU-native PaaS options (like sota.io on Hetzner Germany) for new EU-focused deployments

The Architecture That Satisfies High Level

For SaaS developers targeting EU public sector or regulated industry customers who require High Level:

User → EU-resident DNS (e.g., Hetzner DNS) 
     → EU-native load balancer 
     → Application layer on EU-native PaaS (sota.io on Hetzner Germany)
     → Database on EU-native managed DB (Postgres on Hetzner)
     → EU-based blob storage (Hetzner Object Storage / OVH Object Storage)
     → EU-native CDN (BunnyCDN EU-only, or Fastly with EU-only PoP config)
     → Monitoring on EU-hosted Grafana / self-hosted

Every hop in this chain is under EU jurisdiction. No CLOUD Act exposure at any layer. This is the architecture that satisfies EUCS High Level requirements — and increasingly, the architecture that EU public sector customers will require in procurement specs.

Next in this series: Part 2 — EUCS Technical Requirements Deep-Dive: What Substantial and High Level Actually Demand From Your Stack

sota.io is EU-native managed PaaS on Hetzner Germany. No US parent, no CLOUD Act exposure. Start free →