CADA Cloud Sovereignty Framework SEAL: Private Sector On-Premises Guide

The CADA Cloud and AI Development Act (COM(2026) 502) introduces a structured five-tier sovereignty assurance system, SEAL-0 through SEAL-4, built on eight discrete sovereignty objectives. For compliance officers, CISOs and data protection officers in regulated sectors, this framework is more than a public-procurement instrument: it is the most granular due-diligence vocabulary the European Commission has yet produced for assessing whether a cloud or on-premises hosting provider genuinely removes sensitive data from foreign jurisdictional reach. Understanding how those objectives map to verifiable technical controls, and how Swiss-domiciled operators fit within a framework anchored to EU ownership rules, is now essential for any organisation evaluating sovereign alternatives to Big Tech infrastructure.

The Eight CADA Sovereignty Objectives as a Technical Control Map

Each of the eight CADA sovereignty objectives corresponds directly to a class of technical or contractual control that an on-premises operator must implement and document. Treating them abstractly misses their procurement utility.

The strategic objective requires that the organisation retain the ability to switch providers or repatriate workloads without disproportionate cost or data loss. Technically this means open, documented APIs, standardised container formats (OCI-compliant images), and a tested egress procedure covering files, permissions and metadata. The legal objective targets freedom from extraterritorial law: the US CLOUD Act (18 U.S.C. §2713), Section 702 of the Foreign Intelligence Surveillance Act, and the EU e-Evidence Regulation all create disclosure obligations that bind a provider regardless of where its servers sit, if its parent entity is incorporated in a covered jurisdiction. An on-premises Swiss-hosted deployment satisfies the legal objective only if the entire ownership chain is free of such exposure.

The operational objective covers continuity and resilience: SLA uptime commitments, tested disaster-recovery runbooks, and immutable off-site backup validated by quarterly restoration exercises. The environmental objective is the least technically demanding but requires documented power usage effectiveness (PUE) figures and renewable energy sourcing statements. Supply-chain transparency demands a full hardware bill of materials, signed firmware provenance records, and a named sub-processor register updated within 30 days of any change, fulfilling both the CADA requirement and the parallel obligation under GDPR Article 28(2) which requires that processors obtain controller authorisation before engaging a sub-processor.

The technological openness objective mandates open-source or openly documented software stacks: proprietary lock-in at the hypervisor or storage layer disqualifies a provider from SEAL-3 and above. Security requires cryptographic controls that include post-quantum algorithms for data at rest and in transit, given the harvest-now-decrypt-later threat model. The EU law compliance objective closes the loop by requiring that the operator demonstrate conformity with GDPR, NIS-2, and sector-specific regulation such as DORA for financial entities, through documented audit trails rather than self-attestation alone.

Producing SEAL-3 and SEAL-4 Evidence for Regulated-Sector Tenders

When responding to procurement tenders that reference the EU Cloud Sovereignty Framework, an on-premises operator must produce a structured evidence package, not a marketing narrative. Buyers using instruments such as the Cloud III Dynamic Purchasing System (Cloud III DPS) increasingly embed SEAL equivalence criteria in their technical evaluation envelopes.

For SEAL-3 equivalence, the minimum evidence set includes: a certified copy of the operator’s articles of incorporation and shareholder register demonstrating EU (or equivalent jurisdiction) ownership; a legal opinion confirming the absence of third-country extraterritorial law exposure across the full corporate group; a sub-processor register formatted to meet GDPR Article 28 requirements, with country of establishment for each sub-processor; ISO 27001 certification covering the relevant scope; and a penetration test report no older than 12 months from an accredited third party.

SEAL-4 adds two further requirements. First, an independently audited sovereignty assessment, typically structured around the EUCS High candidate scheme controls published by ENISA, which provides the closest existing technical baseline. Second, a cryptographic architecture document demonstrating that post-quantum key encapsulation (NIST-standardised algorithms such as ML-KEM, formerly CRYSTALS-Kyber) is deployed for data in transit, and that data-at-rest encryption is managed by a key management system whose root of trust is physically located within the sovereign perimeter and is inaccessible to sub-processors.

“The concentration of cloud services in a small number of providers creates systemic risks for the European digital ecosystem and undermines the ability of Member States to maintain control over sensitive public data.” — ENISA, Cloud Cybersecurity Market Analysis 2023

The Swiss-EU Sovereignty Gap at SEAL-3: Legal Structures That Bridge It

CADA SEAL-3 requires that the provider be owned and controlled from within the EU. Switzerland, despite its deep integration with the European regulatory environment and its revised Federal Act on Data Protection (revFADP, in force September 2023, which the European Commission has assessed as providing adequate protection equivalent to GDPR), is not an EU Member State and its companies are not automatically SEAL-3 eligible.

The practical solution is a dual-entity structure. The Swiss operating company, which holds the physical infrastructure, the staff and the technical expertise, sits beneath an EU-incorporated holding entity, typically registered in Germany, the Netherlands or Luxembourg, that exercises genuine board-level governance and holds the customer-facing contractual relationships. “Genuine governance” is the operative phrase: a brass-plate EU subsidiary with no decision-making authority will not satisfy the CADA ownership test, which looks through corporate form to effective control.

The revFADP remains relevant even within this structure. Because the physical servers are in Switzerland, Swiss data protection law governs the processing. The revFADP aligns with GDPR on processor obligations, data subject rights, and breach notification timelines. For the legal sovereignty objective, the critical advantage of Swiss hosting over US-jurisdiction hosting is the absence of CLOUD Act or FISA 702 exposure: Switzerland has no equivalent statute compelling extraterritorial disclosure to a foreign government. The EU-holding structure satisfies CADA; the Swiss physical location satisfies the legal objective.

Sub-Processor and Supply-Chain Transparency in Practice

The CADA supply-chain transparency objective is the most document-intensive of the eight. Regulated buyers frequently underestimate the depth of disclosure required. A compliant sovereign operator must maintain and make available on request the following categories of documentation.

IBM’s Cost of a Data Breach Report 2024 found that the average total cost of a data breach reached USD 4.88 million, the highest figure in the report’s history, underscoring why supply-chain opacity is a financial risk, not merely a compliance formality. A breach traced to an undisclosed sub-processor creates both regulatory liability under GDPR Article 83 and contractual exposure under DORA’s ICT third-party risk provisions.

Using the Eight-Objective Grid as a Private-Sector Due-Diligence Checklist

The CADA framework was drafted primarily in the context of public-sector procurement, and the Cloud III DPS applies it within that context. However, the eight-objective scoring grid has direct utility for private-sector compliance officers in finance, healthcare and legal services, where regulatory obligations under DORA, NIS-2 and sector-specific supervisory guidance create equivalent pressures.

Thales’s 2023 Cloud Security Study found that approximately 39% of businesses experienced a data breach in their cloud environment that year, demonstrating that the risk profile justifying sovereign procurement criteria is not confined to the public sector. A compliance officer evaluating a colocation or managed hosting provider should score each of the eight CADA objectives on a binary met/not-met basis and require documentary evidence for each “met” claim. This produces a defensible audit record that satisfies both internal risk governance and external regulatory examination.

“Sovereignty over data is not just a technical question; it is a question of who ultimately exercises legal authority over information that affects citizens, businesses and the functioning of public institutions.” — European Data Protection Supervisor, EDPS Opinion 2022/C 233/01

For financial institutions subject to DORA, the grid maps cleanly onto the ICT concentration risk assessment required under Article 28 of that regulation. For healthcare organisations subject to NIS-2, it structures the supply-chain risk management obligation under NIS-2 Article 21(2)(d). Using the CADA grid does not require that the provider itself be formally SEAL-certified; the grid is a due-diligence instrument, and its value is in the structured evidence it demands.

Sequencing CADA SEAL and EUCS Certification

CADA sovereignty assurance levels and the EUCS (EU Cybersecurity Certification Scheme for Cloud Services) serve related but distinct functions. CADA SEAL is a policy classification that determines procurement eligibility. EUCS certification, particularly the proposed High+ tier that incorporates sovereignty and immunity requirements, produces a legally recognised third-party attestation under the EU Cybersecurity Act (Regulation (EU) 2019/881).

ENISA’s analysis of European cloud spending shows that more than 80% of European cloud expenditure flows to non-European hyperscalers, a concentration that both CADA and EUCS High+ are designed to address through certification incentives.

The recommended sequencing is as follows. Organisations should first use the CADA eight-objective grid to assess and select a provider, targeting the SEAL tier that matches their regulatory exposure. They should then require that the selected provider commit contractually to achieving EUCS High certification within a defined timeline, typically 18 to 24 months, using the CADA evidence package as the pre-audit baseline. This approach avoids the scenario in which a provider achieves EUCS High (which in current drafts does not require EU ownership) but fails the SEAL-3 ownership test, or conversely satisfies SEAL-3 on paper but has not undergone the independent technical audit that EUCS certification entails.

For regulated buyers in sectors where supervisory authorities are beginning to specify acceptable certification schemes explicitly, such as the European Banking Authority’s ICT risk guidelines under DORA, building both milestones into the vendor contract from the outset is the most defensible procurement posture.

FAQ

What is the difference between SEAL-2 and SEAL-3 under the CADA Cloud Sovereignty Framework?

SEAL-2 requires technical sovereignty controls such as encryption and data residency within the EU, but does not impose ownership restrictions on the provider. SEAL-3 additionally requires that the cloud provider be owned and controlled from within the EU, excluding entities subject to third-country extraterritorial law such as the US CLOUD Act.

Can a Swiss-domiciled operator qualify for SEAL-3 under CADA?

Not automatically. SEAL-3 specifies EU ownership and control. A Swiss-domiciled operator can bridge this gap by establishing an EU-incorporated holding entity with genuine governance authority over the operational infrastructure, ensuring no ownership chain leads to a third-country-jurisdiction parent, and documenting that legal structure in the sub-processor register required by GDPR Article 28.

How does the CADA framework interact with the Cloud III Dynamic Purchasing System?

Cloud III DPS is a UK Crown Commercial Service procurement vehicle; CADA is an EU legislative instrument operating under different legal systems. Regulated buyers in EU Member States can use the CADA eight-objective grid as the substantive evaluation checklist even when procuring through national DPS frameworks that have not yet formally adopted SEAL tiers, because the grid’s evidentiary requirements are jurisdiction-neutral.

When should a regulated organisation pursue EUCS High certification rather than relying on CADA SEAL scoring alone?

EUCS High provides a formal third-party audit trail that is legally recognised across the EU under the Cybersecurity Act. CADA SEAL levels are a policy and procurement classification. Organisations in sectors governed by NIS-2, DORA or critical infrastructure rules should pursue EUCS certification because it produces the attestation artefacts that regulators and courts will accept; CADA scoring is the planning instrument that identifies which EUCS tier to target.

What hardware and firmware provenance records does a CADA-compliant operator need to maintain?

The CADA supply-chain transparency objective requires operators to document the country of manufacture, the firmware version and update chain, and the identity of all sub-processors involved in hardware management. In practice this means maintaining a bill of materials for servers and network equipment, signed firmware release notes, and a contractual chain from the hardware vendor through any colocation provider to the end customer, all of which must be available for audit on request.