Summary Under the proposed Cloud and AI Development Act (CADA), Article 22 and Article 23 form the backbone of the Union's cloud sovereignty transparency framework, but they serve distinct roles. Article 22 establishes the central repository, a public, Commission-maintained database listing all cloud services recognized at Union assurance levels 1 through 4. Article 23 imposes active transparency obligations on cloud providers, requiring them to notify auditors and authorities immediately of any "material change in circumstances" that could affect their recognized status. In short: Article 22 provides the static public record, while Article 23 provides the dynamic mechanism that ensures that record remains accurate. Without Article 23, the Article 22 repository would quickly become obsolete; without Article 22, the notifications under Article 23 would lack a centralized, public-facing output.

Detail

The proposed CADA (COM(2026) 502 final) seeks to reduce the EU's strategic dependence on non-European cloud providers by establishing a harmonized "Union cloud computing sovereignty framework." This framework relies on a recognition mechanism where providers are audited and certified at one of four assurance levels. The integrity of this system depends entirely on the interplay between the infrastructure for public visibility (Article 22) and the behavioral duties of the providers (Article 23).

Article 22: The Central Repository of Recognized Services

Article 22 is the structural pillar of the CADA transparency regime. It mandates the European Commission to create and maintain a dedicated, publicly accessible database.

1. Establishment and Purpose Under Article 22(1), the Commission "shall establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17." This repository is not merely a directory; it is the single source of truth for public sector bodies and private entities seeking to comply with CADA's procurement rules. It lists services recognized as offering Union assurance levels 1, 2, 3, or 4.

2. Registration and Maintenance The responsibility for populating this repository lies with the national competent authorities. Article 22(2) states that 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 ensures that the entry into the repository is directly tied to the formal recognition decision made by the competent authority in the provider's Member State.

3. Historical Transparency and Revocation A critical feature of Article 22 is its requirement for historical transparency. Article 22(3) mandates that "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 prevents providers from "resetting" their reputation by simply re-applying after a failure; past non-compliance remains visible to the market for a significant period.

4. Public Accessibility Finally, Article 22(4) ensures that the repository "shall be publicly available and regularly updated by the Commission and the national competent authorities of establishment on a dedicated and easily accessible website." This accessibility is a prerequisite for the functioning of Article 30, which requires contracting authorities to procure only from services recognized in this repository.

Article 23: The Provider's Duty to Notify

While Article 22 builds the platform, Article 23 ensures the data on that platform is current. It imposes a proactive, continuous duty on cloud computing service providers to monitor their own compliance status.

1. The Trigger: Material Changes Article 23(1) requires that a recognized provider, "on becoming aware of any information or any material change in circumstances that may affect the audit report and the 'positive' opinion under Article 20 or the recognition under Article 17," must act immediately. The provider must notify "the auditing organisation and the national competent authority of establishment" as soon as possible.

The term "material change" is broad. It encompasses any shift that could undermine the criteria in Annex II, such as:

  • A change in ownership or control by a third country.
  • Relocation of infrastructure or personnel outside the Union.
  • A security incident affecting the "state-of-the-art cybersecurity standards" required for the assurance level.
  • Changes in subcontracting arrangements that impact operational autonomy.

2. The Notification Chain Article 23 establishes a rigorous chain of accountability to ensure that a provider's notification triggers a formal reassessment:

  • Step 1 (Provider to Auditor/Authority): The provider notifies the auditor and the national competent authority (Article 23(1)).
  • Step 2 (Auditor's Assessment): The auditing organisation must assess whether the audit report or opinion needs to be amended or revoked (Article 23(2)). If they amend or revoke the opinion, they must notify the national competent authority.
  • Step 3 (Authority's Assessment): The national competent authority must then assess whether its recognition needs to be amended or revoked (Article 23(3)).
  • Step 4 (Union-wide Notification): If the authority amends or revokes the recognition, it must "as soon as possible, notify the national competent authorities of the other Member States and the Commission" (Article 23(3)).

This chain ensures that a change in one Member State is immediately communicated across the Union, preventing a provider from maintaining a valid recognition in one country while being non-compliant in another.

How They Connect: The Feedback Loop

The relationship between Article 22 and Article 23 is one of dependency and feedback. They form a closed-loop system that maintains the integrity of the CADA sovereignty framework.

  1. The Trigger: A provider experiences a material change (e.g., a third-country entity acquires a majority stake).
  2. The Duty (Art 23): The provider is legally obligated to notify the auditor and authority immediately.
  3. The Verification: The auditor and authority assess the impact. If the change violates the assurance criteria, they revoke the recognition.
  4. The Notification (Art 23): The authority notifies the Commission and other Member States of the revocation.
  5. The Update (Art 22): The Commission updates the central repository to reflect the revocation.
  6. The Public Record (Art 22): The revocation is published in the repository and remains visible for five years, alerting all public sector bodies that the provider is no longer eligible for procurement.

Without Article 23, the repository under Article 22 would be a static, potentially misleading list. A provider could lose its sovereignty credentials due to a change in control, but without a duty to report, the repository would continue to list them as "recognized," leading public bodies to inadvertently breach Article 30. Conversely, without Article 22, the notifications under Article 23 would lack a centralized, public-facing output. The market would not know the outcome of the assessments, rendering the transparency duty ineffective.

What this means for you

For legal counsel, compliance officers, and public procurement teams, the distinction between these articles dictates specific operational workflows.

For Cloud Computing Service Providers

You face a continuous compliance obligation, not a one-time certification.

  • Monitor Continuously: You must establish internal governance to detect "material changes" in real-time. This includes monitoring corporate governance, infrastructure location, and subcontractor status.
  • Trigger the Chain: Upon detecting a change, you must notify your auditor and national competent authority "as soon as possible" under Article 23(1). Do not wait for the next annual audit.
  • Prepare for Revocation: Understand that a notification under Article 23 can lead to the revocation of your recognition, which will be published in the Article 22 repository for five years. This historical record can severely impact your marketability.
  • Penalties: Failure to notify under Article 23 constitutes an infringement of the sovereignty chapter, subject to penalties under Article 24 (effective, proportionate, and dissuasive penalties).

For Public Sector Procurement Officers

The Article 22 repository is your primary tool, but it is not a "set and forget" resource.

  • Verify Before Procurement: Before issuing a tender or signing a contract, check the Article 22 repository to confirm the provider holds the required assurance level (e.g., Level 2, 3, or 4 for public-order activities under Article 30(3)).
  • Monitor During Contract: Because Article 23 allows for status changes at any time, you must monitor the repository throughout the contract lifecycle. If a provider's recognition is revoked and published in the repository, you must cease procurement from them for that specific assurance level unless an exception under Article 30(4) applies.
  • Rely on the 5-Year Rule: Use the historical data in the repository (published under Article 22(3)) to assess the long-term reliability of a provider. A history of revoked recognitions is a significant risk indicator.

For Auditing Organisations

You are the critical gatekeeper in the Article 23 notification chain.

  • Act on Notifications: When a provider notifies you of a material change, you must immediately assess its impact on the audit opinion.
  • Communicate Rapidly: If you amend or revoke an opinion, you must notify the national competent authority without delay. Your action triggers the authority's duty to update the Article 22 repository.
  • Maintain Independence: Ensure your assessment is based on the criteria in Annex II and that your audit report is substantiated, as required by Article 20.

Common misconceptions

"Article 22 is just a static list of approved vendors." Incorrect. While it functions as a list, Article 22 is a dynamic, legally mandated repository that includes historical data on revoked recognitions for five years. It is the output of a continuous verification process, not a one-time approval list.

"Article 23 only applies to major security breaches." Incorrect. Article 23(1) applies to "any information or any material change in circumstances." This is broader than security breaches. It includes changes in ownership, infrastructure location, personnel citizenship, or subcontracting arrangements that could affect the sovereignty criteria in Annex II.

"The repository updates automatically in real-time." Incorrect. The repository is updated by the Commission and national competent authorities after they have processed the notifications and assessments described in Article 23. There is a procedural lag between a provider's notification and the public update. Procurement officers must be aware that the repository reflects the status after the authority's assessment, not necessarily the provider's immediate self-declaration.

"Providers can self-certify changes without notifying authorities." Incorrect. Article 23 explicitly requires notification to both the auditing organisation and the national competent authority. A provider cannot unilaterally update their status; the authority must assess and potentially revoke the recognition before the repository is updated.

Related

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