Summary Yes, under the proposed Cloud and AI Development Act (CADA), a cloud computing service provider can hold different Union assurance levels for different services. The sovereignty framework does not assign a single, blanket sovereignty rating to an entire company; instead, recognition is granted on a per-service basis. This means a single provider can offer a basic Union assurance level 1 service for general administrative use while simultaneously maintaining a highly secure Union assurance level 4 service for critical public sector functions, provided each service meets the specific cumulative criteria for its respective tier. The central repository will list each service separately, ensuring public buyers can distinguish between a provider's standard and sovereign offerings.

Detail

The CADA proposal establishes a nuanced, service-specific approach to cloud sovereignty rather than a monolithic corporate certification. This design reflects the reality that cloud providers often operate complex portfolios ranging from basic storage solutions to highly specialized, secure environments for government data. The legislative text explicitly structures the recognition mechanism around the individual "cloud computing service," allowing for granular compliance within a single corporate entity.

Recognition is per cloud computing service

The core mechanism for establishing sovereignty levels is found in Article 17 of the proposal. Article 17(1) explicitly states that "a cloud computing service provider that aims to be recognised as offering a Union assurance level, shall submit an application for recognition to the national competent authority of establishment." Crucially, the application and subsequent recognition process focus on the specific "cloud computing service" rather than the provider as a whole.

This distinction is vital. If a provider offers three distinct servicesβ€”such as a general-purpose infrastructure-as-a-service (IaaS), a specialized database-as-a-service (DBaaS), and a secure sovereign cloud for defenseβ€”they must evaluate and apply for recognition for each service individually. A provider might successfully demonstrate that its general IaaS meets the criteria for Union assurance level 1 (which requires a conformity self-assessment under Article 19), while its secure sovereign cloud meets the stricter criteria for Union assurance level 4 (which requires independent third-party audits under Article 20 and strict personnel and data localization rules).

The criteria for these levels are detailed in Annex II of the proposal. For example, Union assurance level 1 requires that the provider is established in the Union and that customer data remains exclusively within the Union unless otherwise required by the public sector body. In contrast, Union assurance level 4 requires that the provider and its subcontractors are not subject to the control of a third country, that personnel are Union citizens with necessary security clearances, and that sensitive data remains exclusively within the Union. Because these criteria are cumulative and increasingly strict, a single service cannot simultaneously hold multiple levels; it is recognized at the highest level for which it fully complies. However, a provider can hold different levels for different services in its portfolio.

Separate registration in the central repository

To ensure transparency and allow public sector buyers to make informed decisions, CADA mandates a central registry. Article 22 requires the Commission to establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17.

Article 22(2) specifies that "the national competent authority of establishment that recognised a cloud computing service shall register the cloud computing service in the central repository." This confirms that the unit of registration is the service, not the company. Consequently, the repository will list each recognized service separately. A public sector authority searching the repository will see distinct entries for each service offered by a provider, with each entry clearly stating its recognized Union assurance level (1, 2, 3, or 4).

This separate registration is vital for procurement. Under Article 30, contracting authorities must procure services that meet the assurance level determined by their risk assessment. If a ministry needs a Union assurance level 3 service for sensitive non-personal data, it can only purchase the specific service registered at that level. It cannot purchase a lower-level service from the same provider and assume it is sufficient. The repository provides the legal certainty needed to verify which specific service meets the required sovereignty threshold.

Operational implications for providers

For providers, this structure allows for market segmentation. A provider does not need to upgrade its entire infrastructure to meet the highest sovereignty standards if only a fraction of its customers require them. Instead, they can isolate specific services, apply the necessary technical, organizational, and personnel measures for those services, and undergo the appropriate audit or self-assessment for those specific offerings. This targeted approach can reduce compliance costs for providers whose primary market does not require the highest levels of assurance, while still allowing them to compete for high-value public sector contracts with specialized, compliant services.

However, this requires rigorous internal governance. Providers must ensure that the infrastructure, personnel, and data flows for a Level 4 service are strictly segregated from those of a Level 1 service. For instance, if a Level 4 service requires Union citizen personnel, the provider must ensure that the specific staff supporting that service meet this requirement, even if other staff supporting a Level 1 service do not. Failure to maintain this separation could jeopardize the recognition of the higher-level service.

What this means for you

If you are a cloud service provider or data centre operator subject to CADA, you should structure your compliance strategy around your service portfolio, not just your corporate entity.

  1. Audit your service catalog: Identify which of your services are targeted at public sector bodies or entities that may require sovereignty guarantees. You do not need to apply for recognition for services used exclusively by private entities that do not require Union assurance levels, though you may choose to do so for market differentiation.
  2. Prepare for multiple recognition paths: Be ready to manage different compliance workflows. Your general services may only require the self-assessment and EU statement of conformity needed for Union assurance level 1. Your secure services will require independent third-party audits for levels 2, 3, or 4. Ensure your internal processes can support these parallel tracks.
  3. Maintain distinct records: Keep clear documentation separating the infrastructure, personnel, and data flows for each service seeking recognition. Auditors and competent authorities will examine the specific service's compliance with the cumulative criteria in Annex II. Mixing data or personnel pools between a level 1 and a level 4 service could jeopardize the higher-level recognition.
  4. Monitor the central repository: Once recognized, ensure that each of your services is correctly registered in the central repository under Article 22. Inaccurate or missing registrations will prevent public sector buyers from procuring your services, as they rely on this repository to verify compliance.

Common misconceptions

  • Misconception: "If my company is recognized at Level 1, all my services are Level 1."
    • Reality: Recognition is not corporate. It is specific to the cloud computing service. You can have a mix of Level 1, Level 2, Level 3, and Level 4 services under one corporate umbrella, provided each meets its respective criteria.
  • Misconception: "I can upgrade a service from Level 1 to Level 3 without a new audit."
    • Reality: Each level has distinct criteria. Moving from Level 1 (self-assessment) to Level 3 (independent audit, no third-country control, Union citizen personnel) requires a new, rigorous audit process and potentially significant operational changes. The recognition for the new level must be obtained separately.
  • Misconception: "The repository lists my company, not my services."
    • Reality: Article 22 requires the registration of recognized cloud computing services. The repository will list individual services, allowing buyers to distinguish between your basic and sovereign offerings.

Related

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