Summary Under the proposed Cloud and AI Development Act (CADA), the assurance level your workload would need is driven by what the data is for and how sensitive it is, not by a free choice. The four Union assurance levels and their criteria are set out in Article 16 and Annex II. For public sector buyers, the level is decided by a risk assessment under Article 29: activities that do not contribute to the preservation of public order would default to Level 1 (Article 30(2)); activities that do would require Level 2, 3 or 4 (Article 30(3)). The levels are cumulative — each higher level must also satisfy every criterion below it. Level 4, the highest tier, would attach specifically to customer data "identified as sensitive following a risk assessment" (Annex II, 4.1(c)) and adds an EU-citizen personnel rule, a "high" cybersecurity certificate, and no third-country-control derogation. As a provider, you map your architecture to the cumulative Annex II criteria for the level you are targeting.

Detail

CADA, as proposed, would establish a "Union cloud computing sovereignty framework comprising four Union assurance levels, the criteria for which are set out in Annex II" (Article 16(1)). The Commission would be empowered to amend those Annex II criteria — and the audit evidence in Annex III — by delegated act (Article 16(2)), and would review both annexes "at least every 18 months" (Article 16(3)). Treat the levels below as the current proposal, not a frozen standard.

Choosing a level turns on two intersecting questions: who needs the workload (a public-order activity, or routine administration) and what data it handles (ordinary customer data, or data flagged sensitive by a risk assessment). The first drives the procurement floor; the second drives whether you climb to the top tier.

1. The risk assessment decides the floor (public sector)

For public sector bodies and Union entities, the entry point would not be picking a level — it would be a risk assessment.

  • Article 29(1) would require Member States and Union entities to carry out risk assessments identifying public sector activities that use cloud services and contribute to the preservation of public order. (The proposal does not fix a review cadence, so do not assume a fixed cycle.)
  • These assessments would consider sectors falling under Annex I or II of the NIS2 Directive (Directive (EU) 2022/2555), as well as national security, internal security, external border management, defence, justice and law enforcement.

Article 30 would then set the procurement floor based on that assessment:

  • Default: entities whose activities are not identified as contributing to public order "shall use cloud computing services that have been recognised under Article 17 as having a Union assurance level 1" (Article 30(2)).
  • Public-order activities: contracting authorities whose activities are so identified — in the NIS2 sectors and in national security, internal security, external border management, defence, justice or law enforcement — "shall only procure cloud computing services that have been recognised as having a Union assurance level 2, 3 or 4" (Article 30(3)).

The proposal's recitals frame this as a proportionality and subsidiarity exercise: most public services would not require the highest levels, and Levels 3 or 4 would be reserved for specific cases where they are necessary and proportionate to preserve public order. Article 30(3) sets the floor (any of 2, 3 or 4); the risk assessment determines where within that band a given activity lands.

2. Mapping data sensitivity to the levels (Annex II)

As a provider or architect proving compliance, you work from Annex II, which sets out the cumulative criteria. They are strictly cumulative: a provider audited at a higher level "shall satisfy all the applicable cumulative criteria under Annex II applicable to the lower Union assurance levels. Failure to meet any requirements of a lower assurance level shall preclude conformity with the higher Union assurance levels" (Article 20(1)). To reach Level 3 you must satisfy Levels 1, 2 and 3.

Routes differ by level: Level 1 is a conformity self-assessment (Article 19); Levels 2, 3 and 4 require an independent third-party audit at the provider's expense (Article 20), reviewed annually (Article 20(8)).

Level 1 — the baseline (self-assessment)

  • Establishment: provider established in the Union (Annex II, 1.1(a)).
  • Infrastructure: infrastructure and assets in the Union unless the public sector body explicitly requires otherwise (1.1(b)).
  • Data residency: customer data — including metadata and telemetry — remains exclusively within the Union, unless the public sector body explicitly requires otherwise, at any time before, during or after use (1.1(c)).
  • Subcontractors: full transparency, due diligence and ongoing oversight; outsourcing must not compromise operational autonomy (1.1(d), (f)).
  • Cybersecurity: demonstrate compliance with state-of-the-art cybersecurity standards (1.1(e)).
  • Vulnerability reporting: if under third-country control, guarantee (via independent sources) no law requires reporting software-vulnerability information to that country's authorities before exploitation is known (1.1(g)).

Level 2 — enhanced control (audit)

  • Personnel location: infrastructure, assets and personnel in the Union (2.1(b)); additional screening and Union-citizenship requirements only "if the public sector body determines" them necessary (2.1(d)) — not a blanket citizenship rule.
  • AI training ban: data generated by using the service must not be used to train or fine-tune any AI system operated by a third country or a third-country-established entity, and must not be transferred outside the Union (2.1(f)).
  • Cybersecurity: a European cybersecurity certificate of at least assurance level "substantial" under a forthcoming Cybersecurity Act (Regulation (EU) 2019/881) cloud scheme, with national-scheme/highest-standard fallbacks until one exists (2.1(e)).
  • Third-country control: if applicable, demonstrate measures preventing third-country data access, preventing service disruption or degradation, and ensuring the provider is not obliged to give effect to third-country restrictive measures unless legitimate under Member State or Union law (2.1(g)).
  • Supply chain: complete, current SBOM plus dependency list; controls to block tamper-capable remote features; source-code audits of security-relevant third-country components; a documented migration plan (2.1(i)).

Level 3 — high sovereignty (audit)

  • Personnel citizenship: personnel involved, including subcontractor personnel, must be Union citizens, with national security clearance where appropriate for classified information (3.1(d)).
  • No third-country control: provider and subcontractors must not be subject to third-country control (3.1(g)). Derogation: a provider under third-country control may be audited for Level 3 only where the Commission has adopted an implementing act under Article 18 designating an associated third country — and that designation requires the third country to meet all six cumulative criteria of Article 18(1) (adequacy under GDPR Article 45 is only the first). Even then the provider must demonstrate the additional control-mitigation measures.
  • Support operations: technical and operational support initiated and performed exclusively within the Union, by personnel who are Union residents, and by third parties not under third-country control (3.1(h)).
  • Cybersecurity: European cybersecurity certificate of at least "substantial" (3.1(e)) — the same level as Level 2, not "high".

Level 4 — sensitive data, maximum protection (audit)

  • Sensitive-data residency — the defining feature: customer data which, "following a risk assessment", is identified as sensitive must remain exclusively within the Union at any time (4.1(c)). Note the difference from lower levels: this sensitive-data criterion has no "unless the public sector body requires otherwise" carve-out. Level 4 is defined by which data triggers it, not just by stricter controls.
  • Personnel: Union citizens, with national security clearance where appropriate (4.1(d)).
  • No third-country control — no derogation: provider and subcontractors must not be under third-country control (4.1(g)), and unlike Level 3 there is no Article 18 associated-third-country route.
  • Cybersecurity: European cybersecurity certificate of at least assurance level "high" — the only level requiring "high" (4.1(e)).
  • Software control: demonstrate that no third country or third-country entity holds or exercises "effective control over the design, development, maintenance, and evolution" of software components (4.1(i)).

3. Private sector — voluntary, modest

Article 30 binds public procurement. For the private sector, Article 31 provides that private-sector entities within the meaning of NIS2 "may carry out similar assessments." This is voluntary ("may") — not a mandatory spillover. If you sell to private critical-infrastructure operators, expect interest in these levels as a benchmark, but the proposal's obligation falls on CSPs serving public bodies, not on private buyers.

What this means for you

You are a CTO, cloud architect or technical buyer. Use sensitivity-of-data plus public-order role as your decision tree:

  • Start from the buyer's risk assessment, not the level. The level you must hold is downstream of the client's Article 29 assessment: routine administrative workloads target Level 1; only public-order activities open Levels 2–4. Don't default to Level 4 — the proposal's proportionality logic cuts against it, and higher levels narrow your eligible market.
  • Map your architecture bottom-up. Because failure at any lower level precludes the higher one, audit in order: EU establishment and data residency (L1) → personnel-in-EU, AI-training ban, "substantial" certificate, SBOM (L2) → EU-citizen personnel, no third-country control, EU-resident support (L3) → sensitive-data residency, "high" certificate, effective-control-over-software proof (L4).
  • Treat telemetry and metadata as customer data. From Level 1 onward, residency covers "metadata and telemetry data," not just primary content. Logging, observability and analytics pipelines that egress outside the EU are a common failure point.
  • Build the AI-training barrier early. From Level 2, service-generated data must not train or fine-tune any third-country AI system and must not leave the Union — technical and contractual controls, not just a policy.
  • Know your route. Level 1 is self-assessed with a public EU statement of conformity (Article 19); Levels 2–4 need an independent audit at your expense (Article 20), re-reviewed annually (Article 20(8)). The auditing organisation is not "accredited" — it must be independent and conflict-free, with proven competence and objectivity (Article 20(4)).
  • If you are under third-country control, Level 3 is reachable only through an Article 18 designation meeting all six criteria, and Level 4 is closed to you entirely.

Common misconceptions

  • "Level 4 is for all classified data." Level 4 attaches to data identified as sensitive following a risk assessment (Annex II, 4.1(c)). Classified-information handling appears across Levels 3 and 4 via clearance requirements, but the trigger for Level 4 is the sensitivity flagged by the risk assessment, not a blanket "classified" label.
  • "Level 3 needs a 'high' cybersecurity certificate." No. Levels 2 and 3 require at least "substantial" (2.1(e), 3.1(e)); only Level 4 requires "high" (4.1(e)).
  • "Article 18 just means a GDPR adequacy decision." Adequacy under GDPR Article 45 is only criterion (a) of six cumulative criteria in Article 18(1). The third country must also meet conditions on lawful-access conflicts, service-continuity and sanctions, technology provision, market openness and reciprocal procurement access.
  • "I can use non-EU staff for support as long as they sit in the EU." For Levels 3 and 4, personnel must be Union citizens (3.1(d), 4.1(d)); Level 3 support must use Union residents (3.1(h)). For Level 2, personnel must be located in the Union, with citizenship required only if the public sector body deems it necessary (2.1(d)).
  • "Article 31 forces private companies onto these levels." Article 31 is voluntary — private NIS2 entities "may carry out similar assessments." The binding procurement obligation (Article 30) is on public buyers.
  • "The AI Act replaces CADA." They are complementary. The AI Act governs safety and fundamental-rights risks of AI systems; CADA, as proposed, governs the sovereignty and operational autonomy of the cloud infrastructure. A service could be AI-Act compliant yet fail CADA Level 2 by using service-generated data to train a third-country AI model.

Official sources

Related

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