Summary "Immunity from foreign law" means a cloud service is legally and technically shielded so that no third-country authority can compel access to customer data or force a disruption of the service. In the proposed Cloud and AI Development Act (CADA), this is not automatic; it is approximated through the Union assurance levels in Article 16, with the highest levels (3 and 4) requiring that the provider is not under coercive third-country control at all. Recital 48 identifies the underlying problem — third-country laws with extraterritorial reach — and the Annex II criteria translate "immunity" into concrete, auditable requirements on establishment, data location, personnel, supply chain and corporate control. CADA is a proposal and not yet in force.

Detail

The problem: extraterritorial reach of third-country laws

Immunity from foreign law in CADA responds to a specific vulnerability. Recital 48 states that the tailored "sovereign" versions some providers have launched "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." Recital 50 spells out the consequent risks — including "access to sensitive information, unauthorised communication, technology leakage, data manipulation or exfiltration, espionage" and "political and/or economic coercion". CADA therefore reaches beyond data protection (the GDPR) to pursue operational autonomy and control over data and infrastructure.

No single criterion delivers absolute legal immunity, and the proposal does not claim it does. Instead, the assurance levels raise the legal and technical barriers progressively, until at the top tier the provider is structurally outside coercive third-country control.

It is worth being precise about what "immunity" means here. CADA does not purport to override foreign legislation — the EU cannot legislate away the reach of another state's law. What the higher assurance levels do is remove the conditions under which foreign law can bite: if the provider, its subcontractors, its personnel and its software supply chain are not subject to third-country control, and the data and support stay in the Union, then there is no entity the foreign authority can lawfully compel within its own jurisdiction. Recital 48 frames the objective as ensuring the Union has "autonomy or control over its data, assets and digital infrastructure", and recital 46 calls the ability "to retain control over infrastructure, data, assets and technology systems under Union and national jurisdiction" an "imperative policy objective." Immunity, in practice, is the absence of a coercible point of leverage.

The mechanism: Union assurance levels (Article 16)

Article 16 establishes the Union cloud computing sovereignty framework of four assurance levels, with criteria in Annex II. The criteria are cumulative; higher levels approach functional immunity.

Level 1: baseline

The minimum for public procurement (Article 30(2)). It does not deliver immunity in the way higher tiers do.

  • Provider established in the Union (Annex II, 1.1(a)).
  • Customer data remains in the Union unless the public sector body explicitly requires otherwise (Annex II, 1.1(c)).
  • Where under third-country control, a guarantee that no third-country law forces early reporting of software vulnerabilities to that country's authorities (Annex II, 1.1(g)).

Level 2: enhanced sovereignty

Independent third-party audit, plus tighter controls on third-country influence.

  • Infrastructure, assets and personnel located in the Union (Annex II, 2.1(b)).
  • Where under third-country control, measures ensuring that control cannot restrain the service or impose limits on infrastructure, and that third-country access to customer data is prevented (Annex II, 2.1(g)(i)–(ii)).
  • Prevention of any third-country-caused disruption or degradation of the service (Annex II, 2.1(g)(iii)).
  • Software-supply-chain measures, including controls to block remote features that could tamper with or disrupt the service (Annex II, 2.1(i)).

Level 3: high sovereignty

For activities relevant to public order (Article 30(3)).

  • Personnel involved in the service must be Union citizens (Annex II, 3.1(d)).
  • The provider and subcontractors must in principle not be under third-country control (Annex II, 3.1(g)).
  • Derogation only where the Commission has designated an associated third country (Article 18); even then, strict legal and technical measures must prevent access and disruption.
  • Support performed exclusively within the Union by Union residents not under third-country control (Annex II, 3.1(h)).

Level 4: maximum sovereignty

The highest tier.

  • No derogation for third-country control: the provider and subcontractors must not be under such control (Annex II, 4.1(g)).
  • The provider must show that no third country holds or exercises effective control over the design, development, maintenance and evolution of software components — including the ability to materially influence technical evolution, security remediation and long-term continuity (Annex II, 4.1(i)(ii)).
  • "High" cybersecurity certificate (Annex II, 4.1(e)); personnel with national security clearance where classified information is handled (Annex II, 4.1(d)).

Audits and recognition

Immunity is not self-declared. Article 17 establishes a recognition mechanism through national competent authorities. A provider applies to the national competent authority of establishment; for level 1 it submits an EU statement of conformity (Article 19), and for levels 2–4 it submits an audit report and a "positive" audit opinion from an independent auditing organisation (Article 20), which assesses the Annex II criteria — including whether third-country laws could compel access or disruption. Other Member States' authorities have a review period to raise reasoned objections before recognition takes effect Union-wide, and unresolved disputes can be referred to the Commission for a binding decision (Article 17(5)–(10)). Recognition can be revoked where a provider supplied incorrect or misleading information (Article 17(11)). The result is that "immunity from foreign law" is a status verified by a public authority and re-checked over time — not a marketing claim or a one-off attestation.

Notably, the level 1 criteria already include a specific anti-coercion guarantee even where the provider is under third-country control: that no law in that country requires reporting of software vulnerabilities to its authorities before the vulnerabilities are known to have been exploited (Annex II, 1.1(g)). This guards against a subtle channel of foreign leverage — privileged early knowledge of weaknesses — that pure data-residency rules would miss.

What this means for you

For in-house counsel and compliance officers, the proposal would turn cloud procurement into a structured legal obligation:

1. Procurement obligations by risk level

  • Baseline: at least Union assurance level 1 (Article 30(2)).
  • Public-order activities (NIS2 sectors, national security, defence, justice, etc.): only levels 2, 3 or 4 (Article 30(3)).
  • Risk assessments every two years, or whenever necessary (Article 29(1)).

2. Due diligence and supply chain

  • Establish whether the provider has ultimate beneficial owners in third countries and, if so, whether it meets the Annex II measures preventing coercive use of that control.
  • Confirm subcontractors meet the same level — immunity extends down the chain.
  • For levels 2–4, expect a Software Bill of Materials and demonstrations that no remote features could be used to tamper with the service (Annex II, 2.1(i)).

3. Penalties and compensation

  • Member States would set penalties for infringements of the sovereignty framework (Title IV, Chapter I) by providers; these must be "effective, proportionate and dissuasive" (Article 24(1)). The criteria for imposing them are non-exhaustive and include the nature, gravity, scale and duration of the infringement, mitigation, prior infringements, financial benefit, and the provider's Union turnover (Article 24(2)).
  • Recipients may seek compensation for damage or loss from a provider's infringement, in accordance with Union and national law (Article 24(3)).

4. Transition and migration

Where a risk assessment requires a higher level than the current provider offers, Article 29(6) allows a transition period not exceeding 12 months, accounting for technical feasibility, continuity and data portability.

Common misconceptions

GDPR compliance equals immunity from foreign law. The GDPR governs personal-data processing; it does not stop a third-country government from compelling access under its own laws. CADA's assurance levels add the legal and technical barriers (recital 48).

Data localisation alone provides immunity. Localisation is one criterion at every level but is insufficient on its own. A provider could keep data in the Union yet remain subject to third-country control enabling remote access or disruption. Levels 2–4 require controls over personnel, supply chain and corporate governance.

Any EU-established provider qualifies for level 2 or 3. Establishment is necessary but not sufficient. An EU-established but foreign-controlled provider must still prove that the control cannot compromise data or continuity; level 3 also requires Union-citizen personnel, and level 4 allows no third-country control.

Immunity is a one-time certification. It is dynamic. Audit reports are reviewed annually (Article 20), and providers must promptly report material changes that may affect recognition (Article 23). Authorities may revoke recognition where criteria are no longer met.

Official sources

Related

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