Summary Under the proposed Cloud and AI Development Act (CADA), a public contracting authority may derogate from the mandatory requirement to procure recognized sovereign cloud services only if it provides duly justified evidence that one of three specific conditions is met: the service is unavailable in the central repository with no adequate alternative, a similar prior tender failed to yield suitable participants, or compliance would impose disproportionate costs. As proposed in Article 30(4), this is an exceptional measure. The authority must document a search of the central repository (Article 22), prove the absence of alternatives was not due to "artificial narrowing" of parameters, and substantiate any cost claims. Failure to provide robust, auditable evidence could render the procurement invalid.

Detail

The proposed CADA establishes a strict procurement regime to safeguard Union public order. Article 30 mandates that Union entities and public sector bodies generally procure cloud services recognized at Union Assurance Level 1, or higher levels (2, 3, or 4) for activities deemed critical to public order. However, recognizing that the market for fully sovereign, recognized services may not always meet specific technical or urgent needs, Article 30(4) provides a narrow derogation mechanism.

To invoke this derogation, a contracting authority must demonstrate that the derogation is exceptional and duly justified. The proposal outlines three specific scenarios where evidence must be gathered and preserved. These are alternative grounds; satisfying one is sufficient, but the evidence must be rigorous.

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

The most common basis for a derogation is the absence of a suitable recognized service in the market. Under Article 30(4)(a), a derogation is permitted if:

  • The subject matter of the tender cannot be supplied by recognized cloud computing services available in the central repository established under Article 22;
  • No adequate or reasonable alternative or comparable cloud computing service exists; and
  • This absence is not the result of an artificial narrowing down of the parameters of the public procurement procedure.

Evidence Required: To justify this, the contracting authority must document a comprehensive market analysis. This includes:

  • Repository Search Logs: Evidence of a thorough search of the central repository of recognized services (Article 22) showing no matches for the specific technical requirements. The search must be documented with timestamps, search terms, and filters used.
  • Technical Specification Review: Documentation proving that the procurement parameters were set broadly enough to allow for the inclusion of existing recognized services. If the parameters were overly specific (e.g., requiring a proprietary feature only held by a non-recognized provider), the derogation may be deemed invalid due to "artificial narrowing."
  • Alternative Assessment: A comparative analysis demonstrating why non-recognized services or other recognized services with slightly different features are not "adequate or reasonable" alternatives. This often involves technical impact assessments showing that alternative services would fail to meet core operational or security requirements.

2. Failure of Prior Procurement Processes (Article 30(4)(b))

A derogation may also be justified if the contracting authority has recently attempted to procure recognized services but failed to secure suitable outcomes. Article 30(4)(b) allows this if:

  • The contracting authority launched a similar procurement process within the previous year; and
  • It did not receive any suitable tenders or suitable participants.

Evidence Required:

  • Procurement Records: Copies of the previous tender documents, publication notices, and evaluation reports.
  • Timeframe Verification: Proof that the previous tender occurred within the 12-month window preceding the current derogation request.
  • Suitability Assessment: Documentation explaining why the tenders received were unsuitable (e.g., non-compliant with sovereignty criteria, technically inadequate, or financially unviable) and why no participants met the baseline requirements for recognized services.

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

The final ground for derogation relates to economic feasibility. A derogation is permitted if:

  • Applying the requirements of the Regulation would require the contracting authority to procure services at a disproportionate cost.

Evidence Required:

  • Cost-Benefit Analysis: A detailed financial comparison between the cost of procuring a recognized sovereign service and the cost of the alternative solution.
  • Proportionality Assessment: Evidence that the cost increase is not merely higher, but disproportionate relative to the value of the service, the budget of the authority, and the security benefits gained. This requires contextualizing the cost against the specific risk profile of the procurement.
  • Budgetary Constraints: Documentation of the authority's budgetary limits and how the cost of recognized services would jeopardize the delivery of essential public services.

The Role of the Central Repository (Article 22)

A critical component of the evidence chain is the central repository established under Article 22. This repository, maintained by the Commission, lists all cloud computing services recognized as offering Union Assurance Levels 1–4. Before seeking a derogation under Article 30(4)(a), authorities must verify that no suitable service exists in this repository. The absence of a service in the repository is a primary piece of evidence for unavailability. However, authorities must also ensure that their technical requirements do not inadvertently exclude services that are present in the repository but perhaps categorized differently or offering modular solutions. The search of the repository is not a formality; it is a substantive evidentiary requirement.

Documentation and Accountability

While the proposal does not specify a granular template for the derogation justification, the principle of "duly justified" implies that the reasoning must be transparent, auditable, and defensible. National competent authorities and the Commission may review these derogations to ensure they are not used to circumvent the sovereignty framework. Failure to provide adequate evidence could lead to penalties or the invalidation of the procurement process under national public procurement laws, which remain applicable alongside CADA.

What this means for you

For in-house counsel and compliance officers, the derogation mechanism is not a "get out of jail free" card but a high-risk exception that requires rigorous documentation.

  1. Conduct a Repository Check First: Before drafting a derogation justification, mandate a formal search of the Article 22 central repository. Document the search terms, filters used, and results. This is your first line of defense against claims of artificial narrowing.
  2. Map Technical Requirements: Review your technical specifications. Ensure they are functional rather than proprietary. If a non-recognized provider is the only one meeting the specs, ask why. Is it a genuine technical necessity, or a legacy preference? Document the technical rationale for why recognized alternatives are inadequate.
  3. Quantify "Disproportionate": If cost is the issue, do not just state it is "expensive." Provide a quantitative analysis. Compare the total cost of ownership (TCO) of recognized vs. non-recognized services over the contract lifecycle. Demonstrate that the price premium for sovereignty is disproportionate to the risk mitigation achieved.
  4. Track Prior Tenders: Maintain a registry of all cloud procurement attempts. If a tender failed within the last 12 months, use that as evidence. Ensure the failure was due to a lack of suitable recognized providers, not due to poorly structured tender documents.
  5. Prepare for Audit: Store all evidence (search logs, technical assessments, cost analyses, prior tender records) in a dedicated file for the procurement. This file may be requested by national competent authorities or the Commission during audits or investigations.

Common misconceptions

  • "I can derogate if a recognized service is slightly more expensive."
    • Correction: The threshold is "disproportionate cost," not just "higher cost." A modest price premium for enhanced sovereignty is expected and justified. Derogation is only for cases where the cost difference is extreme and unjustifiable relative to the service value.
  • "I don't need to check the central repository if I know my preferred provider isn't there."
    • Correction: Article 30(4)(a) explicitly requires checking the repository. You must prove that no adequate alternative exists in the repository, not just that your preferred provider is absent. There may be other recognized providers you haven't considered.
  • "Artificial narrowing only applies if I name a specific brand."
    • Correction: Artificial narrowing can occur through overly restrictive technical parameters, even if no brand is named. If your specs are tailored to a non-recognized provider's unique features, the derogation may be invalid.
  • "The derogation is permanent."
    • Correction: The derogation is tied to the specific procurement instance. Market conditions change. If a recognized service becomes available later, future procurements may need to comply with the standard rules. The justification is valid only for the current tender.

Related

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