Summary "Sovereignty washing" is marketing a cloud service as sovereign by bolting superficial, localised features onto global infrastructure, without addressing the core risks of extraterritorial data access or service disruption. "Real sovereignty," as framed by the proposed Cloud and AI Development Act (CADA), is a harmonised, auditable status defined by four Union assurance levels (Article 16). For the higher levels, CADA would require independent third-party audits and specific technical, legal and organisational safeguards — strict data localisation, personnel rules, supply-chain controls — to ensure genuine operational autonomy and protection of public order.

Detail

"Sovereignty washing" describes a market practice in which providers — often large non-EU hyperscalers — label services "sovereign" or "local" to appeal to EU public-sector buyers, without fundamentally changing the underlying dependence. The tweaks tend to be cosmetic: hosting data in EU data centres or appointing an EU-based entity, while the core infrastructure, source code and ultimate control remain exposed to third-country laws.

Recital 48 of the CADA proposal addresses this directly. It notes that providers "have launched tailored versions of their service offerings in response to the Union's growing concerns over sovereignty," but that those versions "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." As a result, the proposal reasons, the Union "will not ensure autonomy or control over its data, assets and digital infrastructure."

To counter this, CADA would replace vague claims with a legally grounded Union cloud computing sovereignty framework (Article 16) of four Union assurance levels. The framework is harmonised across the EU, so "sovereign" means the same thing in every Member State.

The problem with sovereignty washing

Sovereignty washing typically leans on two weak guarantees:

  1. Data residency. Storing data physically in the EU. This helps with some data-protection requirements but does not stop a provider's parent company, or third-country authorities, from accessing data where the provider is exposed to extraterritorial laws.
  2. Local presence. A local sales office or legal entity. This does not stop a global parent from degrading service, imposing restrictions, or complying with foreign sanctions or embargoes that conflict with EU interests.

The proposal sets out the underlying risks in Recital 50, which lists misuse (including remote access and control, sabotage), access to information (including unauthorised communication, technology leakage, espionage) and dependency vulnerabilities (including political and economic coercion, vendor or technology lock-in, embargoes or sanctions).

Real sovereignty: the CADA framework

Under the proposal, real sovereignty is a compliance status achieved through strict, cumulative criteria in Annex II. The four levels increase in stringency:

  • Union assurance level 1 is the baseline. The provider must be established in the Union, with infrastructure and assets (including subcontractors') located in the Union, and customer data kept exclusively within the Union unless the public sector body explicitly requires otherwise. Where the provider is under third-country control, it must guarantee — demonstrated by independent sources — that no laws in that third country require reporting software vulnerabilities to foreign authorities before they are known to have been exploited. Level 1 is self-assessed (Article 19).
  • Union assurance levels 2, 3 and 4 require independent third-party audits (Article 20). An independent auditing organisation verifies compliance with the cumulative criteria, which include:
    • Personnel: for levels 3 and 4, personnel involved in service provision must be Union citizens, with national security clearances where classified information is handled. (At level 2, citizenship and additional screening apply only if the public sector body determines they are necessary.)
    • Cybersecurity certification: a European cybersecurity certificate of at least "substantial" assurance (levels 2 and 3) or "high" assurance (level 4) under EUCS, once established.
    • No third-country control: at level 4, the provider and its subcontractors must not be subject to the control of a third country or a legal entity established in a third country, with no derogation. At level 3 the same applies in principle, with a limited derogation possible for providers from "associated third countries" identified by the Commission (Article 18).
    • Software supply-chain transparency: a complete, up-to-date software bill of materials (SBOM) and controls to block remote features that could tamper with or disrupt the service.

Auditable criteria vs marketing claims

The decisive difference is auditability. Marketing claims are opaque and unverified; CADA's framework is transparent and checkable.

Under Article 20, providers seeking recognition at levels 2 to 4 must undergo independent audits by an organisation that is independent, free of conflicts of interest, and competent in auditing cloud computing services. The audit yields a report and a "positive" or "negative" opinion on compliance with the Annex II criteria.

Article 22 would establish a central repository of recognised cloud computing services, maintained by the Commission and the national competent authorities and publicly available. A provider claiming sovereignty must be listed there at a specific assurance level; revocations of an audit opinion or of a recognition are also published and remain available for five years. This removes the "he-said, she-said" of sovereignty washing: a provider cannot simply claim sovereignty — it must prove it through documented, independently verified evidence.

What this means for you

For public-sector procurement officers, telling sovereignty washing from real sovereignty is central to managing risk and complying with the proposed CADA.

  1. Stop accepting marketing brochures. Do not rely on "sovereign cloud" labels. Only services recognised in the central repository (Article 22) at a specific Union assurance level would count as compliant.
  2. Conduct risk assessments. Article 29 requires Member States and Union entities to assess the sensitivity, criticality and magnitude of data and decide the appropriate level. Activities not contributing to public order require services recognised at level 1 (Article 30(2)); activities identified as contributing to public order (for example national security, defence, justice, law enforcement) require level 2, 3 or 4 (Article 30(3)).
  3. Verify audit reports. For levels 2 to 4, confirm a valid "positive" audit opinion and check the provider's current status in the central repository.
  4. Plan for migration. If you currently use a "tailored" offering, you may need to move to a recognised provider. Where a risk assessment requires migration, it must occur within a transition period not exceeding 12 months (Article 29(6)).
  5. Consider EuroCloud. The European public sector cloud federation (the "EuroCloud Federation," Article 34) would facilitate sharing of public-sector cloud and data-centre services among Union entities and public sector bodies, offering access to capacity without each body running a large procurement.

Common misconceptions

  • "Data residency equals sovereignty." Storing data in the EU is only one criterion of level 1. It does not stop third-country authorities accessing data via extraterritorial laws, nor prevent a parent company from disrupting the service. Real sovereignty requires control over infrastructure, personnel and legal jurisdiction.
  • "An EU subsidiary makes a provider sovereign." A local entity does not stop a global parent exercising control. The criteria for levels 2 to 4 require demonstrating that any third-country control cannot restrict the service, reach data, or disrupt continuity — and at level 4, third-country control is prohibited entirely.
  • "Sovereignty is only about national security." Levels 3 and 4 matter most for national security and defence, but level 1 is the minimum for public-sector activities not tied to public order — so even non-sensitive services must move away from sovereignty-washed offerings toward providers meeting the baseline criteria.
  • "Open-source software guarantees sovereignty." CADA promotes open source to reduce lock-in (Article 41), but open source alone does not guarantee sovereignty. The hosting environment, the people running it, and the hardware and software supply chain must still meet the assurance-level criteria.

Official sources

Related

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