Summary Under the proposed Cloud and AI Development Act (CADA), Levels 3 and 4 share an EU-only baseline but differ in three ways: Level 4 requires a "high"-level European cybersecurity certificate (versus "substantial" for Level 3); Level 4 demands the provider demonstrate that no third country holds effective control over its software's design and evolution (a stricter standard than Level 3's controls and migration plans); and, most importantly, Level 4 allows no derogation for providers under third-country control, whereas Level 3 permits such a provider to qualify if the Commission has designated its controlling country as an "associated third country" (Article 18). Both tiers require an independent third-party audit (Article 20).

Detail

CADA would establish a Union cloud computing sovereignty framework of four Union assurance levels, with criteria in Annex II (Article 16). Levels 3 and 4 are the top tiers. Their criteria sit in Annex II, points 3.1 and 4.1 respectively. The distinctions cluster in three areas: cybersecurity certification, software-supply-chain control, and third-country control.

1. Cybersecurity certification: "substantial" vs "high"

  • Level 3 (Annex II 3.1(e)): at least a European cybersecurity certificate of assurance level "substantial" under a cloud scheme to be established under Regulation (EU) 2019/881 (the Cybersecurity Act); pending such a scheme, national schemes apply where they exist, and absent any scheme the provider must meet the highest cybersecurity standards under Union law.
  • Level 4 (Annex II 4.1(e)): the same structure, but at least assurance level "high".

The "high" level implies more rigorous evaluation and a higher standard of resistance to attack.

2. Software supply chain and "effective control"

  • Level 3 (Annex II 3.1(i)): the provider must document an up-to-date SBOM and dependency list; where third-country-licensed components are used, implement controls to block remote tampering, ensure security-relevant third-country components are subject to source-code audits, and maintain a documented migration plan if the vendor fails or the third country imposes restrictions.
  • Level 4 (Annex II 4.1(i)): in addition to the SBOM, the provider must demonstrate that a third country (or a legal entity established there) does not hold or exercise effective control over the design, development, maintenance, and evolution of software components or products. Annex II defines "effective control" as the ability to materially influence technical evolution, maintenance priorities, security remediation, and long-term continuity. At Level 4, source-code audits and a migration plan are not enough — the provider must show that no third-country actor can dictate how the software evolves.

3. Third-country control and the derogation

This is the decisive legal difference.

  • Level 3 (Annex II 3.1(g)): the provider and relevant subcontractors must generally not be subject to third-country control. But there is a derogation: a third-country-controlled provider may be audited for Level 3 where the Commission has adopted an implementing act for that third country. Article 18 is the operative associated-third-countries mechanism, under which the Commission may identify such countries subject to six cumulative criteria (GDPR adequacy, no conflicting lawful-access measures, no compelled disruption or sanctions enforcement, no impediment to state-of-the-art technology, an open market, and reciprocal procurement access). Even then, the provider must prove the safeguards in 3.1(g)(i)–(iv) (no service restraint, prevented data access, prevented disruption, no forced sanctions enforcement) and allow reasonable access to its code.
  • Level 4 (Annex II 4.1(g)): the provider and relevant subcontractors are simply not subject to the control of a third country or a legal entity established in a third country. There is no associated-third-country exception. Level 4 is therefore open only to providers genuinely beyond third-country jurisdictional reach.

4. What the two tiers share

Levels 3 and 4 share several high-bar criteria:

  • Establishment and location: Union establishment, with infrastructure, assets, and personnel in the Union (3.1(a)–(b); 4.1(a)–(b)).
  • Data localisation: at Level 3, customer data (including metadata and telemetry) remains exclusively in the Union unless the public sector body explicitly requires otherwise (3.1(c)); at Level 4, the data identified by risk assessment as sensitive must remain exclusively in the Union with no such carve-out (4.1(c)).
  • Personnel citizenship: Union-citizen personnel, with national security clearance where appropriate (3.1(d); 4.1(d)). (Note that Union citizenship becomes mandatory at Level 3; at Level 2 it is imposed only if the public sector body requires it, per 2.1(d).)
  • AI training: no use of service-generated data to train or fine-tune third-country AI systems, and no transfer outside the Union (3.1(f); 4.1(f)).
  • Support location: support initiated and performed exclusively in the Union, by Union residents, via third parties not under third-country control (3.1(h); 4.1(h)).
  • Open source and separation: controls against remote tampering in open-source components (3.1(j); 4.1(j)) and enforced separation from any third-country subsidiary (3.1(k); 4.1(k)).

The differences are thus concentrated in certificate strictness, the "effective control" software standard, and the absolute ban on third-country control at Level 4.

What this means for you

For in-house counsel and compliance officers, the Level 3/Level 4 line shapes procurement and due diligence.

1. Procurement and risk assessments. Member States and Union entities run risk assessments to set the required level (Article 29); contracting authorities whose activities contribute to the preservation of public order must procure at Level 2, 3, or 4 (Article 30(3)). If your assessment lands on Level 4, your tender documents must say so — and that disqualifies any provider with third-country control or third-country-controlled software evolution.

2. Vendor due diligence. Go beyond a security questionnaire. Verify the certificate level ("high" for Level 4); probe whether any third-country entity has effective control over core software; and scrutinise ownership and control structures, because there is no associated-third-country safe harbour at Level 4.

3. Penalties and liability. Member States must impose effective, proportionate, and dissuasive penalties for infringements (Article 24), and recipients may seek compensation for damage (Article 24(3)). Build audit rights and indemnities into contracts.

4. Timing. CADA is a proposal; if adopted it would enter into force 20 days after publication in the Official Journal and apply from a later date set in the final text (Article 48). Risk assessments are due by one year after entry into force and every two years thereafter (Article 29(1)). Start vendor assessments early.

Common misconceptions

"Level 4 is just Level 3 plus more security." The higher certificate matters, but the sharper difference is the absolute ban on third-country control. A very secure provider can still fail Level 4 if a third-country shareholder holds sway over software updates.

"An adequacy decision lets a non-EU-controlled provider reach Level 4." No. The third-country-control derogation exists only at Level 3 (via Article 18). At Level 4 there is no such route, even for countries with EU adequacy decisions.

"Open-source software disqualifies a provider from Level 4." Not by itself — both tiers permit open source with controls against remote tampering (3.1(j); 4.1(j)). But for Level 4 the provider must still show no third-country effective control over how those components evolve.

"Level 4 is required for all public-sector cloud." No. Bodies whose activities are not identified as contributing to the preservation of public order need only Level 1 (Article 30(2)).

Official sources

Related

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