Summary As proposed in COM(2026) 502 final, the Cloud and AI Development Act (CADA) creates a strict operational link between procurement obligations and a central transparency tool. Article 30 mandates that public-sector buyers procure only cloud services recognized under the Union assurance framework (Levels 1–4). Article 22 establishes the central repository where these recognized services are listed. The relationship is foundational: buyers must consult the Article 22 repository to identify compliant providers before issuing a tender. Crucially, the absence of a suitable service in that repository is a specific, mandatory condition for invoking the derogation in Article 30(4)(a). If a service exists in the repository, a buyer generally cannot claim an exception based on non-availability.

Detail

The proposed CADA framework is designed to eliminate fragmentation in public cloud procurement by tying legal obligations directly to a single, authoritative source of truth. This mechanism ensures that the "sovereign cloud" requirements are not merely aspirational but enforceable through a clear verification process.

The Mandate: Article 30 Procurement Obligations

Article 30 sets the binding rules for contracting authorities and Union entities. It distinguishes between two tiers of public-sector activity based on risk:

  • Baseline Requirement (Article 30(2)): For public sector activities not identified as contributing to the preservation of public order, contracting authorities must procure cloud computing services recognized as having at least Union assurance level 1.
  • Public Order Requirement (Article 30(3)): For activities identified as contributing to the preservation of public order (e.g., national security, defense, justice, law enforcement), authorities must procure only services recognized as having Union assurance levels 2, 3, or 4.

These obligations are not discretionary. They require that the chosen provider has successfully undergone either a conformity self-assessment (for Level 1) or an independent third-party audit (for Levels 2–4) and has been formally recognized by a national competent authority under Article 17.

The Tool: Article 22 Central Repository

To make Article 30 enforceable, CADA requires a centralized mechanism to verify recognition. Article 22 mandates the European Commission to establish and maintain a central repository of cloud computing services recognized in accordance with Article 17.

  • Registration: When a national competent authority recognizes a service, it must register that service in the central repository (Article 22(2)).
  • Transparency: The repository is publicly available and regularly updated. It serves as the definitive list of services that legally satisfy the "recognized" status required by Article 30.
  • Revocation: If a recognition is revoked (e.g., due to a negative audit opinion or material change in circumstances), that revocation is published in the repository and remains visible for five years (Article 22(3)).

The Critical Intersection: The "Market Check" Obligation

The relationship between Article 30 and Article 22 is one of strict dependency. A procurement officer cannot legally comply with Article 30 without referencing the Article 22 repository. The repository is the only authoritative list of services that have met the cumulative criteria of Annex II and received formal recognition.

This dependency creates a mandatory "market check" obligation. Before a contracting authority can claim that no sovereign option exists, it must first verify the contents of the central repository. The repository acts as the evidentiary baseline for determining market availability.

The Derogation Mechanism: Article 30(4)(a)

The most significant operational link between these articles is found in Article 30(4), which outlines the exceptional circumstances under which a contracting authority may decide not to procure a recognized service.

Article 30(4)(a) explicitly ties the ability to derogate to the contents of the Article 22 repository. It states that a derogation is permitted only if:

"the subject matter of the tender cannot be supplied by recognised cloud computing services available in the central repository referred to in Article 22, and no adequate or reasonable alternative or comparable cloud computing service exists, and such absence is not the result of an artificial narrowing down of the parameters of the public procurement procedure."

This provision establishes a three-part test for buyers seeking an exception:

  1. Repository Search: The buyer must demonstrate that they have searched the central repository and found no recognized service capable of supplying the subject matter of the tender.
  2. No Alternative: There must be no adequate or reasonable alternative or comparable service available.
  3. No Artificial Narrowing: The absence of a suitable service must not be the result of the buyer artificially narrowing the tender parameters (e.g., setting overly specific technical requirements that exclude all recognized providers).

If a service meeting the technical needs of the tender is listed in the Article 22 repository at the required assurance level, the buyer cannot invoke Article 30(4)(a). The existence of the service in the repository legally precludes the claim of non-availability.

Operational Workflow for Buyers

To ensure compliance with the proposed CADA framework, public-sector buyers should follow this sequence:

  1. Risk Assessment (Article 29): Determine the required assurance level (Level 1 vs. Levels 2–4) based on whether the activity contributes to public order.
  2. Repository Consultation (Article 22): Query the central repository for services recognized at the required level. This is the mandatory first step.
  3. Technical Evaluation: Assess whether the services listed in the repository can meet the functional and technical requirements of the intended procurement.
  4. Derogation Justification (Article 30(4)(a)): Only if no suitable service is found in the repository may the buyer consider a derogation. The buyer must document:
    • The specific search conducted in the repository.
    • The reasons why the available recognized services were inadequate.
    • Evidence that the tender parameters were not artificially narrowed to exclude recognized providers.

What this means for you

For public-sector procurement officers, legal counsel, and IT strategists, the interplay between Article 30 and Article 22 fundamentally changes the procurement lifecycle. The central repository is no longer just a reference tool; it is a compliance gatekeeper.

  • Pre-Tender Due Diligence is Mandatory: You cannot draft tender specifications in a vacuum. You must consult the Article 22 repository before finalizing technical requirements. If you set parameters that exclude all services currently in the repository, you risk violating the "no artificial narrowing" clause of Article 30(4)(a), rendering any subsequent derogation invalid.
  • Documentation is Your Defense: If you must invoke Article 30(4)(a) because no recognized service exists, your documentation must be robust. You must prove that you checked the repository, that the services listed were technically insufficient, and that your requirements were objectively necessary. Without this proof, the procurement could be challenged as non-compliant.
  • Dynamic Monitoring: The repository is not static. A service recognized today could be revoked tomorrow under Article 23 if material changes occur. Your procurement contracts should include clauses addressing the scenario where a provider's recognition is withdrawn during the contract term, potentially triggering a need for migration or a new procurement process.
  • Collaboration with Risk Teams: Ensure your procurement team works closely with the entity responsible for the Article 29 risk assessment. Misalignment hereβ€”such as procuring a Level 1 service for a public-order activity requiring Level 2β€”would be a direct violation of Article 30(3), regardless of whether the service is in the repository.

Common misconceptions

"The repository is just a marketing list for vendors." Incorrect. The Article 22 repository is a regulatory register. Only services that have successfully completed the rigorous recognition procedure under Article 17 and met the cumulative criteria of Annex II can be listed. A service not in the repository is legally non-compliant for public procurement under Article 30, regardless of its market reputation.

"If a service isn't in the repository, I can automatically use a non-sovereign provider." No. Article 30(4)(a) does not grant an automatic right to bypass sovereignty requirements. It allows a derogation only if no adequate alternative exists in the repository and the absence is not due to artificial narrowing of tender parameters. Buyers must still justify why the available recognized services cannot meet their needs. Cost alone is generally insufficient unless it reaches the threshold of "disproportionate cost" under Article 30(4)(c).

"The repository lists all EU-based cloud providers." Not necessarily. The repository lists only those services that have applied for and received recognition at Union assurance levels 1–4. Many EU-based providers may not yet be recognized, or may have chosen not to pursue recognition. Their absence from the repository means they cannot be procured under the mandatory rules of Article 30 unless a valid derogation applies.

"I can ignore the repository if I find a provider through other channels." No. Article 30 requires the use of services "recognised under Article 17." Recognition is formally recorded in the Article 22 repository. If a provider claims to be recognized but does not appear in the central repository, the buyer cannot legally rely on that status for compliance. The repository is the definitive proof of recognition.

Official sources

Related

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