Summary Under the proposed Cloud and AI Development Act (CADA), a public contracting authority generally cannot procure a cloud computing service that is not listed in the central repository of recognised services, as Article 30 mandates the use of services recognised at the appropriate Union assurance level. However, Article 30(4)(a) provides a narrow, exceptional derogation. This allows a buyer to bypass the repository requirement only if: (1) the subject matter of the tender cannot be supplied by any recognised service in the repository; (2) no adequate or reasonable alternative exists; and (3) the absence of such services is not the result of an artificial narrowing of the procurement parameters. This is a high-bar exception requiring robust documentation, not a discretionary choice.

Detail

The proposed CADA establishes a rigid linkage between public procurement obligations and the central repository of recognised cloud computing services. For legal counsel and procurement officers, the interaction between the mandatory procurement rules in Article 30 and the repository mechanism in Article 22 defines the boundaries of lawful procurement.

The General Rule: The Repository as the Gatekeeper

The CADA proposal creates a "recognised-only" regime for public sector procurement. Article 30 sets out the mandatory assurance levels based on the nature of the public activity:

  • Article 30(2) requires Union entities and public sector bodies whose activities do not contribute to the preservation of public order to procure services recognised at Union assurance level 1.
  • Article 30(3) imposes a stricter obligation on contracting authorities whose activities do contribute to the preservation of public order (e.g., in sectors under NIS2 Annex I/II, national security, defence, justice, or law enforcement). These authorities must procure only services recognised at Union assurance levels 2, 3, or 4.

The definitive list of services meeting these criteria is maintained in the central repository established under Article 22.

  • Article 22(1) mandates the Commission to establish and maintain this repository.
  • Article 22(2) requires national competent authorities to register recognised services in it.
  • Article 22(4) ensures the repository is publicly available and regularly updated.

Consequently, the repository is not merely an informational tool; it is the legal filter for compliance. If a service is not listed, it is, by definition, not "recognised" under the framework. Therefore, procuring a non-listed service for a public-order-relevant activity would constitute a direct violation of Article 30(3), and for non-public-order activities, a violation of Article 30(2).

The Exception: Article 30(4)(a) and the Absence-of-Alternative Derogation

Recognising that the market for sovereign cloud services is still maturing and that specific, highly specialised needs may not yet be met by recognised providers, the proposal includes a derogation in Article 30(4). This paragraph allows contracting authorities to decide, on an exceptional basis and where duly justified, not to procure recognised services.

Article 30(4)(a) is the specific provision addressing the scenario where the repository is empty for a specific need. It states that the derogation applies 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, 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 creates a triple-condition test that must be met cumulatively. A buyer cannot rely on this exception unless they can prove all three elements:

  1. Inability to Supply (The "Gap" Test): The specific subject matter of the tender (e.g., a specific high-performance computing configuration, a niche AI model deployment, or a specific legacy integration) cannot be supplied by any service currently listed in the central repository. The buyer must demonstrate that a search of the repository yielded no viable matches for the technical and functional requirements.
  2. No Adequate Alternative (The "Market" Test): Even if the repository is empty for the specific need, the buyer must prove that no adequate or reasonable alternative or comparable cloud computing service exists. This implies a broader market analysis beyond just the repository. If a non-recognised service exists that could technically meet the need but lacks recognition, the buyer must assess whether it is "adequate" or "comparable." If a reasonable alternative exists (even if not yet recognised), the derogation fails.
  3. No Artificial Narrowing (The "Conduct" Test): The absence of recognised services must not be the result of an artificial narrowing down of the parameters of the public procurement procedure. This is a critical anti-circumvention clause. A contracting authority cannot draft tender specifications so narrowly or with such bespoke requirements that they effectively exclude all recognised providers, and then claim the derogation because "no recognised service can supply the need." The parameters must be objectively necessary and proportionate.

Procedural Implications and the Burden of Proof

Relying on Article 30(4)(a) is not a simple administrative step; it imposes a heavy burden of proof on the contracting authority. The requirement that the decision be "duly justified" implies a need for a comprehensive audit trail.

Required Documentation:

  • Repository Search Log: Evidence of a thorough search of the central repository (Article 22) demonstrating that no service meets the specific subject matter.
  • Market Analysis Report: A detailed analysis confirming the absence of any adequate or reasonable alternative, including non-recognised services that might be comparable.
  • Parameter Review: A justification of the tender specifications proving they were not artificially narrowed to exclude recognised providers. This may involve showing that the requirements are driven by genuine technical necessity (e.g., specific latency requirements for a defence application) rather than vendor lock-in.

Consequences of Non-Compliance: Failure to meet these conditions constitutes an infringement of Chapter IV (Autonomy) of the Regulation. Under Article 24, Member States must lay down rules on penalties for infringements by cloud computing service providers and, by extension, the procurement rules binding contracting authorities. While Article 24 leaves the specific penalty amounts to national law, it mandates that penalties be effective, proportionate and dissuasive. Furthermore, Article 24(3) grants recipients of services the right to seek compensation for damage suffered due to an infringement.

Interaction with Risk Assessments and Multi-Cloud Strategies

The decision to invoke the derogation does not absolve the authority of its broader obligations under Article 29. Member States and Union entities must conduct risk assessments to determine the appropriate Union assurance level for their activities.

  • If a risk assessment identifies a need for Union assurance level 3 or 4, and no such service is available in the repository, the authority may invoke Article 30(4)(a).
  • However, Article 29(9) explicitly requires Member States and Union entities to consider whether a multi-vendor or multi-cloud strategy is appropriate. Even when using the derogation for a specific component, the authority should assess if a hybrid approach (e.g., using a recognised service for the core infrastructure and a non-recognised service for a specific, non-critical function) could mitigate the risk.

Crucially, the derogation in Article 30(4) is an exception, not a rule. The Commission's explanatory memorandum emphasises that the framework is designed to reduce dependencies and ensure public order. Therefore, the use of the derogation should be viewed as a temporary measure until the market catches up, rather than a permanent workaround.

What this means for you

For in-house counsel, procurement officers, and compliance teams in the public sector, the absence of a service in the CADA central repository is a critical compliance trigger, not a mere administrative hurdle.

  1. Conduct a Pre-Tender Repository Audit: Before drafting any tender, you must check the central repository (Article 22) for services meeting the required assurance level (Level 1 for general use; Levels 2-4 for public order). If the service you need is not listed, you cannot proceed under the standard rules of Article 30(2) or (3).
  2. Prepare a "Duly Justified" File: If you must proceed with a non-listed service, you must prepare a robust justification file under Article 30(4)(a). This file must document:
    • The specific search conducted in the repository.
    • The technical reasons why no listed service can supply the subject matter.
    • The market analysis proving no adequate alternative exists.
    • The evidence that your tender parameters were not artificially narrowed.
  3. Scrutinise Your Specifications: Ensure your technical specifications are objectively necessary. If your parameters are so specific that they exclude all recognised providers, you will fail the "no artificial narrowing" test, rendering the derogation invalid.
  4. Monitor for Updates: The repository is dynamic. A service not listed today may be recognised tomorrow. Regularly monitor the repository to ensure you are not unnecessarily relying on the derogation when a compliant option becomes available.
  5. Anticipate Scrutiny: Be prepared to defend your decision before national competent authorities and potentially in court. The "duly justified" standard implies that the burden of proof lies entirely with the contracting authority.

Common misconceptions

  • "If a service is not in the repository, I can never buy it." Incorrect. Article 30(4)(a) explicitly provides a derogation allowing procurement if the subject matter cannot be supplied by recognised services and no adequate alternative exists. However, this is a high-bar exception, not a general rule.
  • "I can use the derogation if I just prefer a non-listed provider." Incorrect. The derogation requires that the subject matter cannot be supplied by recognised services. A mere preference for a non-recognised provider is not a valid justification under Article 30(4).
  • "The repository is just a guide, not a legal requirement." Incorrect. Article 30 mandates the use of recognised services, and Article 22 establishes the repository as the mechanism for identifying them. Procuring a non-recognised service without a valid derogation is an infringement of the Regulation.
  • "I can narrow my tender specs to exclude non-compliant providers, then use the derogation." Incorrect. Article 30(4)(a) explicitly prohibits this. If the absence of recognised services is the result of an "artificial narrowing down of the parameters," the derogation cannot be invoked. The parameters must be objectively necessary.
  • "The derogation applies to all procurement." Incorrect. The derogation applies only where the subject matter cannot be supplied by recognised services. It does not override the requirement to conduct a risk assessment under Article 29 or to consider multi-cloud strategies.

Related

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