Summary Under the proposed Cloud and AI Development Act (CADA), public-sector contracting authorities are legally required to procure cloud computing services that have been formally recognised under the Union cloud computing sovereignty framework. As a mandatory baseline, Article 30(2) requires all public bodies to use services recognised at Union assurance level 1. However, if a national or Union risk assessment determines that a specific activity contributes to the preservation of public order, Article 30(3) prohibits the use of lower-tier services; authorities must instead procure services recognised at Union assurance levels 2, 3, or 4. These recognised services are exclusively identified through a central repository maintained by the European Commission under Article 22.

Detail

The CADA proposal introduces a mandatory, harmonised framework for the public procurement of cloud computing services across the European Union. The core objective is to mitigate strategic dependencies on third-country providers and ensure that critical public data and operations remain under Union control. This requirement is primarily governed by Article 30, which mandates that contracting authorities verify the sovereignty status of any cloud service they intend to purchase before awarding a contract.

The Two-Tier Procurement Obligation

The procurement obligation is not a one-size-fits-all mandate; it is structured around a risk-based approach that distinguishes between general public administration and activities critical to public order.

1. The Minimum Baseline: Union Assurance Level 1 For the vast majority of public-sector activities that do not touch upon sensitive national security or critical infrastructure functions, Article 30(2) establishes a mandatory floor. It states that Union entities and public sector bodies whose activities have not been identified as contributing to the preservation of public order must use cloud computing services that have been recognised as offering Union assurance level 1.

This means that a local municipality procuring a standard customer relationship management (CRM) system or a regional health authority hosting non-sensitive administrative records cannot simply choose the cheapest or most convenient vendor on the open market. They must verify that the provider has undergone the conformity self-assessment process (detailed in Article 19) and has been formally recognised.

Crucial Nuance for SMEs: While most providers must submit their self-assessment to a national competent authority for recognition, Article 17(3) provides a specific derogation for Small and Medium-sized Enterprises (SMEs). For SMEs, the EU statement of conformity issued under Article 19(2) is directly and automatically recognised in all Member States without the need for prior recognition by the evaluating national competent authority. This accelerates market entry for smaller EU providers while maintaining the baseline security standards.

2. The Elevated Requirement: Union Assurance Levels 2, 3, and 4 For activities deemed critical to the stability and security of the state, the requirements are significantly stricter. Article 30(3) mandates that contracting authorities whose activities have been identified as contributing to the preservation of public order must only procure cloud computing services recognised at Union assurance level 2, 3, or 4.

The definition of "public order" activities is determined through a mandatory risk assessment process carried out by Member States and Union entities, as outlined in Article 29. These assessments identify public sector activities that fall under specific high-risk sectors, including:

  • National security and defence.
  • Internal security and law enforcement.
  • External border management.
  • Justice systems.
  • Sectors falling under Annex I or II of Directive (EU) 2022/2555 (NIS2), covering critical entities such as energy, transport, banking, and healthcare infrastructure.

If a risk assessment flags a specific workloadβ€”such as a police database, a tax authority's core ledger, or a defence communication networkβ€”as having public order relevance, the procurement team is legally barred from using a Level 1 service. They must select a vendor that has undergone rigorous independent third-party audits (as required by Article 20) to achieve recognition at Level 2, 3, or 4. The specific level required (2, 3, or 4) will depend on the sensitivity of the data and the criticality of the service, as determined by the national risk assessment and mapped against the criteria in Annex II of the CADA proposal.

The Role of the Central Repository

How can a procurement officer practically verify if a service meets these requirements? CADA eliminates ambiguity by centralising this information. Article 22 establishes a central repository of cloud computing services that have been recognised under the sovereignty framework.

This repository is maintained by the European Commission and is publicly available. It serves as the single source of truth for procurement officers. Before awarding a contract, a contracting authority must check this repository to confirm that the cloud service provider holds a valid recognition for the specific Union assurance level required by their risk assessment. The repository will list the provider, the service, the assurance level granted, and the national competent authority that issued the recognition.

Retention of Revoked Services: A critical legal detail in Article 22(3) is that the revocation of an audit report, audit opinion, or recognition shall be published in the central repository and shall remain available there for five years. This ensures that procurement officers can verify the historical compliance status of a provider and avoid vendors whose recognition has been withdrawn due to non-compliance. If a service is not listed in the repository, or if its recognition has been revoked and the five-year period has not elapsed, it cannot be considered "recognised" under CADA, and procuring it would constitute a breach of Article 30.

Exceptions and Derogations

While the requirement is strict, Article 30(4) provides limited derogations. A contracting authority may decide not to procure a recognised service only under exceptional circumstances, such as:

  • The subject matter of the tender cannot be supplied by any recognised service available in the central repository, and no adequate or reasonable alternative exists (provided this absence is not the result of an artificial narrowing of the tender parameters).
  • A similar procurement process was launched within the previous year but received no suitable tenders or suitable participants.
  • Applying the requirements would require the contracting authority to procure services at disproportionate cost.

These exceptions are narrow and must be duly justified. They are not intended to allow public bodies to bypass sovereignty requirements for convenience or to continue using non-compliant third-country providers without rigorous justification.

What this means for you

For public-sector procurement officers, legal counsels, and IT directors, the CADA proposal fundamentally changes the tendering process for cloud services. You can no longer treat cloud procurement as a purely technical or financial exercise; it is now a compliance-driven process anchored in sovereignty assurance.

1. Integrate Risk Assessments Early Your first step is to review the results of your organisation's risk assessment under Article 29. You must clearly map which of your cloud workloads are classified as "public order" activities and which are not. This classification dictates your procurement ceiling. If you are in the justice, defence, or critical infrastructure sectors, you should anticipate that almost all your core cloud workloads will require Level 2, 3, or 4 services.

2. Update Tender Specifications Your public tender documents must explicitly state that bidders must provide proof of recognition under the CADA sovereignty framework. Specifically:

  • For general IT services: Require proof of recognition at Union assurance level 1. Note that for SME bidders, this may be demonstrated via an EU statement of conformity under Article 19, which is automatically recognised.
  • For critical/sensitive services: Require proof of recognition at Union assurance level 2, 3, or 4 (specifying the minimum level based on your risk assessment).
  • Require bidders to provide their entry in the central repository (Article 22) as part of their technical compliance documentation.

3. Monitor the Central Repository As the central repository becomes operational, it will be your primary tool for vendor due diligence. Before inviting tenders, check the repository to see which providers are already recognised at the levels you need. This will help you assess market availability and avoid the "no suitable tenders" exception scenario. If a preferred vendor is not yet listed, you may need to engage with them early to understand their roadmap for achieving recognition, as the audit and recognition processes (Articles 17–20) can take time.

4. Prepare for Migration If your current cloud contracts are with providers that do not meet these assurance levels, you must plan for migration. Article 29(6) notes that if a risk assessment requires migration to a different cloud service, the transition must occur within a reasonable period that shall not exceed 12 months. Start planning your exit strategies and data portability measures now.

Common misconceptions

Misconception 1: "We only need to worry about this if we host classified data." This is incorrect. The requirement for Union assurance level 1 applies to all public-sector cloud procurement, regardless of data sensitivity. Even a simple website hosting service for a local council must use a recognised Level 1 provider. The higher levels (2, 3, 4) are for public-order activities, but the baseline obligation is universal for the public sector.

Misconception 2: "We can use any EU-based provider." Being established in the EU is a criterion for recognition, but it is not the requirement for procurement. The legal obligation is to procure services that have been recognised under the framework. A provider may be EU-established but fail to meet the transparency, subcontractor oversight, or cybersecurity criteria required for recognition. Until they are listed in the central repository with a valid assurance level, they cannot be procured under Article 30.

Misconception 3: "This only applies to new contracts." While procurement rules typically apply to new tenders, the spirit of the regulation and the migration provisions in Article 29 imply that existing contracts for public-order activities will need to be reviewed. If a risk assessment identifies a critical service that is currently hosted on a non-recognised platform, the authority is expected to migrate within 12 months. Long-term reliance on non-compliant infrastructure for critical public functions will not be sustainable under this framework.

Misconception 4: "The private sector is exempt." While Article 30 specifically targets contracting authorities and Union entities, the ripple effect is significant. Private sector entities operating in sectors of high criticality (as defined in Annex I of the NIS2 Directive) are encouraged to conduct similar impact assessments under Article 31. Furthermore, as public sector demand shifts exclusively to recognised services, the market will naturally gravitate towards providers who can meet these sovereignty standards, indirectly pressuring private-sector buyers to adopt similar criteria.

Related

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