Summary If you are a SaaS provider already subject to the NIS2 Directive and the Data Act, the proposed Cloud and AI Development Act (CADA) would add a distinct sovereignty and procurement layer on top of your existing compliance obligations. As proposed, CADA defines "cloud computing service" by referencing the NIS2 definition, meaning most SaaS offerings fall within its scope. While NIS2 mandates technical cybersecurity and the Data Act enforces interoperability and switching, CADA would introduce a four-tier "Union assurance" framework that acts as a mandatory gateway for EU public sector procurement. To sell to the public sector, providers would need to undergo specific conformity assessments or independent audits to prove they meet EU sovereignty standards, creating a new "recognition" requirement that sits alongside existing security and portability duties.

Detail

The proposed Cloud and AI Development Act (CADA) does not operate in a vacuum; it is explicitly designed to complement existing EU digital legislation, specifically the NIS2 Directive and the Data Act. For SaaS providers, understanding how these three instruments stack is critical for navigating the future regulatory landscape. The proposal clarifies that CADA addresses market failures regarding strategic dependency and public order that NIS2 and the Data Act do not cover.

SaaS is explicitly in scope via the NIS2 definition

The first question for any SaaS provider is whether CADA applies. Under Article 2 of the CADA proposal, the term "cloud computing service" is defined by direct reference to Article 6, point (30), of Directive (EU) 2022/2555 (the NIS2 Directive). The proposal states that this definition encompasses "on-demand access to AI systems... hosted and operated remotely," but explicitly excludes the AI system itself and its underlying model from the definition of the service.

Because NIS2 defines cloud computing services broadly to include infrastructure, platform, and software-as-a-service (SaaS) models that provide scalable, elastic pools of shareable computing resources, most SaaS providers offering remote software solutions to EU customers would fall within the scope of CADA's autonomy and procurement chapters. This means that even if your primary regulatory burden currently stems from NIS2 cybersecurity requirements, you are also a "cloud computing service provider" under CADA. The definition is technology-neutral regarding the delivery model (IaaS, PaaS, SaaS) and focuses on the nature of the service: remote, on-demand access to computing resources.

NIS2, Data Act, and CADA: Three distinct layers

It is a common misconception that CADA replaces NIS2 or the Data Act. The explanatory memorandum and recitals make clear that these instruments address different market failures and risks, creating a "stack" of obligations:

  1. NIS2 Directive (Cybersecurity): NIS2 focuses on the technical security and resilience of essential and important entities. For cloud providers, this means implementing robust risk management measures, incident reporting, and supply chain security to prevent cyberattacks. It is a technical and operational baseline. The CADA proposal notes that NIS2 "does not contain measures to boost the uptake and use of such services" and is "fully focused on technical cybersecurity as opposed to broader sovereignty considerations."
  2. Data Act (Interoperability and Switching): The Data Act addresses vendor lock-in. It mandates that cloud providers allow customers to switch services and export data without undue hindrance. It ensures that users can freely choose providers and combine offers in a multi-cloud approach. The CADA proposal explicitly states that it is consistent with the Data Act and that the Data Act is an "enabler" for CADA, as switching capabilities make it easier for users to move to sovereign EU providers. However, the Data Act "does not contain elements to shape up a more competitive offer of European cloud computing services."
  3. CADA (Sovereignty and Procurement): CADA addresses strategic dependency and public order. It introduces a "Union cloud computing sovereignty framework" with four assurance levels. Unlike NIS2, which is about keeping hackers out, CADA's higher assurance levels (particularly Levels 3 and 4) are about ensuring that no third-country government can legally compel the provider to access EU data or disrupt service continuity. The proposal states that CADA "complements the Cybersecurity Act's focus on cloud cybersecurity with sovereignty considerations."

The Union Assurance Levels and the Procurement Gateway

The most significant operational change for SaaS providers under CADA is the introduction of the Union assurance levels, detailed in Article 16 and Annex II of the proposal. These levels determine whether a provider can sell to the EU public sector.

  • Union Assurance Level 1: This is the baseline for all public sector procurement. Providers must be established in the Union, keep infrastructure and data within the Union (unless explicitly required otherwise by the customer), and demonstrate compliance with state-of-the-art cybersecurity standards. Crucially, for Level 1, providers carry out a conformity self-assessment (Article 19) and issue an EU statement of conformity. SMEs benefit from automatic recognition of this statement across all Member States without prior national authority recognition.
  • Union Assurance Levels 2, 3, and 4: These higher tiers are required for public sector activities identified as contributing to the preservation of public order (e.g., defense, justice, critical infrastructure) following a risk assessment by the Member State (Article 29).
    • Level 2 requires independent third-party audits, stricter data localization (no transfer outside the Union), and proof that data is not used to train third-country AI models. It also requires a European cybersecurity certificate of at least assurance level "substantial" (Annex II 2.1(e)).
    • Level 3 adds requirements for Union citizenship for personnel (conditional on public body requirements) and stricter controls on third-country influence. It also requires a "substantial" cybersecurity certificate.
    • Level 4 is the highest tier, requiring 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. It requires a European cybersecurity certificate of at least assurance level "high" (Annex II 4.1(e)).

Recognition as the new market access ticket

Under CADA, being a compliant cloud provider is not enough; you must be recognized. Article 17 establishes the mechanism for recognition. A provider must submit an application to the national competent authority of their establishment. For Level 1, this involves submitting the self-assessment statement. For Levels 2–4, it requires submitting a positive audit opinion from an independent auditing organization.

Once recognized, the service is listed in a central repository maintained by the Commission (Article 22). This recognition is valid across the entire Union. For SaaS providers, this means that your ability to win public sector contracts will increasingly depend on your "Union assurance level" badge. If a public authority determines that their use case requires Level 3 assurance, they are legally prohibited from procuring services from providers who do not hold that recognition, unless a specific derogation applies (e.g., no adequate alternative exists). This recognition mechanism effectively becomes the new EU-procurement gateway.

What this means for you

For SaaS providers already navigating NIS2 and the Data Act, CADA introduces a new compliance track focused on sovereignty and public procurement eligibility.

  1. Audit your third-country exposures: Even if you are NIS2-compliant, you may not meet CADA's higher assurance levels. If you are controlled by a third-country parent company, or if your subcontractors are located outside the EU, you may be capped at Level 1 or Level 2 (depending on the specific derogations in Annex II). You must map your ownership, data flows, and subcontractor chains to determine your maximum achievable assurance level. Note that for Level 3, personnel must be Union citizens if the public body requires it, whereas for Level 4, the provider must not be subject to third-country control at all.
  2. Prepare for independent audits: If you aim to serve critical public sector clients (Levels 2–4), you must engage with independent auditing organizations. These audits are rigorous, covering everything from source code auditability to the prevention of remote tampering features in your software. Start preparing your technical documentation and security controls for this level of scrutiny now. The audit report must include a "positive" opinion to proceed to recognition.
  3. Leverage the Data Act's switching requirements: Since CADA relies on the ability of public bodies to switch to sovereign providers, ensure your Data Act compliance (portability, switching assistance) is robust. This interoperability is a prerequisite for the CADA ecosystem to function. The proposal explicitly links the Data Act's switching provisions to the goal of reducing dependencies.
  4. Monitor the risk assessments of your public clients: Under Article 29, Member States must conduct risk assessments to determine which public sector activities require Levels 2, 3, or 4. As a provider, you need to understand which of your clients fall into these categories to know which assurance level you need to target. The Commission will provide guidance on these assessments to ensure consistency.

Common misconceptions

  • "NIS2 compliance is enough for public sector cloud contracts." Incorrect. NIS2 ensures technical cybersecurity, but CADA's assurance levels add sovereignty requirements (e.g., data localization, personnel citizenship, absence of third-country control). A provider can be NIS2-compliant but fail to achieve Union Assurance Level 3 due to foreign ownership structures.
  • "CADA only applies to hyperscalers." Incorrect. While large providers are heavily impacted, the definition in Article 2 covers all cloud computing services, including SaaS. SMEs can achieve Level 1 recognition through self-assessment, making them eligible for standard public sector procurement.
  • "The Data Act and CADA are redundant." Incorrect. The Data Act focuses on user rights to switch and port data. CADA focuses on the provider's structural alignment with EU sovereignty. They are complementary: the Data Act enables the market shift that CADA's sovereignty framework encourages.
  • "CADA replaces the AI Act." Incorrect. The AI Act regulates the AI system itself (safety, fundamental rights), while CADA regulates the cloud infrastructure and sovereignty beneath it. The proposal states the AI Act "does not cover aspects of sovereignty."

Official sources

Related

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