Summary Under the proposed Cloud and AI Development Act (CADA), public-sector risk assessments (Article 29) determine the mandatory "Union assurance level" required for cloud services, while the central repository (Article 22) serves as the exclusive, verified source of providers meeting those levels. Buyers must procure only recognised services from this repository that align with their risk assessment outcomes. If no suitable service exists in the repository, strict, narrowly defined derogations under Article 30(4) apply.

Detail

The proposed Cloud and AI Development Act (CADA) establishes a tightly coupled, three-stage mechanism linking sovereign risk assessments with a centralized digital registry. This linkage is designed to ensure that public procurement decisions are both risk-proportionate and verifiably compliant with EU sovereignty standards. The relationship operates through a strict logic chain: Assessment (Article 29) defines the requirement, Verification (Article 22) validates the supply, and Procurement (Article 30) enforces the match.

1. The Risk Assessment Determines the Requirement

The process begins with Article 29, which obliges Member States and Union entities to conduct periodic risk assessments. These assessments must identify public sector activities that contribute to the preservation of public order. This specifically includes sectors falling under Annex I or II of the NIS2 Directive, as well as areas of national security, internal security, external border management, defence, justice, and law enforcement (including the prevention, investigation, detection, and prosecution of criminal offences).

The core output of this assessment is the determination of the appropriate Union assurance level (UAL). The CADA framework defines four levels of sovereignty assurance. The risk assessment dictates whether a public body requires only the baseline protections of UAL 1, or the heightened safeguards of UAL 2, 3, or 4. This step is crucial because it prevents over-regulation of low-risk activities while mandating strict controls for high-risk, public-order-sensitive functions. The assessment must consider the sensitivity, criticality, and magnitude of data processed, as well as the risk of unlawful access by third countries or service disruption.

2. The Central Repository Provides the Verified Supply

Once the required assurance level is determined, the buyer must identify a provider capable of meeting it. This is where Article 22 becomes the critical infrastructure. The Commission is required to establish and maintain a "central repository" of cloud computing services that have been formally recognised as offering specific Union assurance levels.

The repository is not merely a directory; it is a legally significant tool that acts as the single source of truth. Only services that have undergone the rigorous conformity self-assessment (for UAL 1) or independent third-party audits (for UAL 2–4) outlined in the proposalβ€”and have been validated by the national competent authority of establishmentβ€”are registered here. The repository ensures that all public buyers across the Union are accessing the same verified data regarding a provider's sovereignty status, eliminating information asymmetry and reducing the administrative burden of verifying claims individually.

3. Procurement Must Align with the Repository

Article 30 bridges the gap between the risk assessment (Article 29) and the repository (Article 22). It sets out strict procurement obligations based on the outcome of the risk assessment, mandating that buyers source their services directly from the recognised list:

  • For non-public-order activities: Article 30(2) states that Union entities and public sector bodies whose activities have not been identified as contributing to the preservation of public order under Article 29(1) shall use cloud computing services that have been recognised under Article 17 as having a Union assurance level 1. Crucially, these services must be sourced from the central repository established under Article 22.
  • For public-order activities: Article 30(3) imposes a stricter requirement. Contracting authorities whose activities have been identified as contributing to the preservation of public order (e.g., defence, critical infrastructure, law enforcement) shall only procure cloud computing services that have been recognised as having a Union assurance level 2, 3, or 4. Again, these services must be drawn exclusively from the central repository.

This creates a closed loop: the risk assessment dictates the level, and the repository provides the only valid pool of suppliers for that level. A contracting authority cannot legally procure a service at the required level if that service is not listed in the repository.

4. Derogations When No Service Exists

The proposal acknowledges that the market for sovereign cloud services is still developing. Therefore, Article 30(4) provides derogations (exceptions) to the mandatory procurement rules. A contracting authority may decide not to procure a recognised service from the repository only under exceptional, duly justified circumstances.

Specifically, a derogation applies if:

  • The subject matter of the tender cannot be supplied by recognised services available in the central repository (Article 22), and no adequate or reasonable alternative or comparable cloud computing service exists.
  • The absence of such services is not the result of an artificial narrowing down of the parameters of the public procurement procedure.
  • The contracting authority has launched a similar procurement process within the previous year but did not receive any suitable tenders or suitable participants.
  • Applying the requirements of the Regulation would require the contracting authority to procure services at disproportionate cost.

These derogations are narrow and require robust justification to prevent them from becoming a loophole that undermines the sovereignty objectives of the Act.

What this means for you

For public-sector procurement officers, IT strategists, and legal counsel, this framework fundamentally transforms how cloud contracts are planned and executed.

1. Conduct Risk Assessments Early and Accurately You can no longer treat cloud procurement as a purely technical or financial exercise. You must initiate the Article 29 risk assessment process well before drafting tender specifications. You need to determine definitively whether your specific use case falls under "public order" preservation. If it does, you are legally barred from procuring UAL 1 services, even if they are cheaper or more feature-rich. Your risk assessment document will likely need to be auditable, so ensure your methodology for determining the assurance level is robust and defensible.

2. Monitor the Central Repository Actively The central repository (Article 22) will become your primary market intelligence tool. You must check the repository to see which providers are recognised for the specific assurance level your risk assessment demands. Do not rely on provider marketing claims; rely on their status in the repository. As the market matures, the repository will update in real-time, meaning a provider's status could change. Your contract management processes should include clauses that address what happens if a provider's recognition is revoked or downgraded while a contract is active.

3. Plan for Derogations Carefully If you find that no provider in the repository meets your specific technical needs at the required assurance level, you may be tempted to use the derogation in Article 30(4). However, be aware that this requires strong justification. You must document that you have explored the repository thoroughly, that no adequate alternative exists, and that the absence of supply is not due to overly restrictive tender parameters. Using derogations frequently may signal to regulators that the sovereignty framework is not working as intended, potentially leading to stricter enforcement or additional market interventions.

4. Prepare for Multi-Cloud Strategies Article 29(9) encourages considering multi-vendor or multi-cloud strategies as part of the risk assessment. This may mean splitting workloads across different providers in the repository to mitigate dependency risks. Ensure your procurement strategy allows for the modular sourcing of services from multiple recognised providers.

Common misconceptions

Misconception: The repository is just a directory of EU-based providers. Reality: Being established in the EU is only one criterion (and primarily for UAL 1). Higher assurance levels (UAL 2–4) require independent audits, strict data localisation, personnel screening, and cybersecurity certifications. The repository lists services that have passed these rigorous checks, not just those headquartered in Europe.

Misconception: All public sector bodies must use UAL 2, 3, or 4. Reality: No. Article 30(2) explicitly states that bodies whose activities do not contribute to the preservation of public order only need to use UAL 1 services. The risk assessment under Article 29 is the filter that determines this. Using UAL 3 for a simple internal email system would be disproportionate and potentially unnecessary.

Misconception: If a provider is not in the repository, they are illegal. Reality: The repository applies to public sector procurement. Private sector entities are not legally bound to buy only from the repository, though they may choose to do so for compliance with their own risk frameworks (Article 31 allows private entities in critical sectors to conduct similar impact assessments). However, for public bodies, buying outside the repository without a valid derogation is non-compliant.

Misconception: The risk assessment is a one-time event. Reality: Article 29(1) requires risk assessments to be carried out "every two years, or whenever necessary." As threats evolve and your use of cloud services changes, your required assurance level may change, necessitating a re-evaluation of your procurement strategy against the repository.

Related

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