How to scope workloads under CADA's sovereignty rules: A guide for CTOs

Summary Under the proposed Cloud and AI Development Act (CADA), scoping workloads is a mandatory two-step legal and technical process. First, Article 29 requires Member States and Union entities to conduct risk assessments to identify which public sector activities contribute to the preservation of "public order." Second, Article 30 translates these findings into binding procurement rules: activities not linked to public order require a minimum Union assurance level 1, while those linked to public order (e.g., defence, justice, NIS2 sectors) must procure services at level 2, 3, or 4. Crucially, Article 29(9) mandates that authorities consider multi-vendor or multi-cloud strategies during this scoping phase to mitigate dependency risks. For CTOs, this means every workload must be inventoried, classified by data sensitivity and public-order relevance, and mapped to the correct assurance tier before procurement begins.

Detail

The proposed CADA (COM(2026) 502 final) introduces a sovereignty framework that fundamentally changes how public sector bodies select cloud providers. Unlike previous regulations that focused primarily on data protection or cybersecurity, CADA targets the structural resilience of the cloud ecosystem against third-country control. The mechanism for applying these rules is not a blanket mandate for all workloads to reach the highest security tier; rather, it is a risk-based scoping exercise defined in Article 29 and enforced through Article 30.

The Legal Engine: Article 29 and Article 30

The scoping process is the bridge between legal risk assessment and technical procurement.

Article 29: The Risk Assessment Obligation Article 29 imposes a duty on Member States and Union entities to carry out risk assessments. These assessments must be completed within one year of the regulation's entry into force and updated every two years, or whenever necessary. The primary objective is twofold:

Identification: Identify public sector activities that use cloud computing services and contribute to the preservation of public order. The text explicitly lists sectors falling under 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 (including the prevention, investigation, detection, and prosecution of criminal offences).
Classification: Determine which Union assurance level (2, 3, or 4) is appropriate for these identified activities based on their specific risk profile.

When conducting these assessments, Article 29(2) requires authorities to consider four specific dimensions:

Data Sensitivity and Criticality: The sensitivity, criticality, and magnitude of non-personal data processed, including the potential impact on public order.
Personal Data Risks: The nature, scope, context, and purpose of processing personal data, alongside the risk to the rights and freedoms of data subjects.
Third-Country Access: The risk and consequent impact on public order of unlawful access to such data by a third country or a legal entity established in a third country.
Service Continuity: The risk and consequent impact on public order of possible service disruption.

Article 29(9) and Multi-Cloud Strategy A critical, often overlooked element of scoping is Article 29(9). This provision explicitly states that in their risk assessments, Member States and Union entities "shall 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 resilience; it is a statutory requirement to evaluate whether relying on a single provider creates an unacceptable concentration risk for public-order-relevant activities.

Article 30: The Procurement Floor Once the risk assessment under Article 29 is complete, Article 30 dictates the procurement outcome. This article applies to contracting authorities procuring cloud computing services for their exclusive use.

The Baseline (Level 1): Under Article 30(2), Union entities and public sector bodies whose activities have not been identified as contributing to the preservation of public order must use cloud computing services recognised as having at least Union assurance level 1.
The Elevated Requirement (Levels 2–4): Under Article 30(3), contracting authorities whose activities have been identified as contributing to public order (e.g., defence, justice, critical infrastructure) "shall only procure and use services that have been recognised as offering Union assurance levels 2, 3, or 4."

A Practical Framework for Scoping Workloads

For CTOs, architects, and compliance officers, "scoping" translates into a rigorous inventory and classification exercise. This is not a one-time compliance checkbox but a continuous architectural discipline that must precede any procurement decision.

Step 1: Comprehensive Inventory of Cloud-Dependent Workloads

The first step is to map every application, data repository, AI system, and infrastructure component currently hosted in the cloud or planned for migration. This inventory must capture:

Workload Type: Is it IaaS, PaaS, SaaS, or a managed AI service?
Data Profile: What data is processed? (e.g., personal data, operational technology data, classified information, telemetry).
User Base: Who accesses the service? (e.g., general public, civil servants, law enforcement, critical infrastructure operators).
Business Process: What specific public service or function does this workload enable?

Step 2: Classify by Public-Order Contribution

Using the criteria in Article 29(1), determine if the workload supports activities that preserve public order. This is the binary switch that triggers the elevated procurement requirements of Article 30(3).

Non-Public-Order Activities: Standard administrative tasks, general public information portals, or non-critical internal tools. These fall under the baseline Union assurance level 1 requirement.
Public-Order Activities: Workloads supporting NIS2-listed sectors, national security, defence, justice, or law enforcement. These trigger the mandatory requirement for Union assurance levels 2, 3, or 4.

Step 3: Assess Data Sensitivity and Criticality

For workloads identified as contributing to public order, you must drill down to determine the specific assurance level (2, 3, or 4). Article 29(2) guides this by asking:

Sensitivity: Does the workload process special categories of personal data, state secrets, or classified information?
Criticality: Would a disruption to this service cause significant harm to public order, national security, or the rights of citizens?
Magnitude: What is the scale of the data and the number of affected citizens?

The Commission is empowered to specify the methodology and templates for these assessments via implementing acts under Article 29(3). Until these are published, architects should align with existing national classification standards for data sensitivity (e.g., TLP levels, national security classifications) and map them to the CADA assurance levels.

Step 4: Evaluate Multi-Cloud and Multi-Vendor Strategies

Article 29(9) mandates that the risk assessment explicitly considers whether a multi-vendor or multi-cloud strategy is appropriate. Scoping should not result in a single point of failure. If a workload is critical (Level 3 or 4), the architecture must evaluate:

Active-Active or Active-Passive Multi-Cloud: Distributing load across providers with different assurance levels or jurisdictions to mitigate single-provider risk.
Vendor Diversification: Using different providers for different tiers of assurance to avoid concentration risk.
Exit Strategies: Ensuring that workloads can be migrated if a provider's assurance status changes or is revoked.

What This Means for You

For CTOs and architects, the introduction of CADA's sovereignty framework means that technical architecture decisions are now directly tied to legal risk assessments. You can no longer select cloud providers based solely on cost, performance, or feature set.

Collaborate with Legal and Risk Teams: You need the output of the Article 29 risk assessment to know which assurance level applies to your workload. If the legal team classifies a system as "public order relevant," you must architect for Level 2, 3, or 4.
Audit Your Current Stack: Review your current cloud contracts. If you are a public sector body, do your current providers offer recognised Union assurance levels? If not, you face a migration risk. Article 29(6) notes that migration must occur within a reasonable transition period, not exceeding 12 months, taking into account technical feasibility, continuity of service, and data portability requirements.
Design for Portability: To comply with the potential need to switch providers (especially if a provider loses recognition), ensure your workloads are built on open standards and use abstraction layers that facilitate switching. This aligns with the broader EU goal of reducing vendor lock-in.
Monitor Provider Status: Once a provider is recognised, they must report material changes under Article 23. Architects must monitor the central repository of recognised services under Article 22 to ensure their providers maintain their assurance status. If a provider's status is revoked, you may need to migrate workloads within the 12-month window.

Common Misconceptions

"Only defence and intelligence workloads need high assurance levels." While defence and law enforcement are explicitly mentioned in Article 29(1), the scope is broader. Any activity in sectors listed under NIS2 (e.g., energy, transport, health, digital infrastructure) that contributes to public order may require Level 2, 3, or 4. Even non-critical public services require at least Level 1.

"Multi-cloud means using two providers for the same workload at all times." Article 29(9) requires considering multi-cloud strategies, but this does not mandate active-active redundancy for every workload. It is a risk mitigation measure. For lower-risk workloads, a single provider with Level 1 may suffice. For critical workloads, multi-cloud might mean having a warm standby with a different provider or using different providers for different data tiers.

"We can ignore this until the regulation is fully in force." The risk assessments under Article 29 must be carried out within one year of the regulation's entry into force. Scoping is a prerequisite for procurement. Delaying this process will result in non-compliant contracts and potential migration crises later.

"Private sector entities are exempt from scoping." While Article 30 applies to public procurement, Article 31 allows private sector entities in sectors listed in Annex I of NIS2 to carry out similar impact assessments. Furthermore, public procurement requirements often trickle down to private suppliers through contractual obligations. If you supply cloud services to the public sector, you will need to demonstrate compliance with the relevant assurance levels.

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

How to scope workloads under CADA's sovereignty rules