How does a provider correct or update its CADA repository listing?

Under the proposed Cloud and AI Development Act (CADA), a cloud computing service provider cannot directly edit its entry in the central repository of reco

Summary Under the proposed Cloud and AI Development Act (CADA), a cloud computing service provider cannot directly edit its entry in the central repository of recognised Union-assured services. The repository is a regulatory register maintained by the European Commission and populated exclusively by national competent authorities. Instead, providers must trigger updates by notifying their auditing organisation and the national competent authority of establishment of any "material change in circumstances" that may affect their recognition. The authority then assesses the impact, amends or revokes the recognition, and subsequently updates the central repository entry.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, establishes a rigorous transparency framework to ensure public trust in sovereign cloud services. This framework relies on a central repository of cloud computing services that have been formally recognised as meeting specific Union assurance levels (Levels 1–4). For providers, understanding the mechanics of this repository is critical, as the listing serves as the primary, legally binding proof of compliance for public sector buyers and Union entities.

The Central Repository: A Regulatory Register, Not a Directory

As proposed in Article 22, the European Commission is tasked with establishing and maintaining a dedicated central repository. This repository contains details of cloud computing services that have successfully undergone the recognition process under Article 17.

Crucially, the provider does not register itself, nor does it have administrative access to modify its own entry. According to Article 22(2), it is the national competent authority of establishment that registers the cloud computing service in the central repository once recognition has been granted. The text states: "The national competent authority of establishment that recognised a cloud computing service under Article 17 shall register the cloud computing service in the central repository."

The repository is publicly available, regularly updated, and hosted on a dedicated and easily accessible website. Because it is the source of truth for procurement decisions under Article 30, its accuracy is paramount. The separation of powers—where the provider notifies, the authority assesses, and the authority registers—ensures that the listing reflects a verified, audited status rather than self-declared marketing claims.

The Obligation to Notify: Triggering the Update

Because the repository is a dynamic compliance record, providers have an ongoing duty to ensure that the information reflected remains valid. This duty is codified in Article 23, which sets out specific transparency obligations for recognised providers.

Article 23(1) mandates that when a recognised cloud computing service provider becomes aware of "any information or any material change in circumstances that may affect the audit report and the 'positive' opinion... or the recognition," it must notify two specific entities:

The auditing organisation that performed the audit (or the provider itself for Level 1 self-assessments, though the text specifically references the auditing organisation in the context of the audit report).
The national competent authority of establishment.

The regulation requires this notification to occur "as soon as possible." The term "material change" is broad and covers any event or alteration in the provider's operations, infrastructure, subcontracting arrangements, legal status, or personnel that could jeopardise its compliance with the cumulative criteria for its specific Union assurance level. Examples include a change in ultimate beneficial ownership, the relocation of data centres outside the Union, or a breach of cybersecurity standards.

The Assessment and Update Workflow

Once the provider issues a notification under Article 23(1), a structured, two-step assessment process is triggered to determine the necessary update to the repository:

Auditing Organisation Review: Under Article 23(2), the auditing organisation must assess whether the audit report or the "positive" audit opinion needs to be amended or revoked based on the new information. If the auditor determines that the provider no longer complies with the criteria, they must amend or revoke the audit report and opinion. They are then required to notify the national competent authority of establishment "as soon as possible."
Competent Authority Review: Under Article 23(3), the national competent authority of establishment assesses whether its original recognition needs to be amended or revoked. This assessment may be triggered by the provider's initial notification or by the auditor's subsequent notification.

If the competent authority determines that the recognition must change, it amends or revokes the recognition. It must then notify the competent authorities of other Member States and the Commission. Following this chain of notification, the central repository is updated to reflect the new status. The provider never edits the repository directly; they only initiate the chain of events that leads to an update.

Revocation and Historical Visibility

If a recognition is revoked—whether by the auditor revoking the audit opinion or the competent authority revoking the recognition—this change is published in the central repository. Article 22(3) specifies 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 five-year retention period ensures that historical compliance data remains accessible for audit trails, due diligence, and legal accountability, even after a service loses its sovereign status. It prevents providers from concealing past compliance failures when applying for future recognition or when clients conduct historical background checks.

What this means for you

For cloud service providers seeking or maintaining a Union assurance level under the proposed CADA, the update process imposes strict procedural and operational responsibilities. You cannot treat the repository listing as a static marketing asset; it is a dynamic, legally binding compliance record.

1. Establish Internal Monitoring Mechanisms You must have robust internal processes to detect "material changes" immediately. This includes monitoring:

Subcontracting: Onboarding new sub-processors or changing the location of infrastructure.
Personnel: Changes in key personnel who hold security clearances (critical for Levels 3 and 4).
Corporate Structure: Mergers, acquisitions, or changes in ultimate beneficial ownership that might trigger third-country control concerns.
Security Incidents: Breaches that could affect the integrity of the service or data confidentiality.

2. Prepare for Rapid Notification The requirement to notify "as soon as possible" implies that you cannot wait for the next scheduled audit cycle. If a material change occurs, you must promptly engage with your auditing organisation and the national competent authority. Delays in notification could be viewed as a failure to meet transparency obligations, potentially leading to penalties under Article 24, which requires Member States to lay down rules on penalties that are "effective, proportionate and dissuasive."

3. Coordinate with Your Auditor Your relationship with the auditing organisation is central to the update process. Since the auditor must assess the impact of the change on the audit opinion before the competent authority acts, maintain open lines of communication. Ensure your auditor understands the scope of your internal changes so they can provide a timely assessment. For Level 1 providers, who rely on self-assessment, the internal review process must be equally rigorous to ensure the "EU statement of conformity" remains valid.

4. Anticipate Procurement Impacts Public sector buyers rely on the central repository to verify compliance before and during procurement. If your listing is amended or revoked, buyers may be forced to migrate their workloads to maintain compliance with Article 30. For high-assurance levels (3 and 4), where migration is complex, early communication with key public sector clients may be necessary, alongside the formal regulatory notifications, to manage service continuity.

Common misconceptions

Misconception 1: Providers can update their own repository entries. Some providers assume that, like commercial directories or self-service portals, they can log in to update their service details. This is incorrect. The repository is an official regulatory register maintained by the Commission and populated exclusively by national competent authorities. Providers have no direct editing access; they can only trigger updates by notifying the authorities of changes.

Misconception 2: Only negative changes need to be reported. Providers often believe they only need to report incidents or losses of compliance. However, Article 23(1) requires notification of any material change that may affect the audit report or recognition. This includes positive changes, such as expanding infrastructure to new EU locations or upgrading security certifications, if these changes alter the scope or basis of the original audit opinion or the criteria met.

Misconception 3: The process is the same for all Assurance Levels. While the notification obligation in Article 23 applies to all recognised providers, the underlying audit mechanisms differ. Level 1 providers rely on a self-assessment (Article 19), while Levels 2–4 require independent third-party audits (Article 20). Consequently, the "material change" assessment for Level 1 may involve different evidentiary standards than for Level 4, but the duty to notify the competent authority remains consistent across all levels.

Misconception 4: Revocation means immediate deletion from the repository. If a provider loses its recognition, the entry is not erased. Article 22(3) mandates that revocations remain published for five years. This ensures transparency and prevents providers from concealing past compliance failures when applying for future recognition or when clients conduct historical due diligence.

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