Summary Yes, as proposed in the Cloud and AI Development Act (CADA), Union Assurance Level 3 (UAL 3) would require cloud providers to grant independent auditors access to source code, specifically for security-relevant components from third-country manufacturers. Under Annex II, section 3.1(g)(i), if a provider is subject to third-country control, they must demonstrate measures ensuring that control does not restrict service delivery, explicitly stating the provider "should allow for reasonable access to the code." Furthermore, Annex II, section 3.1(i)(ii) mandates that security-relevant components from third-country manufacturers be "subject to source code audits" to verify controls against remote tampering. These requirements are critical for verifying that no third country can remotely disrupt the service or access customer data, distinguishing UAL 3 from lower assurance levels.

Detail

The proposed CADA establishes a tiered sovereignty framework for cloud computing services, known as Union Assurance Levels (UALs), designed to safeguard the Union's public order and strategic autonomy. While Level 1 relies on self-assessment and Level 2 introduces independent audits for general compliance, Level 3 introduces stringent transparency requirements regarding the software supply chain, particularly when third-country control is involved.

The Legal Basis for Code Access in Level 3

The core requirement for source code access in Level 3 is not a blanket disclosure to the public, but a targeted verification mechanism for independent auditing organizations. This is grounded in Article 16, which establishes the Union cloud computing sovereignty framework, and the specific criteria detailed in Annex II.

For a cloud computing service to be recognised at Union Assurance Level 3, it must meet cumulative criteria. A critical scenario arises when a provider or its subcontractors are subject to the control of a third country or a legal entity established in a third country. Annex II, section 3.1(g) outlines the necessary safeguards for such providers. Specifically, section 3.1(g)(i) states that the provider must demonstrate that the third-country control is not exercised in a manner that restrains the provider's ability to perform the service or undermines necessary capabilities. Crucially, this provision includes the explicit requirement that the audited provider "should allow for reasonable access to the code."

This "reasonable access" is a verification tool. It allows the auditing organisation to confirm that the third-country entity cannot unilaterally alter the software, introduce backdoors, or disrupt service continuity. It ensures that the legal and technical measures claimed by the provider are real and effective.

Mandatory Source Code Audits for Third-Country Components

Beyond general access, Level 3 imposes a specific audit obligation on the software supply chain. Annex II, section 3.1(i) details the software supply chain measures required. Section 3.1(i)(ii) addresses components provided, owned, or licensed by a legal entity established in a third country. It mandates that providers implement controls to block remote features that could materially tamper with or disrupt the service.

To verify these controls, the regulation is explicit: security-relevant components from third-country manufacturers must be "subject to source code audits." This means that for any critical software component originating outside the EU, the provider cannot simply rely on vendor assurances or black-box testing. The independent auditor must have the technical ability to inspect the source code to ensure that no hidden mechanisms exist that could be triggered by a third-country authority.

The Role of Independent Audits and Annex III

These requirements are enforced through the independent third-party audit mechanism established in Article 20. Under Article 20(1), providers seeking Level 3 recognition must undergo an independent audit to obtain a "positive" audit opinion. The scope of this audit is defined by Annex III, which lists the specific evidence auditors must request.

Annex III, section 9 (Audit criterion I) reinforces the Level 3 criteria. It instructs auditing organisations to verify that the provider has granted them the right to access and audit the source code of such software. The provider must make all documentation, technical material, and information necessary to evaluate and audit the source code available in a complete, accurate, and accessible format. This includes evidence of testing procedures to prevent the use of remote features and change management procedures that cover firmware and software updates.

Distinction from Level 4

It is vital to distinguish the Level 3 approach from Level 4. While Level 3 allows for third-country control if strict safeguards (including code access and audits) are met, Annex II, section 4.1(g) imposes an absolute prohibition on third-country control for Level 4. For Level 4, the provider and subcontractors must not be subject to third-country control at all. Consequently, Level 4 focuses on demonstrating "effective control" over the design and evolution of components (Annex II 4.1(i)(ii)), whereas Level 3 focuses on verifying that existing third-country control is neutralized through transparency and audit. The source code audit in Level 3 is thus a critical compensatory measure for providers that have not yet achieved the complete separation required for Level 4.

What this means for you

For cloud service providers, public sector buyers, and technology stakeholders, the Level 3 source code requirements have significant operational and strategic implications.

1. For Cloud Service Providers (The Audited)

If you aim to achieve Union Assurance Level 3, particularly if your corporate structure or supply chain involves third-country entities, you must prepare for deep technical scrutiny.

  • Audit Readiness: You must maintain a complete and up-to-date Software Bill of Materials (SBOM) as required by Annex II, section 3.1(i)(i). You must be prepared to grant auditors access to the source code of security-relevant third-party components.
  • Technical Controls: You must implement and document technical controls that block remote features capable of tampering with the service. This is a prerequisite for the source code audit to be successful.
  • IP Protection: While the regulation requires "reasonable access," it does not mandate public disclosure. You should work with auditors to establish secure audit environments (e.g., secure rooms or virtual private networks) that allow code inspection while protecting trade secrets, as Annex III notes that auditors must guarantee confidentiality.

2. For Public Sector Buyers (The Contracting Authorities)

Under Article 30, contracting authorities whose activities contribute to the preservation of public order must procure services recognised at Level 2, 3, or 4.

  • Verification of Sovereignty: When evaluating tenders, you should request evidence that the provider has successfully undergone the source code audits required for Level 3. This is particularly relevant if the provider is a subsidiary of a non-EU entity.
  • Risk Assessment: Under Article 29, you must carry out a risk assessment to determine the appropriate assurance level. If your activity involves sensitive data or critical infrastructure, the source code audit requirement of Level 3 may be the minimum necessary to mitigate the risk of third-country interference.

3. For Software Vendors and Subcontractors

If you supply software components to cloud providers seeking Level 3 recognition, your customers may require you to submit your source code for audit.

  • Contractual Obligations: Your contracts with cloud providers must allow for these audits. Failure to grant access to security-relevant components could disqualify the cloud provider from Level 3, potentially losing them public sector contracts.
  • Migration Plans: Annex II, section 3.1(i)(ii) also requires a documented migration plan in the event that a third-country vendor fails or imposes restrictions. This plan must be part of the audit evidence.

Common misconceptions

"CADA Level 3 requires full source code disclosure to the public." No. The requirement is strictly for access by independent auditing organisations to verify compliance. The source code remains confidential, and auditors are bound by professional secrecy and confidentiality obligations under Article 20(3).

"Only Level 4 requires source code scrutiny." Incorrect. While Level 4 prohibits third-country control entirely, Level 3 explicitly requires source code audits for security-relevant components from third-country manufacturers (Annex II, section 3.1(i)(ii)) and reasonable access to code to verify the absence of restrictive control (Annex II, section 3.1(g)(i)). This is a key differentiator between Level 2 and Level 3.

"Reasonable access is too vague to be enforced." While "reasonable" allows for flexibility regarding IP protection, Annex III provides detailed guidance on the scope of the audit. Auditors are expected to verify specific technical controls, such as the absence of remote tampering features, and must be granted access to the source code, documentation, and change management procedures necessary to perform this verification.

"CADA replaces the AI Act's requirements." No. CADA addresses the sovereignty of the cloud infrastructure, while the AI Act (Regulation (EU) 2024/1689) governs the safety and fundamental rights of AI systems. A provider may need to comply with both: the AI Act for the AI model and CADA for the underlying cloud infrastructure.

Official sources

Related

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