Summary As proposed, the Cloud and AI Development Act (CADA) requires cloud computing service providers seeking Union assurance levels 2, 3, or 4 to maintain a documented migration plan for any software components provided, owned, or licensed by legal entities established in a third country. This obligation, found in Annex II, Sections 2.1(i)(ii), 3.1(i)(ii), and 4.1(i), ensures that if a foreign vendor fails or a third country imposes restrictions, the provider can transition to alternative solutions without disrupting service. The plan must be backed by tested switchover procedures, not just theoretical documentation. This requirement does not apply to Union assurance level 1, which relies on self-assessment.

Detail

The proposed Cloud and AI Development Act (CADA) establishes a sovereignty framework designed to mitigate risks arising from dependence on non-European cloud providers and third-country software supply chains. A critical component of this framework is the requirement for documented migration plans, which serve as a concrete safeguard against vendor lock-in and geopolitical leverage.

The Scope: Assurance Levels 2, 3, and 4

Under CADA, the obligation to maintain a documented migration plan applies specifically to cloud computing service providers (CSPs) seeking recognition for Union assurance levels 2, 3, and 4. These levels require independent third-party audits, unlike level 1, which is based on a conformity self-assessment.

The requirement is embedded in the cumulative criteria for each level in Annex II of the proposal. Specifically, providers must demonstrate that they have implemented and documented controls for software components provided, owned, and licensed by legal entities established in a third country.

Specific Requirements in Annex II

The proposal outlines nearly identical requirements for levels 2 and 3 regarding software supply chain resilience, with a heightened focus on "effective control" for level 4.

For Union Assurance Level 2: Annex II, Section 2.1(i)(ii) states that where software components are provided, owned, and licensed by a legal entity established in a third country, controls must be implemented and documented to:

  1. Block any remote features that could materially tamper with or disrupt a device, system, or software (including during updates).
  2. Ensure that security-relevant components from third-country software manufacturers are subject to source code audits.
  3. Have a documented migration plan in the event that the vendor fails or a third country imposes restrictions.

For Union Assurance Level 3: Annex II, Section 3.1(i)(ii) repeats these exact criteria. It requires that controls be implemented and documented to block remote tampering features and ensure source code audits for security-relevant components. Crucially, it mandates a documented migration plan in the event that the vendor fails or a third country imposes restrictions.

For Union Assurance Level 4: While Annex II, Section 4.1(i)(ii) for Level 4 focuses heavily on "effective control" over software componentsβ€”requiring proof that a third country does not hold or exercise effective control over the design, development, maintenance, and evolution of those componentsβ€”the underlying principle of supply chain resilience remains consistent. The text requires measures to retain effective control, demonstrating that a third country does not hold or exercise effective control over the technical evolution, maintenance priorities, security remediation, and long-term continuity of the component. While the explicit phrase "migration plan" appears in the context of levels 2 and 3, the Level 4 requirement to prove independence from third-country control effectively necessitates a viable path to continuity that does not rely on third-country goodwill, aligning with the migration logic of the lower tiers.

The Role of Audit Evidence

These criteria are not merely declarative; they must be verified by independent auditing organisations. Annex III (Audit Evidence for the Audit Procedure) provides guidance on how these criteria should be assessed. Under Audit Criterion I (Ensuring the transparency of the software supply chain), auditing organisations must request evidence that the provider has identified alternative software solutions, including open-source software.

Specifically, the provider must demonstrate:

  • A risk-based process for identifying and mitigating dependencies on external software manufacturers.
  • Evidence that they have identified one or more alternative software solutions.
  • Tests implemented and a switchover plan enabling migration to such alternative solutions.

This means the migration plan cannot be a theoretical document; it must be backed by technical validation and testing to prove its feasibility. The auditor must verify that the provider can actually execute the migration if the trigger event occurs.

Mitigating Foreign Software Dependency

The inclusion of these migration plan requirements reflects CADA's broader objective to reduce critical external dependencies. By forcing CSPs to map their software supply chains and prepare for vendor failure or geopolitical restriction, the regulation aims to prevent scenarios where a third country could leverage control over essential software components to disrupt European public services or critical infrastructure.

What this means for you

For CTOs, architects, and SMEs evaluating the practical impact of CADA, the migration plan requirement signals a shift from reactive compliance to proactive supply chain architecture.

1. Inventory and Mapping You must move beyond simple license tracking. You need a granular map of every software component in your stack that is owned or licensed by a third-country entity. This includes not just commercial off-the-shelf software, but also third-party libraries, frameworks, and proprietary tools integrated into your cloud services.

2. Documentation of Alternatives For each critical third-country component, you must identify viable alternatives. These could be open-source solutions, European alternatives, or in-house developed replacements. The proposal encourages the use of open source as a lever for sovereignty, so evaluating open-source substitutes will be a key part of this process.

3. Testing the Switchover A written plan is insufficient. Auditors will look for evidence of testing. You should conduct regular drills or simulations to verify that you can actually migrate away from a third-country vendor within an acceptable timeframe without significant service disruption. This includes testing data portability, configuration migration, and functional parity of the alternative solution.

4. Integration with SBOMs This requirement works in tandem with the Software Bill of Materials (SBOM) obligations. Your SBOM should clearly flag components that trigger the migration plan requirement, making it easier for auditors to verify compliance.

5. Strategic Procurement When negotiating with third-country vendors, consider including clauses that facilitate migration, such as data export capabilities and detailed technical documentation. This can reduce the friction and cost of executing your migration plan if needed.

Common misconceptions

"This applies to all cloud providers." No. The migration plan requirement is tied to Union assurance levels 2, 3, and 4. Providers offering only Union assurance level 1 are not subject to this specific audit criterion, as level 1 relies on self-assessment. However, public sector buyers may increasingly prefer higher assurance levels, indirectly pressuring all providers to adopt these practices.

"A theoretical plan is enough." No. The audit evidence requirements in Annex III explicitly call for tests and a switchover plan. Auditors will expect to see proof that the migration has been technically validated, not just documented on paper.

"This only applies to proprietary software." No. The requirement applies to any software component provided, owned, and licensed by a third-country entity. This includes proprietary software from major non-EU tech giants. However, open-source software is also scrutinized, particularly regarding its governance and potential for third-country control.

"Level 4 exempts you from planning." While Level 4 focuses on "effective control," the underlying goal is the same: resilience. If you cannot demonstrate effective control, you may not qualify for Level 4. The migration plan is a key tool for demonstrating that you are not unduly dependent on a third country's goodwill or legal framework.

Related

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