Summary The purpose of the Cloud and AI Development Act's (CADA) transparency obligations is to ensure that the "Union cloud computing sovereignty framework" remains dynamic and accurate, preventing public buyers from relying on outdated or false claims of sovereignty. As proposed, Article 23 imposes a strict duty on cloud providers to immediately notify authorities of any material changes affecting their recognized assurance level. This mechanism ensures the central repository reflects the current reality of the service, thereby safeguarding public order and protecting procurement decisions from sudden shifts in third-country control or legal risks.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, addresses a critical gap in the EU's digital sovereignty: the risk that a cloud service certified today may become non-compliant tomorrow due to changes in ownership, legislation, or operational control. While the Act establishes a static set of criteria for four Union assurance levels (outlined in Annex II), the explanatory memorandum explicitly acknowledges that "the Union's limited data centre capacity" and "dependence on a limited pool of third-country providers" create dynamic risks. To mitigate this, CADA introduces a continuous monitoring loop centered on Article 23.

The Core Mechanism: Article 23 and Continuous Duty

Article 23 is the operational engine that keeps the sovereignty framework alive. It establishes a continuous duty for recognized cloud computing service providers to monitor their own compliance and report any "material change in circumstances" that could affect their status.

Under Article 23(1), a provider must notify both the auditing organisation and the national competent authority of establishment "as soon as possible" upon becoming aware of information that may affect:

  • The audit report and the 'positive' audit opinion issued under Article 20; or
  • The recognition decision granted under Article 17.

This provision shifts the burden of ongoing verification from the public buyer to the provider. In a traditional certification model, a buyer might assume a certificate remains valid until its expiry date. Under CADA, the validity is conditional on the provider's active duty to report. The explanatory memorandum reinforces this by noting that the framework must "ensure that the processing of personal data involving EU citizens complies with EU data protection standards" and that risks associated with "non-compliant data handling" must be minimized. Transparency is the tool that ensures these risks are identified in real-time.

The Cascade Effect: From Notification to Repository Update

The true power of Article 23 lies in its cascading procedural requirements, which ensure that a change in a provider's status is rapidly reflected in the public record. The process is designed to protect the integrity of the central repository established under Article 22.

  1. Initial Notification: The provider reports the change to the auditor and the national authority (Article 23(1)).
  2. Auditor Assessment: The auditing organisation must assess whether the audit report or opinion needs to be amended or revoked (Article 23(2)). If the change is significant (e.g., a third-country entity acquires control, or a new law mandates data access), the auditor may revoke the 'positive' opinion.
  3. Authority Assessment: If the auditor amends or revokes the opinion, the national competent authority must assess whether its recognition of the service needs to be amended or revoked (Article 23(2)).
  4. Union-Wide Notification: If the recognition is amended or revoked, the national authority must notify the other Member States and the Commission (Article 23(3)).
  5. Repository Update: This notification triggers an update in the central repository, ensuring that the "single source of truth" for public buyers is immediately corrected.

This chain of events ensures that a public buyer relying on the repository is protected from inadvertently procuring a service that no longer meets the required Union assurance level. Without Article 23, a provider could lose its sovereignty status due to a geopolitical shift or ownership change, yet remain listed as "compliant" in the repository until the next scheduled audit, creating a dangerous window of exposure.

Linking Transparency to Public Order and Procurement

The explanatory memorandum states that a primary objective of CADA is to "help protect public order by making the supply of cloud computing services more resilient, in particular in the public sector." This objective is operationalized through the interplay of Article 23, Article 29, and Article 30.

Article 29 requires Member States and Union entities to conduct risk assessments to determine which public sector activities contribute to the preservation of public order and, consequently, which Union assurance level (1, 2, 3, or 4) is required. Article 30 then mandates that contracting authorities procure only services that meet these specific levels.

If transparency obligations fail, the link between risk assessment and procurement breaks down. For instance, a public body might classify its law enforcement activities as requiring Union assurance level 3 (which mandates Union citizenship for personnel and prohibits third-country control). If a provider fails to report a change in ownership that introduces third-country control, the public body may unknowingly violate its own risk mitigation strategy. Article 23 closes this loop, ensuring that the legal status of the service in the repository always reflects its technical and legal reality.

Furthermore, the explanatory memorandum highlights that the framework aims to reduce "critical external dependencies." By forcing providers to report changes that might reintroduce such dependencies (e.g., new laws in a third country mandating data access), Article 23 acts as an early warning system for the entire EU public sector.

What this means for you

For public-sector bodies, procurement officers, and legal teams, the transparency obligations under Article 23 fundamentally change how cloud services are managed.

1. Rely on the Repository, But Verify Periodically

You are not required to conduct independent, continuous audits of your provider's sovereignty status. The system is designed so that you can rely on the recognition status listed in the central repository (Article 22). However, because Article 23 mandates that changes be reported "as soon as possible," you must establish internal processes to regularly check for updates to this repository. If a provider's status is downgraded or revoked, you must act in accordance with Article 30. If your risk assessment (Article 29) mandates a higher assurance level than the provider now offers, you may be required to migrate. Article 29(6) notes that if a risk assessment requires migration, it must happen within a reasonable transition period not exceeding 12 months.

2. Strengthen Contractual Clauses

While Article 23 places the legal duty on the provider to notify authorities, your procurement contracts should explicitly reference this obligation. Include clauses that:

  • Require the provider to notify you immediately upon notifying the authorities under Article 23.
  • Allow for immediate contract termination or renegotiation if a provider's Union assurance level is revoked or downgraded due to a failure to report material changes.
  • Define "material change" broadly to include changes in ownership, third-country legislation, or operational control, aligning with the criteria in Annex II.

This protects your organization from being locked into a service that no longer meets the security standards required by your risk assessment and prevents potential liability for non-compliance with Article 30.

3. Align Risk Assessments with Dynamic Status

Ensure your risk assessments under Article 29 are up to date and clearly define which assurance levels are non-negotiable for specific activities. The transparency mechanism works best when your organization has a clear policy on how to react to a status change. If a provider's status changes, you need a clear decision tree: do you accept the lower level (if your activity does not strictly require the higher level), or do you initiate a migration?

Common misconceptions

"Transparency means public disclosure of all technical details." This is incorrect. The transparency obligations in Article 23 are strictly about notifying competent authorities and auditing organisations of material changes affecting the assurance level. They do not require providers to publish their source code, detailed architecture, or sensitive operational data to the general public. Confidentiality and trade secrets are still protected. Article 20(3) explicitly requires auditing organisations to ensure an adequate level of confidentiality and professional secrecy regarding information obtained during audits.

"A one-time audit is sufficient for the lifetime of the contract." No. The sovereignty landscape is dynamic. Laws change, ownership structures shift, and geopolitical risks evolve. Article 23 ensures that the recognition is dynamic. A provider recognized at Union assurance level 3 today may not qualify tomorrow if, for example, a third-country government passes a law compelling data access. The transparency obligation ensures this change is captured and reflected in the repository immediately, rather than waiting for the next annual audit.

"Public buyers are responsible for monitoring providers' compliance." No. The primary duty to monitor and report lies with the provider and the auditing organisation. Public buyers are responsible for procuring services that match their risk assessment and for verifying the status in the central repository. The system is designed so that buyers can trust the repository, provided they check it periodically. The burden of proof for ongoing compliance rests on the provider, not the buyer.

Related

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