How do public buyers find recognised cloud services on the CADA central repository?

As proposed under the Cloud and AI Development Act (CADA), public buyers identify compliant sovereign cloud services by accessing a dedicated central repos

Summary As proposed under the Cloud and AI Development Act (CADA), public buyers identify compliant sovereign cloud services by accessing a dedicated central repository established and maintained by the European Commission. This publicly accessible database lists only those cloud computing services that have been formally recognised by national competent authorities as meeting Union assurance levels 1 through 4. Crucially, the repository ensures transparency by publishing revocations of recognition or audit opinions, which must remain visible for five years. This allows procurement officers to verify current compliance, assess historical risks, and ensure that awarded contracts meet the strict sovereignty requirements of the draft regulation.

Detail

The Cloud and AI Development Act (CADA), as set out in COM(2026) 502 final, introduces a harmonised framework to strengthen the EU's cloud and AI ecosystem. A central pillar of this framework is the creation of a single source of truth for sovereign cloud services. For public-sector contracting authorities, the primary mechanism to identify eligible providers is the central repository of cloud computing services.

The Central Repository: Scope and Legal Basis

Under Article 22(1) of the proposed Regulation, the European Commission is explicitly tasked with establishing and maintaining a dedicated repository. This is not a general directory of all cloud providers operating in the EU. Instead, it is a curated, authoritative register containing only those services that have successfully completed the formal recognition process defined in the CADA sovereignty framework.

The repository serves as the definitive list for services recognised at the four Union assurance levels:

Union Assurance Level 1: The baseline requirement for public sector procurement, focusing on establishment in the Union and data localisation.
Union Assurance Levels 2, 3, and 4: Higher tiers requiring independent third-party audits, stricter personnel criteria (including Union citizenship where required), and guarantees against third-country control.

Article 22(4) mandates that this central repository shall be publicly available. It will be hosted on a dedicated and easily accessible website. This public accessibility is a deliberate design choice to empower procurement officers. It removes the administrative burden of contacting individual national authorities to verify a provider's status. Instead, buyers can independently and instantly verify whether a cloud service holds the necessary recognition for their specific procurement procedure.

How Data is Populated and Maintained

The integrity of the repository relies on a strict administrative workflow. The data is not self-populated by cloud providers. According to Article 22(2), the responsibility for registration lies with the national competent authority of establishment.

The process functions as follows:

A cloud computing service provider submits an application for recognition to the national competent authority in the Member State where it has its main establishment (as defined in Article 25(4)).
If the authority issues a positive recognition decision under Article 17, it is legally obliged to register that service in the central repository.
The Commission and the national competent authorities are responsible for regularly updating the repository.

This mechanism ensures that the information in the repository is authoritative, having been vetted by a public authority, and reflects the current legal status of the service. It prevents providers from claiming recognition without official validation.

Transparency, Revocations, and the Five-Year Rule

A critical feature of the CADA repository is its treatment of non-compliance and the loss of status. Trust in the system depends on full transparency regarding past failures. 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.

Furthermore, this information is not ephemeral. The article specifies that such revocations shall remain available in the repository for five years. This "five-year visibility" rule serves two strategic purposes:

Risk Assessment: It allows public buyers to conduct robust risk assessments under Article 29. A provider with a recent revocation visible in the repository signals a history of failing to meet sovereignty or security standards, which is a material factor in determining the suitability of a vendor for public order-relevant activities.
Market Discipline: It creates a strong incentive for providers to maintain continuous compliance. A loss of recognition is publicly recorded for a significant period, potentially affecting their ability to win public contracts and their reputation in the market.

Integration with Public Procurement Obligations

The central repository is the operational engine for the procurement obligations set out in Article 30. Public sector bodies are legally required to procure cloud services that meet specific assurance levels based on their risk assessments:

Standard Activities: For activities not identified as contributing to the preservation of public order, contracting authorities must procure services recognised at Union Assurance Level 1.
Public Order Activities: For activities identified as contributing to the preservation of public order (e.g., national security, justice, defence, law enforcement), authorities must procure services recognised at Union Assurance Levels 2, 3, or 4.

The central repository is the definitive source for verifying these statuses. Procurement documents will likely reference the repository as the primary evidence of compliance. If a service is not listed in the repository as meeting the required assurance level, it cannot be legally procured for the relevant public sector activity, except in narrowly defined exceptional circumstances (such as when no adequate alternative exists, as per Article 30(4)).

What this means for you

For public-sector procurement officers and compliance teams, the CADA central repository fundamentally changes the vendor evaluation process. Here is how you should prepare:

Verify Before You Bid: Do not rely solely on marketing materials or self-declarations from cloud providers. Before issuing a tender or evaluating bids, you must check the central repository to confirm the provider's current Union Assurance Level.
Check for Revocations: When assessing a provider's track record, actively search for any entries of revoked recognitions. A revocation visible in the repository indicates a past failure to meet sovereignty or security standards. This should be weighed heavily in your risk assessment under Article 29.
Align Tenders with Assurance Levels: Ensure your procurement specifications explicitly require services listed in the central repository at the appropriate assurance level. For standard services, this is Level 1; for sensitive activities involving public order, this is Level 2, 3, or 4.
Monitor Updates: Since the repository is updated regularly, establish a process to re-verify the status of incumbent providers during contract performance. If a provider's recognition is amended or revoked, you may need to take corrective action.
Use the Repository as Evidence: In case of audits or disputes, the entry in the central repository serves as the official proof that the procured service met the legal requirements of CADA at the time of award.

Common misconceptions

Misconception 1: Any cloud provider established in the EU is listed in the repository. Correction: No. The repository only lists services that have successfully completed the formal recognition process under Article 17 and been registered by a national competent authority. A provider may be established in the EU but not yet recognised, or may have failed the audit process. If they are not in the repository with a specific assurance level, they cannot be used for public sector procurement under CADA.

Misconception 2: The repository is managed by the cloud providers themselves. Correction: No. Providers do not self-list. The registration is an administrative duty of the national competent authority that granted the recognition (Article 22(2)). This ensures the data is verified and authoritative.

Misconception 3: Once a provider is removed from the repository, there is no record of it. Correction: No. If a recognition is revoked, the record of that revocation remains in the repository for five years (Article 22(3)). This historical data is public and accessible, ensuring transparency about past non-compliance.

Misconception 4: The repository replaces the need for a risk assessment. Correction: No. The repository tells you the status of a service (e.g., Level 2). It does not tell you which level your specific public activity requires. Public buyers must still conduct risk assessments under Article 29 to determine whether their activity involves public order and thus requires Level 2, 3, or 4, or if Level 1 is sufficient.

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