Summary Under the proposed Cloud and AI Development Act (CADA), a "recognised cloud computing service provider" is a provider whose cloud services have been formally assessed and approved by a national competent authority as meeting specific Union assurance levels (1–4) for sovereignty and security, as detailed in Article 17. This recognition is not a permanent status; it carries ongoing transparency duties. Specifically, Article 23(1) mandates that a recognised provider must, "as soon as possible," notify both the auditing organisation and the national competent authority of establishment of any "material change in circumstances" that could affect their compliance status, audit report, or recognition.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, establishes a harmonised Union cloud computing sovereignty framework. This framework is designed to mitigate risks associated with third-country control and ensure operational autonomy for public sector bodies and Union entities. Central to this framework is the concept of "recognition," which serves as the formal validation that a cloud computing service meets the strict cumulative criteria set out in Annex II.

The Recognition Process (Article 17)

Recognition is the gateway for cloud providers to serve the EU public sector. Under Article 17, a cloud computing service provider seeking recognition must submit an application to the national competent authority of its establishment. The process and evidentiary requirements vary significantly depending on the desired assurance level:

  • Union Assurance Level 1: Providers must submit an EU statement of conformity based on a self-assessment conducted in accordance with Article 19. Notably, for small and medium-sized enterprises (SMEs), this statement is directly and automatically recognised in all Member States without the need for prior review by the evaluating national competent authority. For non-SME providers, the competent authority reviews the evidence.
  • Union Assurance Levels 2, 3, and 4: Providers must undergo independent third-party audits. They are required to submit an audit report and a "positive" audit opinion from an auditing organisation, along with all evidence provided during the audit procedure.

Once the evaluating national competent authority accepts an application, it has 60 days to assess the evidence. If sufficient, the authority prepares a draft recognition decision and notifies other Member States' competent authorities for a 60-day review period. If no reasoned objections are raised, the service is recognised throughout the Union at the appropriate assurance level. This recognition is recorded in a central repository maintained by the Commission, as outlined in Article 22.

Transparency Obligations for Recognised Providers (Article 23)

Recognition is not a static status; it requires continuous compliance. Article 23 establishes critical transparency obligations for providers who have already achieved recognised status. The core duty is found in Article 23(1), which places the onus on the provider to monitor their own operational environment continuously.

The text of 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 creates a proactive duty of disclosure. A "material change in circumstances" is not explicitly defined in the text but, based on the criteria in Annex II, would logically include:

  • Changes in the provider's ownership or control structure that might introduce third-country influence or alter the "control" assessment.
  • Relocation of infrastructure, assets, data, or personnel outside the Union.
  • Changes in subcontractors or supply chain dependencies that affect the software bill of materials (SBOM) or security posture.
  • Cybersecurity incidents that compromise the integrity of the service or the validity of the cybersecurity certificate.
  • Modifications to the service architecture that affect its compliance with the specific assurance level criteria (e.g., changes to data residency or personnel screening).

Upon receiving such a notification, the auditing organisation must assess whether the audit report or opinion needs to be amended or revoked (Article 23(2)). Similarly, the national competent authority must assess whether its recognition needs to be amended or revoked (Article 23(3)). If the recognition is revoked, this must be published in the central repository and remain available there for five years, ensuring that public procurers are aware of the loss of status.

The Interplay Between Recognition and Transparency

The relationship between Article 17 and Article 23 is symbiotic. Article 17 grants the status, but Article 23 ensures its validity over time. Without the transparency mechanism in Article 23, a provider could theoretically meet the criteria at the moment of recognition but subsequently drift into non-compliance (e.g., by acquiring a third-country subsidiary with control rights) without the authorities being aware.

The "as soon as possible" timeline in Article 23(1) is strict. It implies that providers cannot wait for the next annual audit cycle to report changes. If a material change occurs, the provider must trigger the notification immediately. Failure to do so could be considered an infringement of the Chapter, potentially leading to penalties under Article 24, which requires Member States to lay down rules for penalties that are "effective, proportionate and dissuasive."

What this means for you

If you are a cloud service provider or data centre operator aiming to serve the EU public sector, you must treat recognition as a dynamic, ongoing compliance journey rather than a one-time certification.

  1. Establish Robust Monitoring: You need internal processes to detect "material changes in circumstances" immediately. This means your legal, technical, and operational teams must have clear channels to flag issues that could impact your sovereignty assurance level. For example, your legal team must monitor changes in shareholder structures, while your technical team must track infrastructure migrations.
  2. Prepare for Rapid Notification: Article 23(1) requires you to notify the auditing organisation and the national competent authority "as soon as possible." Delaying notification can lead to the revocation of your recognition and potential penalties. You should have a pre-defined protocol for who makes the call and what information is sent immediately upon detecting a change.
  3. Maintain Audit Readiness: For levels 2–4, your relationship with your auditing organisation is critical. You must be prepared to provide evidence of compliance continuously, not just during the initial audit. If a material change occurs, the auditing organisation may need to perform a targeted review or a full re-audit to confirm continued compliance.
  4. Understand the Assurance Levels: Ensure you are targeting the correct assurance level for your target market. Level 1 is the baseline for general public sector use, while levels 3 and 4 are required for high-security contexts involving classified information or critical national infrastructure. The transparency duties apply to all levels, but the nature of "material changes" may differ (e.g., personnel citizenship is a critical factor for levels 3 and 4).

Common misconceptions

  • Misconception: Recognition is permanent.
    • Reality: Recognition is conditional on continuous compliance. Any material change in your operations, ownership, or security posture must be reported. Failure to do so can result in the revocation of your status and removal from the central repository.
  • Misconception: Self-assessment is enough for all providers.
    • Reality: Only Union Assurance Level 1 allows for self-assessment (via an EU statement of conformity). Levels 2, 3, and 4 require independent third-party audits and a positive audit opinion. Furthermore, the transparency duty in Article 23 applies to all recognised providers, regardless of the level.
  • Misconception: Recognition is only for EU-based providers.
    • Reality: While the provider must be established in the Union, the framework allows for the recognition of third-country providers under specific conditions (Article 18), provided the third country meets strict adequacy and sovereignty criteria. However, the default assumption is Union establishment, and any change in control status must be reported.
  • Misconception: The central repository is just a list.
    • Reality: The central repository (Article 22) is a dynamic, publicly available tool that records both recognitions and revocations. It is the primary source of truth for public procurers to verify a provider's status. If a provider fails to notify under Article 23 and is subsequently revoked, this will be visible to all potential customers.
  • Misconception: Only major changes need reporting.
    • Reality: The standard is "material change in circumstances that may affect... the recognition." This is a broad standard. Even changes that seem minor in isolation (e.g., a change in a key subcontractor's location) could be material if they impact the criteria for the specific assurance level.

Related

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