Summary As proposed in the Cloud and AI Development Act (CADA), cloud sovereignty is not a single binary state but a multi-layered concept that, across Article 16 and Annex II, can be read along three dimensions: data sovereignty, operational sovereignty, and technical sovereignty. These dimensions are addressed cumulatively as a service climbs the four "Union assurance levels," helping public sector bodies retain control over their data, service continuity, and technology stack against risks such as extraterritorial legal access, service disruption, and vendor lock-in.
Detail
The proposed CADA, presented by the European Commission in COM(2026) 502 final, would introduce a harmonised "Union cloud computing sovereignty framework" (Article 16). It moves beyond traditional cybersecurity certification to address broader strategic dependencies. While CADA does not label its criteria as three formal "dimensions," the Annex II requirements map naturally onto data, operational, and technical sovereignty.
These requirements respond to the risks set out in Recital 50, which describes the dangers of dependence on a limited number of providers subject to third-country control:
- Misuse: manipulation, remote access and control, sabotage, weaponisation.
- Access to information: access to sensitive information, unauthorised communication, technology leakage, data manipulation or exfiltration, espionage.
- Dependency vulnerabilities: political or economic coercion (for example via vendor or technology lock-in, embargoes or sanctions, or monopoly pricing).
(Recital 46 frames the underlying concentration risk and "vulnerabilities arising from the extraterritorial application of third-country laws.")
1. Data sovereignty
Data sovereignty concerns legal and physical jurisdiction over data — keeping it under EU law and within the Union's borders unless explicitly required otherwise.
- The CADA requirement: Across all four levels, Annex II requires customer data, including metadata and telemetry, to remain exclusively within the Union (points 1.1(c), 2.1(c), 3.1(c); at level 4, point 4.1(c) focuses on data identified as sensitive following a risk assessment), unless the public sector body explicitly requires otherwise. From level 2 upward, data generated by using the service may not be used to train or fine-tune any AI system operated by a third country or third-country legal entity, nor transferred outside the Union (points 2.1(f), 3.1(f), 4.1(f)).
- Risks addressed: This counters "access to information" risks, mitigating the threat of third-country authorities reaching sensitive EU data via extraterritorial laws (such as the US CLOUD Act).
2. Operational sovereignty
Operational sovereignty concerns the autonomy of the provider and the continuity of the service — delivering it without interference, disruption, or degradation from third-country authorities or parent companies.
- The CADA requirement:
- Establishment and control: At level 1, the provider must be established in the Union (1.1(a)). At levels 2–4, the provider and its subcontractors must be established in the Union (2.1(a), 3.1(a), 4.1(a)). For levels 3 and 4, the provider and subcontractors must not be subject to third-country control (3.1(g), 4.1(g)) — with a narrow derogation under Article 18 available only for level 3.
- Personnel and support: Levels 2–4 require infrastructure, assets, and personnel to be located in the Union, and technical and operational support to be initiated and performed exclusively within the Union (2.1(b), (h); 3.1(b), (h); 4.1(b), (h)). At levels 3 and 4, support must be performed by Union-resident personnel and by third parties not subject to third-country control (3.1(h), 4.1(h)).
- Continuity guarantees: Where third-country control exists at level 2 (or under the level 3 derogation), the provider must show that disruption or degradation of the service by a third country is prevented (2.1(g)(iii); 3.1(g)(iii)).
- Risks addressed: This targets "dependency vulnerabilities" and "misuse," guarding against a third-country government compelling a provider to disrupt or degrade service as coercion.
3. Technical and software sovereignty
Technical sovereignty focuses on the technology stack — ensuring hardware, software, and code are transparent, auditable, and free from hidden dependencies or backdoors.
- The CADA requirement:
- Software supply chain: Levels 2–4 require a complete, up-to-date Software Bill of Materials (SBOM) and a list of dependencies (2.1(i)(i), 3.1(i)(i), 4.1(i)(i)).
- Source code and audits: Where software components are owned by third-country entities, controls must block remote tampering features, security-relevant components must undergo source code audits, and a documented migration plan must exist (2.1(i)(ii), 3.1(i)(ii)). At level 4, the provider must demonstrate that no third country holds or exercises effective control over the design, development, maintenance, and evolution of software components (4.1(i)(ii)).
- Open-source controls: Where open-source software is used, providers must document controls preventing remote tampering features (2.1(j), 3.1(j), 4.1(j)).
- Separation: Where a provider maintains a subsidiary in a third country, levels 2–4 require effective legal, technical, and organisational separation between the Union parent and the third-country subsidiary (2.1(k), 3.1(k), 4.1(k)).
- Risks addressed: This addresses "misuse" (sabotage, weaponisation) and "access to information," reducing reliance on opaque, third-country-controlled software stacks.
How the tiers stack these dimensions
Annex II's levels are cumulative — a higher level requires all lower-level criteria (Article 20(1)).
- Level 1 (baseline): Data sovereignty (data stays in the EU) and basic operational sovereignty (EU establishment); self-assessment and EU statement of conformity (Article 19).
- Level 2 (enhanced): Adds operational controls (subcontractors and personnel in the EU) and technical controls (SBOM, no remote tampering); independent audit (Article 20).
- Level 3 (high): Strengthens operational sovereignty by excluding third-country control by default (narrow Article 18 derogation), and requires Union-citizen personnel and separation of third-country subsidiaries.
- Level 4 (highest): Adds technical sovereignty over the supply chain (no third-country effective control over software design and evolution), requires an "high"-level cybersecurity certificate, and allows no third-country control.
What this means for you
For CTOs, architects, and SMEs, CADA would shift procurement from "Is it secure?" to "Is it sovereign?"
- Procurement impact: Public sector bodies — and private entities in critical sectors who choose to assess (Article 31) — would conduct risk assessments (Article 29) to determine the required assurance level. Public order activities would likely require level 2, 3, or 4.
- Vendor evaluation: Evaluate providers on ownership structure, supply-chain transparency, and data handling, not just uptime and cost. Ask for the SBOM and evidence of third-country separation.
- Migration planning: If your provider cannot meet the required level, plan for migration; Article 29(6) allows a reasonable transition period not exceeding 12 months where a risk assessment requires it.
- SME opportunity: SMEs may find new openings in providing level 1 services (with automatic cross-Union recognition of their EU statement of conformity under Article 17(3)) or supporting larger providers.
Common misconceptions
- "Sovereignty means data must never leave the EU." CADA would require data to remain within the Union for recognised services, but allows exceptions where the public sector body explicitly requires otherwise. The focus is on control and jurisdiction.
- "Only EU-owned companies can provide sovereign cloud." Not necessarily. Level 3 allows a derogation for third-country-controlled providers where the Commission recognises the third country (Article 18). Level 4 prohibits third-country control.
- "Technical sovereignty is just cybersecurity." It is broader — supply-chain transparency (SBOM), source-code auditability, and the absence of remote tampering features, independent of any specific cyberattack.
- "CADA replaces the AI Act or GDPR." No. It would complement them; CADA regulates infrastructure and service provision for sovereignty and operational autonomy.
Official sources
Related
- Why is cloud sovereignty important for critical infrastructure? CADA
- Why is sovereignty described as layered or nuanced in CADA?
- CADA Sovereignty: Why Assessment is Per Service, Not Per Provider
- Why is sovereignty a competitiveness issue, not just a security one? | CADA
- Why data residency is not enough for cloud sovereignty under CADA
This is general information about a draft EU regulation, not legal advice.