How to track revocations and changes on the CADA central repository

Under the proposed Cloud and AI Development Act (CADA), the European Commission will maintain a central repository of cloud computing services recognised f

Summary Under the proposed Cloud and AI Development Act (CADA), the European Commission will maintain a central repository of cloud computing services recognised for Union assurance levels 1 through 4, as established in Article 22. If a service's recognition is revoked or amended, this change must be published in the repository and remain visible for five years, ensuring long-term transparency for public-sector buyers. Procurement officers are advised to treat this repository as a dynamic, real-time resource, re-checking a provider's status immediately before finalising contracts to ensure the required assurance level is still held.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, introduces a harmonised framework for cloud sovereignty in the European Union. Its primary aim is to reduce dependence on third-country providers and safeguard the Union's public order. A critical component of this framework is the central repository of cloud computing services, mandated by Article 22. This repository serves as the single, authoritative source of truth for public-sector bodies and Union entities when procuring cloud services that require specific Union assurance levels.

The Role of the Central Repository

As proposed, Article 22(1) stipulates that the Commission "shall establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17." Recognition under Article 17 is the formal administrative process by which a national competent authority confirms that a cloud service meets the cumulative criteria for Union assurance level 1, 2, 3, or 4, as detailed in Annex II.

Once a service is successfully recognised, Article 22(2) imposes a duty on the national competent authority of the provider's establishment to register that service in the central repository. This registration ensures that the service's assurance status is visible across the entire Union, allowing contracting authorities to verify that a provider meets the minimum sovereignty and security standards required for their specific use case, whether that is a baseline Level 1 or a high-assurance Level 4 for public-order-relevant activities.

Tracking Revocations and Changes

The cloud market is dynamic; a provider's compliance status can change due to failed audits, material changes in ownership, or the discovery of misleading information. CADA addresses the risk of relying on outdated status information through strict transparency obligations regarding revocations.

Article 22(3) explicitly states that "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." Crucially, the text mandates that this publication "shall remain available there for five years."

This five-year visibility rule is a significant departure from simple "current status" lists and serves several strategic purposes:

Historical Transparency: It creates a permanent, accessible record of non-compliance. This prevents providers with a history of serious breaches from easily re-entering the public procurement market without their past failures being scrutinised.
Risk Assessment: It allows procurement officers to assess the reliability and stability of a provider's compliance posture over time. A provider with a clean record for five years presents a lower risk than one with a recent revocation.
Accountability: It ensures that the reasons for revocation—whether due to negligence, intentional misrepresentation, or failure to meet audit criteria—remain part of the public record for a substantial period, reinforcing the integrity of the sovereignty framework.

In addition to revocations, Article 22(4) requires that the central repository be "publicly available and regularly updated by the Commission and the national competent authorities of establishment on a dedicated and easily accessible website." While the proposal does not specify the exact technical frequency of "regular" updates, the legal obligation implies a mechanism that ensures information available to buyers is current, likely necessitating near-real-time synchronization between national authorities and the central Commission platform.

The Obligation to Verify Before Contracting

For public-sector bodies, the existence of the repository creates a continuous due diligence obligation that extends beyond the initial tender phase. Article 30 of CADA sets out the procurement rules, requiring contracting authorities to procure only services recognised at the appropriate Union assurance level (Level 1 as a minimum, or Levels 2–4 for activities identified as contributing to public order preservation under Article 29).

Because recognition is not permanent and can be revoked at any time, procurement officers cannot rely solely on the status of a provider at the time of tender launch. The requirement to check the repository effectively extends through the contract award phase. If a provider's status is revoked between the tender announcement and the contract signature, the contracting authority must act in accordance with public procurement law and CADA's requirements. This likely necessitates a re-evaluation of bids, the exclusion of the non-compliant provider, or potentially a new procurement process if no other recognised providers are available.

What this means for you

For public-sector procurement officers, IT directors, and compliance teams, the CADA central repository is not just a static list but an active risk management tool. Here is how you should integrate tracking revocations and changes into your procurement workflows:

1. Implement Pre-Award Verification Checks

Do not assume that a provider's inclusion in a tender document guarantees their ongoing eligibility. As proposed, you must verify the provider's status in the central repository immediately before signing the contract. A provider may have held the required Union assurance level at the time of bidding but lost it due to a failed audit, a change in control structure, or a material change in circumstances in the intervening weeks. Failure to verify could result in a contract with a non-compliant provider, exposing the public body to legal and operational risks.

2. Monitor for Material Changes During Contract Execution

For long-term cloud contracts, consider establishing a monitoring mechanism. While CADA does not explicitly mandate continuous automated monitoring for buyers, the five-year visibility of revocations suggests that historical compliance is a key factor in vendor evaluation. If a provider's status is revoked during an active contract, you must assess the impact on your operational continuity and data sovereignty. The revocation notice in the repository will provide the context needed to determine if you need to migrate data, invoke exit clauses, or initiate a remediation plan.

3. Use the Repository for Vendor Due Diligence

When evaluating new potential suppliers, use the repository to check for past revocations. A provider with a revocation record within the last five years may present higher operational or compliance risks. You can use this information to weight your evaluation criteria, particularly if your procurement includes "Union added value" criteria under Article 32, which allows you to evaluate tenderers' contributions to the European cloud ecosystem. A provider with a clean compliance history may score higher on resilience and trustworthiness metrics, while a history of revocation could be a disqualifying factor depending on the severity.

4. Prepare for Dynamic Updates

Ensure your internal procurement systems can handle dynamic changes in vendor status. If the Commission updates the repository to reflect a revocation, your internal records should reflect this change promptly. This may involve integrating with the repository via API (if available in the final implementation) or establishing a routine manual check schedule for high-risk contracts. Relying on static PDFs or printed lists from the tender phase is insufficient under the proposed framework.

Common misconceptions

Misconception 1: A revoked status disappears from the repository once the provider re-applies. Some may assume that once a provider rectifies issues and re-applies for recognition, the record of their previous failure is deleted. This is incorrect. Article 22(3) mandates that revocations remain visible for five years. This ensures that the market has full visibility into a provider's compliance history, preventing "cherry-picking" of clean records by providers with a history of non-compliance.

Misconception 2: The repository is only for new procurements. While the repository is essential for initial tendering, its relevance extends to existing contracts. If a provider's recognition is revoked, the public sector body may no longer be in compliance with Article 30, which mandates the use of recognised services. Therefore, tracking changes is critical for contract management, not just initial procurement.

Misconception 3: Private sector entities are required to check the repository. CADA imposes mandatory procurement rules on public sector bodies and Union entities. Private sector entities, particularly those in critical sectors under the NIS2 Directive, may conduct similar impact assessments under Article 31, but they are not strictly bound by the same mandatory procurement obligations as the public sector. However, they may voluntarily use the repository to assess supplier risk and ensure supply chain resilience.

Misconception 4: Revocation happens instantly without notice. The revocation process involves the national competent authority or the auditing organisation. Article 23 requires providers to notify the auditing organisation and competent authority of any material changes that may affect their status. This triggers an assessment, which may lead to revocation. The publication in the repository follows this decision, ensuring there is a formal process rather than an arbitrary removal.

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