Summary Under the proposed Cloud and AI Development Act (CADA), there is no fixed statutory deadline (e.g., 24 or 48 hours) for a revocation to appear in the central repository. Instead, the update is triggered by a notification chain initiated by the cloud provider or auditing organisation, with each step requiring action "as soon as possible." Once the national competent authority amends or revokes the recognition, it must notify other authorities and the Commission "as soon as possible" (Article 23(3)). The Commission and national authorities are then required to regularly update the central repository, which must be publicly available (Article 22(3)–(4)). Revocations are not deleted but must remain available for five years.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, establishes a Union cloud computing sovereignty framework designed to mitigate risks associated with dependence on third-country providers. A core component of this framework is the central repository of recognised cloud computing services, which serves as the single source of truth for public sector bodies and other stakeholders verifying the "Union assurance levels" of cloud services.

For CTOs, architects, and compliance officers, understanding the latency between a service losing its status and that change reflecting in the repository is critical for risk management and procurement compliance. The proposal does not impose a rigid, automated timestamp for updates. Rather, it relies on a procedural chain of notifications that culminates in the repository being updated. The speed of reflection is therefore a function of the efficiency of the "as soon as possible" obligations embedded in the text.

The Notification Chain: Article 23

The speed of reflection in the repository is directly tied to the transparency obligations outlined in Article 23. The process is a cascading sequence of notifications, each bound by the "as soon as possible" standard.

  1. Provider/Auditor Notification: The process begins when a recognised cloud computing service provider becomes aware of information or a material change in circumstances that may affect their audit report or recognition. The provider must notify the auditing organisation and the national competent authority of establishment "as soon as possible" (Article 23(1)).
  2. Auditor Assessment: Upon receiving this notification, the auditing organisation assesses whether the audit report or opinion needs to be amended or revoked. If the auditor determines a change is necessary, they must notify the national competent authority of establishment "as soon as possible" (Article 23(2)).
  3. Authority Action: Based on these notifications, the national competent authority of establishment assesses whether its recognition needs to be amended or revoked. If the authority amends or revokes the recognition, it must notify the national competent authorities of the other Member States and the Commission "as soon as possible" (Article 23(3)).

This chain ensures that the Commission and all Member States are informed of a change in status immediately upon the authority's decision. The "as soon as possible" standard is a legal obligation intended to prevent delays, though it does not specify a precise number of hours or days.

Repository Update Mechanism: Article 22

Once the notification chain reaches the Commission and the national competent authority of establishment, the central repository is updated. Article 22 governs the establishment and maintenance of this repository.

  • Registration and Revocation: The national competent authority of establishment that recognised the service registers it in the central repository (Article 22(2)). Crucially, Article 22(3) 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."
  • Public Availability and Regular Updates: Article 22(4) mandates that the central repository shall be publicly available and "regularly updated by the Commission and the national competent authorities of establishment on a dedicated and easily accessible website."

The term "regularly updated" implies a systematic process rather than an instantaneous, real-time API push. However, the obligation to notify "as soon as possible" at each stage of Article 23 creates significant pressure for prompt updates. The repository serves not only as a listing of valid services but also as a historical record of revoked services, ensuring transparency for due diligence purposes. The Commission and national authorities share the responsibility for these updates, ensuring the data is current and accessible.

The Five-Year Retention Rule

A critical detail for architects conducting historical due diligence is that revocations are not deleted. Article 22(3) explicitly requires that revocations "shall remain available there for five years." This ensures that a provider's history of compliance issues remains visible, preventing "churning" between providers or levels to hide past non-compliance. This retention period applies to both the revocation of an audit report/opinion by an auditing organisation and the revocation of a recognition by a competent authority.

What this means for you

For CTOs, architects, and SMEs evaluating the practical impact of CADA, the lack of a hard-coded latency period requires a proactive approach to contract management and risk monitoring.

1. Do not rely solely on the repository for real-time status checks. Because the update is "regular" rather than instantaneous, a service could theoretically be revoked at the national level but not yet reflected in the central repository for a short period. For high-assurance levels (3 and 4), where the risks are highest, your due diligence process should include direct contractual clauses requiring providers to notify you immediately of any material changes or audit issues, parallel to their regulatory obligations under Article 23.

2. Monitor the "as soon as possible" triggers. The burden of initiating the update chain lies with the provider and the auditor. Ensure your service level agreements (SLAs) with cloud providers include explicit penalties or breach conditions for failing to notify the competent authority "as soon as possible" as required by Article 23. If a provider delays notification, they are in breach of CADA, which may give you grounds for contract termination or liability claims under Article 24.

3. Leverage the five-year history for vendor selection. When selecting a provider for Union assurance level 2, 3, or 4, use the central repository not just to verify current status, but to check the five-year history of revocations. A provider with multiple revoked recognitions in the past five years (visible under Article 22(3)) poses a higher operational and sovereignty risk, even if they are currently compliant. This historical data is a key differentiator for assessing long-term reliability.

4. Prepare for the "Regular Update" cadence. While the exact frequency of "regular updates" may be defined in secondary legislation or technical specifications by the Commission, assume a near-daily or weekly update cycle for critical changes. Design your internal compliance dashboards to poll the repository regularly rather than expecting webhook notifications, unless the Commission's technical implementation provides such an interface. The "regularly updated" requirement in Article 22(4) ensures the data remains current, but the specific cadence is a matter of technical implementation.

Common misconceptions

Misconception: The repository updates automatically the moment an auditor issues a negative opinion. Reality: There is a manual and administrative step in the middle. The auditor notifies the competent authority, which then assesses the recognition. Only after the competent authority decides to revoke the recognition does the repository update occur (Article 23(3)). This introduces a procedural delay, however short, between the auditor's finding and the public record.

Misconception: Revoked services are removed from the repository immediately. Reality: Revoked services are published and retained for five years (Article 22(3)). They are not deleted. This is a transparency feature, not a deletion feature, designed to provide a complete history of a provider's compliance status.

Misconception: The Commission updates the repository directly without national input. Reality: The repository is jointly maintained. National competent authorities of establishment register and update the status of services they recognise, while the Commission maintains the platform and ensures regular updates (Article 22(4)). The national authority is the primary source of the revocation data, and the Commission acts on the notifications received under Article 23(3).

Misconception: SMEs are exempt from the notification chain. Reality: While SMEs have streamlined recognition for Union assurance level 1 (automatic recognition without prior authority review under Article 17(3)), the transparency obligations for material changes and revocations still apply to all recognised providers. If an SME's service is revoked, the same notification and publication rules apply, ensuring a level playing field in terms of transparency.

Related

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