What are the CADA Union assurance levels?

The proposed EU Cloud and AI Development Act defines four Union assurance levels for cloud services used by public bodies. Annex II sets 40 criteria across them, covering establishment, data location, personnel, certification, third-country control and software supply chain. Level 1 is self-assessed; Levels 2 to 4 require a third-party audit.

Are CADA assurance levels cumulative?

Yes. Under Article 20(1), failing any requirement of a lower level precludes conformity with the higher levels. A deployment that fails one Level 1 criterion cannot reach Levels 2, 3 or 4.

Can a US hyperscaler reach CADA Level 1?

Not automatically. Level 1 requires the provider to be established in the Union, and the text does not say whether an EU-incorporated subsidiary of a US parent qualifies. level-assessor reports that criterion as undetermined for US-parented providers and asks for the contracting entity rather than picking a side.

Can a non-EU provider reach CADA Level 3?

Only if its home country is recognised as an associated third country under Article 18. That requires six cumulative criteria, and the Commission has not recognised any country yet. Level 4 allows no such exception.

Which assurance level does a public body have to procure?

Level 1 by default (Art. 30(2)). Bodies whose activities contribute to public order — defence, justice, law enforcement, border management and NIS2 sectors — must procure Level 2, 3 or 4, as set by their Article 29 risk assessment (Art. 30(3)). Article 30(4) allows derogations on three grounds.

Is the Cloud and AI Development Act in force?

No. It is Commission proposal COM(2026) 502 of 3 June 2026 and will change in trilogue. The criteria on this page follow the published proposal and its Annex II (Council document ST-10104-2026-ADD-1).

EU Cloud and AI Development Act · Guide

CADA Union assurance levels 1–4, explained

The EU's proposed Cloud and AI Development Act sorts cloud services used by public bodies into four Union assurance levels. This guide lists every Annex II criterion by level, explains which level a buyer must procure, and sets out when a provider controlled from outside the EU — including from the US or Canada — can still qualify.

By Gautam Soni · Founder, Expand Labs Inc. · Updated September 26, 2026

The four levels at a glance

Levels are cumulative. Article 20(1): “Failure to meet any requirements of a lower assurance level shall preclude conformity with the higher Union assurance levels.” To reach Level 3 a service must meet every Level 1, 2 and 3 criterion.

Summary of the four CADA Union assurance levels
Level	What it adds	Criteria	Who checks
Level 1	The provider is established in the Union, its infrastructure is in the Union, and customer data — including metadata and telemetry — stays in the Union. A US hyperscaler is not an automatic pass.	7	Self-assessment
Level 2	Subcontractors and personnel in the Union, support performed only from the Union, a European cybersecurity certificate at 'substantial', and supply-chain controls. A provider controlled from outside the Union can still qualify, but only with specific safeguards.	11	Third-party audit
Level 3	No control from outside the Union — except from a future associated third country under Article 18 — Union-citizen personnel, and support performed by Union residents free of third-country control.	11	Third-party audit
Level 4	A certificate at 'high', no third-country control with no exceptions at all, sensitive data kept in the Union without exception, and effective control over the software components themselves.	11	Third-party audit

All 40 Annex II criteria, by level

Criteria attach to the provider and the subcontractors involved in delivering the service. Titles below are the level-assessor rule set's short names; the Annex II text is quoted verbatim in each rule.

Level 1 criteria — Annex II, point 1.1 · self-assessment

1.1(a)Provider established in the Union
1.1(b)Infrastructure and assets located in the Union
1.1(c)Customer data, metadata and telemetry remain in the Union
1.1(d)Safeguards where support is outsourced outside the Union
1.1(e)State-of-the-art cybersecurity standards
1.1(f)Transparency and oversight of subcontractors
1.1(g)No pre-exploitation vulnerability reporting to a third country

Level 2 criteria — Annex II, point 2.1 · third-party audit

2.1(a)Provider and subcontractors established in the Union
2.1(b)Infrastructure, assets and personnel located in the Union
2.1(c)Customer data, metadata and telemetry remain in the Union
2.1(d)Screened or Union-citizen personnel available on request
2.1(e)European cybersecurity certificate at 'substantial'
2.1(f)Service data not used to train third-country AI, and not transferred out
2.1(g)Safeguards where the provider is third-country controlled
2.1(h)Support initiated and performed exclusively within the Union
2.1(i)Software supply chain measures
2.1(j)Controls over remote features in open-source software
2.1(k)Separation from any third-country subsidiary

Level 3 criteria — Annex II, point 3.1 · third-party audit

3.1(a)Provider and subcontractors established in the Union
3.1(b)Infrastructure, assets and personnel located in the Union
3.1(c)Customer data, metadata and telemetry remain in the Union
3.1(d)Union-citizen personnel, with clearance where appropriate
3.1(e)European cybersecurity certificate at 'substantial'
3.1(f)Service data not used to train third-country AI, and not transferred out
3.1(g)Not subject to third-country control, save by Article 18 derogation
3.1(h)Support performed in the Union, by Union residents, free of third-country control
3.1(i)Software supply chain measures
3.1(j)Controls over remote features in open-source software
3.1(k)Separation from any third-country subsidiary

Level 4 criteria — Annex II, point 4.1 · third-party audit

4.1(a)Provider and subcontractors established in the Union
4.1(b)Infrastructure, assets and personnel located in the Union
4.1(c)Sensitive customer data remains in the Union, without exception
4.1(d)Union-citizen personnel, with clearance where appropriate
4.1(e)European cybersecurity certificate at 'high'
4.1(f)Service data not used to train third-country AI, and not transferred out
4.1(g)Not subject to third-country control, with no derogation
4.1(h)Support performed in the Union, by Union residents, free of third-country control
4.1(i)Effective control over software components
4.1(j)Controls over remote features in open-source software
4.1(k)Separation from any third-country subsidiary

Which level must a public body procure?

Articles 29 and 30 answer the buyer's half of the question. The level is set by the buyer's own Article 29 risk assessment — and since the implementing act defining that methodology does not exist yet, no tool can infer a required level for you.

Art. 30(2)

Default: Union assurance level 1

Public bodies whose activities are not identified as contributing to the preservation of public order must use services recognised at Level 1. Level 1 is a floor, so a service at a higher level also satisfies it.

Art. 30(3)

Public-order activities: Level 2, 3 or 4

Contracting authorities whose activities contribute to public order — in NIS2 sectors and in national security, internal security, border management, defence, justice or law enforcement — may only procure services at Level 2, 3 or 4. Which one comes from the buyer's Article 29 risk assessment.

Derogation grounds — Article 30(4)

A buyer may depart from the required level on one of three grounds:

No adequate or reasonable alternative exists.
A similar procurement in the previous year drew no suitable tenders.
Compliance would require procurement at disproportionate cost.

Article 18: can a non-EU provider reach Level 3?

Level 3 requires that the provider is not subject to third-country control — unless the Commission recognises its home country as an associated third country. Level 4 allows no such exception. “Control” means the ability to exercise a decisive influence on a legal entity, directly or through intermediate entities; there is no percentage threshold.

Recognition requires all six Article 18(1) criteria. They are cumulative, so failing one fails all. No country has been recognised yet.

18(1)(a)GDPR adequacy decision
18(1)(b)No compelled access to non-personal data
18(1)(c)No compelled degradation, disruption or sanctions compliance
18(1)(d)No measures impeding state-of-the-art technologies and servicesno published assessment
18(1)(e)Open market to Union cloud computing servicesno published assessment
18(1)(f)Reciprocal access to public procurementno published assessment

Where the US and Canada stand

Positions as encoded in the rule set. Every one is contested or unassessed: the Commission has adopted no implementing act for any country, so the tool treats Article 18 as a scenario you can set with --assume-article18, and reports both outcomes.

United States
Criterion	Position	What is unresolved
(a) Adequacy	Satisfied, contested	The Data Privacy Framework is framework-conditional and under sustained challenge.
(b) Compelled access	Unresolved	The test is a comparison against Data Act Art. 32(2)–(3), which no published analysis has carried out.
(c) Compelled disruption	Not satisfied, contested	Sanctions law can force a provider to cut off European users. The criteria are cumulative, so this alone decides the US.
(d)–(f) Trade conditions	Unassessed	No published analysis exists.

Canada
Criterion	Position	What is unresolved
(a) Adequacy	Satisfied, contested	Canada's adequacy covers PIPEDA organisations only, and Bill C-36 would replace PIPEDA.
(b) Compelled access	Unresolved	Bill C-22 (lawful access) and the OVH production-order case test how far existing powers reach.
(c) Compelled disruption	Unresolved	Turns on whether Canadian sanctions (SEMA) obligations are saved by the Art. 18(1)(c) proviso.
(d)–(f) Trade conditions	Unassessed	No published analysis exists.

For the Canadian case in depth, read Is Canada a “trusted partner” for Europe's sovereign cloud?

What usually caps a deployment's level

A deployment is only as sovereign as its weakest required dependency. The provider that caps it is rarely the one running the compute. It is usually a service that entered as configuration rather than infrastructure — which is why level-assessor flags these six classes in every report:

CDNA proxy toggle or distribution in front of the site
DNSThe zone and records that resolve the service
Identity providerSSO and user directory
Key managementWhere encryption keys are held
LoggingLog sinks, metrics and telemetry pipelines
RegistryContainer and package registries

level-assessor reads a Terraform plan, traces each resource to the provider and country that control it, and names the resource that caps your level.

Open questions in the text

Where the proposal is ambiguous, the rule set records the question rather than resolving it by default. These four change assessment outcomes:

Is an EU subsidiary "established in the Union"?

Levels 1 to 4 all require establishment in the Union, and none says whether an EU-incorporated subsidiary of a third-country parent qualifies. If incorporation suffices, the criterion does almost no work; if an effective seat is required, no hyperscaler reaches Level 1. This decides whether roughly 70% of European public cloud spend is capable of Level 1 at all.

Does a CDN edge count as infrastructure in the Union?

An anycast CDN terminates TLS at whichever edge is nearest, worldwide. Whether that edge is "infrastructure located in the Union", and whether the request metadata it handles is in scope of 1.1(c), decides whether any CDN-fronted deployment can reach Level 2.

Annex II 3.1(g) cites Article 19, but means Article 18

The Level 3 control derogation refers to an implementing act "under Article 19", which is conformity self-assessment. Article 18 is the associated-third-country provision. It is the single load-bearing cross-reference in the instrument.

Union citizenship at Level 3 may be absolute

On the natural reading of 3.1(d), "where appropriate" governs only security clearance, leaving Union citizenship required for all personnel involved in the service — a demanding requirement and a likely trilogue target.

The full list is kept in the repository's OPEN_QUESTIONS.md.