Sovereignty has moved from a talking point to a procurement requirement. If you handle French state data, critical infrastructure workloads, health records, defence-adjacent industrial data or anything labelled "sensitive" by a regulator, sooner or later someone will ask whether your platform runs on a SecNumCloud-qualified provider. This article covers what the qualification actually guarantees, when it is genuinely required, and — more importantly for platform teams — what changes in your architecture the day you leave a hyperscaler for a qualified cloud.
What SecNumCloud actually qualifies
SecNumCloud is a qualification issued by ANSSI, the French national cybersecurity agency, against a published reference framework (currently version 3.2). It is not a self-assessment and not a certification granted by a private auditor on the vendor's terms: a licensed evaluation body audits the provider, and ANSSI grants the qualification for a defined scope and a limited period, with surveillance audits in between.
Two families of requirements matter:
- Security requirements. They overlap heavily with ISO/IEC 27001 and cloud-specific controls: hardening, segregation of tenants, administration from dedicated workstations, cryptography, logging, incident response, supply-chain control, personnel vetting, physical security.
- Immunity to extra-European law. This is the part hyperscalers cannot satisfy by adding encryption. The framework constrains the legal and shareholding structure of the provider, the location of data and of administration, and the exposure of the provider (and its subcontractors) to non-EU jurisdictions such as the US CLOUD Act or FISA 702.
The critical operational detail: qualification applies to a specific service and a specific scope, not to a company. A provider may have its IaaS qualified while its object storage, managed database or Kubernetes offering sits outside the scope. Always read the scope statement on the official ANSSI list rather than the marketing page, and make it a contractual annex.
When is it actually mandatory?
SecNumCloud is not a blanket obligation for every French company. The drivers are:
- The French state's cloud au centre doctrine, which requires SecNumCloud-qualified (or equivalent) hosting for sensitive state data and for applications handling personal data of citizens or civil servants.
- The SREN law, which extends qualification requirements to certain sensitive data handled by public administrations and some critical operators.
- Sector pressure: operators of vital importance, defence supply chains, and increasingly large prime contractors cascading the requirement down to their software suppliers.
Outside that perimeter, the driver is usually risk appetite plus NIS2/DORA governance, where you must document the jurisdictional exposure of your critical providers. A useful framing for the board: SecNumCloud is the only French scheme that addresses legal risk, not just technical risk.
Positioning against the other schemes
| Scheme | Issued by | Addresses extra-EU legal exposure | Typical use case |
|---|---|---|---|
| ISO/IEC 27001 | Accredited certification bodies | No | Baseline ISMS assurance, present everywhere |
| HDS (health data hosting) | Accredited bodies, French framework | No (hyperscalers are HDS-certified) | Mandatory for hosting French health data |
| C5 (Germany) | Auditors, BSI catalogue | No | German public sector expectations |
| SecNumCloud 3.2 | ANSSI | Yes, by design | Sensitive state data, OIV/critical suppliers |
| EUCS (EU scheme) | EU level, still being finalised | Contested at the highest level | Future harmonisation — do not plan on it yet |
Note the trap: HDS and SecNumCloud are orthogonal. Health data can legally sit on an HDS-certified hyperscaler; SecNumCloud adds the jurisdictional dimension that some health and research projects now demand on top.
Classify before you migrate
The most expensive mistake is to treat "sovereign migration" as a lift-and-shift of the entire estate. Start with a data classification pass, workload by workload, and decide the target per class rather than per application. A pragmatic four-tier model works well:
| Class | Examples | Target |
|---|---|---|
| C0 — public | Marketing site, public docs, open data | Any cloud, optimise for cost |
| C1 — internal | Build artefacts, non-prod, telemetry without identifiers | EU region of any provider |
| C2 — confidential | Customer PII, contracts, business-critical databases | EU provider, encryption with customer-held keys, case-by-case |
| C3 — sensitive/regulated | State data, health records under contract, defence-adjacent IP | SecNumCloud-qualified scope, no exception |
Then look at data flows, not just data at rest. A C3 database hosted on a qualified cloud loses much of its value if logs, traces, backups, the CI/CD pipeline or the SaaS ticketing tool that receives stack traces all leave the perimeter. In practice, the observability and CI/CD chain is where sovereignty programmes leak.
What actually changes for a platform team
Qualified clouds are, for the most part, solid IaaS platforms with a narrower managed-service catalogue than AWS, Azure or GCP. Expect to rebuild part of the PaaS layer yourself:
- Kubernetes: depending on the provider, you either consume a managed offering within the qualified scope or you run your own distribution on qualified compute. Budget for cluster lifecycle, CNI, ingress, certificate management and upgrade cadence as real platform work.
- Databases: fewer fully managed engines. Kubernetes operators (CloudNativePG, MariaDB/MySQL operators, Redis, etc.) are the standard answer — with the operational responsibility that comes with them.
- Object storage: S3-compatible in most cases, but verify consistency semantics, lifecycle rules and multipart limits before assuming your tooling works untouched.
- Observability: SaaS APM is off the table for C3 workloads. Self-hosted Prometheus + Thanos/Mimir, Loki, Tempo and Grafana is the realistic stack. Size it early; telemetry storage is a genuine line item.
- CI/CD: GitHub/GitLab SaaS runners reaching into a qualified network is a red flag in an audit. Self-hosted forge or at minimum runners and artefact registries inside the perimeter, with a one-way promotion flow.
- Secrets and keys: plan for a key management service within the qualified scope, or a self-hosted Vault with HSM-backed unsealing. Customer-managed keys are a strong control even inside a qualified cloud.
- GPUs and AI: availability is improving but remains scarcer than on hyperscalers. If you plan to run LLM inference on sensitive data, validate GPU quotas and models of the qualified offer before designing the product.
Keep the platform portable
The best insurance against provider lock-in — and against a qualification scope changing — is to keep everything above the IaaS line portable. Terraform for infrastructure, a Kubernetes-native application layer, GitOps for reconciliation. The provider-specific surface should be a thin module you can rewrite in days, not weeks.
terraform {
required_version = ">= 1.6"
# Remote state MUST stay inside the qualified perimeter.
backend "s3" {
bucket = "tfstate-prod-c3"
key = "platform/terraform.tfstate"
endpoint = "https://s3.qualified-provider.example"
region = "eu-west-0"
skip_credentials_validation = true
skip_region_validation = true
encrypt = true
}
}
module "landing_zone" {
source = "./modules/sovereign-landing-zone"
# Provider-specific details are isolated here.
classification = "C3"
region = "eu-west-0"
private_only = true # no public IP on worker nodes
egress_allowlist = ["repo.internal", "ocsp.internal"]
kms_key_owner = "customer" # customer-managed keys
}
On the cluster side, enforce the perimeter with policy rather than documentation. A Kyverno rule that blocks any image pulled from outside the internal registry catches the most common sovereignty leak — a base image quietly fetched from a public hub at 3 a.m.:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-registries-c3
spec:
validationFailureAction: Enforce
rules:
- name: only-internal-registry
match:
any:
- resources:
kinds: ["Pod"]
namespaceSelector:
matchLabels:
data-classification: "c3"
validate:
message: "Images must come from registry.internal (sovereign perimeter)."
pattern:
spec:
containers:
- image: "registry.internal/*"
Cost and the hybrid reality
Qualified hosting is more expensive per unit of compute than commodity cloud, and the gap widens when you account for the engineering time spent rebuilding managed services. That is a reason to be precise about scope, not a reason to avoid it. The pattern that works: a hybrid estate where C3 workloads live in the qualified perimeter with strict, audited ingress/egress, and everything else stays wherever it is most efficient — with a single IaC codebase, a single GitOps model and a single identity provider spanning both.
Beware of accidental re-coupling. A C0 front end calling a C3 API is fine; a C3 service depending on a SaaS feature flag provider, a US-hosted error tracker or an external CDN that terminates TLS is not. Draw the flow diagram, mark every external dependency, and treat the list as an audit artefact.
How to evaluate a provider
- Check the qualification on ANSSI's official list, including which services and which sites are covered, and the expiry date.
- Ask for the shared responsibility matrix mapped to the 3.2 framework. Many controls land on you, not the provider.
- Test the API and Terraform provider quality during the PoC — this is where the day-to-day developer experience gap shows up.
- Validate backup, DR and exit: reversibility clauses, export formats, egress cost, and a rehearsed restore in a second region or site.
- Check support model and incident notification timelines against your NIS2/DORA obligations.
- Confirm the roadmap for the services you need (managed Kubernetes, KMS, GPUs) is inside the qualified scope, not adjacent to it.
Bottom line
SecNumCloud is the most demanding cloud assurance scheme available in France, and the only one that seriously addresses foreign-law exposure. It comes with a narrower service catalogue and a higher operating cost, which makes data classification the decisive first step: qualify what must be qualified, keep the rest efficient, and invest in a portable platform layer so that the choice of provider remains a one-module decision rather than a three-year migration.