Summary Under the proposed Cloud and AI Development Act (CADA), a risk assessment determines the required "Union assurance level" for public sector cloud services based on their contribution to public order. If the assessment concludes that a service must operate at a higher assurance level (e.g., Level 2, 3, or 4) than the current provider offers, the contracting authority is legally obliged to migrate. As proposed in Article 29(6), this migration must occur within a "reasonable transition period" that strictly cannot exceed 12 months, balancing security needs with technical feasibility and service continuity.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, introduces a mandatory risk assessment framework to ensure that public sector bodies and Union entities use cloud computing services that match the sensitivity of their activities. This mechanism is central to the Act's goal of reducing dependence on third-country providers and safeguarding public order. Unlike static compliance checks, this framework creates a dynamic obligation to migrate services when the risk profile of an activity changes or when a more accurate assessment reveals a gap between current capabilities and required sovereignty levels.

The Trigger: Article 29 Risk Assessments

The process begins with Article 29, which obliges Member States and Union entities to carry out risk assessments. These assessments are not one-off events; they must be conducted by the date of entry into force plus one year, and then repeated every two years, or "whenever necessary."

The core purpose of the assessment, outlined in Article 29(1), is twofold:

  1. Identify activities: Determine which public sector activities using cloud services contribute to the preservation of public order. This includes sectors listed in Annex I or II of the NIS2 Directive, as well as national security, internal security, border management, defence, justice, and law enforcement, including the prevention, investigation, detection and prosecution of criminal offence.
  2. Determine the Assurance Level: Decide which Union assurance level (Level 2, 3, or 4) is appropriate for these identified activities.

The assessment must consider specific factors listed in Article 29(2), including:

  • The sensitivity, criticality, and magnitude of non-personal and personal data processed, including the potential impact on public order.
  • The risk of unlawful access by a third country or a legal entity established in a third country.
  • The risk of service disruption and its consequent impact on public order.

When Migration Becomes Mandatory

A migration decision is triggered when there is a mismatch between the current cloud service's recognized assurance level and the level determined by the risk assessment. This is a direct consequence of the procurement obligations in Article 30.

  • Baseline Requirement: Under Article 30(2), public sector bodies whose activities are not identified as contributing to public order must use services recognized as having at least Union assurance level 1.
  • Higher Assurance Requirement: Under Article 30(3), if a risk assessment under Article 29(1) identifies that a contracting authority's activities do contribute to the preservation of public order, they must only procure services recognized as having Union assurance level 2, 3, or 4.

If an authority is currently using a service that only meets Level 1 (or no recognized level) for an activity now deemed critical to public order, the risk assessment creates a legal imperative to migrate to a provider that holds the appropriate higher-level recognition. The migration is not optional; it is a compliance requirement to align the infrastructure with the sovereignty framework.

The 12-Month Transition Cap

Recognizing that cloud migration is complex and that abrupt changes could disrupt essential public services, CADA provides a specific, bounded timeframe for this transition. 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, taking into account technical feasibility, continuity of service and data portability requirements applicable to such migration."

This clause is critical for CTOs, architects, and legal counsel. It establishes a hard ceiling of 12 months for the migration process once the risk assessment mandates a change. However, it is not a fixed 12-month deadline for all cases; the period must be "reasonable" and tailored to three specific constraints:

  • Technical Feasibility: The complexity of moving applications, data, and dependencies.
  • Continuity of Service: Ensuring that critical public services do not suffer downtime or degradation during the transition.
  • Data Portability: Adhering to existing data portability requirements (such as those in the Data Act) to ensure data can be moved securely and completely without loss.

The phrase "shall not exceed 12 months" creates a statutory maximum. No justification based on complexity or cost can legally extend the transition period beyond this limit. This forces authorities to prioritize migration planning immediately upon the conclusion of a risk assessment that identifies a gap.

Strategic Considerations: Multi-Cloud and Vendor Lock-in

Article 29(9) adds another layer to the decision-making process. When conducting these risk assessments, Member States and Union entities must consider whether a multi-vendor or multi-cloud strategy is appropriate as part of their procurement of cloud computing services.

This means the risk assessment isn't just about moving from Provider A to Provider B; it is an opportunity to evaluate if distributing workloads across multiple sovereign providers would better mitigate the risks of dependency and disruption. By mandating this consideration, CADA encourages authorities to avoid creating new single points of failure while migrating to higher assurance levels.

What this means for you

For CTOs, architects, and SMEs in the public sector or those serving public sector clients, the CADA risk assessment framework changes cloud procurement from a purely technical or cost-driven decision to a compliance-driven lifecycle management process.

1. Audit Your Current Stack Against Assurance Levels You must map your current cloud services to the CADA Union assurance levels. If you are serving a public sector body in a "public order" sector (e.g., healthcare, energy, justice), you need to verify if your service holds the necessary Level 2, 3, or 4 recognition. If you do not, and the client's risk assessment determines your service is insufficient, you face a potential churn risk within 12 months. Providers should proactively seek recognition at higher levels to remain eligible for these contracts.

2. Plan for the 12-Month Horizon If you are a public sector IT leader, start your risk assessments immediately upon the Regulation's entry into application. Identify gaps between your current providers' assurance levels and your required levels. Begin drafting migration plans that respect the 12-month maximum. This includes:

  • Assessing data portability readiness and ensuring contracts allow for seamless data extraction.
  • Evaluating the technical feasibility of moving legacy applications to sovereign alternatives.
  • Engaging with new providers who hold the required Union assurance recognitions well in advance of the deadline.

3. Design for Portability and Multi-Cloud Architects should prioritize cloud architectures that minimize vendor lock-in. Since CADA encourages multi-cloud strategies to reduce dependency, designing applications to be portable across different sovereign cloud providers will make future migrations faster and cheaper, helping you stay well within the 12-month transition window. The "reasonable" period within the 12-month cap is more likely to be achieved if the architecture is already decoupled from proprietary vendor-specific tools.

4. Monitor for "Whenever Necessary" Triggers The risk assessment is not static. It must be updated every two years or "whenever necessary." Significant changes in the threat landscape, new third-country laws affecting data access, or changes in the criticality of your data could trigger a new assessment and, consequently, a new migration mandate. Build governance processes to review these triggers regularly so you are not caught off guard by a sudden requirement to migrate.

Common misconceptions

Misconception 1: Migration only happens if a provider is banned. Reality: Migration is triggered by a mismatch in assurance levels, not just by a provider being banned. A provider may be perfectly compliant and legal, but if it only offers Level 1 assurance and your activity requires Level 3 due to its public order relevance, you must still migrate. The trigger is the risk assessment outcome, not a regulatory ban.

Misconception 2: The 12-month period is a fixed deadline for all migrations. Reality: Article 29(6) sets a maximum of 12 months. The actual period must be "reasonable" based on technical feasibility and service continuity. Some migrations may take 6 months; others might take the full 12 if they involve highly complex legacy systems. However, no justification can extend it beyond 12 months. The "reasonable" period is a variable within a fixed cap, not a fixed duration itself.

Misconception 3: Only large government bodies need to worry about this. Reality: The risk assessment applies to all "Union entities" and "public sector bodies" as defined in the Act. This includes a wide range of organizations, from national ministries to local municipal authorities and specific agencies. Any cloud service provider working with these entities must understand the assurance levels required by their clients' risk assessments.

Misconception 4: Data protection laws (like GDPR) cover this. Reality: While GDPR protects personal data, it does not address "sovereignty" or "operational autonomy" in the same way. CADA explicitly states that it complements data protection frameworks by addressing risks like third-country access to non-personal data, service disruption, and the strategic importance of infrastructure, which are outside the scope of GDPR alone. The migration trigger here is about public order and sovereignty, not just data privacy.

Official sources

Related

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