Summary As proposed, the Cloud and AI Development Act (CADA) establishes a central repository to serve as the single, authoritative source of truth for cloud computing services recognized under the Union cloud computing sovereignty framework. Maintained by the European Commission, this repository is critical for auditors and national competent authorities (NCAs) because it consolidates all recognition data, amendments, and revocations into one accessible location. Article 22(2) mandates that the national competent authority of establishment registers the service, while Article 22(3) requires that revocations remain published for five years, creating a permanent compliance history. This single record eliminates information asymmetry, supports consistent cross-border oversight, and enables NCAs to verify a provider's status instantly without resorting to slow bilateral information requests.

Detail

The CADA proposal introduces a rigorous sovereignty framework for cloud computing services, categorized into four Union assurance levels (1–4). For this framework to function effectively across the EU's internal market, the proposal establishes a central repository under Article 22. This digital infrastructure is not merely a list; it is the operational backbone that connects national recognition decisions with EU-wide transparency, directly aiding the work of auditing organizations and supervisory authorities.

The Legal Mandate and Scope

Article 22(1) explicitly mandates the Commission to "establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17." The scope is precise: the repository does not contain every cloud provider in the EU, but only those services that have successfully undergone the recognition process and have been formally recognized as offering a specific Union assurance level. This ensures that the data within the repository is legally validated and current.

The Registration Chain: Article 22(2)

The integrity of the repository relies on a strict chain of responsibility defined in Article 22(2). The provision 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."

This mechanism is vital for auditors and authorities for several reasons:

  1. Single Point of Entry: It prevents duplication and ensures that the authority which performed the evaluation (the evaluating NCA) is the sole entity responsible for inputting the data. This creates a clear audit trail linking the recognition decision to the public record.
  2. Immediate Visibility: Once an evaluating NCA adopts a recognition decision (following the 60-day review period in Article 17), the obligation to register ensures that the service becomes visible across the Union immediately. This supports the principle of mutual recognition, allowing a provider recognized in one Member State to be instantly identifiable by authorities in all others.
  3. Accountability: By tying the registration duty to the "authority of establishment," the proposal ensures that the entity with the primary investigative and enforcement powers (under Article 25) is directly responsible for the accuracy of the data in the central system.

Transparency, Public Access, and Dynamic Updates

Article 22(4) establishes 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."

For auditors and NCAs, this public availability serves as a primary verification tool. It allows authorities to:

  • Verify Status Instantly: An NCA in a "destination" Member State (where a service is used) can check the repository to confirm the status of a provider established elsewhere, rather than waiting for a formal mutual assistance request under Article 27.
  • Monitor Market Trends: The repository provides a real-time view of the sovereign cloud market, helping authorities identify gaps in assurance levels or geographic coverage.

Crucially, the repository is dynamic. It is not a static list of approved providers but a living record of compliance status.

The Critical Role of Revocations: Article 22(3)

Perhaps the most significant feature for oversight is the handling of negative outcomes. 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."

This provision is essential for effective oversight and risk management:

  • Historical Transparency: The five-year retention period ensures that a provider cannot simply "reset" their record by withdrawing and re-applying. It creates a permanent historical record of non-compliance.
  • Auditor Due Diligence: Auditing organizations can review the five-year history of a provider before accepting an engagement, identifying patterns of non-compliance or previous revocations.
  • Regulatory Consistency: It prevents a situation where a provider is recognized in one Member State while having a revoked status in another, as the central record would flag the revocation immediately.

Supporting NCA Cooperation and Consistency

The repository acts as the technical enabler for the cooperation mechanisms in Articles 27 (Mutual Assistance) and 28 (Cross-border Cooperation). By providing a single, centralized source of truth, the repository reduces the administrative burden on NCAs.

  • Streamlined Oversight: Instead of initiating a formal request for information under Article 27 to verify a provider's status, an NCA can often rely on the data in the central repository. This accelerates enforcement actions and reduces bureaucratic friction.
  • Consistent Application: The repository ensures that all NCAs are looking at the same data. If a recognition is revoked in the Member State of establishment, the revocation is published centrally, ensuring that all other Member States are immediately aware of the change. This prevents inconsistent enforcement where a provider might be considered "compliant" in one jurisdiction but "revoked" in another.
  • Audit Efficiency: Auditing organizations, which are responsible for assessing compliance for levels 2–4, can use the repository to verify the current status of providers. This helps prevent conflicting audit opinions and ensures that the audit process is based on the most up-to-date recognition status.

Integration with the Broader Framework

The repository is deeply integrated into the CADA ecosystem. It connects the recognition process (Article 17), the transparency obligations (Article 23), and the penalties regime (Article 24). When a provider fails to notify a material change under Article 23, the resulting revocation is published in the repository under Article 22(3), triggering potential penalties. This closed loop ensures that the repository is not just a passive database but an active tool for enforcement and market discipline.

What this means for you

For legal counsel, compliance officers, and auditors, the CADA central repository represents a fundamental shift in regulatory visibility.

1. Data Accuracy is a Legal Obligation For cloud providers, the data in the repository is the official record of your compliance status. Since the national competent authority of establishment is responsible for registration under Article 22(2), providers must ensure their national authority has the correct, up-to-date information. Any discrepancy between your internal records and the repository could be flagged as a material change, triggering an audit or revocation.

2. The Five-Year "Shadow" of Revocation Compliance teams must understand that a revocation is not a temporary setback; it is a permanent record for five years. If your provider loses its assurance level, that fact will be visible to all potential public sector clients and regulators for half a decade. This makes maintaining continuous compliance critical, as the reputational and commercial impact of a revocation is long-lasting.

3. Auditors Must Verify Against the Central Record Auditing organizations should treat the central repository as the primary source of truth during their assessments. Before issuing an audit opinion, auditors must verify that the provider's status in the repository matches the current reality. If a provider has been revoked in the repository, the audit cannot proceed until the issue is resolved. The repository's five-year history is a key input for risk-based auditing.

4. NCAs Can Rely on the Repository for Enforcement National competent authorities should utilize the repository as their first line of defense in cross-border supervision. Before launching a formal investigation or requesting information from another Member State, the NCA should check the central repository. If a revocation or amendment is already published, the NCA can act immediately on that basis, ensuring consistent enforcement across the EU.

Common misconceptions

Misconception 1: The repository is a general directory of all cloud providers. Correction: No. The repository only lists services that have been recognized under Article 17 as offering a specific Union assurance level (1–4). Providers that have not applied, or whose applications were rejected, do not appear in the repository. It is a list of vetted services, not a general industry directory.

Misconception 2: The Commission manually updates the repository with every change. Correction: While the Commission maintains the technical platform, the national competent authorities are responsible for the data. Under Article 22(2), the authority of establishment registers the service. Under Article 22(3), they (or the auditing organization, in the case of revocation) ensure the revocation is published. The Commission's role is to ensure the platform is available and secure, not to generate the data.

Misconception 3: Revocations are removed once a provider re-applies. Correction: No. Article 22(3) explicitly mandates that revocations remain available for five years. Even if a provider successfully re-applies and gains recognition again, the historical record of the previous revocation remains visible for the full five-year period to ensure transparency and accountability.

Misconception 4: Only government officials can access the repository. Correction: Article 22(4) states the repository shall be publicly available. Any individual, including auditors, private sector entities, and the general public, can access it to verify the status of a cloud computing service. This transparency is a core feature of the proposal.

Related

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