Is the CADA central repository a marketplace to buy cloud services?

Summary No, the CADA central repository is not a marketplace where public-sector bodies can purchase cloud services. As proposed in Article 22 of the Cloud and AI Development Act (CADA), it is a transparency register maintained by the European Commission. Its sole function is to list cloud computing services that have been formally recognised as meeting specific Union assurance levels (1 through 4). While it is the definitive source for verifying a provider's sovereignty status, it does not host bids, facilitate contracts, or process payments. Instead, it serves as the critical data source that enables contracting authorities to make informed procurement decisions in compliance with Article 30.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, introduces a dual-track approach to strengthening Europe's cloud ecosystem: a sovereignty framework for service assurance and a procurement framework for public buying. A common point of confusion arises regarding the digital infrastructure supporting these tracks. Specifically, the central repository established under Article 22 is often mistaken for a commercial platform.

The Legal Nature of the Central Repository

Under Article 22(1) of the proposal, the European Commission is mandated to:

"establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17 ('central repository')."

The text is explicit: this is a repository of recognised services, not a platform for transactions. The legal mechanism is one of transparency and verification, not commercial exchange. The repository aggregates data regarding the compliance status of cloud computing service providers, acting as the single source of truth for the Union's sovereignty framework.

The distinction is structural. A marketplace implies a venue where buyers and sellers meet to negotiate price, terms, and delivery. The CADA central repository contains no such functionality. It does not display pricing, accept purchase orders, or manage vendor relationships. Its content is strictly limited to the administrative outcome of the recognition process: the fact that a service has been verified against the criteria in Annex II and assigned a specific Union assurance level.

How the Repository is Populated and Maintained

The integrity of the repository relies on a strict chain of custody involving national competent authorities, not self-service by providers. Article 22(2) clarifies the registration process:

"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 provision ensures that only services that have successfully passed the rigorous recognition procedure—whether through a self-assessment for Level 1 or an independent audit for Levels 2, 3, and 4—are entered into the system. A provider cannot simply "list" themselves; they must first be recognised by the competent authority in their Member State of establishment.

Furthermore, the repository is dynamic and includes historical data to ensure full transparency. Article 22(3) mandates:

"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 "negative transparency" is crucial for risk management. It ensures that if a provider loses their recognised status due to non-compliance or a failed audit, this information remains visible to the public for five years, preventing procurement officers from inadvertently selecting a non-compliant provider based on outdated information.

Public Accessibility and the Role of Transparency

To ensure the framework is effective, the repository must be accessible to all stakeholders. Article 22(4) states:

"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."

This public availability serves a specific policy goal: reducing information asymmetry. By making the recognition status of providers transparent, CADA enables private sector entities, auditors, and the general public to verify the sovereignty claims of cloud providers. However, the act of listing a service does not constitute an endorsement for purchase, nor does it create a contractual relationship. It merely confirms that the service has passed a specific regulatory hurdle defined in Annex II.

Distinction from the Common Procurement Framework

It is vital to distinguish the central repository (Article 22) from the common procurement framework (Articles 37–40). These are two separate instruments within the proposal:

The Repository (Article 22): A static, informational register. It answers the question: "Is this provider recognised at Level X?"
The Common Procurement Framework (Articles 37–40): An active mechanism for buying. It answers the question: "How can the Commission and Member States jointly purchase these services?"

The repository provides the data needed to set the technical and sovereignty requirements for procurements. For instance, a contracting authority might look at the repository to identify which providers are eligible for a tender requiring Level 3 assurance. However, the repository itself does not host the tender, the bids, or the contract award. The actual purchasing process is governed by the public procurement rules and the specific mechanisms in Articles 37–40, which allow the Commission to act as a central purchasing body.

What this means for you

For public-sector procurement officers, legal counsel, and cloud service providers, understanding the non-commercial nature of the repository is essential for compliance and strategy.

1. Verification, Not Transaction

The repository is your due diligence tool, not your shopping cart. Before initiating a tender or evaluating bids, you must consult the repository to verify if a potential supplier holds the required Union assurance level.

For Level 1: Check if the service is listed as having an EU statement of conformity.
For Levels 2–4: Check if the service has a valid recognition based on an independent audit.
Action: Do not attempt to contact providers or negotiate prices through the repository. It is a read-only information service.

2. Informing Tender Specifications

The repository enables you to draft precise, legally robust tender specifications. Instead of asking bidders to "prove sovereignty" with vague claims, you can require them to:

"Be recognised in the CADA central repository at Union assurance level [X] at the time of contract award."

This shifts the burden of proof to the pre-qualification stage and reduces the administrative burden of verifying complex sovereignty criteria from scratch. It ensures that only eligible providers can participate in your procurement procedure.

3. Mandatory Compliance Checks

Your procurement decisions are legally bound by the risk assessment results. Under Article 29, Member States and Union entities must conduct risk assessments to determine if their activities contribute to the preservation of public order.

If the risk assessment determines public order relevance, Article 30(3) requires you to procure only services recognised at Level 2, 3, or 4.
The central repository is the definitive list of these eligible services. If a provider is not in the repository at the required level, they are legally ineligible for your contract.
If the activity is not public order relevant, Article 30(2) requires a minimum of Level 1.

4. Lifecycle Monitoring

Compliance is not a one-time event. Article 22(3) ensures that revocations are published and remain visible for five years. You should periodically check the repository during the lifecycle of a long-term contract. If a provider's recognition is revoked, you may need to trigger contract termination or migration clauses to ensure continued compliance with Article 30.

5. Strategic Planning for Providers

For cloud service providers, the repository is the gateway to the public market. You cannot sell to public bodies requiring Level 2+ without being listed. The process involves:

Preparing for the audit (Levels 2–4) or self-assessment (Level 1).
Submitting evidence to the national competent authority.
Waiting for the authority to register you in the central repository.
Once listed, you can market your service as "CADA recognised," but you must still compete for contracts through standard procurement procedures.

Common misconceptions

Misconception 1: The repository is a directory for hiring providers. Many assume the central repository functions like a freelance platform or a B2B marketplace where public bodies can directly hire cloud providers. In reality, it is a regulatory register. It lists what is compliant, not who is available for hire at what price. Commercial negotiations must occur outside this system, adhering to standard public procurement procedures (e.g., TED, national portals).

Misconception 2: Being listed in the repository guarantees the best price or performance. Inclusion in the central repository confirms that a service meets specific sovereignty, security, and data residency criteria (as defined in Annex II). It does not certify cost-effectiveness, technical performance speed, latency, or customer service quality. Procurement officers must still evaluate these commercial and technical factors separately during the tender evaluation phase.

Misconception 3: Providers can self-list their services. Providers cannot simply upload their details to the repository to claim compliance. Recognition is granted only after a rigorous process involving national competent authorities and, for Levels 2–4, independent third-party audits. Article 22(2) places the onus on the national authority to register the service, ensuring that the data is verified and legally sound before it appears in the public register.

Misconception 4: The repository replaces the need for risk assessments. Some believe that if a service is in the repository, no further risk assessment is needed. This is incorrect. Article 29 requires Member States and Union entities to conduct risk assessments to determine which assurance level is appropriate for their specific activities. The repository provides the list of options, but the risk assessment dictates which option is mandatory for your specific use case. A provider listed at Level 4 may still be ineligible if your risk assessment only requires Level 2 (though Level 4 would satisfy Level 2), or conversely, a Level 2 provider would be ineligible if your assessment requires Level 4.

Misconception 5: The repository is a transaction platform. The repository does not facilitate the exchange of funds, the signing of contracts, or the management of service delivery. It is purely an informational tool. The actual procurement activities, including the potential use of the Commission as a central purchasing body, are governed by Articles 37–40, which are distinct from the transparency mechanism of Article 22.

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