Summary Under the proposed Cloud and AI Development Act (CADA), public-sector contracting authorities are generally required to procure cloud computing services recognised as offering at least Union assurance level 1 (or levels 2–4 for public-order activities). However, Article 30(4) provides a narrow derogation mechanism allowing authorities to procure non-recognised services on an "exceptional basis and where duly justified." To document this legally, you must formally record which of the three specific qualifying grounds appliesβ€”unavailability of recognised services, previous failed procurement, or disproportionate costβ€”and explicitly demonstrate that the absence of suitable providers is not the result of "artificially narrowing down the parameters of the public procurement procedure." This written justification is mandatory for audit trails and compliance with the sovereignty framework.

Detail

The proposed Cloud and AI Development Act (CADA) establishes a strict procurement framework designed to safeguard the Union's public order and reduce strategic dependencies on third-country providers. As outlined in Article 30, contracting authorities must procure cloud computing services that have been formally recognised under Article 17 as offering a specific Union assurance level.

  • Article 30(2) mandates that authorities whose activities do not contribute to the preservation of public order must use services recognised at Union assurance level 1.
  • Article 30(3) requires authorities whose activities do contribute to public order (e.g., in sectors listed in Annex I or II of Directive (EU) 2022/2555, or in national security, defence, justice, or law enforcement) to procure services recognised at Union assurance levels 2, 3, or 4.

Recognising that the market for sovereign cloud services is still maturing, the proposal includes a safety valve in Article 30(4). This provision permits contracting authorities to decide not to procure recognised services on an "exceptional basis and where duly justified." However, invoking this derogation is not a matter of administrative convenience; it requires a rigorous, evidence-based justification that aligns with one of three specific statutory grounds.

The Three Qualifying Grounds for Derogation

To lawfully invoke a derogation under Article 30(4), the contracting authority must identify and document that one or more of the following circumstances apply. The justification must explicitly state which ground is being relied upon:

1. Unavailability of Recognised Services (Article 30(4)(a))

This ground applies when the subject matter of the tender cannot be supplied by recognised cloud computing services available in the central repository referred to in Article 22. Furthermore, the authority must demonstrate that "no adequate or reasonable alternative or comparable cloud computing service exists."

  • The "Artificial Narrowing" Prohibition: The text of Article 30(4)(a) contains a critical safeguard: the derogation is invalid if the absence of suitable providers is "the result of an artificial narrowing down of the parameters of the public procurement procedure."
  • Documentation Requirement: You must prove that the tender specifications were drafted neutrally and based on functional needs, not on proprietary features unique to non-EU providers. If the technical parameters were designed in a way that only a specific non-recognised provider could meet them, the derogation is legally void.

2. Previous Failed Procurement (Article 30(4)(b))

This ground acknowledges market immaturity. It applies if the contracting authority has "launched a similar procurement process within the previous year but did not receive any suitable tenders or suitable participants."

  • Documentation Requirement: You must attach the records of the previous procurement process launched within the last 12 months. The documentation must show that the tender was open, the parameters were not artificially narrow, and the lack of response was genuine (e.g., zero bids, or bids that failed to meet the mandatory assurance level requirements).

3. Disproportionate Cost (Article 30(4)(c))

This ground applies if "applying the requirements of this Regulation would require the contracting authority to procure services at disproportionate cost."

  • Documentation Requirement: This is a high bar. A simple price difference is insufficient. You must provide a detailed financial analysis demonstrating that the cost differential is so significant that it undermines the procurement's value for money to an extent that outweighs the strategic benefits of sovereignty. The justification must explain why the cost is "disproportionate" in the specific context of the project.

The Critical Role of the Central Repository

Before claiming unavailability under Article 30(4)(a), the contracting authority is legally required to verify the central repository established under Article 22. This repository contains all cloud computing services recognised across the Union as offering assurance levels 1–4.

  • Verification Step: Your documentation must include a record of the search conducted in the repository, the date of the search, and the specific assurance levels checked.
  • Gap Analysis: If no service is found, you must explain why the existing recognised services are not "adequate or reasonable" for your specific needs. This explanation must be technical and functional, not based on a preference for a specific vendor's ecosystem.

Avoiding "Artificial Narrowing" of Parameters

The phrase "artificial narrowing down of the parameters" in Article 30(4)(a) is the most significant compliance risk in the derogation process. It is a direct anti-circumvention measure. To avoid this pitfall, your documentation must demonstrate that:

  1. Functional Specifications: Technical specifications are based on performance outcomes (e.g., latency, throughput, security standards) rather than specific proprietary technologies or brand names that only non-EU providers possess.
  2. Appropriate Lotting: The scope of the tender has not been fragmented into such small lots that no single sovereign provider can bid, unless such fragmentation is objectively justified by the nature of the work.
  3. Neutral Evaluation Criteria: The evaluation criteria do not inadvertently favour non-sovereign providers by weighting factors that only they can satisfy (e.g., requiring data centres in specific non-EU locations when the service does not legally require it).

If a derogation is challenged during an audit or by a competitor, the primary question will be whether the authority made a genuine effort to source sovereign services and whether the market failure was real or constructed through restrictive tender design.

What this means for you

As a public-sector procurement officer, you are the first line of defense in implementing the EU's cloud sovereignty strategy. When preparing a tender for cloud computing services, follow these steps to ensure your derogation documentation stands up to scrutiny:

  1. Check the Repository First: Before drafting your tender, consult the central repository (Article 22) to see if recognised services exist for your needs. If they do, you generally cannot use a derogation unless you can prove cost disproportionality or specific technical unavailability.
  2. Conduct a "Narrowing" Self-Assessment: Before publishing the tender, have your legal or technical compliance team review the specifications. Ask: "Could a Union-assured provider bid on this?" If the answer is no, revise the parameters to be more neutral. Document this review process.
  3. Create a Formal Justification File: If you believe a derogation under Article 30(4) is necessary, create a dedicated document. Do not rely on verbal approvals or internal emails. This document must:
    • Explicitly cite the specific paragraph of Article 30(4) (a, b, or c).
    • Include evidence of the market research (repository search logs, outreach to providers).
    • Include the self-assessment confirming no artificial narrowing occurred.
    • Include the cost-benefit analysis (if relying on ground c) or previous tender records (if relying on ground b).
  4. Monitor Market Development: The derogation is "exceptional." As the market for sovereign cloud services grows, the justification for derogations will become harder to sustain. Regularly review your procurement strategies to align with the increasing availability of Union-assured services.
  5. Engage Early with Competent Authorities: If you are in a sector contributing to public order (requiring levels 2–4), engage with your national competent authority early. They may provide guidance on recognised services and help validate your market research if you believe no adequate alternative exists.

Common misconceptions

  • "I can use a derogation because the sovereign service is more expensive."
    • Correction: Cost must be disproportionate (Article 30(4)(c)). A marginal price increase is not sufficient. You must demonstrate that the cost difference is so high that it undermines the procurement's value for money to an extent that outweighs the sovereignty benefits.
  • "I can narrow the technical specs to fit my preferred non-EU provider and then claim no EU provider exists."
    • Correction: This is explicitly prohibited. Article 30(4)(a) states the derogation is invalid if the absence of recognised services is the result of "artificial narrowing down of the parameters." This is a common audit finding and can lead to procurement challenges and legal liability.
  • "A derogation is permanent."
    • Correction: Derogations are exceptional and time-bound to the specific procurement. As the market matures, authorities are expected to move toward recognised services. Repeated use of derogations without genuine market failure may be viewed as non-compliance with the spirit of the Regulation.
  • "I don't need to document the derogation if my superior approves it."
    • Correction: "Duly justified" implies a formal, written record. Verbal approval is insufficient for audit purposes. The documentation must clearly link the decision to one of the three grounds in Article 30(4) and provide the supporting evidence.

Related

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