Data residency vs data sovereignty: the difference under CADA

Summary Data residency is about where data physically sits; data sovereignty is about who controls it and which laws bind the provider. Under the proposed Cloud and AI Development Act (CADA), residency is a necessary but insufficient condition for sovereignty: storing data in an EU data centre does not stop a foreign government from compelling access if the provider is subject to that country's law — the US CLOUD Act being the standard worked example. CADA's four Union assurance levels (Article 16) therefore require not just EU location of infrastructure and personnel but, at higher levels, freedom from coercive third-country control. Recital 48 makes the residency-is-not-sovereignty point explicit. CADA is a proposal and not yet in force.

Detail

The distinction between data residency and data sovereignty is foundational to CADA (COM(2026) 502 final). The proposal deliberately moves the question from where data is stored to who controls the infrastructure and which laws apply to the provider, because physical location alone does not shield data from extraterritorial legal demands.

The limit of data residency

Data residency is the physical location of storage and processing. CADA addresses it through geographic criteria: even at the lowest tier, Union assurance level 1, the provider must keep infrastructure, assets and customer data — including metadata and telemetry — within the Union "unless the public sector body explicitly requires otherwise" (Annex II, points 1.1(b)–(c)).

But residency is not sovereignty. Recital 48 states that the tailored "sovereign" versions 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." So even if data never leaves an EU data centre, it remains exposed where the provider can be legally compelled by a third country to disclose it.

How CADA defines sovereignty

CADA expresses sovereignty through the four Union assurance levels (Article 16), with cumulative criteria in Annex II. Moving up the levels, the requirements shift from geographic presence toward legal and operational independence:

Level 1 (residency plus basic governance). Provider established in the Union; infrastructure in the Union; and, where the provider is 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)). A first step, but it does not block general data-access demands.
Level 2. Where the provider is under third-country control, it must implement legal, technical and organisational measures so that the control cannot restrict the service, access customer data, or disrupt continuity (Annex II, 2.1(g)).
Level 3. The provider and subcontractors must in principle not be under third-country control. A derogation exists only where the Commission has designated an associated third country (Article 18); even then, measures must prevent third-country access to data and service disruption (Annex II, 3.1(g)).
Level 4. No derogation: the provider and subcontractors must not be under third-country control (Annex II, 4.1(g)), and the provider must show that no third country holds effective control over the design, development, maintenance and evolution of software components (Annex II, 4.1(i)).

The US CLOUD Act as the worked example

The clearest illustration of why residency is not sovereignty is the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act). Its central provision, 18 U.S.C. § 2713, requires a provider of electronic communication service or remote computing service to "comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States."

The consequence: a US-based provider may host data in a Frankfurt data centre (satisfying residency), yet still be obliged to produce it under US legal process. The physical location is, for the purposes of the US obligation, irrelevant. CADA's higher assurance levels are designed to remove that exposure by requiring providers either to demonstrate that such demands cannot reach the service or not to be subject to the controlling jurisdiction at all. Recital 50 catalogues the risks the framework targets, including "access to information (i.e. access to sensitive information, unauthorised communication, technology leakage, data manipulation or exfiltration, espionage)" and "dependency vulnerabilities (i.e. political and/or economic coercion ... by using vendor or technology lock-ins, embargos or sanctions ...)".

Sovereignty is conferred, not declared

A second structural difference is that residency can be asserted in a contract, whereas sovereignty under CADA would be a recognised status. A provider applies to the national competent authority of establishment (Article 17). For level 1 it submits an EU statement of conformity (Article 19); for levels 2–4 it submits an audit report and a "positive" audit opinion (Article 20). Other Member States' authorities review the draft recognition before it takes effect Union-wide (Article 17(5)–(7)), and recognised services are listed in the Commission's central repository (Article 22). Recital 47 explains why this matters: without a harmonised EU framework there is "no cross-cutting Union regulatory framework establishing a harmonised understanding of what constitutes a trusted cloud computing service", and diverging national labels "risk fragmenting the Union internal market".

The associated-third-country route (Article 18)

The framework is not closed to foreign-controlled providers. Article 18 lets the Commission, by implementing act, designate third countries whose providers may be audited for level 3, but only where the country meets cumulative conditions: a relevant adequacy decision under Article 45 GDPR; no measures enabling control that conflicts with the lawful-access rules for non-personal data in Article 32 of Regulation (EU) 2023/2854 (the Data Act); no measures to compel service degradation or disruption, or to force compliance with sanctions or embargoes (unless legitimate under Member State or Union law); no measures impeding state-of-the-art technologies; an open market to Union cloud services; and equivalent access to its own public procurement for Union-controlled providers. This is a far more demanding test than a residency clause, and it illustrates the gap between the two concepts: residency asks only where data sits; sovereignty asks whether the controlling legal order can reach it at all.

Public-sector obligations

The practical consequence falls on public buyers. Under Article 29, Member States and Union entities would conduct risk assessments to determine the appropriate level. Activities not identified as public-order relevant would require at least level 1 (Article 30(2)); activities that contribute to public order — in NIS2 sectors or in national security, defence, justice and similar fields — would require levels 2, 3 or 4 (Article 30(3)). For those functions, residency would not be enough: the provider would have to be legally and technically insulated from foreign compulsion.

What this means for you

For in-house counsel and compliance officers:

Audit existing contracts. A service guaranteeing EU residency but owned or controlled by a third-country entity would likely not deliver sovereignty under CADA, and would remain exposed to extraterritorial access.
Run the Article 29 risk assessment. Determine whether your processing contributes to public order (NIS2 sectors, national security, defence, justice). If so, levels 2–4 would apply.
Verify recognition. Do not rely on the phrase "sovereign cloud". Confirm the provider's recognised level via the national competent authority (Article 17) and the Commission's central repository (Article 22).
Prepare to migrate. Where a risk assessment requires a different service, Article 29(6) allows up to 12 months to migrate, accounting for technical feasibility, continuity and data portability.
Watch the private-sector signal. Article 31 lets NIS2-scope private entities run similar impact assessments; public procurement requirements tend to shape private demand. Recital 66 notes that requirements imposed by or on public authorities to adopt specific assurance levels "tend to be mirrored by private-sector entities", so today's public-sector residency-versus-sovereignty distinction is likely to become a commercial expectation more broadly.

Common misconceptions

"Residency equals sovereignty." No. Residency is geography; sovereignty is legal control. A US company can host data in Berlin yet still be compelled by US law to produce it.
"A GDPR adequacy decision solves sovereignty." An adequacy decision under Article 45 GDPR addresses transfer standards; it does not prevent access for national-security or law-enforcement purposes. For an associated third country under CADA Article 18, the Commission must assess both adequacy and the absence of measures that could compel access or service disruption — a separate and stricter test.
"An EU subsidiary of a foreign provider is sovereign." Not necessarily. Annex II points 2.1(k) and 3.1(k) require a provider that maintains a third-country subsidiary to demonstrate effective legal, technical and organisational separation between the Union parent and that subsidiary. Mere EU incorporation does not suffice if ultimate control sits abroad.
"Open source guarantees sovereignty." Open source aids transparency and can reduce lock-in (Annex II, 2.1(j)), but CADA's sovereignty criteria turn on the provider's legal status and control. A provider using open-source software can still be subject to coercive third-country laws.
"Residency rules and sovereignty rules are the same legal test." They are not. Residency is largely satisfied by geography and contract; sovereignty under CADA is a recognised, audited status (Articles 17, 20) resting on establishment, control, personnel, support location and supply-chain criteria in Annex II. A service can be fully residency-compliant and still be ineligible for level 3 or 4 because of who ultimately controls the provider.

Official sources

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

Data residency vs data sovereignty