Summary As proposed, the Cloud and AI Development Act (CADA) imposes strict, ongoing transparency obligations on cloud service providers seeking Union assurance recognition, fundamentally altering how cloud contracts and service level agreements (SLAs) must be structured. Providers must promptly notify authorities of material changes that could affect their assurance status under Article 23, while the Commission maintains a central public repository where revocations remain visible for five years under Article 22(3). Consequently, providers should embed specific notification triggers and tier-change risks into their contractual frameworks, and buyers should tie SLA performance metrics and termination rights to their provider's ongoing status in this public repository to mitigate sovereignty and operational continuity risks.

Detail

The proposed CADA introduces a rigorous sovereignty framework designed to mitigate the risks associated with dependence on third-country cloud providers. Central to this framework are transparency and monitoring mechanisms that ensure the continuous integrity of a provider's recognized status. For cloud service providers (CSPs) and data centre operators aiming to serve the EU public sector, these provisions create ongoing compliance burdens that extend well beyond initial certification. The two most critical provisions governing this ongoing transparency are Article 23, which mandates proactive reporting of material changes, and Article 22, which establishes the central repository for recognized services.

The Duty to Notify: Article 23

Article 23 establishes a dynamic transparency obligation. It is not sufficient for a CSP to achieve recognition at a specific Union assurance level and then operate in a static manner. The regulation requires active monitoring and immediate reporting throughout the lifecycle of the service.

Specifically, Article 23(1) states that a recognized cloud computing service provider must, "as soon as possible, notify the auditing organisation and the national competent authority of establishment" upon 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."

This provision creates a continuous duty of care. A "material change" is not exhaustively defined in the enacting articles but is understood in the context of the audit criteria in Annex II. This could include changes in corporate control, shifts in infrastructure location, alterations in subcontractor arrangements, or any event that might trigger the extraterritorial reach of third-country laws. The obligation is triggered by the provider's awareness, implying that CSPs must have robust internal governance and monitoring systems to detect such changes immediately.

Once notified, the chain reaction begins. Under Article 23(2), the auditing organisation must assess whether the audit report or opinion needs amendment or revocation. If they do, they must notify the national competent authority. Subsequently, under Article 23(3), the national competent authority assesses whether its recognition needs amendment or revocation. If it does, the authority must notify other Member States and the Commission. This cascade ensures that any degradation in sovereignty assurance is rapidly communicated across the Union.

The Central Repository and Public Visibility: Article 22

Article 22 establishes the infrastructure for this transparency. The Commission is required to establish and maintain a "central repository" of cloud computing services recognized under Article 17. This repository is not an internal administrative tool; it is a public-facing mechanism.

Article 22(4) mandates that the central 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 means that any buyer, competitor, or regulator can verify a provider's status at any time.

Crucially, the repository also serves as a public record of non-compliance. Article 22(3) specifies 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 five-year retention period is significant. It creates a long-term reputational and contractual risk for providers. A revocation is not a temporary blip that disappears from public view; it is a permanent scar on the provider's public record for half a decade. This visibility is designed to protect public order by ensuring that contracting authorities and private sector entities can make informed decisions based on up-to-date and historically accurate data regarding a provider's sovereignty credentials.

Implications for Contractual Frameworks

The interplay between Article 23 and Article 22 transforms standard cloud contracts. Traditional SLAs focus on uptime, latency, and support response times. Under CADA, SLAs must also account for "sovereignty uptime" and regulatory compliance status.

For providers, the risk is that a material change triggers a review, which may lead to a downgrade or revocation. If a provider's status changes, they may no longer be eligible to fulfill contracts with public sector bodies that require specific assurance levels (e.g., Level 3 or 4). Therefore, providers cannot simply promise uninterrupted service; they must promise uninterrupted compliant service.

For buyers, particularly public sector contracting authorities, the central repository becomes a key performance indicator (KPI) source. If a provider is removed from the repository, the buyer may be in breach of their own statutory obligations to use sovereign services. Thus, the provider's status in the Article 22 repository is as critical to the contract's viability as the data centre's power supply.

What this means for you

For cloud service providers and data centre operators subject to CADA, the transparency obligations require a strategic overhaul of your legal and operational contracts.

1. Embed Notification Triggers in Your Contracts You must update your terms of service and master service agreements (MSAs) to include specific clauses regarding regulatory status changes. These clauses should:

  • Define what constitutes a "material change" in the context of your specific service offering, aligning with Annex II criteria.
  • Grant you the right to suspend or terminate services if a change in your corporate structure or external legal environment triggers a mandatory notification under Article 23 that could jeopardize your assurance level.
  • Clarify that your obligation to maintain a specific assurance level is conditional on your ability to meet the audit criteria. If a material change occurs, you are obligated to notify authorities, and the resulting review period may impact your ability to serve certain clients.

2. Reflect Tier-Change Risk in SLAs Standard SLAs often include remedies for downtime, such as service credits. You should introduce similar mechanisms for "status downtime." If your recognition is under review or revoked due to a material change you had to report under Article 23, you may need to exit the market for high-assurance clients. Your contracts should allow for an orderly transition or termination in such scenarios, protecting you from liability for failing to provide a service you are no longer legally permitted to offer to certain clients.

3. Monitor the Repository Actively Since Article 22(3) mandates that revocations remain in the repository for five years, you must monitor your own listing. Ensure that any corrections or updates to your status are reflected accurately. Discrepancies between your internal compliance status and the public repository can lead to severe reputational damage and loss of trust among existing and potential clients.

4. Advise Your Buyers Proactively inform your clients, especially public sector bodies, about these obligations. Provide them with the direct link to your entry in the central repository. Encourage them to include monitoring of this repository in their own risk management frameworks. By doing so, you demonstrate transparency and build trust, which is a key differentiator in the sovereign cloud market.

Common misconceptions

Misconception 1: Transparency obligations only apply during the initial audit. Many providers believe that once they have obtained a "positive" audit opinion and recognition, their transparency duties are largely complete. This is incorrect. Article 23 creates an ongoing, dynamic obligation. Any material change post-recognition must be reported. Failure to do so can lead to revocation and penalties.

Misconception 2: The central repository is an internal EU government tool. Article 22(4) makes it clear that the repository is "publicly available." It is not a confidential register. Competitors, journalists, and the general public can access it. Providers must treat their repository listing as a public-facing brand asset, not just a regulatory checkbox.

Misconception 3: A revoked status disappears after the issue is resolved. Article 22(3) explicitly states that revocations "shall remain available there for five years." Even if you rectify the issue and regain recognition, the record of the previous revocation remains. This long-term visibility means that compliance failures have lasting consequences for your market reputation.

Misconception 4: "Material change" is vague and can be interpreted narrowly. While the term is not exhaustively defined, the context of the sovereignty framework (Annex II) implies a broad interpretation. Changes in ownership, subcontractors, infrastructure location, or applicable third-country laws are all likely to be considered material. Providers should err on the side of caution and notify authorities when in doubt, as failure to notify is itself a compliance risk.

Official sources

Related

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