EU Cloud Sovereignty Certification 2026: EUCS Levels Explained for Developers

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

Cloud certifications are supposed to make procurement decisions easier. In practice, EUCS — the EU's Cybersecurity Certification Scheme for Cloud Services — has become a flashpoint for exactly the question developers and compliance teams care most about: does a certified cloud provider still hand your data to US authorities?

The answer is nuanced, and getting it wrong costs you. This guide decodes EUCS assurance levels (Basic, Substantial, High), explains what the ongoing sovereignty debate removed from the original scheme, and gives you a practical checklist for evaluating any cloud provider's actual compliance posture — not just their marketing claims.

What Is EUCS and Why Does It Exist

EUCS is the EU's framework for certifying the cybersecurity posture of cloud services. It was developed by ENISA (European Union Agency for Cybersecurity) under authority granted by the EU Cybersecurity Act (Regulation EU 2019/881, effective 2019, with certification schemes rolling out through 2024–2026).

Before EUCS, cloud security certifications were fragmented across member states. Germany had BSI C5. France had SecNumCloud. The Netherlands, Spain, and other member states had their own criteria. A cloud provider certified in Germany had to repeat the entire audit process in France. EUCS aims to create mutual recognition across the EU so that a High-level certification is valid everywhere.

The scheme covers three cloud delivery models:

• Infrastructure as a Service (IaaS) — compute, storage, network
• Platform as a Service (PaaS) — managed runtimes, databases, orchestration
• Software as a Service (SaaS) — end-user applications

Each model has tailored requirements at each assurance level, reflecting the different attack surfaces and responsibilities in the shared responsibility model.

The Three EUCS Assurance Levels

Level 1: Basic

Target use cases: Low-sensitivity data, internal tooling, public-facing applications without personal data.

Assessment method: Self-assessment or lightweight conformity assessment. Providers document their controls against EUCS Basic criteria and submit declarations.

Key requirements:

• Asset management: cloud assets inventoried and classified
• Access control: least-privilege principles, MFA for admin access
• Vulnerability management: regular patching cycles, CVE monitoring
• Incident management: documented incident response process
• Physical security: data centers with controlled access
• Encryption: data encrypted at rest and in transit using accepted algorithms

What Basic does NOT require:

• Independent third-party audit of the actual implementation
• Formal ISMS (Information Security Management System)
• Specific encryption key management requirements
• Penetration testing on a defined cadence
• Dedicated EU-only operations staff

Basic certification tells you a provider has documented their security posture. It does not tell you the posture has been independently verified or tested.

Level 2: Substantial

Target use cases: Moderate-risk processing, business data with confidentiality requirements, data subject to sector regulations (fintech, HR).

Assessment method: Independent third-party conformity assessment by an accredited Conformity Assessment Body (CAB). Providers cannot self-certify at Substantial.

Key requirements (additions over Basic):

• Formal ISMS: ISO 27001 or equivalent, covering all in-scope cloud services
• Third-party audit: Annual CAB audit covering policy documents, technical controls, and operational procedures
• Penetration testing: Annual external penetration test with remediation tracking
• Supply chain: Formal risk assessment of key subprocessors and suppliers
• Cryptographic controls: Approved algorithms with defined key rotation schedules
• Business continuity: Documented and tested DR/BCP with defined RTO/RPO targets
• Logging and monitoring: Centralized logging with anomaly detection and alerting

What Substantial does NOT require:

• Sovereignty of control (provider can be foreign-owned)
• Mandatory EU-only operations or support teams
• Restriction on data access from outside the EU
• Specific data residency requirements beyond "documented policy"

Substantial certification tells you a provider has been audited against serious security criteria. It still does not address jurisdiction — a provider can hold Substantial certification while being fully subject to CLOUD Act orders.

Level 3: High

Target use cases: High-risk data, critical infrastructure operators, public sector, healthcare, financial sector, sensitive public procurement.

Assessment method: Accredited CAB assessment using stricter audit protocols, including technical testing of implemented controls (not just policy review). CABs must themselves be accredited by national accreditation bodies.

Key requirements (additions over Substantial):

• Hardware security modules (HSMs): Key management operations in certified HSMs, not software
• Regular red-team exercises: Adversarial testing beyond standard penetration testing
• Privileged access management (PAM): Comprehensive session recording and approval workflows for privileged operations
• Real-time security monitoring: 24/7 SOC with defined response SLAs
• Supply chain depth: Tier-2 and Tier-3 subprocessor risk assessment
• Physical security hardening: Biometric controls, man-traps, CCTV with retention
• Cryptographic validation: Modules validated to FIPS 140-3 or equivalent

What High certification requires that Substantial does not: The jump from Substantial to High is significant. High-level certification is intended for providers handling data where compromise could have severe societal impact. The audit is more invasive and technically rigorous.

The critical gap: Even EUCS High does not currently mandate that cloud providers be EU-incorporated or EU-controlled entities. This was the central controversy.

The Sovereignty Controversy: What Was Almost in EUCS

When ENISA published early EUCS drafts (2020–2022), the High level included sovereignty requirements:

• Cloud provider must be controlled by an EU legal entity (no foreign parent with operational control)
• No access to EU data from outside the EU — support staff, engineers, contractors
• No data transfers outside EU even for operational purposes
• Subprocessors must also meet sovereignty criteria

These requirements would have effectively barred AWS, Microsoft Azure, and Google Cloud from EUCS High certification. All three are controlled by US corporations subject to CLOUD Act jurisdiction. Their EU subsidiaries are not independent controlling entities — they are operationally dependent on US parent infrastructure, staffing, and key management systems.

The response from US cloud providers and their government was forceful. The US Trade Representative flagged EUCS sovereignty requirements as discriminatory barriers to trade. US providers argued the requirements would fragment the global cloud market and harm EU companies dependent on hyperscaler services.

The result: By 2024–2025, sovereignty requirements were restructured. The current scheme:

• Makes operational sovereignty optional at High level
• Member states can require sovereignty requirements for specific regulated sectors (public sector, critical infrastructure) through national implementation
• Does not uniformly require EU-controlled entities for EUCS High certification

What this means for developers: EUCS High certification is a strong cybersecurity signal. It is not a sovereignty signal. A provider can achieve EUCS High and still be a US corporation subject to CLOUD Act orders for EU data.

EUCS vs. CLOUD Act: The Gap Every Developer Needs to Understand

This is the most important section in this guide.

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) allows US law enforcement to compel US-headquartered cloud providers to produce data stored anywhere in the world, including EU data centers, without necessarily notifying the data subject or the EU member state government.

EUCS certification does not address CLOUD Act exposure. Here is why:

A provider can have EUCS High certification — with HSMs, 24/7 SOC, red-team exercises, and full physical security — and still be legally required to hand over your data to the US Department of Justice under a CLOUD Act order.

Why encryption doesn't fully protect you: If a US-parent provider holds your encryption keys (or your data is decrypted for them to read, as in standard cloud storage), a CLOUD Act order can compel them to produce decrypted data. Customer-managed keys (BYOK) with HSMs not accessible to the provider are stronger, but most SaaS workloads don't implement this.

GDPR Art. 48 and the conflict: GDPR Art. 48 prohibits transfers of EU personal data to foreign courts or authorities without proper legal mechanisms (SCCs, adequacy decisions, derogations). CLOUD Act orders conflict with Art. 48. The practical result: a US-parent provider receiving a CLOUD Act order faces a conflict between US federal law and GDPR. US federal law currently wins in US courts.

EUCS, BSI C5, and Gaia-X: How the Frameworks Relate

German developers often encounter BSI C5 (Cloud Computing Compliance Criteria Catalogue) alongside EUCS. Here is how they relate:

BSI C5 is generally more mature than EUCS and has been required for German federal procurement since 2022. BSI C5 High is roughly equivalent to EUCS Substantial in rigor. BSI C5 does not explicitly address CLOUD Act jurisdiction but has stronger operational security requirements than EUCS Basic.

SecNumCloud (ANSSI, France) is the most sovereignty-aware of these frameworks. Qualified providers must be EU-controlled entities with no foreign-parent access to operations. SecNumCloud qualification is why OVHcloud and Scaleway can credibly claim legal data sovereignty for French public sector workloads. SecNumCloud is a model for what EUCS High's sovereignty tier could have been.

Gaia-X focuses on interoperability, portability, and transparency rather than cybersecurity depth. A Gaia-X label means a provider participates in the federation and declares their data policies, but it is not a security audit framework.

CLOUD Act Risk Matrix: Major Cloud Providers

Scoring note: 25/25 = maximum CLOUD Act exposure (US-incorporated, US-controlled, all data accessible to parent). 1/25 = minimal exposure (EU-incorporated, EU-controlled, no US operations).

What EUCS Means for GDPR Compliance

EUCS certification is not a GDPR compliance certificate. They address different things:

GDPR Art. 28 (Data Processing Agreements) requires that processors implement appropriate technical and organizational measures. EUCS certification provides evidence of TOMs but does not replace a DPA.

GDPR Art. 46 (Transfers to Third Countries) requires appropriate safeguards for data transferred outside the EEA. EUCS certification does not constitute a safeguard for international transfers — it applies to processing within the EEA.

GDPR Art. 32 (Security of Processing) requires appropriate security measures. EUCS certification is strong evidence of Art. 32 compliance, particularly at Substantial and High levels.

Practical implication: A controller relying on a US-parent provider with EUCS High certification still needs SCCs for any transfer risk, still faces Art. 48 conflict with CLOUD Act, and still risks supervisory authority action if a CLOUD Act order results in data leaving the EEA without proper mechanism.

Practical Checklist: Evaluating Cloud Providers Against EUCS + Sovereignty

Use this checklist when selecting or reviewing a cloud provider:

Tier 1 — EUCS Certification

• Does the provider hold a current EUCS certificate (level: Basic / Substantial / High)?
• Is the certificate in scope for the services you use (IaaS/PaaS/SaaS)?
• Is the certificate from an accredited CAB or self-declared?
• When does the certificate expire or require renewal?

Tier 2 — Legal Entity and Jurisdiction

• Is the provider's legal entity incorporated in an EU member state?
• Does the provider's ultimate parent have EU-majority control?
• Is the provider subject to US, UK, or other third-country law enforcement orders?
• Has the provider published a transparency report disclosing authority requests?

Tier 3 — Operational Sovereignty

• Are EU data center operations staffed exclusively by EU-based employees?
• Is key management performed in the EU with EU-controlled HSMs?
• Does the provider restrict support access from non-EU staff?
• Does the provider have a published policy for responding to non-EU legal orders?

Tier 4 — GDPR Specifics

• Does the provider have a compliant DPA covering GDPR Art. 28 requirements?
• Are sub-processors disclosed and individually approved?
• Is data residency in the EU contractually guaranteed, not just a setting?
• Does the provider notify you of legal orders (where legally permitted)?

What EU-Native PaaS Looks Like in Practice

For developers deploying applications rather than managing raw infrastructure, the relevant question is: does your Platform-as-a-Service provider inherit the sovereignty posture of their infrastructure, or does the platform layer introduce new exposure?

A managed PaaS built on Hetzner (EU-incorporated, Germany-based, no US parent) and operated by an EU entity inherits Hetzner's low CLOUD Act exposure. The deploy platform, the control plane, the build pipelines, the secrets management — all outside US jurisdiction.

Contrast this with a US-originated PaaS (Railway, Render, Fly.io) that runs workloads on AWS or GCP US regions. Even if data is processed in Europe, the control plane, billing system, and customer data often flow through US-incorporated entities.

sota.io runs on Hetzner Germany. Control plane, builds, secrets storage, and data residency are EU-only. There is no US parent company with access to your deployments. CLOUD Act orders cannot reach the operating entity.

EUCS certification is a checklist item. Jurisdiction is the underlying reality. For most EU developers and organizations that care about data sovereignty, the latter matters more.

Timeline: When EUCS Certification Will Matter for Procurement

If you manage infrastructure for a regulated EU organization, your cloud provider needs to be on a path to EUCS certification now. EUCS Basic will not satisfy regulators for sensitive workloads beyond 2026.

Key Takeaways

1. EUCS has three levels — Basic (self-assessed), Substantial (third-party audited), High (accredited lab, stricter controls). Each addresses cybersecurity posture, not legal jurisdiction.

2. The sovereignty controversy matters — Original EUCS High would have required EU-controlled providers. The requirement was weakened under US industry pressure. This is a policy gap developers should understand.

3. EUCS High ≠ CLOUD Act immunity — A US-parent cloud can achieve EUCS High certification and still be subject to CLOUD Act orders. EUCS certifies security controls, not legal sovereignty.

4. BSI C5 (Germany) and SecNumCloud (France) are complementary — They predate EUCS and are more mature. SecNumCloud is the strongest sovereignty signal in the EU today.

5. True sovereignty requires both — Technical security (EUCS certification) AND legal protection (EU-incorporated, EU-controlled provider without US-parent jurisdiction). Demand both.

6. Procurement timelines are moving — EUCS Substantial will be required for regulated workloads in EU procurement by 2026–2027. Providers without a certification roadmap are a risk.

Resources

• ENISA EUCS Scheme Documentation
• BSI C5 Criteria Catalogue
• ANSSI SecNumCloud Qualification
• EU Cybersecurity Act
• CLOUD Act Text
• GDPR Art. 48 — Transfers Not Authorized by Union Law