Summary Before launching a tender, a procurement team must consult the CADA central repository to verify that candidate cloud services hold the specific Union assurance level required by the authority's risk assessment. Under Article 30, public bodies would be required to procure only services recognized at the appropriate level (Level 1 for standard activities; Levels 2–4 for public-order-relevant activities). The team must confirm the service's current status in the repository established under Article 22 and ensure no recognition has been revoked. A static vendor list is insufficient; the check must be a live verification against the EU's official register.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, introduces a mandatory verification step for public procurement of cloud computing services. Before issuing a tender, contracting authorities cannot rely solely on vendor claims, historical certifications, or marketing materials. They must perform a live check against the EU's central repository of recognized services. This process is governed by two pivotal provisions: the establishment and maintenance of the repository under Article 22, and the procurement obligations tied to sovereignty levels under Article 30.

The Central Repository: The Definitive Source of Truth

Article 22 mandates that the European Commission shall establish and maintain a dedicated repository of cloud computing services that have been recognized in accordance with Article 17. This is the "central repository."

For a procurement officer, this repository is the definitive source of truth. It is not merely a list of interested parties or a directory of EU-based providers; it is a legally binding register of services that have successfully undergone the conformity self-assessment (for Level 1) or independent third-party audits (for Levels 2–4) required for their specific assurance level.

Key features of the repository under Article 22(4) include:

  • Public Accessibility: The repository is publicly available to all stakeholders.
  • Regular Updates: It is regularly updated by the Commission and the national competent authorities of establishment.
  • Dedicated Interface: It is hosted on a dedicated, easily accessible website.

Crucially, Article 22(3) states that the revocation of an audit report, audit opinion, or recognition by a competent authority shall be published in the central repository and remain available there for five years. This means the repository is dynamic. A service that was recognized yesterday may have its status revoked today due to non-compliance, the supply of incorrect information, or a material change in circumstances. Therefore, a static list of approved vendors is insufficient; the check must occur close to the tender launch date to ensure validity.

Matching the Assurance Level to the Contract

The primary purpose of checking the repository is to ensure alignment with the procurement requirements set out in Article 30. CADA does not allow public bodies to choose any cloud provider based on price or feature set alone; it mandates procurement based on "Union assurance levels" determined by a prior risk assessment.

Article 30(2) establishes a baseline requirement: Union entities and public sector bodies whose activities have not been identified as contributing to the preservation of public order must use cloud computing services recognized as having Union assurance level 1.

Article 30(3) imposes stricter requirements for sensitive activities. Contracting authorities whose activities have been identified as contributing to the preservation of public order (such as those in national security, internal security, external border management, defence, justice, or law enforcement, including the prevention, investigation, detection and prosecution of criminal offences) must only procure cloud computing services recognized as having Union assurance level 2, 3, or 4.

Therefore, the procurement team's check in the repository serves two critical functions:

  1. Existence Check: Is the specific cloud service offered by the bidder listed in the repository?
  2. Level Check: Does the service hold the specific assurance level (1, 2, 3, or 4) that the authority's risk assessment dictates is necessary for this tender?

A service recognized at Level 1 cannot be used for a tender requiring Level 3, even if the provider is otherwise reputable or offers the lowest price. The repository will clearly indicate the assurance level for which each service is recognized. Procuring a Level 1 service for a public-order-relevant activity would constitute a breach of Article 30(3).

Handling Revocations and Status Changes

One of the most critical aspects of the pre-tender check is verifying that a service's recognition is active and valid. Article 22(3) ensures transparency regarding negative outcomes. If a national competent authority revokes a recognition because a provider supplied incorrect or misleading information, or if an auditing organization revokes an audit opinion due to non-compliance, this revocation is published in the central repository.

If a procurement team selects a bidder whose service shows a published revocation in the repository, the tender would likely be non-compliant with Article 30. The regulation requires the procurement of services recognized as offering the appropriate level. A revoked service is, by definition, no longer recognized and thus ineligible for procurement under the standard rules.

Furthermore, Article 23 imposes transparency obligations on providers to notify authorities of material changes. If a provider's circumstances change in a way that affects their compliance (e.g., a change in control by a third-country entity, a breach of data localization rules, or a failure in cybersecurity certification), they must notify the auditing organization and the competent authority. If this leads to a revocation, it will appear in the repository. The procurement team's check acts as the final gatekeeper to ensure these dynamic changes have not invalidated the provider's eligibility between the time of the risk assessment and the tender launch.

Exceptions and Derogations

While the repository check is mandatory, Article 30(4) provides limited derogations. A contracting authority may decide not to procure a recognized service if:

  • The subject matter of the tender cannot be supplied by recognized services available in the central repository, and no adequate or reasonable alternative or comparable cloud computing service exists (provided this absence is not the result of an artificial narrowing of parameters).
  • The contracting authority has launched a similar procurement process within the previous year but did not receive any suitable tenders or suitable participants.
  • Applying the requirements of Article 30 would require the contracting authority to procure services at disproportionate cost.

However, these exceptions are narrow and require robust justification. They do not remove the obligation to check the repository first. The authority must demonstrate that they have looked in the repository and found no suitable recognized service before invoking a derogation. A failure to check the repository would undermine the justification for any such derogation, as the authority cannot claim a service is unavailable if it was not verified against the official register.

What this means for you

For public-sector procurement officers, the CADA repository check is not a bureaucratic formality; it is a compliance checkpoint that protects the integrity of the tender and the security of public data. Here is how to integrate this into your workflow:

  1. Conduct the Risk Assessment First: Before looking at the repository, ensure your authority has completed the risk assessment required by Article 29. You cannot know which assurance level to search for in the repository until you know whether your activities contribute to the preservation of public order. The risk assessment determines the minimum level required (Level 1 vs. Levels 2–4).
  2. Search by Service, Not Just Provider: The repository lists cloud computing services, not just companies. A large provider may have some services recognized at Level 3 and others only at Level 1. Ensure the specific service described in the tender specifications matches the entry in the repository. A provider's general corporate status does not guarantee all their services meet the required level.
  3. Verify the Assurance Level: Cross-reference the assurance level listed in the repository with your risk assessment. If your tender requires Level 3 for a defense-related application, a Level 1 entry is a disqualification. Do not assume a higher level implies a lower one is acceptable; the regulation requires the appropriate level.
  4. Check for Revocations: Look for any indicators of revoked status. If a service was recently revoked, it will remain in the repository for five years as a warning. Do not procure from a service with an active revocation or a recent history of non-compliance.
  5. Document the Check: Keep a record of the repository check at the time of tender preparation. This demonstrates due diligence and compliance with Article 30, protecting the authority against challenges that the procurement process ignored sovereignty requirements.
  6. Update Before Award: If the tender process is long-running, re-check the repository before the final award. A provider's status could change between the publication of the tender and the signing of the contract. A service recognized at the start of the process may be revoked before the contract is signed.

Common misconceptions

Misconception 1: "If a provider was recognized last year, they are still compliant." This is incorrect. Recognition is not permanent. Under Article 20 and Article 23, providers are subject to annual reviews and must report material changes. If a provider fails an audit or changes its operational structure in a way that violates assurance criteria, its recognition can be revoked. The repository under Article 22 reflects the current status. A historical certification is not sufficient; the live repository status is what matters.

Misconception 2: "The repository contains all cloud providers in the EU." No. The repository only contains services that have successfully applied for and received recognition under Article 17. Many cloud providers may operate in the EU but have not sought or achieved CADA recognition. If a provider is not in the repository, they cannot be procured under Article 30 (unless a rare derogation applies). The absence of a provider from the repository is a definitive signal that they are not eligible for standard public procurement under CADA.

Misconception 3: "I can choose any Level 3 service for any high-risk activity." Not necessarily. While Article 30(3) mandates Levels 2, 3, or 4 for public-order-relevant activities, the specific level must be determined by the risk assessment under Article 29. Some activities may require Level 4 due to the sensitivity of the data (e.g., classified information). The repository will show which level a service holds, but the procurement team must ensure that the service's level meets the minimum requirement derived from their specific risk assessment. A Level 2 service is not automatically suitable for a use case requiring Level 4.

Misconception 4: "The repository is only for technical cybersecurity checks." The CADA sovereignty framework goes beyond technical cybersecurity. The assurance levels (detailed in Annex II of the proposal) include criteria on data localization, personnel citizenship, absence of third-country control, and software supply chain transparency. The repository confirms compliance with this broader sovereignty framework, not just technical security standards like ISO 27001 or EUCS. Checking the repository ensures you are buying sovereignty, not just security.

Official sources

Related

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