Summary Under the proposed Cloud and AI Development Act (CADA), a single cloud provider does not receive a single, monolithic listing for its entire corporate entity. Instead, the central repository established by Article 22 is populated with entries for specific "cloud computing services." Consequently, a single provider canβ€”and frequently willβ€”have multiple distinct listings within the repository. Each listing corresponds to a specific service offering that has undergone a separate recognition procedure and achieved a specific Union assurance level (1, 2, 3, or 4). As proposed in Article 22(1)–(2), the Commission maintains a repository of recognised services, not a register of providers. This means a provider might appear once for a basic infrastructure service at Level 1, and again for a specialized sovereign environment at Level 3 or 4, reflecting the granular, service-specific nature of the proposed sovereignty framework.

Detail

To understand the structure of the CADA repository, one must first identify the precise legal object of recognition. The proposed Regulation establishes a "Union cloud computing sovereignty framework" comprising four distinct assurance levels, as set out in Article 16. The mechanism for entering this framework is not a corporate-wide certification but a service-specific recognition process. Article 17 outlines the procedure whereby a cloud computing service provider submits an application for recognition to the national competent authority of establishment. Crucially, the application, the subsequent evaluation, and the resulting recognition focus on the "cloud computing service" itself, assessing whether that specific service meets the cumulative criteria for a particular Union assurance level as defined in Annex II.

The text of Article 22(1) explicitly mandates that the Commission shall establish and maintain a dedicated repository of "cloud computing services" that have been recognised in accordance with Article 17. The legislation deliberately avoids referring to a repository of "providers" or "legal entities." This distinction is legally significant. It establishes that the unit of record in the central repository is the service, not the corporate parent. Article 22(2) further clarifies this operational detail, stating that the national competent authority of establishment that recognised a "cloud computing service" shall register that specific service in the central repository.

This service-centric architecture has direct and profound implications for how providers are listed in the marketplace. A large cloud provider may offer a generic infrastructure-as-a-service (IaaS) product that meets the criteria for Union assurance level 1, while simultaneously offering a specialized, air-gapped sovereign cloud environment that meets the significantly stricter criteria for Union assurance level 3 or 4. Under the proposed CADA, these would be treated as distinct "cloud computing services." The provider would be required to submit separate applications for recognition for each service. Upon successful recognition, the competent authority would register each service individually in the central repository. Therefore, a single corporate entity could appear multiple times in the repository, with each entry reflecting a different service offering and its respective assurance level.

Furthermore, the recognition is tied to the specific configuration, operational boundaries, and technical parameters of the service as audited. The criteria in Annex II vary significantly between levels. For instance, Union assurance level 2 requires that infrastructure, assets, and personnel are located in the Union, and that the service obtains a European cybersecurity certificate of at least "substantial" assurance level. Union assurance level 3 adds stricter requirements, such as mandatory Union citizenship for personnel (conditional on public body requirements) and more rigorous controls on third-country influence. If a provider offers two services that differ in these technical and operational parameters, they cannot be covered by a single recognition. Each must be evaluated against its target assurance level.

The audit process, described in Article 20, is conducted on the "audited service," and the resulting audit report and opinion are specific to that service. Article 22(2) mandates that this specific recognition be registered. Thus, the repository will reflect a granular view of the market, showing exactly which services from which providers meet which levels of sovereignty assurance. A provider cannot "piggyback" a high-level recognition from one service onto another; each service stands on its own merits.

The repository is designed to be publicly available and regularly updated by the Commission and national competent authorities (Article 22(4)). It serves as a critical transparency tool for public sector bodies and private entities to identify which specific services meet their risk assessment requirements. If a provider updates a service, changes its subcontractors, or modifies its infrastructure in a way that affects its compliance with the assurance level criteria, it must notify the auditing organisation and the competent authority (Article 23). This may lead to amendments or revocations of the recognition for that specific service, which would then be reflected in the repository entry for that service, without necessarily affecting other services offered by the same provider. This dynamic nature ensures that the repository remains an accurate reflection of the current sovereignty status of each listed service.

What this means for you

For CTOs, architects, and procurement officers evaluating cloud providers under the proposed CADA, this structure necessitates a fundamental shift from corporate-level due diligence to service-level verification. You cannot assume that because a provider is listed in the repository, all its services meet the same sovereignty standards. You must identify the specific service you intend to procure and verify its individual listing in the central repository.

When conducting your risk assessments under Article 29, you will determine the required Union assurance level for your public sector activities or critical private sector operations. You must then search the repository for services that have been explicitly recognised at that level or higher. A provider might have a listing for a level 1 service, but if your risk assessment requires level 3, that specific listing is insufficient. You would need to check if the same provider has a separate listing for a level 3 service. If not, that provider cannot fulfill your requirement for that specific use case, regardless of its overall market reputation or its status as a "sovereign" provider for other services.

For SMEs and larger enterprises alike, this granularity offers flexibility but also complexity. You can mix and match services from the same provider if they hold different assurance levels, allowing you to allocate less critical workloads to lower-assurance (and potentially lower-cost) services while reserving higher-assurance services for sensitive data or critical functions. However, it also increases the administrative burden of procurement. Your procurement teams will need to track multiple service IDs and assurance levels rather than a single vendor contract. Ensure that your contracts explicitly reference the specific recognised service and its assurance level as listed in the repository to maintain compliance with Article 30, which mandates that contracting authorities procure services recognised at the appropriate assurance level.

Additionally, this structure implies that a provider's "sovereignty" is not a binary state. A provider might be fully compliant for one service line while failing to meet the criteria for another. This requires continuous monitoring. As Article 23 requires providers to notify authorities of material changes, the status of a specific service listing can change. A service that was Level 3 today could be downgraded or revoked tomorrow if the provider fails to maintain the required controls, while their other services remain unaffected.

Common misconceptions

"CADA creates a 'sovereign cloud provider' label for the whole company." This is incorrect. CADA recognises services, not companies. A provider can be a "non-sovereign" provider for some services (e.g., those not meeting level 1 criteria or not seeking recognition) and a "sovereign" provider for others. The repository lists the service, not the corporate brand.

"A single audit covers all services offered by a provider." The audit process is service-specific. While an auditing organisation may assess the provider's overall governance and supply chain, the audit opinion and report must confirm compliance for the specific "audited service" against the criteria for its target assurance level. Therefore, a provider cannot leverage a level 4 audit for one service to automatically claim level 4 status for a different, less secure service. Each service requires its own audit report and recognition.

"The repository is a static list of approved vendors." In reality, the repository is dynamic. Recognitions can be amended or revoked if a provider fails to maintain compliance or if material changes occur (Article 23). A listing can disappear or change assurance level, requiring continuous monitoring by procurers. The repository reflects the current status of each service, not a historical approval.

"If a provider is listed, all their services are safe." Listing in the repository only confirms that a specific service meets the criteria for a specific assurance level. It does not imply that all services offered by that provider meet any level of assurance. Procurers must verify the specific service ID and its associated level.

Related

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