CADA Level 3 Technical Requirements: What EU Cloud Sovereignty Actually Demands

Post #1568 in the sota.io EU Cloud Compliance Series

In the four-tier CADA assurance framework, Level 3 marks the dividing line between geographic compliance and structural sovereignty. Levels 1 and 2 address where data sits and whether third-country law can reach it in theory. Level 3 asks a harder operational question: who can actually access the cloud infrastructure, and under whose authority?

For SaaS developers building for EU public-sector clients — ministries, health authorities, regional governments, defence contractors, and critical infrastructure operators — understanding Level 3 is no longer optional. Procurement frameworks across EU member states are aligning to CADA, and providers that cannot demonstrate Level 3 qualification will be excluded from tender requirements that specify CADA sovereignty compliance.

This guide breaks down every technical and legal requirement at Level 3, with guidance on how to verify provider claims and what documentation to request in procurement due diligence.

Why Level 3 Exists

The gap between Levels 2 and 3 reflects a practical discovery that emerged from post-GDPR enforcement: contractual sovereignty is not the same as operational sovereignty.

A cloud provider can satisfy Level 2 — demonstrating that no third-country law technically compels disclosure — while still creating access conditions that effective sovereignty requires eliminating. The scenarios Level 3 targets include:

• Remote support access by US-employed staff: An EU-based subsidiary uses support tooling and personnel from its US parent for incident response, creating a CLOUD Act exposure path through the employees rather than the legal entity.
• US-parent-controlled identity and access management: The EU subsidiary delegates IAM administration to its US parent's corporate identity systems, meaning US-parent employees retain access permissions.
• Technology stack with extraterritorial dependencies: Core components of the cloud platform — orchestration, monitoring, billing — are operated from non-EU locations, creating operational control vectors that undermine legal independence claims.

Level 3 closes these gaps by imposing requirements not just on corporate structure but on operational practice.

The Five Level 3 Requirements

1. EU Majority Ownership and Control

The requirement: The cloud provider must be majority-owned by entities incorporated in EU member states, and no non-EU entity may hold effective control through voting rights, board composition, or veto powers over strategic decisions.

What "effective control" means in practice:

• Direct equity: a non-EU entity holding >50% of voting shares fails.
• Indirect control: a non-EU entity holding 35-49% of shares but exercising effective veto via shareholder agreement or board appointment rights also fails.
• Golden shares: a non-EU parent retaining a "golden share" with veto rights over data access decisions fails even if their equity stake is minority.

Verification approach for procurement due diligence:

• Request the provider's corporate structure chart showing ultimate beneficial owners.
• Verify incorporation of parent entities (Companies House/equivalent registries in DE, FR, NL, AT, etc.).
• Review shareholder agreements for veto or consent provisions affecting data access.
• Check for cross-shareholding structures that could create indirect non-EU control.

Providers that clearly qualify:

• Hetzner Online GmbH — privately held, family-owned in Germany. No US or non-EU parent.
• OVHcloud SAS — publicly traded, Paris; parent OVH Groupe SAS, France.
• Scaleway SAS — subsidiary of Iliad SA (Xavier Niel, France).
• IONOS SE — Deutsche Telekom AG subsidiary (Germany).

Providers that fail at ownership:

• AWS — Amazon.com Inc. (Delaware, USA) owns AWS EMEA SARL.
• Azure — Microsoft Corporation (Washington, USA) owns Microsoft Ireland Operations.
• GCP — Alphabet Inc. (Delaware, USA) owns Google Cloud EMEA Ltd.
• Oracle Cloud — Oracle Corporation (Texas, USA) owns EU operations.

2. EU-Only Personnel Access

The requirement: All personnel with administrative, technical, or operational access to customer data and infrastructure must be EU nationals or legal residents operating exclusively under EU employment law. Non-EU personnel — including contractors, subcontractors, and parent-company support staff — must have zero access to Level 3 customer environments.

What this means operationally:

• Site reliability engineers with production access must be EU-resident.
• Database administrators with access to customer data volumes must be EU-resident.
• Security operations centre staff monitoring Level 3 customer environments must be EU-resident.
• Support staff with any capacity to access customer data for incident resolution must be EU-resident.

The parent-company support trap: This requirement disqualifies most large non-EU cloud providers even when their EU subsidiaries are otherwise independent. Major cloud providers operate global NOC/SOC staffing models where US, Indian, or other non-EU personnel routinely participate in EU customer incident resolution. Under Level 3, any such access — even for a 30-minute incident bridge — disqualifies the provider for that customer engagement.

Technical controls to verify this:

• Request the provider's PAM (Privileged Access Management) configuration showing geographic access restrictions.
• Verify that production access keys cannot be delegated to non-EU staff profiles.
• Ask for evidence of access logging that shows no non-EU personnel access in a 90-day sample period.
• Review the provider's HR records (or attestations) showing the geographic composition of operational staff.

Why EU-native providers have a structural advantage: Cloud providers built entirely in the EU — Hetzner, Scaleway, OVHcloud, IONOS — hire and train their operational staff locally. They have no legacy of global staffing rotations and no parent-company support infrastructure to disconnect from. Structural compliance is the default; it is not an engineering project.

3. No CLOUD Act or Equivalent Extraterritorial Exposure

The requirement: The provider must demonstrate that no law applicable to it — or to any entity with operational control over customer data — enables disclosure to non-EU authorities without an EU court order.

The CLOUD Act mechanism: The US Clarifying Lawful Overseas Use of Data Act (18 U.S.C. §2523, enacted 2018) enables US law enforcement to compel disclosure of data held by US-incorporated entities regardless of where the data physically resides. The key legal point is entity incorporation, not data location. AWS Frankfurt, Azure Netherlands, and GCP Belgium all store data in EU territory; all are subject to CLOUD Act disclosure because their parent entities are US-incorporated.

What Level 3 providers must demonstrate:

• No parent or affiliate entity subject to CLOUD Act or equivalent legislation (Chinese National Intelligence Law, Russian Data Localisation with state access provisions, UK IPA Schedule 7).
• No contractual arrangement with any CLOUD-Act-covered entity that could be used to access Level 3 customer data.
• Where the provider uses third-party sub-processors, each must also pass the same ownership and jurisdictional test.

The sub-processor exposure pathway: A provider can be EU-incorporated while routing Level 3 customer data through a US-parent-owned monitoring or observability service. If the US-parent sub-processor receives data that includes customer content — even metadata, usage telemetry, or log data containing customer identifiers — CLOUD Act exposure reappears.

Procurement verification questions:

• "Does any entity in your sub-processor chain have US, Chinese, or other extraterritorial jurisdiction?"
• "Can you provide a complete list of sub-processors with their incorporation jurisdiction?"
• "Does your network telemetry or monitoring infrastructure send any customer-derived data to non-EU entities?"

4. EU-Jurisdictional Legal Structure

The requirement: The provider's contractual relationship with public-sector customers must be governed by EU member state law and subject to EU court jurisdiction. Legal disputes, data breach notifications, and regulatory inspections must be resolvable through EU legal mechanisms.

What this rules out: Contracts governed by US law under Delaware or California jurisdiction, mandatory arbitration clauses requiring resolution outside the EU, and indemnity structures that limit liability in ways inconsistent with GDPR and CADA.

Technical correlate: The provider must be able to receive and respond to compelled access requests from EU authorities (Europol, national intelligence agencies, regulatory authorities) through standard EU legal channels — and must be able to challenge any such request through EU courts. A provider whose legal entity is outside the EU cannot do this.

Key contractual provisions to verify:

• Governing law: "This agreement is governed by the laws of [EU member state]."
• Jurisdiction: "The competent courts of [EU city] have exclusive jurisdiction."
• Data access: "Provider will notify customer of any government access request, except where prohibited by law, and will challenge any request it believes to be unlawful."
• Applicable law override: No clause that would allow non-EU law to override GDPR obligations.

5. Operational Independence from Non-EU Parent Systems

The requirement: The provider's operational infrastructure — identity management, monitoring, incident response tooling, network backbone — must not be functionally dependent on systems operated by non-EU entities.

The dependency trap in practice: A cloud provider can be EU-incorporated, EU-staffed, and CLOUD-Act-free while still failing Level 3 if its core operational platform relies on technology controlled by a non-EU parent. Specific failure modes include:

• Using AWS CloudTrail, Azure Monitor, or GCP Stackdriver to monitor EU customer environments.
• Routing EU customer traffic through non-EU network points of presence owned by a non-EU parent.
• Using a US-parent-owned certificate authority or key management service for EU customer data encryption.
• Delegating IAM token issuance to a non-EU identity provider managed by the parent.

The EU-native structural default: Providers built from the ground up in the EU — without a US or non-EU parent to spin off from — do not have these legacy dependencies. Their monitoring is EU-operated. Their identity infrastructure is EU-maintained. Their network backbone does not cross non-EU points of control.

CADA Level 3 Checklist for Procurement Due Diligence

Use this checklist when evaluating cloud providers for public-sector or critical-infrastructure workloads.

What Level 3 Means for SaaS Developers

If you are a SaaS developer targeting public-sector clients, CADA Level 3 creates two distinct compliance paths:

Path 1 — Your cloud provider achieves Level 3. You can inherit the provider's CADA Level 3 status for infrastructure-level controls. You still need to ensure your application-level controls (access logging, encryption at application layer, data minimisation) meet the Level 3 standard, but the foundation is solid.

Path 2 — Your cloud provider does not achieve Level 3. You cannot inherit sovereignty compliance, and no amount of application-level engineering compensates for a Level 3-failed infrastructure layer. Your options are: migrate to a Level 3 provider, or decline public-sector engagements that require Level 3.

There is no middle path. Level 3 is binary in the CADA framework: either the provider qualifies through corporate structure, personnel composition, and operational independence — or they do not. Technical controls are necessary but not sufficient; the legal and ownership structures must hold first.

sota.io and CADA Level 3: As an EU-native managed PaaS operating on Hetzner Germany infrastructure, sota.io qualifies for CADA Level 3 at the infrastructure layer. Hetzner Online GmbH is privately held in Germany, has no non-EU parent, employs EU-resident operational staff, and has no CLOUD Act exposure. SaaS developers deploying on sota.io deploy on Level 3-qualified infrastructure.

Level 3 in the Broader CADA Context

CADA Level 3 is not the endpoint. Level 4 — Full Supply Chain Control — extends the sovereignty requirements to hardware manufacturers, component suppliers, and the entire technology stack. Level 4 is currently achievable only by a small number of highly specialised EU cloud providers and is expected to apply to defence, intelligence, and classified government data initially.

For most public-sector SaaS applications — healthcare administration, education platforms, municipal services, regional procurement systems — Level 3 is the operative standard. It is demanding enough to exclude all US hyperscalers operating under their current corporate structures, while remaining achievable by EU-native cloud providers.

The practical market consequence: public-sector procurement tenders requiring CADA Level 3 compliance will, by structural necessity, route toward EU-headquartered cloud providers. For SaaS developers choosing infrastructure now, aligning with Level 3-qualified providers is not just a compliance decision — it is a market access decision.

Summary

CADA Level 3 requires:

1. EU majority ownership with no non-EU effective control
2. EU-only operational personnel — no non-EU staff with production access
3. No CLOUD Act or equivalent exposure in the provider's corporate structure
4. EU-jurisdictional legal structure for contract and dispute resolution
5. Operational independence from non-EU parent systems and sub-processors

All five must hold simultaneously. A provider that qualifies on four but fails on one does not achieve Level 3 under the CADA framework.

For procurement professionals, the checklist above provides the documentation requests that convert Level 3 claims into verifiable evidence. For SaaS developers, the infrastructure choice at project start determines whether Level 3 public-sector market access is open or closed.

The next post in this series covers CADA versus EUCS: the overlap, the gaps, and which certification matters for different procurement contexts.