Summary Under the proposed Cloud and AI Development Act (CADA), achieving Union assurance level 4 requires that no third country or legal entity established in a third country holds or exercises "effective control" over the design, development, maintenance, and evolution of critical software components. As proposed in Annex II, Section 4.1(i)(ii), this definition extends beyond formal equity ownership to include the ability to "materially influence the technical evolution, maintenance priorities, security remediation, and long-term continuity of the component." For CTOs and architects, this means you must prove that strategic decisions regarding your software supply chain cannot be overridden by foreign jurisdictions, even if the code is open-source or the vendor is technically independent.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, introduces a rigorous sovereignty framework designed to mitigate risks associated with dependence on non-European cloud and AI providers. Central to this framework are four "Union assurance levels," with Level 4 representing the highest tier of sovereignty. This tier is intended for the most critical public sector activities where data confidentiality, operational autonomy, and the prevention of harm to public order are paramount.

While Article 16 of the proposal establishes the overarching scope of the Union cloud computing sovereignty framework, the specific technical and operational criteria for each level are detailed in Annex II. For providers seeking recognition at Union assurance level 4, the requirements for software supply chain transparency and control are significantly stricter than those for levels 1 through 3. The most critical and nuanced requirement concerns the concept of "effective control" over software components.

The Definition of "Effective Control"

The core of the Level 4 software requirement is found in Annex II, Section 4.1(i)(ii). This provision mandates that the audited provider must demonstrate measures are in place to retain effective control over software components or products. Specifically, the provider must prove that:

"a third country or a legal entity established in a third country does not hold or exercise effective control over the design, development, maintenance, and evolution of those components or products."

CADA explicitly defines what constitutes this "effective control." It is not limited to equity ownership, voting rights, or formal contractual rights. Instead, the proposal states that effective control includes:

"the ability to materially influence the technical evolution, maintenance priorities, security remediation, and long-term continuity of the component."

This definition is crucial because it targets the power to act, rather than just the status of ownership. A third-country entity might not own the EU-based subsidiary or the specific software license, but if it possesses the authority to dictate which bugs are fixed first, which features are developed next, or whether a product is supported long-term, it exercises effective control. The requirement captures the reality that in modern software ecosystems, influence can be exerted through commercial leverage, dependency on proprietary toolchains, or control over the underlying development infrastructure, not just through shareholding.

Context Within the Level 4 Criteria

To understand the weight of this requirement, it must be viewed alongside the other cumulative criteria for Union assurance level 4 in Annex II. These criteria form a holistic shield against third-country interference:

  1. Establishment and Location: The audited provider and its subcontractors must be established in the Union, with infrastructure, assets, and personnel located exclusively within the Union (Annex II, 4.1(a) and (b)).
  2. Data Residency: Sensitive customer data must remain exclusively within the Union at all times (Annex II, 4.1(c)).
  3. Personnel: All personnel involved in the service provision must be Union citizens, and those handling classified information must have necessary national security clearances (Annex II, 4.1(d)).
  4. Cybersecurity Certification: The service must obtain a European cybersecurity certificate of at least assurance level 'high' under a scheme established under Regulation (EU) 2019/881 (Cybersecurity Act) (Annex II, 4.1(e)). Note the distinction: Level 2 and 3 require "substantial" assurance, while Level 4 requires "high" assurance.
  5. No Third-Country Control of the Provider: The audited provider and its subcontractors must not be subject to the control of a third country or a legal entity established in a third country (Annex II, 4.1(g)).
  6. Support Exclusivity: Technical and operational support must be initiated and performed exclusively within the Union by Union residents and parties not subject to third-country control (Annex II, 4.1(h)).

The software supply chain requirement (4.1(i)) sits alongside these strict operational constraints. It ensures that the underlying code driving the cloud service is not subject to the same geopolitical or legal risks as the service provider itself. Even if the provider is EU-owned and the data is EU-resident, the service fails Level 4 if the software's future is dictated by a foreign entity.

Comparison with Lower Assurance Levels

The requirement for "effective control" is unique to Level 4. While Levels 2 and 3 also require robust software supply chain measures, they focus more on transparency, mitigation, and migration capabilities rather than absolute control over the software lifecycle.

  • Level 2 (Annex II, 2.1(i)): Requires a complete and up-to-date Software Bill of Materials (SBOM) and controls to block remote features that could tamper with or disrupt systems. It also requires source code audits for third-country components and a documented migration plan if the vendor fails or restrictions are imposed. However, it does not explicitly ban third-country influence over the evolution of the software, provided there is a viable migration path.
  • Level 3 (Annex II, 3.1(i)): Similar to Level 2, it requires an SBOM, source code audits for security-relevant components, and migration plans. Crucially, Level 3 introduces a derogation allowing third-country-controlled providers to qualify if the Commission has adopted an implementing act under Article 18 (Associated third countries) and specific safeguards are in place. This derogation allows for a controlled relationship with third-country entities under strict conditions.
  • Level 4 (Annex II, 4.1(i)): Removes the option for derogation regarding third-country control of the software itself. The focus shifts from "can we migrate if things go wrong?" to "do we have unambiguous control over the lifecycle of the software right now?" The requirement to demonstrate that no third country can influence "security remediation" and "long-term continuity" is a qualitative leap from the previous levels. It demands that the EU entity retains the final say on the software's survival and security posture.

Audit Evidence and Verification

How will this be verified? Annex III, "Audit Evidence for the Audit Procedure," outlines the evidence auditing organizations must request. For software supply chain transparency (Audit Criterion I), the audited provider must provide:

  1. SBOM and Dependencies: A complete and up-to-date SBOM for all software components, including open-source software (OSS).
  2. Origin and Reliance: Documentation on where and by whom the software is designed, developed, and maintained, including the degree of reliance on non-EU vendors.
  3. Mitigation of Dependencies: Evidence of a risk-based process for identifying and mitigating dependencies on external manufacturers. This includes identifying alternative solutions and having a switchover plan.
  4. Source Code Auditability: The provider must ensure the third-party independent auditor is granted the right to access and audit the source code. This includes making available all documentation and technical material necessary to evaluate the code.

For Level 4 specifically, the auditor will scrutinize the governance structures of the software suppliers. They will look for evidence that the EU-based provider has the contractual and technical authority to direct the roadmap, prioritize security patches, and ensure the software remains available and functional without interference from foreign entities. The auditor will assess whether the EU entity can unilaterally decide to fork the code, change the maintenance schedule, or halt development without needing approval from a third-country board or executive.

What this means for you

For CTOs, architects, and SMEs evaluating the practical impact of CADA, the Level 4 "effective control" requirement poses significant challenges for those relying on global software stacks, particularly those dominated by US or Asian hyperscalers and vendors.

1. Re-evaluating Your Software Stack If you aim to provide services to the EU public sector at Level 4, you cannot simply rely on standard commercial off-the-shelf (COTS) software from third-country vendors, even if you host it in Europe. You must map your entire software supply chain. For every critical component, you must answer: Who decides the roadmap? Who prioritizes security fixes? Who owns the long-term maintenance? If the answer involves a board or executive team in a third country, you likely fail the Level 4 test. The mere existence of a third-country parent company with veto rights over product strategy is a disqualifying factor.

2. Open Source Is Not a Silver Bullet While Annex II 4.1(j) addresses open-source software separately, requiring controls against remote tampering features, the "effective control" rule in 4.1(i) still applies to proprietary components and potentially to the governance of critical open-source foundations if they are subject to third-country influence. You must ensure that the open-source projects you rely on are not effectively controlled by third-country entities in a way that allows them to influence technical evolution or security remediation. If a third-country foundation controls the release process or the core maintainers of a critical library, the "effective control" requirement may not be met.

3. Contractual and Governance Changes To comply, you may need to restructure your relationships with software vendors. This could involve:

  • EU Subsidiaries with Real Power: Ensuring that EU-based subsidiaries have genuine decision-making power over software development and maintenance, not just sales and support. This may require amending articles of association to remove third-country veto rights.
  • Escrow and Source Code Access: Securing rights to source code and build environments that allow you to take over maintenance if the vendor fails or if third-country interference occurs.
  • Independent Development: In some cases, the only way to guarantee Level 4 compliance is to develop core software components in-house or through EU-based partnerships where governance is strictly controlled within the Union.

4. Documentation Burden You will need to prepare extensive documentation for audits. This includes SBOMs, evidence of source code audits, and detailed governance documents proving that third-country entities cannot influence technical evolution. This is a resource-intensive process that requires close collaboration between legal, technical, and procurement teams. The burden of proof lies with the provider to demonstrate the absence of third-country influence.

Common misconceptions

Misconception 1: "Effective control" only means majority ownership. Reality: CADA explicitly defines effective control to include the ability to "materially influence technical evolution, maintenance priorities, security remediation, and long-term continuity." Even if an EU entity owns 100% of a software company, if a third-country parent company dictates the product roadmap or security patch priorities, effective control is not retained by the EU entity.

Misconception 2: Open-source software is exempt from control requirements. Reality: While there are specific provisions for open-source software (Annex II 4.1(j)) focusing on preventing remote tampering, the broader requirement for effective control over software components (4.1(i)) still applies. If your service relies on critical proprietary modules or if the open-source foundation is effectively controlled by a third country, you must demonstrate that this control does not undermine your Level 4 status.

Misconception 3: Hosting the code in Europe is enough. Reality: Data residency and infrastructure location (Annex II 4.1(b)) are separate from software control. You can host software in an EU data center, but if the code is developed, maintained, and evolved by a third-country entity that controls the roadmap and security fixes, you do not meet the Level 4 software supply chain criteria.

Misconception 4: This only applies to custom-built software. Reality: The requirement applies to "software components or products" used in the provision of the service. This includes third-party libraries, operating systems, databases, and middleware. You must assess the entire stack, not just your proprietary application code.

Official sources

Related

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