National Sovereign Cloud Strategies: Cloud de Confiance, Souveräner Cloud and Beyond

National sovereign cloud strategies are formal frameworks, whether government certification schemes, legal qualification labels or procurement standards, through which a country or group of countries defines what it means for a cloud service to be immune from foreign-jurisdiction access demands. For compliance officers and CISOs in regulated sectors, understanding the differences between France’s Cloud de Confiance, Germany’s Souveräner Cloud approach and Swiss FADP-based hosting is not an academic exercise: it determines whether a contract with a cloud provider actually removes the data from the reach of the US CLOUD Act, FISA 702, or the EU e-Evidence Regulation.

France’s SecNumCloud and the Cloud de Confiance Label: A Legal Firewall by Design

The Cloud de Confiance label is the most legally explicit national sovereign cloud qualification currently active in the EU. It rests on the SecNumCloud framework, version 3.2, published by ANSSI (Agence nationale de la sécurité des systèmes d’information) in 2022, and combines strict technical security controls with a structural ownership requirement that disqualifies any provider subject to non-EU law.

The ownership and control requirement is the scheme’s most consequential clause. A provider holding a US parent, even at several layers of corporate distance, cannot qualify, because ANSSI’s position is that the CLOUD Act reaches through corporate structures regardless of where data is physically stored. Former ANSSI Director General Guillaume Poupard described the intent directly: “Cloud de Confiance is not just a label; it is a legal firewall. A provider that holds a US parent company cannot qualify, because the CLOUD Act reaches through corporate structures regardless of where data is physically stored.”

This creates an immediate complication for joint-venture models. S3NS, the joint venture between Thales and Google Cloud, has been awarded SEAL-2 recognition within the emerging EU Cloud Sovereignty Framework and is actively pursuing SecNumCloud qualification. The structural arrangement separates operational control so that Thales, an EU entity, manages the qualified service layer. However, Google Cloud’s underlying technology originates from a US-parent entity, and ANSSI has not yet issued full qualification as of the time of writing. The question of whether operational separation is sufficient to satisfy the legal independence test remains open and is precisely the kind of judgment a compliance officer cannot outsource to a vendor’s marketing materials.

Germany’s Souveräner Cloud and BSI C5: Security Attestation Without Jurisdictional Immunity

Germany’s approach, often grouped under the term Souveräner Cloud, differs from France’s in a fundamental way: the primary certification instrument, the BSI C5 (Cloud Computing Compliance Criteria Catalogue), is a security controls attestation framework, not a legal ownership qualification.

BSI C5 requires an independent auditor to attest that a cloud provider meets defined criteria across domains including physical security, encryption, incident management and supply chain transparency. The scheme is rigorous, internationally recognised, and widely used by German federal agencies and regulated-sector entities. The BSI itself has been explicit about the scheme’s scope: “The BSI C5 attestation was designed to be technology-neutral and auditable across borders, but sovereignty in the jurisdictional sense requires additional contractual and structural safeguards that C5 alone does not mandate.”

The practical implication for cross-border regulated data flows within the EU is significant. A provider attested under C5 that is owned by or operationally dependent on a US-headquartered company remains subject to CLOUD Act compulsion. German federal procurement rules address this by layering C5 attestation with ownership screening and contractual prohibitions, but these are procurement conditions, not part of the C5 standard itself. An organisation in, say, the Netherlands or Austria relying solely on a C5 attestation from a US-owned provider has not removed foreign-jurisdiction exposure.

Where C5 genuinely adds value is in providing a structured, independently audited baseline for security controls that can be compared across providers. For organisations evaluating multi-jurisdictional hosting, C5 attestation answers the question of whether a provider’s controls are auditable; SecNumCloud answers the question of whether the provider is legally immune from foreign access orders. Both questions matter, and they are not the same question.

Why EUCS Failed to Agree on a Sovereignty Tier

ENISA’s EU Cybersecurity Certification Scheme for Cloud Services (EUCS) was intended to create a single EU-wide certification framework replacing the patchwork of national schemes. The proposed High assurance level in earlier ENISA drafts included an EU ownership and control requirement, which would have functionally mirrored Cloud de Confiance at scale.

Member states failed to reach political agreement on that ownership requirement. The blocking coalition included countries with large cloud-consuming industries that relied on US-hyperscaler infrastructure and were concerned that an ownership condition would restrict market access or increase costs. The result is that EUCS, as it has progressed through 2023 and into 2024, covers security control requirements without mandating EU legal ownership at any assurance level. This means EUCS certification, even at the highest proposed level, does not by itself remove CLOUD Act exposure.

The gap has been filled nationally. France retains SecNumCloud. Germany layers C5 with procurement rules. Spain, Italy and others have developed or are developing national reference frameworks. Gaia-X, the European AISBL trust framework, provides interoperability and labelling infrastructure across these national schemes, but Gaia-X labels themselves are not sovereignty certifications: they attest compliance with Gaia-X trust framework rules, which do not include the jurisdictional ownership requirement that defines Cloud de Confiance.

Swiss FADP Hosting: Strong Data Protection, a Different Kind of Sovereignty

The revised Swiss Federal Act on Data Protection (FADP), which entered into force on 1 September 2023, substantially modernised Swiss data protection law and aligned it more closely with GDPR. Swiss-hosted providers operating under the revised FADP offer a genuinely different jurisdictional environment: Switzerland is not subject to FISA 702, the CLOUD Act (which applies only to US-person and US-entity providers), or EU e-Evidence Regulation, because Switzerland is not an EU member state.

The European Commission has issued an adequacy decision for Switzerland, enabling personal data transfers from EU member states without Standard Contractual Clauses. However, this decision was issued under the pre-2023 legal framework, and the Commission’s review of adequacy in light of the revised FADP remains a process compliance officers should track actively.

The foreign-jurisdiction immunity picture for Swiss hosting depends on the provider’s ownership. A Swiss-hosted provider that is owned by a US parent remains subject to CLOUD Act compulsion for data in its possession. A Swiss-owned provider, hosted in Switzerland, with no US operational dependencies, sits outside all three of the major extra-territorial access regimes (CLOUD Act, FISA 702, and EU e-Evidence). That is a meaningful legal position, but it requires verification of the full corporate and operational chain, not merely the location of servers.

Switzerland’s third-country status creates one residual risk: if the adequacy decision were suspended or withdrawn (as occurred with the EU-US Privacy Shield), EU-to-Switzerland transfers would require Standard Contractual Clauses and transfer impact assessments. Organisations with continuity obligations should maintain contingency documentation.

How Compliance Officers Should Use These Schemes Together

A compliance officer evaluating multi-jurisdictional hosting options needs to separate at least three dimensions: security control quality, legal jurisdiction immunity, and cross-border data transfer legitimacy. No single certification mark answers all three simultaneously.

IBM’s 2023 Cost of a Data Breach Report recorded the global average cost of a data breach at USD 4.45 million, the highest in the report’s 18-year history (IBM, 2023). ENISA’s Threat Landscape 2023 identified ransomware and data-targeted attacks on public administrations as among the top threat categories affecting EU member states (ENISA, 2023). These figures establish why the choice of hosting jurisdiction is a financial and operational risk question, not only a compliance formality.

For security control assurance, BSI C5 and equivalent national schemes provide independently audited evidence. For jurisdictional immunity, only schemes with explicit ownership and legal independence requirements (SecNumCloud, or contractually enforced Swiss-hosted equivalents) provide a defensible position. For cross-border transfers, the adequacy status of the destination country and the data category involved determine whether SCCs and transfer impact assessments are required.

The SEAL levels within the EU Cloud Sovereignty Framework, where S3NS holds SEAL-2, provide a useful comparative signal for where a provider sits on the sovereignty spectrum, but SEAL levels are not yet backed by the legally binding force of a national qualification like SecNumCloud. A compliance officer at a French public authority must achieve SecNumCloud-qualified hosting for certain data categories; SEAL-2 alone does not satisfy that requirement today.

ANSSI reports that as of 2024, only a small number of providers have received full SecNumCloud qualification (ANSSI, 2024), which itself signals how demanding the bar is and why many regulated-sector organisations are currently operating on interim arrangements that may not withstand a serious enforcement or incident review.

The practical recommendation is to build a sovereign cloud evaluation matrix that lists each data category, the applicable regulatory requirement (GDPR, NIS-2, DORA, sector-specific), the required assurance level, and then maps candidate providers against all three dimensions independently. A provider can score well on security controls and poorly on jurisdictional immunity, or hold adequacy-backed data transfer legitimacy but fail on ownership independence. The matrix makes those gaps visible before a contract is signed, rather than after a supervisory authority raises them.

FAQ

Does a SecNumCloud-qualified provider completely eliminate CLOUD Act risk?

Yes, for providers that are legally and structurally independent of US-parent entities. SecNumCloud qualification explicitly requires that the provider not be subject to non-EU law that could compel disclosure, which rules out joint ventures where a US firm retains operational or capital control. However, the qualification covers the cloud service itself; organisations must verify that all software dependencies and subprocessors within the stack meet the same criterion.

Can a German federal authority use a BSI C5-attested provider that also holds US ownership without additional safeguards?

BSI C5 attestation does not by itself block CLOUD Act exposure, because C5 is a security controls framework, not a jurisdictional immunity standard. German federal authorities handling classified or sensitive data typically layer C5 with additional procurement requirements, including ownership screening and contractual prohibitions on disclosure to foreign authorities, which are separate from the C5 audit scope.

How does Switzerland’s third-country status affect GDPR-compliant data transfers to Swiss-hosted providers?

The European Commission has issued an adequacy decision for Switzerland, meaning personal data can flow from EU member states to Swiss entities without Standard Contractual Clauses. However, the adequacy decision predates the revised FADP (in force September 2023). Compliance officers should monitor the Commission’s adequacy status page for Switzerland and ensure their transfer impact assessments remain current against any change.

What is the practical difference between EUCS High level and a national scheme like Cloud de Confiance?

EUCS High, as originally proposed by ENISA, would have required EU ownership and control as a condition for the highest assurance level, effectively mirroring the intent of Cloud de Confiance at EU scale. Because member states could not agree on that sovereignty tier, EUCS covers security controls without the jurisdictional ownership requirement. National schemes therefore remain the only certified route to verifiable foreign-jurisdiction immunity today.

Where does S3NS sit in this landscape, and what should a procurement team verify?

S3NS has been awarded SEAL-2 recognition within the EU Cloud Sovereignty Framework and is pursuing SecNumCloud qualification. Its structure places operational control with Thales, an EU entity. Procurement teams should verify directly with ANSSI’s published qualification registry whether full SecNumCloud qualification has been granted before treating the service as Cloud de Confiance-compliant, and should request evidence of the legal independence chain rather than relying on SEAL-2 status alone.