Summary Under the proposed Cloud and AI Development Act (CADA), cloud sovereignty is assessed and recognised at the individual service level, not the corporate provider level. This means a single cloud computing service provider can have one service recognised at Union assurance level 1, while a different service from the same provider is recognised at level 3 or 4. Article 17 explicitly establishes that recognition is granted to a specific "cloud computing service" (the "audited service"), allowing for granular sovereignty claims that reflect the distinct technical and operational realities of each offer. This service-specific approach ensures that public sector procurement under Article 30 can precisely match the required assurance level to the sensitivity of the activity.

Detail

The proposed Cloud and AI Development Act (CADA) introduces a nuanced, risk-based approach to cloud sovereignty that diverges from a binary "sovereign or non-sovereign" provider classification. Instead, the proposal establishes a framework where sovereignty is evaluated, audited, and recognised per specific cloud computing service. This service-level granularity is central to the Union cloud computing sovereignty framework outlined in Title IV of the proposal.

Recognition Applies to Specific Services

Article 17 of the CADA proposal, titled "Recognition of cloud computing service providers," explicitly frames the recognition process around the service rather than the corporate entity. While the article title references the provider, the operative text clarifies that the object of recognition is the service itself.

Paragraph 1 states that a cloud computing service provider aiming to be recognised as offering a Union assurance level must submit an application for recognition to the national competent authority of establishment. Crucially, the application must include evidence demonstrating compliance for the specific service in question.

Paragraph 7 of Article 17 provides the definitive legal scope: "the audited service shall be recognised throughout the Union at the appropriate Union assurance level." The use of the term "audited service" rather than "audited provider" indicates that the legal status of sovereignty is attached to the specific technical and operational configuration of that service. This distinction is vital because a single provider may operate multiple distinct service offerings, each with different infrastructure footprints, data residency policies, supply chain dependencies, and personnel arrangements. A provider's general corporate structure does not automatically confer sovereignty status on every service it offers; each service must independently satisfy the cumulative criteria set out in Annex II.

A Provider Can Offer Services at Different Levels

Because recognition is service-specific, a single provider can maintain a portfolio of services that span different Union assurance levels. This flexibility is a core feature of the proposal, designed to accommodate the diverse needs of the market while ensuring high assurance for critical public order functions.

For example, a provider might offer a standard public cloud service that meets the criteria for Union assurance level 1. Under Annex II, section 1.1, this level requires the provider to be established in the Union and for customer data to remain exclusively within the Union, unless explicitly required otherwise by the public sector body. Simultaneously, that same provider could offer a dedicated, air-gapped sovereign cloud instance for public sector bodies that meets the stricter criteria for Union assurance level 3 or 4.

These higher levels impose significantly more rigorous requirements:

  • Level 3 requires that personnel, including those of subcontractors, are Union citizens (where appropriate, with national security clearance) and that the service obtains a European cybersecurity certificate of at least assurance level 'substantial' (Annex II, section 3.1(d) and (e)).
  • Level 4 escalates this to a 'high' cybersecurity certificate and mandates that the provider and its subcontractors are not subject to the control of a third country (with a specific derogation mechanism under Article 18 for third-country control if specific safeguards are met) (Annex II, section 4.1(e) and (g)).

This tiered structure allows providers to tailor their offerings to the specific risk assessments of their customers. Under Article 29, Member States and Union entities must conduct risk assessments to determine which Union assurance level (2, 3, or 4) is appropriate for their public sector activities. If a contracting authority determines that its activities contribute to the preservation of public order, Article 30(3) mandates that it "shall only procure cloud computing services that have been recognised as having a Union assurance level 2, 3 or 4." By assessing sovereignty per service, CADA enables a precise match between the sensitivity of the public sector use case and the sovereignty guarantees of the specific cloud instance being procured.

The Recognition Mechanism

The mechanism for achieving this service-level recognition is detailed in Article 17. The process begins with the provider submitting an application to the national competent authority of establishment. The pathway differs based on the target level:

  • Level 1: The provider carries out a conformity self-assessment and issues an EU statement of conformity (Article 19). For SMEs, this statement is directly and automatically recognised across the Union without prior national recognition (Article 17(3)).
  • Levels 2, 3, and 4: The provider must undergo independent third-party audits to obtain an audit report and a 'positive' audit opinion (Article 20).

The evaluating national competent authority assesses the evidence submitted for the specific service. Article 17(5) grants the authority 60 days to assess the evidence and prepare a draft recognition decision. This decision is then notified to other Member States for a 60-day review period. If no reasoned objections are raised, the service is recognised throughout the Union. This mutual recognition mechanism ensures that a service certified in one Member State is valid across the EU, but the certification remains tied to that specific service's compliance with the criteria in Annex II.

Furthermore, Article 23 imposes transparency obligations on providers. They must notify the auditing organisation and the national competent authority of any material changes that may affect the audit report or recognition. This ongoing monitoring ensures that the service-level sovereignty claim remains valid over time. If a provider changes the infrastructure or subcontractors for one service but not another, the sovereignty status of each service can be reassessed independently. This dynamic approach prevents a "once certified, always certified" scenario and ensures that the assurance level reflects the current reality of the service.

What this means for you

For cloud service providers and data centre operators, the service-level assessment model requires a strategic shift in how sovereignty is marketed, managed, and audited.

  1. Granular Compliance Strategies: You cannot rely on a blanket "sovereign" label for your entire organisation. You must map your service portfolio against the four Union assurance levels in Annex II. Identify which services can realistically meet the criteria for levels 2, 3, or 4. This may involve creating dedicated infrastructure, operational silos, or distinct personnel pools for higher-assurance services to ensure they meet strict requirements like Union-only citizenship or the absence of third-country control.
  2. Targeted Audits: Prepare for independent third-party audits (Article 20) for each service seeking recognition at levels 2–4. Auditors will examine the specific evidence for each service, including software bills of materials (SBOMs), data flow diagrams, and subcontractor agreements. Ensure your documentation clearly delineates the boundaries of each service to facilitate precise auditing. A failure in one service's supply chain should not automatically disqualify another service if the evidence shows they are operationally separate.
  3. Dynamic Risk Management: Implement robust change management processes. Under Article 23, any material change affecting a service's compliance must be reported. If you update the infrastructure for one service, you must assess whether this impacts its sovereignty status, without necessarily affecting other services from the same provider. This allows for agility in innovation while maintaining compliance for critical offerings.
  4. Market Differentiation: Use the tiered recognition to differentiate your offerings. Public sector buyers are increasingly required to procure services at specific assurance levels (Article 30). By having services recognised at multiple levels, you can address a broader range of public sector needs, from standard administrative tasks (Level 1) to critical public order functions (Levels 2–4). This allows you to compete for high-value contracts without compromising the flexibility of your commercial offerings.

Common misconceptions

  • "If one service is sovereign, all services from the provider are sovereign." This is incorrect. Recognition is granted to the "audited service" (Article 17(7)). A provider's standard public cloud offering may not meet the criteria for Level 3 or 4, even if a dedicated sovereign instance does. Each service is assessed on its own merits against the criteria in Annex II. A provider could be Level 1 for its general public cloud and Level 4 for its government-specific instance.

  • "Sovereignty is a one-time certification." Recognition is ongoing. Article 23 requires providers to notify authorities of material changes. Auditing organisations must annually review the audit report and opinion (Article 20(8)). If a service's configuration changes such that it no longer meets the criteria (e.g., a new subcontractor introduces third-country control), its recognition can be revoked.

  • "Level 1 recognition is automatic for all EU-based providers." While Level 1 relies on self-assessment (Article 19), providers must still meet the cumulative criteria in Annex II, section 1.1, such as being established in the Union and ensuring data remains exclusively within the Union. SMEs benefit from automatic recognition of their Level 1 statements across the Union (Article 17(3)), but the criteria must still be met. Non-compliance can lead to penalties under Article 24.

  • "The provider's corporate citizenship determines the service level." Corporate establishment is a baseline requirement, but the service level depends on the specific operational controls. For instance, a provider established in the EU could still fail Level 3 or 4 if its personnel are not Union citizens or if it is subject to third-country control, even if the data stays in the EU.

Related

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