Summary As proposed, the Cloud and AI Development Act (CADA) would establish a central repository of cloud computing services recognized under specific Union assurance levels, serving as the mandatory source of truth for public sector procurement. For a CTO, this means your cloud strategy must pivot from evaluating "trust" to verifying Article 22 registration status. You must map your data sensitivity to the correct assurance tier (Level 1 baseline vs. Levels 2–4 for public order), anticipate procurement mandates under Article 30, and build architectural resilience against the risk of recognition revocation. Ignoring this register could disqualify your organization from public contracts or leave you non-compliant with new sovereignty mandates.

Detail

The CADA proposal represents a paradigm shift in how the EU governs cloud infrastructure. It moves away from vague concepts of "trust" toward a rigid, auditable framework of tiered assurance levels. At the operational heart of this framework is the central repository of recognized cloud computing services, established under Article 22. This repository is not a marketing directory or a voluntary certification list; it is a legally significant registry that determines the eligibility of providers for public sector procurement.

For a Chief Technology Officer (CTO), the repository transforms cloud strategy from a purely technical or commercial decision into a compliance-critical function. The following analysis details how to integrate this register into your architecture, procurement planning, and risk management.

The Central Repository: The Single Source of Truth (Article 22)

Article 22 mandates that the Commission shall establish and maintain a dedicated repository of cloud computing services that have been recognized in accordance with Article 17. This repository serves as the definitive verification point for public authorities and, by extension, the private sector entities supplying them.

Key operational features of the repository as proposed include:

  • Public Accessibility and Transparency: The repository must be publicly available and regularly updated by the Commission and national competent authorities on a dedicated, easily accessible website. This ensures that any stakeholder can verify the current status of a provider.
  • Revocation Visibility and Historical Record: Crucially, Article 22 stipulates that the revocation of an audit report or the revocation of a recognition by a competent authority "shall be published in the central repository and shall remain available there for five years." This creates a permanent, transparent record of non-compliance or loss of status, preventing providers from simply "resetting" their reputation after a failure.
  • Registration Responsibility: The national competent authority of the provider's establishment is responsible for registering the service. This creates a clear chain of accountability: the provider undergoes self-assessment (Level 1) or independent audit (Levels 2–4), the auditor issues an opinion, the national authority validates and registers the service, and the Commission maintains the central record.

For a CTO, the implication is binary: if a provider is not listed in the repository with the required assurance level, they are effectively invisible to public sector buyers. A provider's marketing claims of "sovereignty" are legally irrelevant unless reflected in their registration status.

Procurement Mandates: The Link Between Repository and Law (Article 30)

The repository's utility is driven by the procurement obligations set out in Article 30. This article creates a direct legal dependency between the technical status of a cloud service in the repository and the procurement requirements for public bodies.

Article 30 establishes a tiered procurement approach based on the risk assessments mandated in Article 29:

  1. Minimum Baseline (Union Assurance Level 1): Under Article 30(2), Union entities and public sector bodies whose activities have not been identified as contributing to the preservation of public order must use cloud computing services that have been recognized under Article 17 as having Union assurance level 1. This is the mandatory floor for general public sector IT.
  2. Public Order Relevance (Levels 2–4): Under Article 30(3), contracting authorities whose activities have been identified as contributing to the preservation of public order (e.g., national security, internal security, defense, justice, law enforcement, and critical infrastructure sectors) "shall only procure cloud computing services that have been recognised as having a Union assurance level 2, 3, or 4."

This creates a strict procurement filter. A CTO cannot select a provider based solely on cost, performance, or feature set. They must first determine the sensitivity of their data and operations (via the risk assessment in Article 29) and then select a provider from the repository who holds the corresponding assurance level. If the repository does not contain a provider at the required level, the procurement process cannot legally proceed with that vendor.

Strategic Implications for Cloud Architecture and Planning

Integrating the CADA repository into your cloud strategy requires a shift from static vendor selection to dynamic compliance management. The following strategic pillars are essential for CTOs.

1. Vendor Qualification and Due Diligence

Your vendor evaluation matrix must include a mandatory, real-time check against the CADA repository. A provider's claim of "sovereignty" is legally insufficient unless it is reflected in their recognition status within the register. CTOs should require proof of application for recognition and actively monitor the status of their providers. If a provider is not in the repository, they are disqualified for public sector activities requiring Union assurance levels 1 through 4.

2. Tiered Data Strategy and Cost Optimization

Not all data requires the highest level of sovereignty. Article 30 distinguishes between general public services (Level 1) and those with public order relevance (Levels 2–4). A sophisticated cloud strategy will classify data and workloads accordingly.

  • Level 1: Suitable for non-critical administrative data. This tier offers a broader market of providers and potentially lower costs.
  • Levels 2–4: Reserved for sensitive, critical infrastructure, and public order-relevant data. By reserving higher assurance levels only for critical data, you optimize costs while ensuring compliance. Storing non-critical data on Level 1 services may be more cost-effective, while reserving Level 3 or 4 services for sensitive workloads ensures you meet the strictest mandates without over-engineering the entire stack.

3. Anticipating Revocation Risk and Migration

The five-year retention of revocation data in the repository (Article 22) signals that past failures will haunt providers. For CTOs, this means evaluating a provider's stability and audit history is critical. A provider with a history of near-misses or minor non-compliances might be at higher risk of future revocation.

Furthermore, Article 30 creates a direct operational risk: if a provider is removed from the repository, you lose your legal basis for using their service. While Article 22 requires revocations to be published, it does not mandate immediate migration timelines in the same way it mandates procurement. However, Article 29(6) notes that if a risk assessment requires migration to another cloud computing service, the Member State or Union entity "shall migrate within a reasonable transition period that shall not exceed 12 months."

Therefore, your architecture must support portability to other recognized providers in the repository to avoid breach of contract or legal non-compliance. Your strategy should include contractual clauses that allow for exit or migration if a provider's recognition status is downgraded or revoked, ensuring business continuity within the 12-month window.

4. Multi-Cloud Resilience

To mitigate the risk of a single provider's revocation, CTOs should consider a multi-cloud strategy where at least two providers hold the necessary assurance level for critical workloads. This ensures that if one is removed from the repository, you can failover to another compliant provider without disrupting public order-relevant services. This approach aligns with the resilience objectives of the proposal and reduces the "single point of failure" risk inherent in relying on a single recognized vendor.

What this means for you

As a CTO or architect, you must treat the CADA repository as a core component of your vendor risk management and procurement strategy. Here are actionable steps to prepare:

  • Audit Current Vendors: Check if your current cloud providers are in the CADA repository (once established). If they are not, and you serve public sector clients or are a public body yourself, you are at immediate risk. Begin engaging with providers about their roadmap to achieving Union assurance levels and undergoing the necessary audits.
  • Map Data to Assurance Levels: Conduct a rigorous classification of your data and services. Identify which workloads fall under "public order relevance" as defined in Article 30 and Article 29. This will dictate which tier of the repository you must draw from. Do not assume all data requires Level 4; use the tiered approach to balance cost and compliance.
  • Update RFPs and Contracts: Include clauses that require vendors to maintain their recognition status in the central repository. Define clear exit strategies and migration support obligations in the event of a revocation or downgrade, referencing the 12-month migration window noted in Article 29. Ensure contracts allow for immediate suspension of services if a provider loses their status.
  • Plan for Multi-Cloud Resilience: To mitigate the risk of a single provider's revocation, consider a multi-cloud strategy where at least two providers hold the necessary assurance level for your critical workloads. This ensures that if one is removed from the repository, you can failover to another compliant provider.
  • Monitor the Repository: Establish a process to regularly monitor the central repository for changes in your providers' status. Automation tools may be necessary to track these updates in real-time, given the legal implications of sudden revocations. The five-year retention of revocation data means you must also monitor the historical status of potential new vendors.

Common misconceptions

"The repository is just a list of EU providers." Incorrect. The repository is a list of recognized services that have met specific, audited criteria for Union assurance levels. An EU-based provider is not automatically in the repository; they must undergo self-assessment (Level 1) or independent audit (Levels 2–4) and be recognized by a national competent authority. A non-EU provider could theoretically be recognized at Level 3 if the Commission adopts an implementing act under Article 18 regarding third-country assurances, though this is a high bar.

"I only need to worry about this if I am a government agency." While Article 30 directly binds public sector bodies, the ripple effect is significant. Private sector entities, especially those in critical sectors (NIS2 entities), may face similar pressures or customer demands. Furthermore, if you supply services to public bodies, your cloud infrastructure must comply with their procurement requirements. If your provider is not in the repository, you cannot be a vendor for the public sector.

"Once a provider is in the repository, they are safe forever." No. Recognition is subject to annual review and potential revocation. Article 22 explicitly requires revocations to be published. A provider can lose their status due to non-compliance, changes in ownership, failure to maintain cybersecurity standards, or changes in third-country control. Your strategy must account for this dynamic risk.

"Level 1 is too low to be useful." Level 1 is the mandatory baseline for most public sector activities not deemed critical to public order. It requires EU establishment, data localization within the Union, and compliance with state-of-the-art cybersecurity standards. For many use cases, this is sufficient and offers a broader market of providers. Reserving higher levels for critical data is a more efficient strategy.

Related

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