Summary Article 22 of the proposed Cloud and AI Development Act (CADA) establishes the central repository of cloud computing services — a publicly available register of services recognised under Article 17 as offering a Union assurance level (1 to 4). The Commission establishes and maintains it (Article 22(1)); the national competent authority of establishment registers each service it recognises (Article 22(2)); revocations are published and kept available for five years (Article 22(3)); and the whole repository must be publicly available and regularly updated (Article 22(4)). CADA is a draft proposal, so the repository does not yet exist.

Detail

Article 22 creates the central repository of cloud computing services, the public record at the centre of CADA's sovereignty framework. It turns recognition decisions into something a buyer can verify, and it is the reference point for the procurement rules in Article 30.

Establishing the repository (Article 22(1))

Article 22(1) requires that "The Commission shall establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17 ('central repository')." The scope is limited to services recognised under Article 17 — that is, services found to meet the cumulative criteria for a Union assurance level (1, 2, 3 or 4) set out in Annex II. Recital 57 explains the rationale: a central repository is needed to facilitate the secure and efficient storage, access and exchange of relevant information among public-sector customers, auditing organisations, competent authorities and the Commission.

Registration by national authorities (Article 22(2))

Execution is decentralised even though visibility is central. Article 22(2) provides that "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." Assessment and recognition happen at national level, in the Member State of the provider's establishment; the recognised service is then entered into a Union-wide register. The provider does not register itself.

Revocations and the five-year record (Article 22(3))

The repository tracks loss of status, not only current recognitions. Article 22(3) 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 and shall remain available there for five years." The five-year retention keeps a recent revocation visible even after its immediate legal effect has passed, so a provider cannot quietly disappear and re-emerge without its history being apparent.

Public availability (Article 22(4))

Article 22(4) requires that the repository be "publicly available and regularly updated by the Commission and the national competent authorities of establishment on a dedicated and easily accessible website." This is what lets procurement teams and compliance staff verify a service's recognised status through one Union-wide interface rather than fragmented national records.

Position in the recognition chain

Article 22 is the publication step in a sequence:

  1. Assessment — conformity self-assessment for level 1 (Article 19) or independent audit for levels 2-4 (Article 20).
  2. Recognition — the national competent authority of establishment grants recognition (Article 17).
  3. Publication — the service is registered in the central repository (Article 22).
  4. Procurement — public authorities procure from recognised services (Article 30).

If a service is not in the repository, it is not "recognised" for the purposes of CADA's procurement mandates, subject only to the narrow derogations in Article 30(4).

Article 22 in relation to Article 23

Article 22 (the register) and Article 23 (transparency obligations) work as a pair. Article 23 governs how a recognised provider must report material changes and how the auditing organisation and competent authority reassess the audit report, opinion and recognition. Where that process ends in amendment or revocation, Article 22 is where the result becomes publicly visible: the revocation is published under Article 22(3) and the repository is updated under Article 22(4). In short, Article 23 is the procedural engine and Article 22 is the public output. A reader trying to understand a single repository entry — current level, or a revocation notice — is seeing the visible trace of decisions taken under Articles 17, 20 and 23.

What the proposal leaves to later detail

Article 22 sets the obligation, the responsibilities and the public character of the repository, but several operational matters are not spelled out in the article itself. The precise data fields, the format of entries, and the technical arrangements for the "dedicated and easily accessible website" are not prescribed in Article 22; they would be worked out in implementation. Article 17(12) allows the Commission to adopt implementing acts on the practical arrangements for the recognition procedures that feed the repository. As with the rest of CADA, these details would only take shape once the proposal is adopted and the framework becomes operational.

What this means for you

For in-house counsel and compliance officers, Article 22 changes how recognised cloud services are identified and monitored.

Simpler due diligence. Rather than independently reconstructing a provider's legal structure, data location and audit status, you can check whether the service is listed at the required level (Article 22(4)). A listing reflects that the Annex II criteria for that level were met at recognition.

Ongoing monitoring. Compliance is continuous. Because revocations are published for five years (Article 22(3)), monitoring the repository for changes to current providers' status is a sensible risk-management step — a revocation may put you in breach of internal policy or of an Article 30 mandate.

Procurement enablement. For public bodies, Article 30 requires procuring recognised services for relevant activities; the repository is the tool that makes that workable. If a preferred provider is not listed at the required level, it cannot be used for the relevant workloads unless an Article 30(4) derogation applies.

What it does and does not contain. The repository records the service and its assurance level, plus revocations — not customers' data, and not the detailed audit evidence, which stays with auditing organisations and authorities under confidentiality (Article 20(3)).

Common misconceptions

"The repository lists all cloud providers in the EU." No. It lists only services recognised under Article 17. Absence does not make a service unlawful, but it means the service cannot be used for CADA-mandated public-sector procurement.

"A listing certifies general cybersecurity." The repository records recognition against the Annex II sovereignty criteria for a level. Cybersecurity features in those criteria (for example, a European cybersecurity certificate at the "substantial" level for level 2, once such a scheme exists), but the repository is a sovereignty register, not a standalone cybersecurity certification body.

"Revocation removes a service from the repository immediately." Article 22(3) requires revocations to be published and kept available for five years. A revoked service is marked as revoked rather than simply deleted, so its recent history stays visible.

"The Commission populates the repository itself." The Commission maintains the platform, but the national competent authority of establishment registers each recognised service (Article 22(2)) — a shared-responsibility model.

Related

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