Summary As proposed in the Cloud and AI Development Act (CADA), the central repository would be the publicly available record of cloud computing services that have been recognised under Article 17 as offering a Union assurance level. Under Article 22, each entry would correspond to a recognised service at a specific level (1 to 4), registered by the national competent authority that recognised it. The repository would also publish revoked audit reports and opinions and revoked recognitions, which must remain visible for five years (Article 22(3)). CADA is a draft proposal, so the repository does not yet exist.

Detail

The central repository, established under Article 22, is the part of CADA's sovereignty framework that turns abstract assurance levels into something a buyer can actually look up. It is established and maintained by the European Commission, and populated by the national competent authorities that grant recognition.

Recognised services and their assurance level

The repository catalogues cloud computing services that have completed the recognition process in Article 17 and shows the Union assurance level each service has been recognised to offer. There are four cumulative levels, with criteria set out in Annex II:

  • Level 1 is the baseline. Annex II requires, among other things, that the provider is established in the Union; that infrastructure, assets and customer data (including metadata and telemetry) remain in the Union unless the public-sector body explicitly requires otherwise; that the service meets state-of-the-art cybersecurity standards; and that there is full transparency around subcontractors.
  • Levels 2, 3 and 4 add further cumulative criteria. As an audited provider moves up a level it must satisfy all the lower-level criteria as well (Article 20(1)). Higher levels are the ones that public-order-relevant activities must use under Article 30.

The level shown for a service reflects the recognition decision, not a self-declaration. Article 22(2) provides that the national competent authority of establishment that recognised the service registers it in the repository, which is what confirms it met the cumulative criteria for that level.

Public availability

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 allows a buyer, anywhere in the Union, to verify a service's recognised status through a single interface rather than chasing national records. Recital 57 frames the repository as facilitating secure and efficient access to, and exchange of, this information among public-sector customers, auditing organisations, competent authorities and the Commission.

Revocations and loss of status

The repository is not only a list of currently recognised services; it also records the loss of recognition. Article 22(3) provides 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."

It is worth being precise here: what is published is the revocation of an audit report/opinion or of a recognition, not every "negative" audit opinion in the abstract. A negative audit opinion would mean a service is not recognised at the level sought in the first place; the repository's revocation entries concern services that had recognition (or a positive opinion) and then lost it.

The five-year retention period serves several purposes:

  1. Historical accountability — buyers can see if a previously recognised service later lost its status.
  2. Risk management — a pattern of revocations may signal instability in a provider's ability to maintain its assurance level.
  3. Market integrity — a provider cannot quietly drop off the list and reappear without its recent history being visible.

What the repository is not

The proposal establishes the repository's existence, contents and public nature, but the underlying technical detail is held elsewhere. The detailed audit evidence sits with the auditing organisations and competent authorities and is subject to confidentiality and professional-secrecy duties (Article 20(3)). The repository records the outcome — recognition at a level, or revocation — rather than the full audit file.

In fact, Article 20(3) expressly limits what may even leave the audit process: auditing organisations must ensure confidentiality and professional secrecy over information obtained during audits, and under Article 23 the auditing organisation is to share only information necessary for reporting purposes that does not contain anything reasonably considered confidential. The repository is consistent with that logic — it surfaces status, not the sensitive technical and commercial detail behind it.

How current is the information?

The proposal requires the repository to be "regularly updated" (Article 22(4)) but does not promise real-time accuracy. The update path runs through people and processes: a provider notifies a material change (Article 23(1)); the auditing organisation and the authority assess it (Article 23(2)-(3)); and only if recognition or an audit report/opinion is amended or revoked does the entry change. For audited levels, the annual review under Article 20(8) is a further regular checkpoint. A practical reading is that the repository reflects the most recent formal decision about a service, which may lag a very recent operational change. That is one reason the framework also places an active reporting duty on providers rather than relying on the register alone.

Why both current status and revocations are shown

Showing only current recognitions would let a service that had lost its status simply vanish from view. By keeping revoked audit reports/opinions and revoked recognitions visible for five years (Article 22(3)), the repository gives a buyer the fuller picture needed for a considered procurement decision: not just "is this service recognised now?" but "has this service's recognised status been stable?"

What this means for you

For public-sector procurement officers and legal teams, the repository would be the primary tool for confirming sovereignty status before and during a contract.

  1. Verify before you award. Check that a service is listed at the level your risk assessment requires (level 1 for general activities; levels 2-4 for public-order-relevant activities under Article 30). A service that is not listed at the right level cannot be procured under the Article 30 rules, save for the limited derogations in Article 30(4) (for example, where no adequate recognised alternative exists).
  2. Rely on recognition, not self-declaration. The listing is an authoritative, EU-wide statement of recognised status, which reduces the need to take a provider's word for its compliance.
  3. Monitor during the contract. If a service's recognition is amended or revoked, that change should appear in the repository; you would need to react accordingly. CADA does not, in the proposal text, set a fixed migration deadline for this situation, so plan transition arrangements into your contracts.
  4. Read the revocation history. A revocation visible from a few years ago may legitimately inform how you weigh a provider for a high-assurance contract today.

Common misconceptions

  • "The repository lists every cloud provider operating in the EU." No. It lists only services recognised at a Union assurance level. Many providers may operate in the EU without seeking recognition; they would not appear and would be ineligible for CADA-mandated public procurement.

  • "Once a service is listed, its status is permanent." Recognition is conditional and subject to annual review for audited levels (Article 20(8)) and to revocation (Articles 17(11), 20(7), 22(3)). The repository reflects current status and records past revocations.

  • "The repository contains the full audit reports." It records recognised status and revocations. The detailed audit evidence is held by auditing organisations and competent authorities under confidentiality (Article 20(3)); the repository shows the result, not the underlying documentation.

Related

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