Summary The proposed Cloud and AI Development Act (CADA) would prevent "sovereignty washing"β€”where providers falsely claim high levels of trustβ€”by replacing self-declaration with a rigorous, audited verification system. As proposed, providers seeking Union Assurance Levels 2, 3, or 4 must undergo independent third-party audits, and their status must be recorded in a central repository established under Article 22. This public database serves as the single source of truth, allowing buyers to instantly verify claims. To ensure claims remain accurate over time, Article 23 imposes strict transparency duties, requiring providers to immediately report any material changes that could affect their status. Finally, Article 24 empowers Member States to impose effective, proportionate, and dissuasive penalties for infringements, while granting service recipients the right to seek compensation for damages caused by non-compliance. Together, these measures create a system where unsupported claims are exposed, and false advertising carries significant financial and legal risk.

Detail

The proposed CADA addresses the critical market failure of "sovereignty washing" by establishing a harmonised Union cloud computing sovereignty framework. This framework, defined in Article 16, creates four distinct Union Assurance Levels (UALs). While Level 1 permits a conformity self-assessment, the higher levels (2, 3, and 4)β€”which are mandatory for public sector activities contributing to public orderβ€”require independent verification. The Act prevents false claims through a triad of mechanisms: mandatory independent audits, a public central repository, continuous transparency obligations, and robust enforcement.

The Verification Barrier: Independent Audits and Recognition

Under the proposal, a cloud provider cannot simply assert that their service is "sovereign" or "trusted." For Union Assurance Levels 2, 3, and 4, the burden of proof shifts entirely to the provider and an independent auditor. Article 20 mandates that providers seeking recognition at these levels must undergo independent third-party audits at their own expense. These audits are not superficial checks; they require the provider to submit comprehensive evidence regarding their establishment, infrastructure location, personnel citizenship, data localisation, and freedom from third-country control, as detailed in Annex II.

The audit process culminates in an audit report and an audit opinion. Only a "positive" audit opinion, confirming compliance with all cumulative criteria, allows a provider to proceed to recognition. Crucially, the audit opinion alone does not grant EU-wide validity. Under Article 17, the provider must submit an application to the national competent authority of their establishment. This triggers a mutual recognition procedure where the evaluating authority notifies other Member States. If no reasoned objections are raised within a 60-day review period, the service is recognised across the Union. This peer-review mechanism ensures that a provider cannot exploit regulatory gaps in a single Member State to make false EU-wide claims.

The Central Repository: A Public Source of Truth

The most powerful tool against false claims is the central repository mandated by Article 22. This provision requires the Commission to establish and maintain a dedicated, publicly available repository of all cloud computing services recognised under the sovereignty framework. This is not a private internal list; it is a public-facing database regularly updated by the Commission and national competent authorities.

The repository functions as a critical anti-fraud mechanism in three ways:

  1. Immediate Verification: Public buyers, civil society, and competitors can instantly verify a provider's claimed assurance level. If a provider markets their service as offering Union Assurance Level 4, but they are not listed in the repository with that specific status, the claim is demonstrably false. This eliminates the ability of providers to rely on ambiguous marketing language or unverified self-declarations.
  2. Permanent Record of Non-Compliance: Article 22(3) explicitly states that the revocation of an audit report or a recognition must be published in the central repository and remain available for five years. This creates a permanent, public record of failure. A provider that has been stripped of their status due to non-compliance cannot simply rebrand and re-enter the market without this history being visible to potential customers.
  3. Standardisation: By centralising recognition, the repository eliminates the confusion caused by divergent national labels or proprietary "trust marks." It forces all providers to conform to the single, EU-wide criteria set out in Annex II, preventing the fragmentation of the market and the proliferation of misleading national certifications.

Continuous Transparency: Catching Drift and Change

Sovereignty is not a static attribute; it can be compromised by changes in ownership, infrastructure, or legal jurisdiction. To prevent providers from obtaining a high assurance level and then silently degrading their compliance posture, Article 23 imposes strict, ongoing transparency obligations.

Under Article 23(1), a recognised cloud computing service provider must, "as soon as possible," notify both the auditing organisation and the national competent authority of establishment of any information or material change in circumstances that may affect the audit report, the audit opinion, or the recognition. These changes could include:

  • A shift in ownership or control that introduces third-country influence.
  • A change in the location of data centres or critical infrastructure.
  • Modifications to subcontracting arrangements that compromise data localisation or operational autonomy.

Upon receiving such notification, the auditing organisation must assess whether the audit report or opinion needs to be amended or revoked. Similarly, the competent authority must assess whether the recognition needs to be amended or revoked. If the status is amended or revoked, the authority must notify other Member States and the Commission. This continuous monitoring loop ensures that a provider's sovereignty claim remains valid over time and that any "drift" away from compliance is detected and acted upon immediately.

Penalties and Compensation: The Deterrent

To ensure these verification and transparency mechanisms are not merely theoretical, Article 24 establishes a robust enforcement framework. Article 24(1) requires Member States to lay down rules on penalties applicable to infringements of the sovereignty chapter by cloud computing service providers. These penalties must be "effective, proportionate and dissuasive."

The article provides a non-exhaustive list of criteria for imposing penalties, including:

  • The nature, gravity, scale, and duration of the infringement.
  • Any financial benefits gained or losses avoided by the infringing party.
  • The infringing party's annual turnover in the preceding financial year.

Crucially, Article 24(3) goes beyond regulatory fines by granting recipients of cloud computing services the right to seek compensation from providers for any damage or loss suffered due to an infringement of their obligations. This creates a direct financial incentive for providers to maintain accurate and truthful sovereignty claims. If a provider falsely claims a higher assurance level, leading to a security breach, data exposure, or service disruption for a public authority, the provider faces not only regulatory fines but also civil liability for damages. This dual layer of enforcementβ€”regulatory penalties and civil compensationβ€”significantly raises the cost of making false claims.

What this means for you

For public-sector procurement officers and IT managers, the proposed CADA framework fundamentally changes how you verify cloud sovereignty. You no longer need to rely on marketing brochures or conduct complex, resource-intensive due diligence on every potential vendor. Instead, the Article 22 central repository becomes your primary verification tool.

Practical steps for buyers:

  1. Verify Before You Buy: Before issuing a tender or awarding a contract, check the central repository to confirm that the provider holds the specific Union Assurance Level required by your risk assessment under Article 29. If a provider is not listed, or is listed at a lower level than claimed, the claim is unsupported.
  2. Monitor for Changes: Use the repository to monitor your current providers. Because of the transparency duties in Article 23, any material change affecting a provider's status will trigger a reassessment and a potential update (or revocation) in the repository. You will be alerted to these changes without needing to conduct your own audits.
  3. Leverage Enforcement: If you discover a provider has made false claims or failed to disclose a material change, you have recourse. Under Article 24, you can report the infringement to the national competent authority for penalties and, if you have suffered damage, seek compensation for your losses.

This system shifts the burden of proof from the buyer to the provider, ensuring that the cloud market is transparent, accountable, and free from misleading "sovereignty washing."

Common misconceptions

Misconception 1: Providers can self-certify for high assurance levels. Some providers may claim they can self-declare Union Assurance Levels 2, 3, or 4. This is incorrect. As proposed, only Level 1 allows for a conformity self-assessment under Article 19. Levels 2, 3, and 4 strictly require independent third-party audits under Article 20 and formal recognition by national competent authorities under Article 17.

Misconception 2: The central repository is only for internal government use. The repository under Article 22 is explicitly "publicly available." This transparency is intentional, allowing all stakeholders, including private sector entities, civil society, and competitors, to verify a provider's status and hold them accountable.

Misconception 3: Once recognized, a provider's status is permanent. Recognition is not permanent. Providers must undergo annual reviews of their audit reports, and they must notify authorities of any material changes under Article 23. If a provider fails to comply or if a material change compromises their status, their recognition can be revoked, and this revocation will be published in the repository for five years.

Misconception 4: CADA replaces existing cybersecurity certifications. CADA's sovereignty framework complements, but does not replace, existing cybersecurity certifications such as the European Cybersecurity Certification Scheme for Cloud Services (EUCS). While cybersecurity is a component of sovereignty (e.g., Level 2 and 3 require a "substantial" certificate, Level 4 requires a "high" certificate), sovereignty also includes aspects like data localisation, personnel citizenship, and freedom from third-country control, which are not fully covered by cybersecurity standards alone.

Official sources

Related

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