Summary No, the transparency obligations under the proposed Cloud and AI Development Act (CADA) do not simply cease when a cloud computing service provider exits the central repository. While the status of being a recognized provider offering a specific Union assurance level ends upon revocation or withdrawal, the regulatory duties surrounding that exit persist. Specifically, Article 23(1) imposes a continuous duty on recognized providers to notify authorities of any material changes that may affect their recognition, a duty that is often the very trigger for the exit. Furthermore, Article 22(3) mandates that any revocation of an audit report or recognition must be published in the central repository and remain publicly available for five years. Consequently, the regulatory footprint of a provider's exit is permanent for a defined period, ensuring market transparency and preventing "revolving door" compliance failures.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, establishes a sophisticated framework for cloud sovereignty based on four Union assurance levels. A cornerstone of this framework is the central repository of recognized services, maintained by the European Commission. For cloud service providers (CSPs), understanding the lifecycle of recognition is critical. A common misconception is that once a service is removed from the repositoryβ€”whether voluntarily or due to non-complianceβ€”the provider is immediately absolved of all regulatory duties. The text of the proposal, particularly the interplay between Article 22 and Article 23, demonstrates that this is incorrect.

The Central Repository as a Historical Record

The central repository is not merely a directory of currently active, compliant services; it is also a mechanism for historical accountability. Article 22(1) establishes the Commission's duty to maintain this repository for services recognized under Article 17. However, the transparency of the framework relies equally on the visibility of failures and withdrawals.

Article 22(3) explicitly addresses the permanence of revocation records. It states:

"The revocation of an audit report and audit opinion by an auditing organisation or the revocation of a recognition by a competent authority shall be published in the central repository and shall remain available there for five years."

This provision creates a mandatory "memory" for the ecosystem. If a provider's recognition is revokedβ€”whether due to a failure to maintain the required assurance level, a breach of sovereignty criteria, or a voluntary withdrawal that results in the loss of statusβ€”the fact of that revocation is not erased. It is published and retained for a fixed period of five years. This ensures that public sector bodies, which rely on the repository to make procurement decisions under Article 30, can see the full compliance history of a provider. It prevents a scenario where a provider loses recognition for serious deficiencies and immediately re-enters the market without a visible record of their past non-compliance.

The Triggering Role of Article 23(1)

The obligation to report material changes is the engine that drives the update of the repository. Article 23(1) imposes a proactive duty on recognized providers that does not vanish the moment a provider decides to exit. The article requires that:

"On becoming aware of any information or any material change in circumstances that may affect the audit report and the 'positive' opinion under Article 20 or the recognition under Article 17, the recognised cloud computing service provider shall, as soon as possible, notify the auditing organisation and the national competent authority of establishment."

This obligation is triggered by the change in circumstances, not by the current status of the provider. If a provider experiences a material changeβ€”such as a change in ownership structure, a loss of infrastructure location within the Union, or a failure to maintain cybersecurity standardsβ€”that change may lead to the revocation of their recognition. The provider is legally required to report this change before the recognition is formally revoked.

Therefore, the act of "exiting" the repository is often preceded by the fulfillment of the Article 23(1) notification duty. The provider cannot simply stop offering the service or let the recognition lapse without reporting the underlying material changes that caused the lapse. The notification is the first step in the regulatory process that leads to the update of the repository.

The Chain of Notification and Revocation

The process of exiting the repository involves a structured chain of notifications that reinforces the persistence of transparency duties.

  1. Provider Notification (Article 23(1)): The provider notifies the auditing organization and the competent authority of the material change.
  2. Auditor Action (Article 23(2)): If the auditing organization determines that the change requires amending or revoking the audit report or opinion, it must notify the national competent authority of establishment.
  3. Authority Action (Article 23(3)): If the national competent authority amends or revokes the recognition based on this information, it must notify the other Member States and the Commission.

This cascade ensures that the exit is a documented, transparent event. The provider's initial duty under Article 23(1) is the catalyst for the entire process. Even if the provider ceases to offer the service, the duty to report the reason for the cessation (if it constitutes a material change affecting recognition) remains.

Distinction Between Voluntary Withdrawal and Revocation

It is important to distinguish between a provider voluntarily ceasing to offer a service and a formal revocation due to non-compliance.

  • Voluntary Withdrawal: If a provider decides to stop offering a service that was previously recognized, this constitutes a "material change in circumstances" under Article 23(1). The provider must notify the authorities. The competent authority will then update the repository to reflect that the service is no longer recognized. While the service is removed from the "active" list, the record of the withdrawal and the notification trail remains part of the administrative history.
  • Formal Revocation: If the recognition is revoked due to non-compliance (e.g., failure to meet the criteria in Annex II), Article 22(3) applies directly. The revocation is published and retained for five years. This is a public record of failure, distinct from a simple market exit.

In both scenarios, the provider cannot "walk away" from the regulatory framework without fulfilling the notification requirements. The obligation to report material changes is tied to the provider's actions and the state of the service, not just its current listing status.

What this means for you

For cloud service providers and data center operators subject to the proposed CADA, the implications of exiting the repository are significant for compliance strategy and reputation management.

  1. Plan for Exit Notifications: Do not assume that stopping a service ends your obligations. If you discontinue a recognized service or experience a change that affects your assurance level, you must proactively notify your auditing organization and the national competent authority of establishment under Article 23(1). Failure to report these material changes "as soon as possible" could be viewed as a breach of the regulation, potentially triggering penalties under Article 24.
  2. Expect Public Visibility of Revocation: If your recognition is revoked, understand that this is not a private administrative matter. Under Article 22(3), the revocation will be published in the central repository and remain visible for five years. This record will be accessible to public sector bodies and competitors. Ensure your internal governance can handle the reputational and commercial impact of this mandatory disclosure.
  3. Maintain Audit Relationships During Exit: Even if you are in the process of exiting the market or downgrading your assurance level, you must cooperate with your auditing organization. The audit report and opinion are the basis for your recognition. Any changes affecting them must be reported to trigger the correct update in the repository.
  4. Document Material Changes Rigorously: Keep detailed records of any material changes in circumstances (e.g., changes in ownership, infrastructure location, or subcontractor status). You will need to demonstrate to the competent authority that you reported these changes promptly to comply with Article 23(1). This documentation is your primary defense against claims of non-compliance during the exit process.

Common misconceptions

Misconception 1: "Once I'm off the list, I'm free from CADA." Reality: CADA's obligations are tied to the provision of cloud computing services and the status of those services. Exiting the repository does not erase past obligations or the duty to report the reasons for exiting. The five-year retention of revocation records under Article 22(3) ensures that the regulatory community remains aware of your compliance history. The "exit" is a documented event, not a disappearance.

Misconception 2: "Transparency obligations only apply while I am recognized." Reality: Article 23(1) requires notification of material changes that may affect the recognition. This implies an ongoing duty to monitor and report changes even as your status is in flux. The obligation to report the change that leads to revocation is a transparency duty in itself. You cannot wait until the recognition is officially revoked to report the cause; the duty arises the moment you become aware of the material change.

Misconception 3: "I can remove my service from the repository without consequence." Reality: Providers do not unilaterally remove themselves from the repository. The competent authority of establishment registers services and updates the repository based on recognition decisions (Article 22(2)). If recognition is revoked, the authority publishes the revocation. You cannot hide a revocation; it is a mandatory public record for five years. Attempting to bypass the notification process under Article 23(1) would constitute a separate infringement.

Related

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