Summary Under the proposed Cloud and AI Development Act (CADA), cloud computing service providers (CSPs) recognised at Union assurance levels 1 through 4 face a continuous, active duty to monitor their operations. Article 23 mandates that providers must notify their auditing organisation and their national competent authority of establishment "as soon as possible" upon becoming aware of any information or material change in circumstances that could affect their audit report, "positive" audit opinion, or official recognition. Failure to trigger this notification mechanism promptly exposes the provider to significant enforcement risks under Article 24, including administrative penalties and civil liability for damages suffered by public sector customers.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, establishes a dynamic sovereignty framework. Unlike static compliance regimes where a certificate is valid for a fixed period regardless of intervening events, CADA treats recognition as a living status that depends on the continuous adherence to the criteria set out in Annex II. The mechanism designed to maintain this integrity is the transparency obligation found in Article 23.

This article creates a three-stage "cascade" of responsibility: the provider's duty to detect and notify, the auditor's duty to reassess, and the competent authority's duty to update the Union-wide recognition status.

Stage 1: The Provider's Duty to Detect and Notify (Article 23(1))

The primary obligation rests on the recognised cloud computing service provider. Article 23(1) states:

"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, the recognised cloud computing service provider shall, as soon as possible, notify the auditing organisation and the national competent authority of establishment."

This provision imposes a strict timeline and a broad scope:

  • The Trigger: The obligation is triggered by "becoming aware." This is a subjective standard that becomes objective in enforcement; a provider cannot claim ignorance if a reasonable monitoring system would have detected the change. The change must be "material," meaning it has the potential to alter the validity of the audit findings or the recognition decision.
  • The Scope: The change must be capable of affecting either the audit report/opinion (the technical assessment) or the recognition (the legal status granted by the state). This covers a wide range of scenarios, from changes in ownership structure (Article 17) and infrastructure location (Annex II) to cybersecurity incidents that compromise the integrity of the service.
  • The Recipients: The provider must notify two distinct entities simultaneously:
    1. The auditing organisation that issued the "positive" opinion.
    2. The national competent authority of establishment (the NCA) that granted the recognition.
  • The Timeline: The phrase "as soon as possible" implies immediate action. There is no grace period for internal deliberation once the provider is aware of the material change.

Stage 2: The Auditor's Reassessment (Article 23(2))

Once the notification is received, the burden shifts to the independent auditing organisation. Article 23(2) requires the auditor to act decisively:

"On the basis of the notification under paragraph 1, the auditing organisation shall assess whether the audit report or the audit opinion need to be amended or revoked. Where the auditing organisation amends or revokes the audit report or the audit opinion, it shall, as soon as possible, notify the national competent authority of establishment."

This stage ensures that the technical assessment remains aligned with reality. The auditor must:

  • Evaluate the material change against the criteria in Annex II.
  • Determine if the original "positive" opinion still stands.
  • If the opinion is no longer valid, the auditor must formally amend or revoke the report.
  • Crucially, the auditor must then notify the NCA of this change. The auditor cannot simply revoke the opinion and leave the NCA unaware; the regulatory chain must be closed.

Stage 3: The Competent Authority's Final Decision (Article 23(3))

The final link in the chain is the national competent authority of establishment. Article 23(3) dictates the authority's response:

"On the basis of the notification referred to in paragraph 1 or 2, the national competent authority of establishment shall assess whether its recognition needs to be amended or revoked. Where the national competent authority of establishment amends or revokes it recognition of the cloud computing service, it shall, as soon as possible, notify the national competent authorities of the other Member States and the Commission."

This step ensures Union-wide consistency. If a provider loses its status in one Member State due to a material change, that loss of status must be communicated to all other Member States and the European Commission. This prevents a situation where a provider is recognised in Germany but has lost its status in France, yet continues to be listed in the central repository as valid across the Union.

The Consequences: Penalties and Compensation (Article 24)

The transparency obligations in Article 23 are not merely administrative; they are the frontline of enforcement. Failure to comply triggers the penalty regime established in Article 24.

Article 24(1) mandates that Member States lay down rules on penalties for infringements of the sovereignty chapter by cloud computing service providers. These penalties must be "effective, proportionate and dissuasive."

Article 24(2) provides a non-exhaustive list of criteria that Member States must consider when imposing penalties. A failure to notify under Article 23 would be evaluated against factors such as:

  • The nature, gravity, scale and duration of the infringement (e.g., how long the provider operated with a revoked status before notifying).
  • Any action taken to mitigate the damage (e.g., did the provider self-report immediately upon discovery?).
  • Previous infringements by the provider.
  • Financial benefits gained or losses avoided due to the infringement (e.g., continuing to win public contracts while non-compliant).
  • The infringing party's annual turnover in the Union.

Furthermore, Article 24(3) introduces a critical civil liability risk:

"Recipients of the cloud computing services shall have the right to seek, in accordance with Union and national law, compensation from cloud computing service providers for any damage or loss suffered due to an infringement by those providers of their obligations under this Chapter."

If a public sector body procures a service based on a recognition that should have been revoked due to an unreported material change, and that change leads to a security breach or service disruption, the public body can seek full compensation from the provider. This creates a dual risk: administrative fines from the state and civil damages from the customer.

What this means for you

For cloud service providers, data centre operators, and their legal/compliance teams, Article 23 transforms compliance from a periodic audit event into a continuous operational process. You cannot rely on the annual audit cycle to "catch" changes. You must build an internal "early warning system."

1. Define "Material Change" Against Annex II

The regulation does not provide a checklist of what constitutes a "material change." You must map your internal risk registers to the criteria in Annex II. A change is material if it impacts any of the following:

  • Establishment: Changes in legal incorporation, registered office, or main establishment location.
  • Infrastructure & Assets: Relocation of servers, data storage, or backup facilities outside the Union (for levels 2-4).
  • Personnel: Changes in the citizenship or security clearance of key operational staff (for levels 3-4).
  • Control: Changes in ownership structure, voting rights, or the introduction of third-country control (for levels 2-4).
  • Subcontracting: Changes in the list of subcontractors or the location of their support operations.
  • Cybersecurity: Incidents that compromise the "state-of-the-art" standards required for the assurance level.
  • Software Supply Chain: Changes in the SBOM (Software Bill of Materials) or the introduction of third-country controlled components.

2. Implement a "Trigger-to-Notification" Workflow

Your internal process must be designed to minimize the time between "becoming aware" and "notifying."

  • Detection: Integrate automated monitoring for legal entity changes (e.g., commercial register updates), infrastructure shifts (e.g., cloud region changes), and security incidents.
  • Triage: Establish a rapid-response team (Legal, Compliance, CTO) empowered to make a preliminary "materiality" assessment within hours, not days.
  • Notification: Prepare pre-approved notification templates for both the auditor and the NCA. The notification must be sent "as soon as possible." Delaying to gather more information is a risk; it is better to notify early and update later than to miss the deadline.

3. Document the "As Soon As Possible" Decision

In the event of an enforcement action, your defense will rely on demonstrating good faith and promptness. Maintain a detailed audit trail:

  • Timestamp: Record exactly when the change was first detected.
  • Assessment Log: Document the internal review process that determined the change was material.
  • Notification Proof: Keep copies of the emails or formal letters sent to the auditor and NCA, including timestamps.
  • Mitigation: Document any steps taken immediately after notification to mitigate the impact of the change. This is a specific mitigating factor under Article 24(2)(b).

4. Prepare for the "Cascade" Effect

Understand that your notification triggers a chain reaction.

  • If you notify the auditor, they may revoke your opinion.
  • If the auditor revokes the opinion, they notify the NCA.
  • If the NCA revokes recognition, they notify all other Member States and the Commission.
  • Result: Your service may be removed from the central repository (Article 22) and become ineligible for public procurement immediately. Have a contingency plan for customers who may need to migrate off your service if your status is downgraded.

Common misconceptions

Misconception 1: "I only need to report changes that make me non-compliant." Correction: The obligation is broader. Article 23(1) requires notification of any change that "may affect" the audit report or recognition. This includes changes that might improve your status (e.g., acquiring a new subsidiary that strengthens your EU establishment) or changes that are neutral but require an update to the record. If it affects the validity of the current recognition, it must be reported.

Misconception 2: "I can wait until my next scheduled audit to report the change." Correction: This is a critical error. Article 23 explicitly requires notification "as soon as possible" upon becoming aware. Waiting for an annual audit cycle (which may be 12 months away) would be a direct violation of the transparency obligation and could be treated as a severe infringement under Article 24, potentially leading to the revocation of recognition and significant penalties.

Misconception 3: "Notifying the auditor is enough; the NCA will find out from them." Correction: Article 23(1) is explicit: the provider must notify both the auditing organisation and the national competent authority of establishment. Relying on the auditor to inform the NCA is insufficient and leaves the provider in breach of the direct notification duty.

Misconception 4: "If I didn't know about the change, I'm not liable." Correction: While the trigger is "becoming aware," the law expects providers to have robust monitoring systems in place. If a provider claims ignorance of a change that a reasonable provider with proper controls would have detected (e.g., a change in the commercial register or a major data center outage), they may be held liable for negligence. The "duty of care" implies a proactive duty to know.

Misconception 5: "Penalties are just fines; the worst that happens is a ticket." Correction: Beyond administrative fines, Article 24(3) grants public sector bodies the right to seek compensation for damages. If a public body suffers a breach because it relied on a recognition that should have been revoked due to an unreported change, the financial liability could far exceed any administrative fine.

Related

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