Summary Under the proposed Cloud and AI Development Act (CADA), a provider seeking recognition at Union assurance level 2 would have to satisfy all eleven cumulative criteria in Annex II, Section 2.1(a)-(k). In summary, as proposed: the provider and its involved subcontractors are established in the Union (2.1(a)); infrastructure, assets and personnel are located in the Union (2.1(b)); customer data — including metadata and telemetry — stays exclusively in the Union unless the public sector body explicitly requires otherwise (2.1(c)); the customer can require additional screening and Union-citizenship for staff (2.1(d) — conditional, not blanket); the service holds a European cybersecurity certificate of at least assurance level "substantial" (2.1(e) — not "high"); service-generated data is neither used to train third-country AI nor transferred outside the Union (2.1(f)); any third-country control is neutralised by safeguards (2.1(g)(i)-(iv)); support is initiated and performed exclusively in the Union (2.1(h)); a complete SBOM plus third-country-component and vulnerability-reporting controls are in place (2.1(i)(i)-(iii)); open-source components are controlled (2.1(j)); and a third-country subsidiary is legally and technically separated (2.1(k)). Level 2 is verified by an independent third-party audit (Article 20), not self-assessment, and it is cumulative — Level 2 also requires meeting every Level 1 criterion (Article 20(1)).

Detail

CADA (COM(2026) 502 final) is a proposal and is not in force. As proposed, Article 16 establishes a Union cloud computing sovereignty framework comprising four Union assurance levels, with criteria set out in Annex II, that providers would have to meet to supply cloud computing services to Union entities and public sector bodies. Union assurance level 2 is the first audited tier: unlike Level 1 (self-assessment under Article 19), Levels 2, 3 and 4 would be verified by an independent third-party audit under Article 20.

A scope note in the introduction to Annex II matters for several Level 2 criteria: "software" within the meaning of Article 3(4) of Regulation (EU) 2024/2847 (the Cyber Resilience Act) is in scope of Annex II and Annex III, whereas "hardware" (Article 3(5)) is out of scope. The SBOM and source-code-audit duties below therefore bite on software and software products, not on physical hardware.

The eleven criteria in Annex II, Section 2.1 are cumulative: a provider must meet every one. Article 20(1) further provides that a provider audited at a higher level "shall satisfy all the applicable cumulative criteria under Annex II applicable to the lower Union assurance levels", and that "[f]ailure to meet any requirements of a lower assurance level shall preclude conformity with the higher Union assurance levels." So a Level 2 candidate must also satisfy the Level 1 criteria (Annex II §1.1). The criteria below are the Level 2 set as proposed.

Establishment, location and personnel (2.1(a), (b), (d))

  • Establishment (2.1(a)): the audited provider and the subcontractors involved in providing the audited service are established in the Union. Subcontractors here means third parties with a direct contractual relationship with the provider that contribute to provision and delivery of the service (Annex II §2.2).
  • Location of infrastructure, assets and personnel (2.1(b)): the infrastructure, assets and personnel of the audited provider — including those of involved subcontractors — are located in the Union. Level 2 adds personnel to the Level 1 infrastructure/assets test.
  • Conditional screening and citizenship (2.1(d)): if the public sector body determines that additional personnel screening and Union-citizenship requirements are necessary, the provider should ensure that personnel meeting those requirements are available. As proposed, this is conditional on the customer's determination — it is not a blanket Union-citizenship rule. (Blanket Union-citizenship for personnel appears only at Levels 3 and 4 in Annex II §3.1(d) and §4.1(d).)

Data residency and the AI-training / transfer ban (2.1(c), (f))

  • Data residency (2.1(c)): customer data, including metadata and telemetry data, processed, stored and transferred by the provider and involved subcontractors remains exclusively within the Union — "unless the public sector body explicitly requires otherwise and at any time, including before, during or after the configuration or use of the service."
  • No third-country AI training; no transfer (2.1(f)): data generated by using the audited service "are not used to train or fine-tune any AI system operated by a third country or a legal entity established in a third-country, and are not transferred outside the Union in any case." Note the absence of a customer carve-out here: unlike 2.1(c), the transfer ban in 2.1(f) is unconditional as proposed.

Cybersecurity certification (2.1(e))

The audited service obtains a European cybersecurity certificate of at least assurance level "substantial" under a cloud-services scheme to be established under Regulation (EU) 2019/881 (the Cybersecurity Act), provided such a scheme has been established and is available. Until then, national cybersecurity certification schemes apply where they exist; absent any Union or national scheme, the provider must demonstrate that the service complies with the highest cybersecurity standards under applicable Union law. The threshold is "substantial", not "high" — "high" is required only at Level 4 (Annex II §4.1(e)).

Third-country control safeguards (2.1(g)(i)-(iv))

If the provider or involved subcontractors are subject to the control of a third country or a third-country-established legal entity, the provider must demonstrate that necessary legal, technical and organisational measures ensure that:

  • (i) that control is not exercised so as to restrain or restrict the provider's ability to perform and deliver the service, impose limitations on the infrastructure, assets and personnel required, or undermine the capabilities and standards needed;
  • (ii) access by a third country or third-country-established legal entity to customer data is prevented;
  • (iii) disruption of service continuity and/or degradation of service quality by a third country is prevented;
  • (iv) the provider is not obliged to implement, enforce or give effect to restrictive measures — "such as sanction regimes, embargoes, or any equivalent legal or administrative measures" — adopted by a third country, "unless such measures are legitimate under the national laws of Member States or Union law."

Critically, as proposed Level 2 does not bar third-country control outright; it requires that control be neutralised by demonstrable safeguards. (A no-third-country-control rule, subject only to the Article 18 associated-third-countries derogation, appears at Level 3; Level 4 bars it with no derogation.)

EU-only support (2.1(h))

Technical and operational support or assistance related to the audited service — "including subsequent sub-outsourcing arrangements" — must be initiated and performed exclusively within the Union. As proposed there is no emergency or "follow-the-sun" exception for support from outside the Union at Level 2.

Software supply chain (2.1(i)(i)-(iii))

  • (i) SBOM and dependencies: a complete and up-to-date software bill of materials (SBOM) "as defined in Article 3, point (39), of Regulation (EU) 2024/2847" (the Cyber Resilience Act), plus a list of identified dependencies relevant to the service, are documented and made available to the auditing organisation.
  • (ii) Third-country component controls: where software components or products are provided, owned and licensed by a third-country-established legal entity, the provider implements and documents controls to block any remote features that could materially tamper with or disrupt a device, system or software (including during updates); ensures that security-relevant components from third-country software manufacturers are subject to source-code audits; and has a documented migration plan in the event the vendor fails or a third country imposes restrictions.
  • (iii) Vulnerability-reporting guarantee: where the provider is under third-country control, it gives the same guarantee as at Level 1 — that no laws or practices in that third country require it to report software-vulnerability information to that country's authorities before those vulnerabilities are known to have been exploited.

Open-source controls (2.1(j))

Where open-source-licensed software is used, the provider must demonstrate documented controls to prevent remote features or mechanisms that could materially tamper with or disrupt the system. Open-source use does not exempt a component from supply-chain control.

Third-country subsidiary separation (2.1(k))

To the extent the provider operates globally and maintains a subsidiary in a third country, it must have implemented measures ensuring effective legal, technical and organisational separation between the Union parent and the third-country subsidiary.

How Level 2 is verified

Level 2 is established by an independent third-party audit under Article 20, conducted at the provider's own expense, producing an audit report and a "positive" or "negative" audit opinion (Article 20(1), (5)). The auditing organisation is not described in the proposal as "accredited"; instead Article 20(4) requires it to be independent and free of conflicts of interest (including no non-audit services to the provider for 12 months before and a commitment not to provide them for 12 months after, no audit services to that provider in the prior 10 years, and no contingent fees), to have proven technical competence in auditing cloud services, and to have proven objectivity and professional ethics. The organisation assesses each Annex II criterion against the audit evidence listed in Annex III (Article 21), and the evidence must be relevant, sufficient and reliable (Article 21(2)). A "positive" opinion supports recognition under Article 17; the provider must then resubmit the report and opinion annually for review, which may confirm, update or revoke it (Article 20(8)).

What this means for you (provider)

Treat Level 2 as a structural change to your delivery model, not a paperwork exercise:

  • Locate people, not just servers. Level 2 adds personnel to the location test (2.1(b)). Any support, operations or development staff touching the audited service must sit in the Union, and 2.1(h) means even emergency support cannot be initiated from outside the Union. Plan EU-resident teams accordingly, and be ready to staff with additional-screened or Union-citizen personnel if a customer invokes 2.1(d).
  • Lock down data egress. 2.1(c) keeps customer data (including metadata/telemetry) in the Union absent an explicit customer requirement; 2.1(f) bans transfer of service-generated data outside the Union in any case and bars its use to train or fine-tune third-country AI — a hard line with no customer carve-out. Audit your telemetry, logging and AI/ML pipelines for any third-country egress.
  • Build the SBOM and vendor-control programme now. You will need a complete, current SBOM (per CRA Article 3(39)) and dependency list ready for the auditor (2.1(i)(i)). For third-country software components: remote-feature blocking, source-code audits of security-relevant components, and a documented exit/migration plan (2.1(i)(ii)). Open-source is in scope too (2.1(j)). Because Annex II covers "software" but not "hardware", scope these to your software and software products.
  • If you are under third-country control, engineer it out. You do not have to be EU-owned at Level 2, but you must demonstrate the 2.1(g)(i)-(iv) safeguards plus the 2.1(i)(iii) vulnerability-reporting guarantee, and — if you keep a third-country subsidiary — the 2.1(k) separation measures. Expect to evidence access controls, key management, governance and contractual terms.
  • Get the certificate and the auditor. Pursue a "substantial"-level certificate under the Cybersecurity Act cloud scheme when available, or the national/highest-standards fallback (2.1(e)). Engage an auditing organisation that meets the Article 20(4) independence, competence and objectivity tests, and budget for the audit and its annual renewal review (Article 20(8)).
  • Keep a paper trail. Annex III drives the evidence the auditor will request for each criterion (Article 21). Maintain contracts, data-flow maps, screening records, SBOMs, source-code-audit results and migration plans as living documents.

Common misconceptions

"Level 2 requires all staff to be EU citizens." No. As proposed, Level 2 requires personnel to be located in the Union (2.1(b)); Union-citizenship applies only where the public sector customer determines additional screening and citizenship are necessary (2.1(d)). Blanket Union-citizenship is a Level 3 and Level 4 requirement.

"Level 2 needs a 'high' cybersecurity certificate." No. The threshold is at least "substantial" (2.1(e)). "High" is required only at Level 4.

"A third-country-owned provider can't reach Level 2." Not necessarily. Level 2 permits third-country control if the 2.1(g)(i)-(iv) safeguards (plus the 2.1(i)(iii) guarantee and any 2.1(k) separation) are demonstrated. The outright no-third-country-control rule is Level 3 (with the Article 18 derogation) and Level 4 (no derogation).

"Encryption lets data leave the EU." No. 2.1(c) requires customer data — including metadata and telemetry — to stay exclusively in the Union unless the customer explicitly requires otherwise, and 2.1(f) bans transfer of service-generated data outside the Union in any case. Encryption does not change the residency rule.

"Proprietary or open-source software is exempt from the SBOM/controls." No. The SBOM (2.1(i)(i)) applies regardless of licence, and open-source components carry their own control duties (2.1(j)).

"The auditor must be government-accredited." The proposal does not use "accredited". It sets independence, conflict-of-interest, competence and objectivity criteria for the auditing organisation in Article 20(4).

Official sources

Related

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