Summary Under the proposed Cloud and AI Development Act (CADA), public procurement is inextricably linked to the central repository established by Article 22. Contracting authorities would be legally required to procure only cloud computing services formally recognised at the appropriate Union assurance level, as verified through this repository. Article 30(2) sets the baseline requirement for general public sector activities (Union assurance level 1), while Article 30(3) mandates higher assurance levels (2, 3, or 4) for activities contributing to the preservation of public order. Crucially, Article 30(4) ties the ability to derogate from these rules directly to the repository: a contracting authority may only bypass the requirement if the subject matter cannot be supplied by recognised services available in the central repository. This makes the repository the definitive "source of truth" for compliance, market availability, and legal justification for any exception.

Detail

The proposed Cloud and AI Development Act (CADA) creates a closed-loop system where technical sovereignty certification drives public procurement decisions. Unlike previous frameworks where compliance might be self-declared or verified through disparate national registers, CADA centralises the validation of cloud sovereignty into a single, Union-wide digital register. This mechanism ensures that public funds are directed exclusively toward services that have undergone rigorous, independent assessment for Union assurance.

The Central Repository: The Definitive Source of Truth

Article 22 of the CADA proposal establishes the legal architecture for the central repository of cloud computing services. This is not a passive directory but a dynamic, legally binding register maintained by the European Commission. Its primary function is to provide a single point of access for verifying the sovereignty status of cloud services across the entire Union.

Under Article 22(1), the Commission is mandated to "establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17." The recognition process itself is rigorous: for Union assurance level 1, providers submit a self-assessment and an EU statement of conformity; for levels 2, 3, and 4, providers must undergo independent third-party audits and obtain a "positive" audit opinion.

Once a service is recognised, Article 22(2) imposes a strict obligation on the national competent authority of establishment to "register the cloud computing service in the central repository." This registration is the final step that transforms a provider's claim of compliance into a legally recognised status.

The repository is designed for transparency and accountability. Article 22(4) states that the 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 ensures that procurement officers, auditors, and the public can access real-time data on which services are compliant.

Furthermore, Article 22(3) addresses the lifecycle of recognition. It 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 and shall remain available there for five years." This historical record prevents "zombie recognitions," ensuring that a service that has lost its status due to non-compliance or material changes remains visible as revoked, thereby protecting public bodies from inadvertently procuring non-compliant services.

Procurement Obligations: The Article 30 Mandate

The operational link between the repository and public spending is defined in Article 30, which sets out the obligations for contracting authorities. The core principle is that public bodies would be prohibited from procuring cloud services that are not formally recognised in the central repository at the level required by their specific risk profile.

Article 30(2) establishes the baseline obligation for general public sector activities. It states that "Union entities and public sectors bodies whose public sector activities have not been identified as contributing to the preservation of public order under the risk assessment referred to in Article 29(1) shall use cloud computing services that have been recognised under Article 17 as having a Union assurance level 1." In practice, this means that for standard administrative tasks, a procurement officer must verify that the chosen service is listed in the central repository with a level 1 recognition.

For activities with higher sensitivity, Article 30(3) imposes a stricter mandate. It requires that "Contracting authorities... whose activities have been identified as contributing to the preservation of public order... shall only procure cloud computing services that have been recognised as having a Union assurance level 2, 3, or 4." The specific level (2, 3, or 4) is determined by the risk assessment conducted by Member States under Article 29, which considers factors such as national security, defence, justice, and law enforcement. Crucially, the procurement officer would be required to cross-reference the tender with the central repository to confirm that the service holds the specific higher-level recognition mandated by the risk assessment.

The Repository as the Gatekeeper for Derogations

The most critical interaction between procurement and the repository occurs in the derogation mechanism. Article 30(4) allows contracting authorities to deviate from the recognition requirements, but only under exceptional and narrowly defined circumstances. The repository acts as the primary evidence base for these exceptions.

Article 30(4)(a) explicitly ties the derogation to the repository's contents. It permits a derogation "where the subject matter of the tender cannot be supplied by recognised cloud computing services available in the central repository referred to in Article 22." This clause creates a legal presumption: if a service is not in the repository, it is not "available" for the purpose of the procurement. Conversely, if a service is in the repository at the required level, the contracting authority would generally be barred from claiming that no adequate alternative exists. The officer would be required to demonstrate that they searched the repository and found no suitable recognised services before invoking this derogation.

Additionally, Article 30(4)(b) allows for a derogation if "the contracting authority has launched a similar procurement process within the previous year but did not receive any suitable tenders." While this does not explicitly mention the repository, the evaluation of "suitable tenders" would inherently depend on the repository. A tender offering a service not listed in the central repository would be considered non-compliant and thus "unsuitable." Therefore, the repository serves as the benchmark for determining whether a previous tender failed due to a lack of market supply or a lack of compliant bidders.

Finally, Article 30(4)(c) allows for a derogation where "applying the requirements of this Regulation would require the contracting authority to procure services at disproportionate cost." Even in this cost-based exception, the repository remains relevant. The authority would need to prove that the cost of procuring a recognised service (as listed in the repository) is disproportionate compared to the non-recognised alternative, a comparison that relies on the repository defining the "recognised" baseline.

The Practical Workflow for Public Buyers

For a procurement officer operating under the proposed CADA framework, the workflow would be fundamentally altered by the central repository:

  1. Risk Assessment & Level Determination: Before drafting a tender, the officer would rely on the risk assessment under Article 29 to determine the required Union assurance level (1, 2, 3, or 4).
  2. Repository Search: The officer would then query the central repository established under Article 22 to identify all services currently recognised at that specific level. This step is mandatory to define the market scope.
  3. Tender Specification: The tender documents would explicitly require bidders to provide evidence of their service's recognition status, referencing the entry in the central repository.
  4. Bid Evaluation: During evaluation, the officer would verify that the service offered by each bidder is listed in the repository with the correct assurance level. A service not found in the repository would be automatically disqualified under Article 30(2) or (3).
  5. Derogation Justification: If no bids are received from recognised providers, the officer would document the search results from the central repository. This documentation would be the primary evidence required to invoke the derogation under Article 30(4)(a), proving that no recognised services were "available in the central repository."

What this means for you

As a public-sector procurement officer or a cloud service provider seeking public contracts, the proposed CADA framework would fundamentally change your operational landscape.

  • For Public Buyers: The central repository would become your primary compliance tool. You would no longer be able to rely on a provider's marketing claims or self-declarations. Your legal obligation under Article 30 would be to procure only services listed in the repository. If you need to bypass this rule, you would be required to prove that the repository contained no suitable options. Failure to check the repository could render a procurement decision legally vulnerable.
  • For Cloud Providers: To access the public sector market, you would need to undergo the recognition process and ensure your service is registered in the central repository. Without this registration, your service would be effectively invisible to public buyers under the standard rules of Article 30. You would also need to monitor the repository for revocations or updates to your status, as any change would be immediately visible to your potential clients.
  • For Market Transparency: The repository would create a level playing field. All recognised services would be visible in one place, allowing public buyers to compare options based on their assurance level. This transparency would encourage competition among EU-based providers and reduce the reliance on non-recognised third-country providers.

Common misconceptions

"If a provider is based in the EU, they are automatically compliant." Reality: Being established in the EU is a necessary condition for Union assurance level 1, but it is not sufficient. The service must be formally recognised and listed in the central repository under Article 22. Without this registration, the service would not meet the procurement requirements of Article 30.

"The central repository is just a voluntary list of providers." Reality: The repository is a mandatory legal instrument. Article 30 explicitly references it as the source for verifying recognition. The derogation clause in Article 30(4)(a) makes the repository's contents the legal benchmark for determining market availability. It is not optional; it is the gatekeeper for public procurement.

"I can use a derogation if I just prefer a non-recognised provider." Reality: Derogations under Article 30(4) are exceptional and strictly limited. You would only be able to use them if you can prove that no recognised service is available in the repository (Article 30(4)(a)), that previous tenders failed to attract suitable bids (Article 30(4)(b)), or that the cost is disproportionate (Article 30(4)(c)). Preference alone is not a valid ground.

"The repository only lists services that are currently active." Reality: Article 22(3) requires that revocations of recognition remain in the repository for five years. This ensures that procurement officers can see the full history of a provider's compliance status, preventing the procurement of services that have previously failed to meet standards.

Related

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