Summary No, inclusion in the CADA central repository does not guarantee that a cloud service is "fully sovereign." As proposed under Article 22, the repository serves as a public register of services recognised by national competent authorities as meeting specific Union assurance levels ranging from 1 to 4, as defined in Article 16. Inclusion confirms that a provider has successfully undergone the necessary conformity self-assessment (for Level 1) or independent third-party audit (for Levels 2–4) for their claimed level, but it does not equate to a single, absolute standard of sovereignty. Only services recognised at the highest assurance levels (3 and 4) meet the strictest criteria for operational autonomy, Union citizenship of personnel, and protection against third-country control. Level 1 represents a baseline of establishment and data residency within the Union. Therefore, a listing is a verification of compliance with a specific tier, not a blanket certification of maximum sovereignty.
Detail
To understand why repository inclusion is not synonymous with "full" sovereignty, one must examine the structure of the Union cloud computing sovereignty framework established by Article 16 of the proposed Cloud and AI Development Act (CADA). The proposal moves away from a binary "sovereign vs. non-sovereign" classification and instead introduces a proportional, four-tier system of Union assurance levels. These levels are cumulative, meaning that to qualify for a higher level, a provider must satisfy all the criteria of the lower levels.
Article 16 sets out the scope of this framework, establishing that cloud computing service providers must meet specific criteria to offer their services to Union entities and public sector bodies. The criteria for these levels are detailed in Annex II of the proposal, though the recognition mechanism itself is governed by the articles in Title IV.
The Four Assurance Levels: A Gradient of Sovereignty
The sovereignty requirements escalate significantly as one moves from Level 1 to Level 4. The distinction is critical for procurement decisions:
- Union Assurance Level 1 (Baseline): This is the entry-level tier. As proposed, providers seeking this level must demonstrate that they are established in the Union, that their infrastructure and assets (including those of subcontractors) are located in the Union, and that customer data remains exclusively within the Union unless explicitly required otherwise by the public sector body. Providers carry out a conformity self-assessment for this level. While this ensures a baseline of data residency and legal establishment, it does not impose strict requirements on the nationality of personnel or comprehensive protection against third-country corporate control.
- Union Assurance Level 2 (Enhanced): This level introduces stricter requirements. It mandates that personnel involved in the provision of the service are located in the Union and that the service obtains a European cybersecurity certificate of at least 'substantial' assurance. Crucially, it requires that data generated by using the service is not used to train or fine-tune AI systems operated by third countries. Independent third-party audits are required for this level.
- Union Assurance Level 3 (High Sovereignty): This tier significantly raises the bar for sovereignty. It requires that personnel, including subcontractors, are Union citizens (conditional at Level 2, mandatory at Level 3). It also mandates that the provider and its subcontractors are not subject to the control of a third country or a legal entity established in a third country, with limited exceptions for associated third countries that have met specific criteria under Article 18. This level is designed for activities where public order is relevant and higher protection is needed.
- Union Assurance Level 4 (Maximum Sovereignty): This is the highest tier, intended for the most sensitive public sector activities. It retains the Union citizen requirement for personnel and adds that sensitive customer data must remain exclusively within the Union. It also requires a European cybersecurity certificate of at least 'high' assurance. Like Level 3, it strictly prohibits third-country control over the provider and its subcontractors.
The Role of the Central Repository (Article 22)
Article 22 establishes the central repository of cloud computing services. The Commission is tasked with establishing and maintaining this repository, which lists cloud computing services that have been recognised in accordance with Article 17. When a national competent authority recognises a service, it registers the service in this central repository.
The repository's primary function is transparency and market clarity. It allows public sector bodies and other users to identify which services have been validated against the CADA criteria. However, the repository does not assign a single "sovereign" label. Instead, it lists the specific Union assurance level (1, 2, 3, or 4) for which the service has been recognised.
Therefore, a service listed in the repository with a Level 1 recognition is compliant with CADA's baseline requirements but does not meet the stringent sovereignty criteria associated with Levels 3 or 4. For a CTO or architect evaluating a service for a high-security use case, seeing a service in the repository is only the first step; they must verify the specific assurance level listed.
Recognition, Revocation, and Dynamic Compliance
The recognition process is rigorous. For Levels 2–4, providers must undergo independent audits by auditing organisations that meet strict independence and competence requirements (Article 20). The national competent authority of the provider's establishment assesses the evidence and, if satisfied, issues a recognition decision. This recognition is then published in the central repository.
However, recognition is not permanent. Article 23 imposes transparency obligations on providers to report any material changes that may affect their compliance. If an auditing organisation or a competent authority determines that a provider no longer meets the criteria, the recognition can be amended or revoked. Article 22(3) states that any revocation of an audit report or recognition must be published in the central repository and remain available there for five years. This dynamic nature means that a listing in the repository is a snapshot of compliance at a given time, subject to ongoing monitoring and potential revocation.
What this means for you
For CTOs, architects, and SMEs evaluating cloud providers, understanding the nuance of the CADA repository is critical for procurement and risk management.
- Do Not Equate Listing with Maximum Sovereignty: If your organisation requires the highest level of data protection and operational autonomy (e.g., for handling sensitive personal data, critical infrastructure, or national security-related information), a Level 1 listing is insufficient. You must explicitly look for services recognised at Level 3 or Level 4 in the repository.
- Verify the Specific Assurance Level: When searching the central repository, pay close attention to the tier assigned. A provider may offer multiple services, some at Level 1 and others at Level 3. Ensure the specific service you intend to procure is listed at the required level.
- Use the Repository as a Starting Point, Not the End Point: The repository confirms that a provider has passed the initial recognition hurdle. However, as a buyer, you should still conduct your own due diligence. Check for any published revocations or amendments in the repository's history. For Level 1 services, remember that these are based on self-assessment, whereas Levels 2–4 are backed by independent audits.
- Align with Your Risk Assessment: CADA requires Member States and Union entities to conduct risk assessments to determine the appropriate assurance level for their activities (Article 29). As a private sector entity, especially if you are in a high-criticality sector under NIS2, you should consider conducting similar impact assessments. If your risk assessment indicates a need for protection against third-country data access and service disruption, you should mandate Level 3 or 4 services.
- Plan for Transitions: If you are currently using a provider that is not in the repository or is only at Level 1, and your risk assessment dictates a higher level, you may need to migrate. Article 29(6) notes that if a risk assessment requires migration to another cloud computing service, the migration should occur within a reasonable transition period not exceeding 12 months. Start planning early.
Common misconceptions
- Misconception: "If it's in the repository, it's sovereign."
- Reality: Sovereignty is tiered. A Level 1 service is in the repository but lacks the strict personnel, control, and cybersecurity requirements of Levels 3 and 4. It offers baseline data residency and establishment guarantees, not full sovereignty.
- Misconception: "The repository lists all EU cloud providers."
- Reality: The repository only lists services that have been formally recognised by a national competent authority as meeting one of the Union assurance levels. Many EU-based cloud providers may not have sought recognition or may not meet the criteria for any level, and thus will not appear in the repository.
- Misconception: "Level 1 is for small providers only."
- Reality: Any provider, regardless of size, can seek recognition at any level provided they meet the criteria. However, Level 1 is the only level that allows for self-assessment (with a derogation for SMEs that allows direct recognition without prior authority review in some cases, per Article 17(3)). Levels 2–4 require independent audits, which may be more costly and complex, but large providers can also offer Level 1 services for less sensitive workloads.
- Misconception: "Once listed, the status is permanent."
- Reality: Recognition is subject to ongoing monitoring. Providers must report material changes, and auditing organisations can revoke audit opinions. Revocations are published in the repository, so a current listing does not guarantee future compliance.
Related
- CADA Recognition vs Repository Listing: What's the Difference?
- How does the CADA repository support EU digital sovereignty goals?
- How does a provider correct or update its CADA repository listing?
- How public buyers verify CADA sovereignty claims against the central repository
- How do I check a cloud service's sovereignty tier in the CADA repository?
This is general information about a draft EU regulation, not legal advice.