What is the Union cloud computing sovereignty framework under CADA?

As proposed, the Cloud and AI Development Act (CADA) would create a Union cloud computing sovereignty framework: a single, EU-wide set of trust criteria fo

Summary As proposed, the Cloud and AI Development Act (CADA) would create a Union cloud computing sovereignty framework: a single, EU-wide set of trust criteria for cloud services used by public bodies. Article 16 would establish four Union assurance levels (1 to 4), with the detailed criteria for each set out in Annex II. The levels would rise from a baseline self-assessed level (Level 1) to the strictest, audited level reserved for the most sensitive data (Level 4). Public bodies would carry out risk assessments to identify which activities preserve public order, and procure cloud services at the assurance level matching that risk. CADA is a proposal and is not in force; details could change.

Detail

The Union cloud computing sovereignty framework is a central pillar of the proposed Cloud and AI Development Act (CADA). It would address the EU's strategic dependence on a small number of cloud providers subject to third-country control — a dependence the proposal links to concentration risks, the extraterritorial reach of third-country laws, and the possible degradation or disruption of services. Rather than leaving "sovereign cloud" to fragmented national definitions, CADA would set one harmonised, auditable standard so public buyers across the Union can compare services on a like-for-like basis.

The legal basis: Article 16

The framework would be established under Article 16 of the CADA proposal. As Article 16(1) puts it, the chapter "establishes a Union cloud computing sovereignty framework comprising four Union assurance levels, the criteria for which are set out in Annex II, that cloud computing service providers shall meet in order to provide their cloud computing services to Union entities and public sector bodies."

The criteria themselves are deliberately kept out of the main legal text and placed in Annex II, so they can be updated without reopening the whole regulation. Article 16(2) would empower the European Commission to amend the assurance levels in Annex II — and the audit evidence in Annex III — by delegated act. Article 16(3) would require the Commission to review Annex II and Annex III "at least every 18 months."

The four Union assurance levels

The framework would be proportionate by design: the proposal notes that most public services would not require the highest levels of assurance, and that the four levels reflect the "nuanced and layered nature of sovereignty." The criteria are cumulative — each higher level would include everything required at the levels below it, and failing any lower-level requirement would preclude conformity at a higher level (Article 20(1)).

Union assurance level 1 would be the baseline for general public-sector use and the only level confirmed through a conformity self-assessment rather than an external audit (Article 19). Under Annex II §1.1, the provider would have to be established in the Union; its infrastructure and assets (including those of subcontractors) would have to be located in the Union, unless the public body explicitly requires otherwise; customer data — including metadata and telemetry — would have to remain exclusively within the Union, again unless the public body explicitly requires otherwise; the service would have to meet state-of-the-art cybersecurity standards; and the provider would owe full transparency on its subcontractors.
Union assurance level 2 would add stricter conditions and require an independent third-party audit (Article 20). Under Annex II §2.1, both the provider and the subcontractors involved would have to be established in the Union, with infrastructure, assets, and personnel located in the Union. The service would need a European cybersecurity certificate of at least assurance level "substantial" (under a future cloud scheme to be established under the Cybersecurity Act, with fallbacks until one exists). Data generated by using the service could not be used to train or fine-tune any AI system operated by a third country or a third-country entity, and could not be transferred outside the Union. Providers would also have to manage their software supply chain — for example, by maintaining a Software Bill of Materials (SBOM) and documenting controls over third-country software components.
Union assurance level 3 would build on Level 2 for more sensitive activities, including those involving classified information. Under Annex II §3.1, personnel involved (including subcontractor personnel) would have to be Union citizens and, where appropriate, hold national security clearance from a Member State. The cybersecurity certificate requirement would remain at least "substantial" — Level 3 is not the "high" tier. As a rule, the provider and its subcontractors would have to be free of third-country control. By way of derogation, a provider under third-country control could still be audited for Level 3, but only where the Commission has adopted an implementing act under Article 18 identifying the relevant third country (see below), and the provider additionally demonstrates measures preventing third-country data access, disruption, and coercion.
Union assurance level 4 would be the highest tier, for the most critical public-order activities. Under Annex II §4.1, it would require a European cybersecurity certificate of at least assurance level "high" — the only level demanding "high." Customer data that a risk assessment identifies as sensitive would have to stay exclusively within the Union at all times, with no "unless the public body requires otherwise" carve-out. Personnel would have to be Union citizens; the provider and subcontractors would have to be free of third-country control, with no Article 18 derogation available at this level; and the provider would have to retain effective control over its software components, demonstrating that no third country or third-country entity holds effective control over their design, maintenance, and evolution.

Recognition and auditing

To rely on the framework, a provider would have to be formally recognised. Article 17 would set out the mechanism: the provider applies to the national competent authority of its place of establishment (the "evaluating national competent authority"), which can recognise a service Union-wide after a notification and review process involving other Member States. For Level 1, the application centres on the EU statement of conformity issued under Article 19; under Article 17(3), such a statement issued by a provider that is an SME would be "directly and automatically recognised in all Member States" without prior recognition. For Levels 2, 3, and 4, the application would include the audit report and a "positive" audit opinion under Article 20.

Those audits would be carried out by independent auditing organisations — not "accredited" bodies, but organisations that must meet the independence, competence, and objectivity conditions in Article 20(4) (for example, no conflicts of interest, no recent non-audit work for the provider, proven technical competence, and professional ethics). Recognised services would be listed in a central repository maintained by the Commission (Article 22), giving public buyers a single, publicly available source of truth.

What this means for you

If you procure or oversee cloud services for a public body, the framework would change how you choose a provider: a generic cybersecurity certificate alone would no longer be enough, because you would also have to match the service's sovereignty profile to the sensitivity of your data and operations.

Identify your activities through a risk assessment. Under Article 29, Member States and Union entities would carry out risk assessments to identify which public-sector activities, using cloud services, contribute to the preservation of public order. The proposal does not fix a particular review cadence. The outcome of that assessment would then drive your procurement obligation:

If your activity is not identified as contributing to public order, you would still have to use a service recognised at Union assurance level 1 (Article 30(2)).
If your activity is identified as contributing to public order — for example in sectors covered by the NIS2 Directive, or in national security, internal security, external border management, defence, justice, or law enforcement — you would have to procure only services recognised at Union assurance level 2, 3, or 4 (Article 30(3)).

Use the central repository. When preparing a tender, you would be able to check the Commission's central repository (Article 22) to confirm a provider has been recognised at the level you need. The repository would also publish revocations, which remain available for five years.

Note the SME shortcut at Level 1. Because an EU statement of conformity from an SME would be automatically recognised across the Union (Article 17(3)), smaller European providers could reach Level 1 buyers without a separate national recognition step — which may widen the field of eligible suppliers for baseline needs.

Private-sector entities are not bound by these procurement rules, although under Article 31 those within the meaning of NIS2 "may carry out similar assessments" on a voluntary basis.

Common misconceptions

"Sovereignty means data can never leave the EU." Data localisation is central, but it is calibrated. At Level 1 — and for several criteria at Levels 2 and 3 — data must stay in the Union unless the public body explicitly requires otherwise. Only at Level 4, for data identified as sensitive, does the proposal drop that carve-out and require data to remain exclusively within the Union at all times.

"Any provider with third-country owners is automatically disqualified." Not at every level. Levels 1 and 2 set conditions on third-country control rather than an outright bar. At Level 3, a provider under third-country control may still be audited — but only where the Commission has adopted an implementing act under Article 18. That mechanism is not simply a GDPR adequacy decision: the third country would have to satisfy all six cumulative criteria in Article 18(1)(a)–(f), of which a GDPR adequacy decision is only the first. At Level 4 there is no such derogation at all.

"The sovereignty framework replaces cybersecurity certification." It would sit on top of it. Level 2 and Level 3 would require a European cybersecurity certificate of at least "substantial," and Level 4 of at least "high"; the sovereignty criteria then add operational autonomy, data-governance, personnel, and supply-chain conditions that a standard security certificate does not cover.

"You should always buy the highest level to be safe." The framework is risk-based, and the proposal states that most public services would not require the highest levels. Over-specifying a level above what your risk assessment supports could needlessly limit competition and raise cost without adding meaningful protection.

Official sources

This is general information about a draft EU regulation, not legal advice.