Summary As proposed, the Cloud and AI Development Act (CADA) central repository of recognised cloud computing services is not updated on a fixed calendar schedule (e.g., monthly or annually). Instead, Article 22(4) of the proposal mandates that the repository be "regularly updated" by the European Commission and national competent authorities. This "regular" update cycle is driven dynamically by specific legal events: the registration of new recognitions, the amendment of existing statuses following material changes, and the publication of revocations. The system is designed to reflect the current, real-time status of Union assurance levels to ensure public procurement decisions are based on accurate, up-to-date information.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, establishes a critical piece of digital infrastructure: a centralised repository of cloud computing services that have been formally recognised as offering specific Union assurance levels. This repository serves as the definitive source of truth for contracting authorities, auditors, and the public to verify the sovereignty status of cloud providers.

The Legal Mandate for "Regular" Updates

The core obligation regarding the maintenance and frequency of updates is explicitly set out in Article 22 of the proposal. While the text does not prescribe a specific time interval (such as "every 24 hours" or "quarterly"), it establishes a continuous, event-driven obligation.

Article 22(4) states 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 use of the term "regularly updated" in the legislative text, combined with the context of the surrounding articles, indicates a dynamic process rather than a periodic batch update. The repository must remain current to fulfill its purpose: enabling contracting authorities to make informed procurement decisions under Article 30 and ensuring that the Union's public order is safeguarded. If the repository were updated only annually, it would fail to capture revocations or downgrades that could occur at any time, potentially leading to the procurement of non-compliant services.

What Drives the Updates?

The "regular" updates are not arbitrary; they are triggered by specific administrative and legal events defined throughout the sovereignty framework (Title IV, Chapter I). The repository changes in response to three primary types of events:

  1. New Recognitions (Registration): When a cloud computing service provider successfully completes the recognition process, the repository is updated to reflect this new status. Under Article 17, once a national competent authority of establishment adopts a recognition decision (either directly for Level 1 or after the 60-day review period for Levels 2–4), the authority is obligated to register the service in the central repository. This ensures that newly recognised providers are immediately visible to the market.

  2. Amendments and Material Changes: The status of a provider is not static. Under Article 23, recognised providers must notify the auditing organisation and the national competent authority of establishment "as soon as possible" upon becoming aware of any "material change in circumstances" that may affect their audit report or recognition.

    • If an auditing organisation amends or revokes an audit report based on such a notification, the national competent authority must assess whether its recognition needs to be amended or revoked.
    • If the recognition is amended (e.g., a downgrade from Level 4 to Level 3), the national competent authority must update the repository to reflect this new status.
    • This mechanism ensures that the repository reflects the current assurance level, not just the level at the time of initial recognition.

  3. Revocations and Withdrawals: The repository also serves as a historical record of non-compliance. Article 22(3) explicitly mandates 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 and shall remain available there for five years."

    • This means that when a provider loses their status due to a failed audit, the supply of incorrect information, or a material breach, the revocation is immediately published.
    • Crucially, this negative status is not removed after a short period; it remains visible for five years to ensure transparency and allow contracting authorities to assess the provider's compliance history.

The Roles in the Update Process

The maintenance of the repository is a shared responsibility between national and EU levels, ensuring both local accuracy and Union-wide accessibility:

  • National Competent Authorities of Establishment: These authorities act as the primary data entry points. Under Article 22(2), the national competent authority that recognised a cloud computing service is responsible for registering that service in the central repository. They are also responsible for updating the status when they amend or revoke a recognition following an audit or a material change notification. Their role is to ensure the data originating from their jurisdiction is accurate and timely.
  • The European Commission: The Commission's role is to "establish and maintain" the repository itself (Article 22(1)). Under Article 22(4), the Commission is jointly responsible with national authorities for ensuring the repository is "regularly updated" and made publicly available on a dedicated website. The Commission ensures the technical infrastructure supports these frequent updates and that the data is aggregated and accessible across the entire Union.

Technical Implications of "Regularly Updated"

While the legislative text does not define the technical frequency of database synchronisation, the requirement for the repository to be "easily accessible" and "regularly updated" implies a technical architecture capable of near-real-time data propagation.

  • Event-Driven Architecture: The system is likely designed to trigger updates immediately upon the receipt of a recognition decision, an amendment notice, or a revocation order.
  • Public Accessibility: The requirement for a "dedicated and easily accessible website" suggests that the updates are pushed to the public interface promptly, rather than held in a backend queue for periodic release.
  • Reliance for Procurement: Public procurement decisions under Article 30 rely on the validity of the Union assurance level. A significant lag between a revocation event and its reflection in the repository would undermine the Act's objectives, potentially allowing contracting authorities to procure services that no longer meet the required sovereignty standards.

What this means for you

For public-sector procurement officers, IT managers, and cloud service providers, the dynamic nature of the CADA repository has significant operational implications.

  • Verify Before Every Contract: You cannot rely on a provider's status from a previous tender or a marketing brochure. Because the repository is updated "regularly" based on live events, you must check the central repository immediately before finalising any contract. A provider recognised six months ago may have had their status revoked or downgraded due to a failed audit or a material change in their ownership structure.
  • Implement Continuous Monitoring: Your due diligence does not end at the contract signing. Since the repository reflects real-time changes, you should establish a process to monitor the status of your current providers throughout the contract term. If a provider loses their Union assurance level (e.g., dropping from Level 3 to Level 2), this may trigger a breach of contract or necessitate a migration plan, as outlined in the risk assessments under Article 29.
  • Trust the Official Source: Do not rely on self-declarations or third-party summaries. The central repository is the only definitive source of truth for recognised status. The Commission and national authorities are legally bound to keep it accurate, providing you with a reliable tool for compliance.
  • Check the History: If a provider's status is revoked, it remains in the repository for five years. This allows you to assess the long-term compliance history of a provider. A history of revocations, even if the provider has regained status, may indicate higher operational risk.

Common misconceptions

"The repository is updated only once a year." This is incorrect. The legislation requires "regular" updates driven by specific events like recognitions, audits, and revocations. There is no annual freeze or batch update process mentioned in Article 22. The system is designed to be dynamic.

"Providers update their own status in the repository." No. While providers must submit evidence and notifications (under Articles 17 and 23), the actual registration and status updates in the central repository are performed exclusively by the national competent authorities and the Commission. Providers cannot self-certify their status in the public registry.

"Once recognised, a provider stays in the repository forever." Incorrect. Recognition is conditional on ongoing compliance. If a provider fails an audit, supplies misleading information, or experiences a material change that breaks the assurance criteria, their status can be revoked. This revocation is published in the repository and remains visible for five years.

"The repository is only for new procurements." The repository is a living document. Its regular updates are designed to support the entire lifecycle of cloud service usage, including ongoing compliance monitoring for existing contracts. A change in status during a contract term is a critical event that the repository is designed to capture immediately.

Related

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