Summary A private cloud provides dedicated infrastructure, but it does not automatically guarantee data sovereignty or protection from foreign laws. Under the proposed Cloud and AI Development Act (CADA), "sovereign cloud" is a legal status defined by Union assurance levels (Article 16, as proposed), with criteria on control, personnel, data localisation and third-country law exposure set out in Annex II. A private cloud hosted by a non-EU-controlled entity, or one exposed to extraterritorial laws, may offer isolation but can still fail the sovereignty requirements that CADA would attach to public-sector procurement.

Detail

The debate between private cloud and sovereign cloud often confuses technical architecture with legal sovereignty. A private cloud is an infrastructure model where resources are provisioned for exclusive use by a single organisation. It may be owned, managed and operated by the organisation, a third party, or some combination, and it may exist on or off premises. Its value proposition is isolation and dedicated resources, which can improve security and performance. But the physical location of the servers, and the exclusivity of access, do not dictate who has legal jurisdiction over the data or the provider.

A sovereign cloud, by contrast, is a regulatory concept. As proposed in CADA, it would be defined by a Union cloud computing sovereignty framework comprising four Union assurance levels (Article 16). The framework is designed to mitigate risks from dependence on non-European providers, such as the extraterritorial application of third-country laws (for example the US CLOUD Act) and potential service disruption.

Ownership and isolation are not sovereignty

The critical point is that ownership or isolation does not equal sovereignty. A private cloud could be operated by a European subsidiary of a non-EU hyperscaler. Even if the infrastructure is physically in the EU and dedicated to one client, the parent group may still be subject to foreign laws that can compel data disclosure. Under CADA, such a service would not necessarily qualify for the higher assurance levels, because the provider is subject to the control of a third country.

CADA's framework (Article 16) sets cumulative criteria for each level in Annex II. For Union assurance level 1, the provider must be established in the Union and customer data — including metadata and telemetry — must remain exclusively within the Union unless the public sector body explicitly requires otherwise (Annex II, §1.1). Level 1 also requires full transparency over subcontractors and, where the provider is third-country-controlled, a guarantee that no laws in that country require it to report software vulnerabilities to that country's authorities before those vulnerabilities are known to have been exploited (Annex II, §1.1(g)).

Higher levels impose stricter controls. Union assurance level 3 requires that the provider and its subcontractors are not subject to the control of a third country or a legal entity established in a third country, with a single, narrow exception: providers from an "associated third country" recognised by the Commission may be audited for level 3 (Article 18). Union assurance level 4 applies the same prohibition with no derogation at all — the Article 18 route does not extend to level 4 (Annex II, §4.1(g)). Levels 3 and 4 also require that infrastructure, assets and personnel are located in the Union and that personnel involved in the service are Union citizens; at level 4, customer data identified as sensitive through a risk assessment must remain exclusively within the Union (Annex II, §4.1(c)).

Why a private cloud does not automatically qualify

A private cloud deployment does not by itself satisfy these criteria. If an organisation builds a private cloud using hardware and software from a third-country vendor, the service must still demonstrate compliance with the relevant Union assurance level. For example, at Union assurance level 2 the provider must implement controls to block remote features that could materially tamper with or disrupt systems, and ensure that security-relevant components from third-country software manufacturers are subject to source-code audits, with a documented migration plan (Annex II, §2.1(i)).

So a "private" cloud is an architectural choice, while a "sovereign" cloud is a compliance status. You can have a private cloud that is not sovereign (if it relies on non-compliant third-country technology or a third-country-controlled provider), and a sovereign cloud that is not private (a multi-tenant public-cloud service that meets the strict assurance criteria).

Procurement implications

For public-sector bodies the distinction would be legally binding. Article 30 would require Union entities and public sector bodies whose activities are not identified as contributing to the preservation of public order to use services recognised at Union assurance level 1 (Article 30(2)). For activities that are identified as contributing to public order — sectors under Annex I or II of the NIS2 Directive, or national security, internal security, external border management, defence, justice or law enforcement — authorities must only procure services recognised at levels 2, 3 or 4 (Article 30(3)).

Simply deploying a private cloud would not exempt a public authority from these rules. The service must be formally recognised (Article 17) as meeting the specific level required by the risk assessment (Article 29).

What this means for you

For CTOs and architects, the shift from "private vs public" to "sovereign vs non-sovereign" requires a different vendor-evaluation lens.

  1. Audit your supply chain. If you use a private cloud hosted by a third party, verify its Union assurance level status. A private cloud run by a third-country-controlled provider — even with data in Europe — may not meet level 2 or 3 because of third-country control.
  2. Software bill of materials (SBOM). To reach levels 2–4 you would need a complete, up-to-date SBOM and controls over third-country software components (Annex II, §2.1(i)) — even where the infrastructure is privately dedicated.
  3. Align with the risk assessment. Public-sector bodies must conduct risk assessments (Article 29) to determine the required level. For sensitive data or public-order activities, a standard private-cloud offering may not suffice; you would need a provider with formal recognition at level 3 or 4.
  4. Contractual controls. Ensure contracts prevent the provider from using your data to train or fine-tune AI operated by a third country (Annex II, §2.1(f)) and require measures to prevent third-country access to customer data (Annex II, §2.1(g)).

Common misconceptions

  • "Private cloud means my data is safe from foreign laws." Not necessarily. If your private-cloud provider is controlled by a group subject to foreign laws (for example the US CLOUD Act), that law may still reach the data regardless of where the servers sit. Sovereignty under CADA turns on the legal control of the provider, not only physical location.

  • "Sovereign cloud means the infrastructure must be owned by an EU government." Incorrect. Sovereign status refers to the assurance level of the service — criteria such as Union citizenship of personnel, data localisation and freedom from third-country control. A private European company can provide a sovereign service if it meets the Annex II criteria.

  • "I don't need to worry about this if I host on premises." Misleading. On-premises hosting gives physical control, but CADA's procurement rules for public-sector bodies (Article 30) require recognised assurance levels. If you outsource management of on-premises infrastructure to a third party, that provider must still meet the relevant criteria, and the software and hardware used must comply with the supply-chain transparency requirements of the level you claim.

  • "Level 1 is the same as level 4." Incorrect. The levels are cumulative and increasingly strict. Level 1 allows a third-country-controlled provider to qualify if specific controls are in place; level 4 prohibits third-country control entirely (with no Article 18 derogation), requires a "high"-level cybersecurity certificate, and requires sensitive data identified through a risk assessment to remain exclusively in the Union (Annex II, §4.1).

Related

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