What does 'operational autonomy' mean in CADA?

Under the proposed Cloud and AI Development Act (CADA), "operational autonomy" ensures that a cloud computing service provider retains full, unrestricted c

Summary Under the proposed Cloud and AI Development Act (CADA), "operational autonomy" ensures that a cloud computing service provider retains full, unrestricted control over the performance, continuity, and delivery of its services, free from external interference. Specifically, Annex II 1.1(d) mandates that if a provider outsources technical or operational support to third parties outside the Union, those arrangements must not compromise this autonomy. For CTOs and architects, this means verifying that a provider's reliance on external support does not create a dependency allowing a third party to disrupt service, degrade quality, or exert control over infrastructure. As proposed, CADA allows such outsourcing only if strict legal, technical, and organisational measures guarantee the EU provider's independent decision-making power.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, introduces a harmonised EU framework for cloud sovereignty, centred on four "Union assurance levels" established by Article 16. These levels define the cumulative criteria a cloud computing service provider must meet to be recognised as offering a specific level of trust and sovereignty to EU public sector bodies. A core pillar of this framework is operational autonomy—the ability of the provider to act independently in delivering its service without being subject to external coercion or control.

The Legal Definition and Requirement

While CADA does not provide a standalone dictionary definition of "operational autonomy" in Article 2 (Definitions), the concept is operationally defined through the cumulative criteria in Annex II. The most direct and critical reference appears in the criteria for Union Assurance Level 1.

Annex II, Section 1.1(d) states that for a provider to meet Level 1 criteria:

"where the cloud computing service provider outsources the technical and operational support or assistance, including any subsequent sub-outsourcing arrangements, to third-party service providers outside of the Union, the necessary legal, technical and organisational measures are implemented to ensure traceability, security and governance of those operations and those operations do not, in any way, compromise the operational autonomy of the cloud computing service provider."

This provision is critical because it acknowledges that EU-based providers may still rely on global supply chains or third-country support teams. However, it draws a strict line: the existence of external support is permissible only if it does not erode the provider's ability to independently manage its service. The text explicitly includes "subsequent sub-outsourcing arrangements," meaning the autonomy requirement cascades down the entire supply chain.

What Constitutes a Compromise of Autonomy?

Based on the broader context of the sovereignty framework (Articles 16–24) and the stricter requirements for higher assurance levels (Levels 2–4), "compromising operational autonomy" generally refers to scenarios where a third party (whether a subcontractor, a parent company in a third country, or a foreign government) can:

Disrupt Service Continuity: Force the provider to stop or degrade the service (e.g., through "kill switches," remote tampering, or legal coercion).
Control Infrastructure: Exert influence over the hardware, software, or personnel required to deliver the service.
Impose External Mandates: Force the provider to comply with restrictive measures, sanctions, or data access requests from a third country that conflict with EU law or the provider's ability to serve EU customers.

For Union Assurance Levels 2, 3, and 4, the requirements become significantly stricter. For example, Annex II 2.1(g) requires providers to demonstrate that third-country control does not "restrain or restrict the provider's ability to perform and deliver the service." At Level 4, the provider and its subcontractors must not be subject to the control of a third country at all (Annex II 4.1(g)). Thus, "operational autonomy" is a sliding scale: Level 1 allows outsourced support if autonomy is preserved; higher levels require structural independence from third-country control.

The Role of Governance and Traceability

Annex II 1.1(d) links operational autonomy directly to governance. A provider cannot simply claim autonomy; they must implement "necessary legal, technical and organisational measures" to ensure it. For architects and CTOs evaluating a provider, this means looking for evidence of:

Legal Measures: Contracts that explicitly prohibit third-party support vendors from accessing customer data or interfering with service delivery without explicit, prior authorisation from the EU-based provider. These contracts must also ensure that the provider is not legally compelled by a third country to act against the interests of the EU customer.
Technical Measures: Network architectures that isolate administrative access. For instance, support staff in a third country should not have privileged access to the production environment hosting EU customer data. The text implies that "traceability" is required, suggesting that all access and actions by third-party support must be logged and auditable.
Organisational Measures: Clear chains of command where the EU-based provider retains final decision-making authority over operational incidents, updates, and security responses. The provider must demonstrate that it is not merely a shell for a third-country entity.

What this means for you

For CTOs, architects, and SMEs evaluating cloud providers for EU public sector work or high-assurance private use cases, "operational autonomy" is a due diligence checklist item, not just a marketing term. As proposed, CADA would require public procurement to align with these assurance levels (Article 30), making this a critical compliance factor.

1. Audit Your Provider's Outsourcing Map

If your provider claims Union Assurance Level 1, request documentation on their subcontracting arrangements, particularly those involving support staff outside the Union. Ask:

Which third-country entities provide technical support?
What level of access do these entities have? (e.g., Can they reset passwords, deploy patches, or view logs?)
What contractual clauses prevent these entities from acting on behalf of their home government to disrupt service?

2. Verify "No Compromise" Controls

Ensure the provider has implemented the "necessary legal, technical and organisational measures" cited in Annex II 1.1(d).

Technical: Look for geographically restricted administrative paths. Support tickets from third countries should not trigger automatic access to EU infrastructure.
Legal: Review the provider's Master Services Agreement (MSA) and subcontractor agreements for clauses that guarantee the EU provider's right to refuse unlawful third-country data requests or service disruption orders.

3. Plan for Migration Risks

If your current provider relies heavily on third-country support without robust autonomy safeguards, they may fail to meet Level 1 criteria under CADA. As public sector procurement shifts toward Union Assurance Level 1 (Article 30), you may face vendor lock-in risks if your provider cannot demonstrate compliance. Start assessing alternative providers who have already decoupled their operational support from third-country dependencies.

4. Distinguish Between "Support" and "Control"

Not all third-country involvement violates autonomy. A provider can use third-country software libraries or hardware (if designed/manufactured elsewhere) as long as the operational control remains with the EU entity. Focus your assessment on personnel and administrative access, not just the origin of the software stack. The key is whether the third party can force a change or prevent a change in the service.

Common misconceptions

Misconception 1: "Operational autonomy means no third-country involvement." False. Annex II 1.1(d) explicitly permits outsourcing technical support to third parties outside the Union. The requirement is that these arrangements do not compromise the provider's autonomy. A provider can use global support teams if strict governance and technical isolation are in place.

Misconception 2: "Autonomy is only about data location." False. Data localisation (keeping data within the Union) is a separate criterion (Annex II 1.1(c)). Operational autonomy is about control and continuity. You can have data in the Union but still lack autonomy if a third-country parent company can remotely shut down the service or force a degradation of performance.

Misconception 3: "Level 1 requires full independence from third countries." False. Level 1 allows for third-country control of the provider (e.g., an EU subsidiary of a US parent) if the provider guarantees that no third-country laws require reporting vulnerabilities before exploitation (Annex II 1.1(g)) and that outsourced support does not compromise autonomy (Annex II 1.1(d)). Higher levels (2–4) impose stricter bans on third-country control.

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