Summary As proposed in COM(2026) 502 final, the Cloud and AI Development Act (CADA) fundamentally shifts cloud strategy from a cost-performance model to a sovereignty-compliance imperative. CTOs must map hybrid and multi-cloud workloads to specific "Union assurance levels" based on risk assessments mandated by Article 29. For public sector bodies, Article 30 imposes strict procurement thresholds: Level 1 for general activities, and Levels 2–4 for activities contributing to public order. Crucially, Article 29(9) explicitly requires considering a multi-vendor or multi-cloud strategy to mitigate concentration risks. If a risk assessment triggers a migration, Article 29(6) mandates a transition period not exceeding 12 months. CTOs must now audit their entire support chain, personnel citizenship, and third-country control status to ensure their architecture can legally sustain these assurance levels.

Detail

The proposed Cloud and AI Development Act (CADA) introduces a rigorous sovereignty framework that requires CTOs and cloud architects to re-evaluate hybrid and multi-cloud designs not just for technical resilience, but for legal and operational independence from third-country jurisdictions. Unlike the GDPR (which focuses on data privacy) or NIS2 (which focuses on cybersecurity), CADA targets the "operational autonomy" of the cloud stack itself. The core challenge for a CTO is to demonstrate that the infrastructure, personnel, and control mechanisms supporting a workload are free from extraterritorial interference that could compromise public order.

The Foundation: Risk Assessment under Article 29

The assessment process begins with the mandatory risk assessments outlined in Article 29. Member States and Union entities must carry out these assessments to identify public sector activities that contribute to the preservation of public order. This scope is broad, covering sectors listed in Annex I or II of Directive (EU) 2022/2555 (NIS2), as well as national security, internal security, external border management, defence, justice, and law enforcement.

The outcome of this assessment is the determination of the appropriate Union assurance level (Level 2, 3, or 4) for specific workloads. For activities not identified as contributing to public order, the baseline requirement is Union assurance Level 1. However, for those identified as public-order-relevant, the risk assessment must determine whether Level 2, 3, or 4 is proportionate and necessary. This determination is not static; it must consider the sensitivity, criticality, and magnitude of the data processed, as well as the risk of unlawful access by a third country or service disruption.

The Multi-Cloud Mandate: Article 29(9)

A pivotal provision for architects designing hybrid or multi-cloud environments is Article 29(9). This paragraph explicitly instructs Member States and Union entities to "consider whether a multi-vendor or multi-cloud strategy is appropriate as part of their procurement of cloud computing services."

This is not merely a suggestion for redundancy; it is a sovereignty risk mitigation tool. The provision acknowledges that reliance on a single provider—even one established in the Union—creates a concentration risk that could undermine operational autonomy. For a CTO, this means the assessment must go beyond technical failover. You must evaluate whether a multi-cloud strategy effectively diversifies sovereignty risk. If a primary provider is subject to third-country control laws that could compromise service continuity, the multi-cloud architecture must ensure that failover workloads or distributed components remain within compliant environments that meet the required assurance level.

The assessment under Article 29(9) requires identifying "operational, regulatory or resilience-related circumstances that would support the adoption of a multi-vendor or multi-cloud strategy." In practice, this means documenting scenarios where a single vendor's failure (due to legal coercion, sanctions, or technical disruption) would threaten public order, and demonstrating how a multi-cloud approach mitigates that specific threat.

Procurement Constraints: Article 30

Once workloads are mapped to assurance levels via the Article 29 risk assessment, Article 30 dictates the procurement rules that CTOs must enforce. This article creates a hard constraint on the cloud stack:

  • General Activities: For public sector bodies whose activities have not been identified as contributing to public order, Article 30(2) requires the use of cloud services recognised as having Union assurance level 1.
  • Public Order Activities: For contracting authorities whose activities have been identified as contributing to public order under Article 29(1), Article 30(3) mandates that they "shall only procure cloud computing services that have been recognised as having a Union assurance level 2, 3 or 4."

This distinction is critical for hybrid architectures. A CTO cannot simply host a "public order" workload on a Level 1 compliant service (e.g., a standard EU-based cloud with US ownership) even if the data stays in the EU. The higher levels (2–4) impose stricter criteria, including:

  • Personnel: Union citizenship requirements (conditional at Level 2 if the public body requires it; mandatory at Levels 3 and 4).
  • Infrastructure: Exclusive location within the Union.
  • Control: No third-country control (unless a specific derogation under Article 18 applies for Level 3).
  • Support: Technical and operational support must be initiated and performed exclusively within the Union.

Migration Planning: The 12-Month Deadline

A significant operational challenge for CTOs managing legacy hybrid environments is the migration timeline. Article 29(6) states: "Where the risk assessment requires the migration to another cloud computing service, the Member State or Union entity shall migrate within a reasonable transition period that shall not exceed 12 months."

This deadline forces CTOs to plan migration paths well in advance of any compliance trigger. The assessment must account for "technical feasibility, continuity of service and data portability requirements." This implies that CTOs must evaluate current vendor lock-in risks immediately. If a provider's assurance status changes (e.g., a loss of recognition due to a change in third-country control), or if a new risk assessment reclassifies a workload as public-order-relevant, the CTO has a maximum of 12 months to move that workload to a compliant provider.

This constraint necessitates that multi-cloud architectures be designed with "data portability" as a primary feature. Contracts must include clauses facilitating migration, and technical architectures must support the rapid shifting of workloads between compliant providers without data loss or service interruption.

Private Sector and Critical Infrastructure

While Article 30 specifically binds contracting authorities and Union entities, Article 31 extends the logic to the private sector. Entities in sectors listed in Annex I of the NIS2 Directive (e.g., energy, transport, banking, health) may carry out similar impact assessments. Furthermore, the Commission may adopt delegated acts requiring impact assessments for private entities in sectors of "high criticality."

Even if not strictly mandatory for all private firms, the market reality is that public sector procurement rules will ripple through the supply chain. Private cloud providers seeking to serve public bodies must meet the Union assurance levels. Consequently, CTOs in the private sector must anticipate that their own supply chains will be audited against these standards, and their ability to serve critical infrastructure will depend on their compliance with the CADA sovereignty framework.

What this means for you

For CTOs and cloud architects, CADA transforms cloud strategy from a purely technical or financial optimization problem into a sovereignty-compliance imperative. Your assessment workflow must now include a dedicated "sovereignty layer" that runs parallel to your security and cost models.

  1. Inventory and Map Workloads: Begin by creating a comprehensive inventory of all cloud workloads. Classify each based on its sensitivity and contribution to public order (for public bodies) or criticality (for private entities). Use the Article 29 framework to assign a required Union assurance level (1–4) to each workload. Do not assume all workloads require Level 4; the risk assessment determines the proportionate level.
  2. Audit Providers Against Annex II: Evaluate your current cloud providers against the specific criteria in Annex II. Check for:
    • Third-country control: Is the provider subject to control by a non-EU entity? If so, does the Commission have an implementing act under Article 18 recognizing that country for Level 3?
    • Personnel: Are the personnel supporting the service Union citizens? (Note: Level 2 is conditional; Levels 3 and 4 are mandatory).
    • Support Location: Is technical support performed exclusively within the Union?
    • Data Residency: Is data stored and processed exclusively in the Union?
  3. Design for Multi-Cloud Sovereignty: Leverage Article 29(9) to justify multi-cloud investments. Design your architecture so that critical workloads are distributed across providers that meet different assurance levels or geographic requirements. This reduces the risk of a single point of sovereignty failure. Ensure your multi-cloud strategy includes legal and technical mechanisms to prevent data leakage to non-compliant providers during failover.
  4. Plan Migrations Early: With the 12-month maximum in Article 29(6), you cannot wait for a compliance deadline to move workloads. Start planning data portability and application refactoring now. Ensure your contracts include exit clauses that facilitate migration and that your technical architecture supports rapid shifting of workloads between compliant providers.
  5. Engage with Procurement: Work closely with your procurement teams to ensure that tender documents reflect the required assurance levels. Use the Union added value criteria in Article 32 to favor providers that strengthen the European digital supply chain.

Common misconceptions

"Multi-cloud automatically ensures sovereignty." No. A multi-cloud strategy only enhances sovereignty if the alternative providers also meet the required Union assurance levels. If all your providers are subject to third-country control laws (e.g., US CLOUD Act jurisdiction), your multi-cloud architecture does not mitigate sovereignty risk. The diversification must be within the compliant set.

"Data residency is enough for higher assurance levels." No. Union assurance levels 2–4 require more than just data staying in the EU. They require personnel to be Union citizens (mandatory for Levels 3 and 4), support to be performed within the Union, and no third-country control over the provider. A provider with EU data centers but US-based support and ownership may not qualify for Levels 2–4.

"Private companies are exempt from these assessments." While Article 30's procurement mandates apply to public bodies, Article 31 allows for impact assessments for private entities in critical sectors. Furthermore, public sector requirements will ripple through the supply chain, forcing private providers to comply to win contracts. Private CTOs in critical sectors should anticipate mandatory impact assessments via delegated acts.

"Migration can be delayed indefinitely." Article 29(6) sets a strict 12-month maximum for migration once a risk assessment requires it. CTOs must treat this as a hard deadline for operational continuity. "Reasonable transition period" is capped at one year; there is no provision for indefinite extensions.

Official sources

Related

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