Summary Under the proposed Cloud and AI Development Act (CADA), the line between a "sovereign" and an "ordinary" cloud would be drawn by audited, legally defined criteria rather than marketing. An ordinary cloud may be subject to foreign laws that allow a third country to access data or disrupt service; a sovereign cloud, in CADA terms, is one recognised at a Union assurance level (Article 16) whose infrastructure, personnel, data and corporate control are verified against the criteria in Annex II. CADA is explicit (recital 48) that vendor-branded "sovereign" versions of hyperscaler services do not, on their own, solve the core problem. As proposed, public bodies would have to use recognised services — levels 2 to 4 for activities relevant to public order.

Detail

For public buyers, "sovereign cloud" is often a vendor label rather than a verifiable property. CADA — COM(2026) 502 final, still a proposal — aims to replace that label with harmonised, auditable criteria called Union assurance levels.

The problem with ordinary and market-led "sovereign" clouds

An ordinary cloud is typically a commercial offering from a global provider. The explanatory memorandum notes that the EU market is dominated by a few non-EU hyperscalers — over 70% of the European market — that are "subject to third-country jurisdictions where laws with an extraterritorial effect apply, including laws mandating data access and transfer that may conflict with EU fundamental rights and data protection frameworks", and that this dependence also exposes users to "operational discontinuity".

A common assumption is that buying a hyperscaler's "sovereign" edition fixes this. Recital 48 rejects that: providers "have launched tailored versions of their service offerings in response to the Union's growing concerns over sovereignty", but "those versions do not address the core sovereignty issues allowing for the extraterritorial reach of third-country laws and the possible degradation or disruption of the service."

So an ordinary cloud — and even a vendor-branded "sovereign" one — may still let a third country:

  1. compel access to customer data through its laws;
  2. disrupt or degrade service continuity as a form of coercion; or
  3. influence the provider through ownership or control.

Recital 47 adds the internal-market dimension: some Member States "have developed or are in the process of developing national approaches to identifying national sovereign services", but national measures "do not adequately address the cross-border issues" and "risk fragmenting the Union internal market". A core purpose of CADA's framework is therefore to replace a patchwork of national "sovereign" labels with one EU-wide, auditable standard.

CADA's answer: Union assurance levels

Article 16 establishes a Union cloud computing sovereignty framework "comprising four Union assurance levels, the criteria for which are set out in Annex II". Level 1 rests on a conformity self-assessment (Article 19); levels 2, 3 and 4 require an independent third-party audit (Article 20). Annex II sets the criteria as cumulative requirements, tightening at each step.

Level 1: the baseline

Level 1 is the minimum for public-sector procurement (Article 30(2) applies it to activities not identified as public-order relevant). Its Annex II criteria include: the provider is established in the Union; infrastructure and assets, including subcontractors', are in the Union unless the public sector body explicitly requires otherwise; customer data, including metadata and telemetry, stays in the Union on the same condition; and, where the provider is under third-country control, a guarantee that no third-country law requires early reporting of software vulnerabilities to that country's authorities. Level 1 provides residency and operational presence but does not on its own eliminate the risk of third-country control over the corporate structure.

Levels 2, 3 and 4: for public order

For activities identified as contributing to the preservation of public order — sectors under the NIS2 Directive, plus national security, internal security, border management, defence, justice or law enforcement — Article 30(3) would require services recognised at levels 2, 3 or 4. These require third-party audits and progressively stricter criteria.

Level 2 adds: all infrastructure, assets and personnel in the Union; personnel screening and Union-citizenship requirements if the public sector body determines they are necessary; a European cybersecurity certificate of at least "substantial" (or applicable national/highest Union standards until such a scheme exists); a ban on using service data to train or fine-tune third-country-operated AI systems; and, where the provider is under third-country control, measures ensuring that control cannot restrict the service, access customer data, or disrupt continuity.

Level 3 raises the bar: personnel involved in the service must be Union citizens (with national security clearance where appropriate); the provider and subcontractors must in principle not be under third-country control, with a derogation only where the Commission has designated an associated third country (Article 18); and support must be performed within the Union by Union residents, by parties not under third-country control.

Level 4 is the highest tier: a "high" cybersecurity certificate; no derogation for third-country control; and a demonstration that no third country holds effective control over the design, development, maintenance and evolution of software components, including the ability to materially influence technical evolution and security remediation.

The role of risk assessments

The level is not chosen at random. Article 29 would require Member States and Union entities to carry out risk assessments identifying which activities contribute to public order and which level (2, 3 or 4) is appropriate, weighing the sensitivity, criticality and magnitude of the data, the risk of unlawful third-country access, and the risk of service disruption. A local authority's public website might need only level 1, while a defence ministry's systems would likely require level 3 or 4. Recital 52 underlines that the framework is meant to be proportionate — "most public services would not require the highest levels of assurance" — so a "sovereign cloud" requirement does not mean everything must run at level 4.

Recognition: who decides a cloud is "sovereign"

Under CADA, "sovereign" would be a status conferred by a public authority, not a vendor. A provider applies to the national competent authority of establishment (Article 17). For level 1 it submits an EU statement of conformity; for levels 2–4 it submits the audit report and a "positive" audit opinion (Article 17(3)–(4)). The evaluating authority assesses the evidence, and other Member States' authorities have a review period to raise reasoned objections before recognition takes effect across the Union (Article 17(5)–(7)). The recognised service is then entered in the Commission's central repository (Article 22). An "ordinary" cloud, by contrast, carries no such recognition — which is exactly why a buyer cannot tell the two apart from marketing alone.

What this means for you

For public-sector buyers, CADA would shift the burden of proof from buyer to provider and auditor. You would no longer take a vendor's "sovereign" claim on trust; you would check the central repository the Commission would maintain (Article 22).

  1. Run the risk assessment. Determine whether your activities relate to public order and, if so, the required level (Article 29).
  2. Procure only recognised services. Buy services recognised at the required level; do not rely on contract language alone.
  3. Plan for migration. If your current service — ordinary or a hyperscaler "sovereign" edition — falls short, Article 29(6) allows a transition period of up to 12 months, taking account of technical feasibility, continuity of service and data portability.
  4. Consider multi-cloud. Article 29(9) requires you to consider whether a multi-vendor or multi-cloud strategy is appropriate to limit single-provider dependency. Recital 65 frames this as a context-specific, resilience-driven decision rather than a default.
  5. Watch for re-classification. The Commission may, after reviewing a Member State's risk assessment, adopt implementing acts specifying the levels needed for an activity if it concludes the level chosen is not appropriate (Article 29(5)). A service judged "sovereign enough" today could need upgrading if the required level changes.

Common misconceptions

  • "My provider offers a 'sovereign cloud', so I am compliant." As recital 48 stresses, vendor "sovereign" editions often do not address the extraterritorial reach of third-country laws. Unless a service is recognised under CADA's assurance levels, it does not meet the proposal's definition of sovereignty.
  • "Data localisation is enough." Level 1 keeps data in the Union, but true sovereignty (levels 2–4) also covers personnel, supply chain and freedom from coercive third-country mandates. Data in Frankfurt held by a foreign-controlled company can still be reached through that company's home law.
  • "I can pick any level I like." The level is dictated by the risk assessment of your activities. Using level 1 for a high-risk activity such as national security would not satisfy Article 30.

Related

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