Summary Under the proposed Cloud and AI Development Act (CADA), "sovereignty by design" is not a marketing label but a mandatory architectural baseline for public sector cloud procurement. It would require providers to embed legal, technical and organisational controls — data localisation, personnel requirements, supply-chain transparency — directly into their service from the outset, rather than applying post-hoc "sovereign wrappers." Providers would have to build toward the specific, cumulative criteria in Annex II to achieve recognised Union assurance levels under Article 16.

Detail

"Sovereignty by design" under CADA shifts the burden of proof from contractual promises to verifiable architectural facts. The proposal would establish a Union cloud computing sovereignty framework of four assurance levels (Article 16(1)); to be recognised at a given level, a provider must demonstrate compliance with the cumulative criteria in Annex II. The framework is designed to mitigate risks of third-country control, unauthorised data access and service disruption, keeping the EU's critical digital infrastructure under operational control.

Building control into architecture, not just contracts

Historically, many providers have offered "sovereign" options by adding contractual clauses or limited technical restrictions (e.g. data residency) to existing global platforms. For higher assurance levels, CADA would reject this "bolt-on" approach and demand that sovereignty be intrinsic to the design.

For Union assurance level 1 (Annex II, Section 1), the baseline includes:

  • Establishment: the provider is established in the Union.
  • Infrastructure and assets: infrastructure and assets (including subcontractors' involved in the service) are located in the Union, unless the public sector body explicitly requires otherwise.
  • Data localisation: customer data, including metadata and telemetry, remains exclusively within the Union (unless explicitly required otherwise).
  • Vulnerability reporting: where the provider is subject to third-country control, it guarantees there are no laws in that country requiring it to report software vulnerabilities to foreign authorities before they are known to have been exploited (Annex II, Section 1.1(g)).

As the level rises, the architectural demands tighten. Union assurance level 2 (Annex II, Section 2) introduces independent audits and requires that:

  • Personnel and assets: infrastructure, assets and personnel (including subcontractors') are located in the Union.
  • AI training data: data generated by using the service is not used to train or fine-tune any AI system operated by a third country, and is not transferred outside the Union.
  • Supply-chain transparency: the provider maintains a complete, up-to-date Software Bill of Materials (SBOM) and documents dependencies, and implements controls to block remote features that could tamper with or disrupt devices or software.
  • Legal separation: where the provider operates globally and maintains a subsidiary in a third country, it ensures effective legal, technical and organisational separation between the Union parent company and that subsidiary (Annex II, Section 2.1(k)).

Union assurance levels 3 and 4 (Annex II, Sections 3 and 4) impose stricter controls still — notably Union-citizenship requirements for personnel involved in the service, and cybersecurity certification at "substantial" (Level 3) or "high" (Level 4) under a European cybersecurity certification scheme. Crucially, for Levels 3 and 4 the provider and its subcontractors must not be subject to third-country control (Annex II, Sections 3.1(g) and 4.1(g)). The only exception is a narrow Level 3 derogation for "associated third countries" recognised by the Commission under Article 18 (which requires, among other things, a GDPR adequacy decision and guarantees against control, service disruption and coerced sanctions).

The role of auditing and recognition

Sovereignty by design is not self-certified at the higher levels. Article 17 would establish a recognition mechanism: providers apply to the national competent authority of establishment. For Union assurance level 1, a provider may self-assess and issue an EU statement of conformity (Article 19). For Levels 2, 3 and 4, the provider must undergo independent third-party audits (Article 20).

These audits are rigorous: auditing organisations verify the Annex II criteria using the audit evidence listed in Annex III, which can include examining data flows, corporate governance and access controls to confirm no foreign entity can exert control over operations or data. The provider must obtain a "positive" audit opinion before recognition at the level.

Contrast with "sovereign wrappers"

The proposal explicitly distinguishes genuine sovereignty from superficial compliance. Recital 48 notes that tailored "sovereign" versions launched by providers "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." CADA's framework would require the architecture itself to prevent these risks: storing data in an EU data centre is insufficient if the third-country parent can access it remotely or if the software stack contains components controlled by foreign entities. Sovereignty by design requires technical measures such as keeping technical and operational support initiated and performed exclusively within the Union (Annex II, Section 2.1(h)).

What this means for you

For CTOs, architects and SMEs, the shift to sovereignty by design would change procurement and architecture strategy.

  1. Move beyond data residency. Residency alone is no longer a sufficient proxy for sovereignty. Evaluate the whole supply chain — corporate structure, origin of software components, and location of support staff.
  2. Demand transparency. Under Article 23, recognised providers must notify the auditing organisation and competent authority of any material change that could affect their recognition. As a buyer, require access to audit reports and SBOMs to verify Annex II compliance.
  3. Plan for migration. If your current provider relies on "sovereign wrappers" without underlying architectural sovereignty, it may not qualify for Levels 2–4. Article 29 would require public sector bodies to conduct risk assessments to set the appropriate level, and Article 29(6) would allow a transition period not exceeding 12 months for any migration.
  4. Evaluate SME paths. SMEs entering the public sector market should weigh the cost of recognition. Article 17(3) would let an SME's EU statement of conformity for Level 1 be directly and automatically recognised across Member States, but Levels 2–4 require significant investment in audits and architecture.

Common misconceptions

  • "Sovereign cloud means data stays in the EU." Data localisation is one component (Annex II, Section 1.1(c)), but the framework also covers personnel requirements, supply-chain transparency and freedom from third-country control.
  • "US providers can never be sovereign." CADA would not automatically exclude third-country providers. Article 18 would let the Commission recognise certain "associated third countries" as providing sufficient assurances for Union assurance level 3, subject to strict cumulative criteria including a GDPR adequacy decision and guarantees against unauthorised access or service disruption — though meeting these is challenging for providers subject to laws like the US CLOUD Act.
  • "Sovereignty is just about cybersecurity." Cybersecurity is necessary but not sufficient. The proposal distinguishes technical cybersecurity (addressed by the Cybersecurity Act and EUCS) from sovereignty, which includes operational autonomy and protection against political or economic coercion.

Official sources

Related

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