Summary The European Commission will define the operational and technical procedures for the CADA central repository through implementing acts adopted under the examination procedure specified in Article 46(2). While Article 22 mandates the establishment of this publicly accessible register of recognised cloud services, it deliberately leaves the specific technical standards, data formats, and administrative workflows to secondary legislation. This legislative design ensures the repository can adapt to rapid technological shifts in cloud infrastructure and cybersecurity without requiring a full amendment to the primary regulation, while guaranteeing uniform application across all Member States.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, introduces a Union cloud computing sovereignty framework designed to mitigate strategic dependencies on third-country providers. A critical component of this framework is the central repository of cloud computing services recognised as offering specific Union assurance levels (1, 2, 3, or 4). This repository serves as the single source of truth for public sector bodies, auditors, and the Commission to verify the sovereignty status of cloud providers.

The Mandate: Article 22

Article 22 of the CADA proposal establishes the legal obligation for the Commission to create and maintain this infrastructure. The text is explicit: the Commission "shall establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17."

The article outlines three core functional requirements for the repository:

  1. Registration by Competent Authorities: The national competent authority of establishment that recognises a cloud service under Article 17 is responsible for registering that service in the central repository. This ensures that the data originates from the verified national authority, not directly from the provider.
  2. Public Accessibility: The repository must be "publicly available and regularly updated by the Commission and the national competent authorities of establishment on a dedicated and easily accessible website." This transparency is vital for public procurement, allowing contracting authorities to verify that a provider meets the required assurance level before awarding a contract.
  3. Revocation Transparency: The article mandates that any revocation of an audit report, audit opinion, or recognition must be published in the central repository. Crucially, this record "shall remain available there for five years." This five-year retention period prevents providers from erasing their history of non-compliance, ensuring that public bodies can assess historical risks.

However, Article 22 stops short of defining how these functions are technically executed. It does not specify the data schema, the API protocols for national authorities to upload data, the security architecture for the website, or the precise workflow for updating records. These operational details are intentionally omitted from the primary text.

The Procedure: Article 46(2) and Implementing Acts

To fill this gap, the proposal relies on Article 46, which governs the adoption of implementing acts. Specifically, Article 46(2) states: "Where reference is made to this paragraph, Article 5 of Regulation (EU) No 182/2011 shall apply."

This reference triggers the examination procedure, the standard EU mechanism for adopting implementing acts that have significant implications for Member States. In the context of the central repository, the Commission will use this procedure to adopt acts that specify:

  • Technical Specifications: The exact data formats, metadata standards, and interoperability protocols required for national competent authorities to register services. This ensures that a recognition issued in France is technically identical to one issued in Germany.
  • Update and Maintenance Protocols: The detailed timelines and automated processes for how the Commission and national authorities update the repository, ensuring the "regularly updated" requirement of Article 22 is met consistently.
  • Security and Access Controls: The technical measures to protect the integrity of the repository, ensuring that while the list is public, the underlying data exchange between authorities remains secure and compliant with EU cybersecurity standards.

Why Operational Detail is Left to Implementing Acts

The decision to delegate these specifics to implementing acts under Article 46(2) is a deliberate legislative strategy driven by three factors:

  1. Technological Agility: Cloud infrastructure and cybersecurity standards evolve rapidly. A primary regulation like CADA is difficult to amend and would become obsolete quickly if it contained rigid technical specifications (e.g., specific API versions or encryption standards). Implementing acts allow the Commission to update these technical rules swiftly in response to new threats or innovations without reopening the entire legislative process.
  2. Uniformity and Consistency: Without a centralised set of rules defined by the Commission, Member States might develop incompatible systems, leading to fragmentation. The examination procedure ensures that the technical rules are debated and approved by a committee of Member State representatives, guaranteeing that the repository functions as a truly Union-wide tool rather than a collection of national silos.
  3. Expertise Integration: The detailed technical requirements for a secure, high-volume data repository require input from cybersecurity experts and IT architects. The implementing act process allows the Commission to consult with bodies like ENISA and technical working groups to draft robust, practical rules that a general legislative text cannot accommodate.

What this means for you

For CTOs, cloud architects, and public sector IT managers, understanding the distinction between the mandate (Article 22) and the procedure (Article 46) is critical for long-term planning.

For Cloud Service Providers (Especially SMEs)

  • Data Readiness: While you will submit your recognition evidence to your national competent authority, the format of that submission will be dictated by the implementing acts. SMEs should prepare their compliance documentation (e.g., EU statements of conformity for Level 1, audit reports for Levels 2-4) to be structured and machine-readable, anticipating that the Commission will standardise these inputs.
  • Long-Term Visibility: Be aware that the five-year retention rule for revocations in the repository is a permanent feature of the system. A revocation is not a temporary glitch; it is a public record that will persist for half a decade. This necessitates robust internal governance to ensure that any material changes triggering a revocation are managed proactively.
  • Monitoring the Procedure: Since the technical rules are not yet final, providers should monitor the Commission's consultations on the implementing acts. These acts will define the specific "dedicated and easily accessible website" mentioned in Article 22, which will be your primary interface for verifying your own status and that of competitors.

For Public Sector Buyers and IT Architects

  • Procurement Integration: Your procurement workflows must be designed to query the central repository. The implementing acts will define the API or interface for this query. You should plan for an automated verification step that checks the assurance level of a provider against the repository before contract award, as required by Article 30.
  • Risk Monitoring: The repository is a dynamic tool. Your IT systems should be capable of ingesting updates from the repository to detect changes in a provider's status (e.g., a downgrade from Level 3 to Level 2, or a revocation). This is essential for maintaining compliance with your ongoing risk assessment obligations under Article 29.
  • Interoperability Planning: The repository will likely serve as the backbone for the EuroCloud Federation (Article 34). Design your internal systems to be flexible enough to integrate with the data standards that will be established by the Commission's implementing acts, ensuring smooth cross-border data sharing in the future.

Common misconceptions

Misconception 1: The central repository is a certification body. The repository does not perform audits or issue recognitions. It is a register that reflects decisions made by national competent authorities and auditing organisations. The Commission's role under Article 22 is purely administrative: to maintain the list. The quality and validity of the data depend entirely on the rigour of the national authorities and the independent audits conducted under Article 20.

Misconception 2: The repository's technical rules are fixed in the CADA text. This is incorrect. Article 22 sets the goal (a public, updated repository), but Article 46(2) delegates the method. The specific technical standards, data fields, and update mechanisms are not in the regulation itself but will be defined later via implementing acts. This means the "look and feel" and technical capabilities of the repository are subject to change as the Commission refines the rules.

Misconception 3: Only large providers will be listed. The repository is open to all cloud computing service providers that achieve recognition under Article 17, regardless of size. Article 17(3) explicitly provides a derogation for SMEs, allowing their Level 1 EU statements of conformity to be "directly and automatically recognised in all Member States without the need for prior recognition by the evaluating national competent authority." These SME recognitions will be registered in the central repository, ensuring they have equal visibility in the public procurement market.

Related

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