Summary The proposed Cloud and AI Development Act (CADA) establishes a central repository to list cloud computing services recognised under the Union sovereignty framework, but the primary text does not explicitly itemise the specific data fields for each entry. Article 22(1) mandates the Commission to establish and maintain the repository, while Article 22(2) assigns the responsibility of registering services to national competent authorities. Crucially, Article 22(3) requires that any revocation of an audit report or recognition be published and remain visible for five years. While the exact schema (e.g., specific identifiers, technical endpoints) is reserved for future implementing acts, the entry must logically contain the service identity, the recognised Union assurance level (1–4), and the current status (active or revoked) to fulfil the transparency and procurement obligations of the Act.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, introduces a "central repository" as a cornerstone of its transparency and market-access framework. This repository serves as the single source of truth for public sector bodies and private entities seeking to verify the sovereignty status of cloud services. However, the legislative text deliberately separates the obligation to create the repository from the technical specification of its data fields.

The Legal Mandate: Article 22

The architecture of the repository is defined in Article 22, titled "Central repository of cloud computing services." The article establishes the governance model and the minimum content requirements without prescribing a rigid data dictionary.

1. Establishment and Maintenance (Article 22(1)) The proposal places the operational burden on the European Commission. Article 22(1) states: "The Commission shall establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17." This ensures a unified, EU-wide platform rather than a fragmented set of national databases. The Commission is responsible for the technical infrastructure, security, and public accessibility of the system.

2. Registration Responsibility (Article 22(2)) While the Commission hosts the platform, the data entry is decentralised. Article 22(2) specifies: "The national competent authority of establishment that recognised a cloud computing service under Article 17 shall register the cloud computing service in the central repository." This creates a workflow where the national authority, having verified the provider's compliance with the criteria in Annex II, pushes the recognition data to the central system. This ensures that the data originates from the entity with the legal mandate to verify the service.

3. Revocation and Historical Transparency (Article 22(3)) A critical feature of the repository is its ability to track the lifecycle of a recognition, including its failure. Article 22(3) mandates: "The revocation of an audit report and audit opinion by an auditing organisation 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 provision ensures that:

  • Revocation Status is a mandatory field. A service cannot simply disappear from the record if its recognition is withdrawn; its history of non-compliance must remain visible.
  • Duration of Visibility is fixed at five years. This acts as a reputational safeguard, preventing providers from "hiding" past failures by re-applying immediately under a new guise.

4. Public Accessibility (Article 22(4)) 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 confirms that the data fields must be human-readable and machine-accessible to support the procurement obligations of contracting authorities under Article 30.

Implied Data Fields from the Sovereignty Framework

Although Article 22 does not list fields like "Provider VAT Number" or "Service Endpoint URL," the surrounding provisions in Title IV (Autonomy) dictate the minimum information required to make the repository functional.

Service Identity and Provider Details To satisfy the requirement of registering a service "recognised in accordance with Article 17," the entry must uniquely identify the provider and the specific service.

  • Article 17 requires providers to submit an application for recognition to the national competent authority of establishment. This application includes evidence of establishment, infrastructure location, and personnel details.
  • Consequently, the repository entry must contain the name of the cloud computing service provider, the name of the specific cloud service being recognised, and the Member State of establishment. Without these identifiers, the repository would fail to distinguish between different offerings from the same provider or different providers with similar names.

Recognised Union Assurance Level The primary purpose of the repository is to inform procurement decisions.

  • Article 16 establishes four Union assurance levels (1 to 4).
  • Article 17(7) states that upon successful recognition, "the audited service shall be recognised throughout the Union at the appropriate Union assurance level."
  • Therefore, every entry must explicitly display the Union assurance level (e.g., "Level 2" or "Level 4"). This is the critical data point for contracting authorities. Under Article 30(3), authorities procuring for public-order-relevant activities must procure only services recognised at levels 2, 3, or 4. Without a clear "Assurance Level" field, the repository could not support this mandatory procurement filter.

Audit and Conformity Status The repository must reflect the current validity of the recognition.

  • For Level 1, recognition is based on a self-assessment and an EU statement of conformity (Article 19).
  • For Levels 2–4, recognition relies on an independent audit and a "positive" audit opinion (Article 20).
  • Article 22(3) requires the publication of revocations. This implies a status field (e.g., "Active," "Revoked," "Under Review") is necessary. A service with a revoked status must be distinguishable from an active one to prevent accidental procurement of non-compliant services.

Temporal Data and Validity

  • Article 20(8) requires audited providers to submit audit reports for annual review. This implies that the repository entry must reflect the validity period or the date of the last successful audit.
  • Article 22(3) mandates the five-year retention of revocation data. This requires a historical log or a specific "Revocation Date" field that persists even after the service is no longer active.

The Role of Implementing Measures

The proposal explicitly acknowledges that the primary legislation is not the place for technical data schemas.

  • Article 46 grants the Commission the power to adopt implementing acts to ensure uniform conditions for implementation.
  • While Article 22 does not contain a specific paragraph delegating the definition of data fields, the general framework of Article 17(12) (regarding practical arrangements for recognition procedures) and the need for interoperability suggest that the Commission will adopt implementing acts to define the exact data schema.
  • These future acts will likely specify:
    • Unique identifiers (e.g., linking to the Business Registers Interconnected System - BRIS).
    • Technical metadata (e.g., service endpoints, supported regions).
    • Machine-readable formats (e.g., JSON/XML schemas) to allow automated procurement systems to query the repository.
    • Specific fields for Annex II criteria (e.g., confirmation of "Union citizenship" for personnel or "substantial" cybersecurity certification).

Until these implementing acts are adopted, the exact granularity of the data fields remains subject to the Commission's future rule-making, though the core elements (Identity, Level, Status, Revocation History) are legally mandated by the text of Article 22.

What this means for you

For technology leaders, compliance officers, and public sector buyers, the current state of Article 22 has specific implications for system design and procurement strategy.

For Cloud Service Providers (CSPs)

  • Prepare for Dynamic Data: Do not assume a static "certificate" approach. Article 23 requires providers to notify authorities of "any material change in circumstances" that may affect the recognition. Your internal systems must be capable of triggering an update to the national competent authority, which will then update the central repository.
  • Audit Readiness: Since Article 22(3) mandates a five-year public record of revocations, a single failure can have long-term reputational consequences. Ensure your audit processes (especially for Levels 2–4) are robust and that you have a clear remediation path if a "negative" opinion is issued.
  • SME Advantage: If you are an SME seeking Level 1 recognition, Article 17(3) allows your EU statement of conformity to be "directly and automatically recognised in all Member States." This implies a streamlined registration process for your entry in the repository, potentially reducing the time-to-market compared to larger providers requiring full audits.

For Public Sector Buyers and Procurement Officers

  • The Repository is the Source of Truth: Under Article 30, you are legally required to procure services at specific assurance levels. You cannot rely on marketing brochures or self-declared compliance statements alone. You must query the central repository to verify the recognised assurance level and current status of any potential vendor.
  • Automate Verification: Given that the repository will be "regularly updated" (Article 22(4)), your procurement platforms should be designed to integrate with the repository API (once defined). This allows for real-time validation of vendor status before contract award.
  • Monitor Revocations: Implement automated alerts for changes in the repository. If a provider's status changes to "Revoked," Article 22(3) ensures this remains visible for five years. You must have a contingency plan to migrate away from such providers immediately to avoid breaching Article 30 procurement obligations.

For IT Architects and Developers

  • Design for Interoperability: While the specific fields are not yet fixed, the requirement for a "dedicated and easily accessible website" (Article 22(4)) suggests a standardised, likely API-driven interface. Architect your systems to consume structured data (e.g., JSON) rather than unstructured text.
  • Data Privacy: Note that the repository contains recognition data, not the full audit reports. Article 20(3) protects the confidentiality of information obtained during audits. The repository will likely expose only the outcome (Level, Status) and not the sensitive technical details of the audit evidence.

Common misconceptions

Misconception 1: The repository contains full audit reports and sensitive technical data.

  • Reality: No. Article 22 mandates the publication of the recognition and the revocation. The actual audit reports, detailed evidence, and trade secrets remain confidential between the provider, the auditing organisation, and the competent authorities, protected by Article 20(3). The repository is a status register, not a document archive.

Misconception 2: The data fields are fully defined in the CADA proposal text.

  • Reality: The proposal only mandates the existence and public nature of the repository (Article 22). The specific data fields (e.g., whether it includes IP ranges, specific hardware locations, or detailed SBOMs) will be defined in future implementing acts. Providers should not assume a minimal dataset; they should prepare for comprehensive transparency as defined by the Commission later.

Misconception 3: Revocations are removed from the repository immediately after a new application.

  • Reality: Article 22(3) explicitly states that revocations shall remain available in the repository for five years. This is a deliberate design choice to ensure that past non-compliance or security failures remain visible to potential customers for a significant period, preventing "reputation laundering."

Misconception 4: The repository is a static list updated only annually.

  • Reality: Article 23 requires providers to notify authorities of material changes "as soon as possible." Combined with Article 22(4)'s requirement for the repository to be "regularly updated," the system is designed to be dynamic, reflecting real-time changes in a provider's compliance status.

Related

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