SecNumCloud and BSI C5 on One Kubernetes Platform: Can You Really Avoid Two Stacks?
SecNumCloud is a qualification ANSSI grants to your hosting provider; BSI C5 is an ISAE 3000 attestation you publish about your own service. You can serve French public sector and German enterprise buyers from one Kubernetes platform and one delivery pipeline, but not from one cloud region or one provider.
Yes for the platform layer, no for the hosting layer. One Kubernetes distribution, one GitOps pipeline and one policy set can serve both markets. SecNumCloud requires a provider on the ANSSI qualified list, so an in-scope French public sector workload cannot sit in a non-qualified hyperscaler region.
The two documents are different legal objects. SecNumCloud 3.2 is a qualification ANSSI grants to a cloud service provider for a named service, with criteria on immunity from non-EU extraterritorial law and EU ownership and control. BSI C5 is an attestation report an independent auditor issues under ISAE 3000 about a specific cloud service, and you can obtain one for your own SaaS on almost any cloud, including a French sovereign provider.
The working architecture is two clusters, one control plane. A SecNumCloud-qualified cluster holds in-scope French public sector tenants, a German or EU cluster on Azure, Google Cloud, AWS or an EU provider holds enterprise customers, and the same internal developer platform drives both with identical manifests, identical RBAC and one audit trail.
Most audit evidence is reusable. Access control, logging, change management, encryption, backup, vulnerability management and incident response map across SecNumCloud, C5, ISO 27001 and SOC 2, so the duplicated cost lands on hosting, data services and audit fees.
Qovery deploys into your own cloud accounts and your own existing Kubernetes clusters on AWS, Google Cloud, Azure, Scaleway or self-managed Kubernetes, so a sovereign cluster and a standard EU cluster become two targets of the same git-push workflow. Qovery is not a SecNumCloud qualification and does not make you C5 attested.
You can run one Kubernetes platform for both French public sector buyers and German enterprise buyers. You cannot run one cloud region for both. This looks like a Kubernetes question, but it is really a compliance-architecture question, and the honest answer has two halves.
I keep having the same conversation with European SaaS CTOs. A French ministry wants SecNumCloud, a German insurer wants a BSI C5 report, and the team assumes it now needs two infrastructure stacks, two pipelines and two platform teams. It needs two clusters. Everything else should stay single.
Can one Kubernetes platform really satisfy both SecNumCloud and BSI C5?
Yes at the platform and process layer, no at the hosting layer. One Kubernetes platform, one pipeline and one policy set can serve both buyers, but in-scope SecNumCloud workloads must run on a service listed on the ANSSI qualified catalogue, while a BSI C5 attestation can cover a service on almost any cloud.
In practice the verdict is one Kubernetes distribution, one delivery pipeline, one policy set, and two clusters in two hosting footprints.
The optimistic answer fails first. None of the native regions of AWS, Google Cloud or Microsoft Azure carries a SecNumCloud qualification, so "one global region for everyone" does not exist for in-scope workloads. The pessimistic answer fails too. Duplicating the platform team, the CI, the manifests and the policy engine is the expensive mistake, and it is the one that makes your two audits disagree with each other.
So define the unit of duplication precisely: duplicate the cluster and the data plane, and keep the control plane, the tooling and the compliance process single.
Qualify the deal before you re-architect. The French "cloud au centre" doctrine (circulaire n° 6282-SG of 5 July 2021, updated in 2023) requires SecNumCloud for data of particular sensitivity handled by State administrations, and Article 31 of the SREN law of 21 May 2024 wrote that into law for the State and its operators. Plenty of French customers never trigger it.
The rest of this article walks through five decisions: provider choice, cluster topology, data boundary, evidence reuse, and who operates the control plane.
What is the actual difference between SecNumCloud and BSI C5?
SecNumCloud is a qualification ANSSI grants to a cloud service provider for a named service, valid for a fixed period. BSI C5 is an attestation report an auditor issues under ISAE 3000 about a specific cloud service, which the provider or SaaS vendor then hands to customers. One decides who may host you, the other decides how you prove what you do.
The SecNumCloud 3.2 referential, dated 8 March 2022, mixes technical controls with legal ones. The provider's registered office and infrastructure must sit in the EU, operations must be run from the EU, the service must be immune from non-EU extraterritorial law, and non-EU entities are capped at 24% of capital and voting rights individually and 39% collectively. A qualification names services and datacentres, and it lasts three years with annual surveillance audits (ANSSI FAQ).
C5 works the other way round. Per BSI's C5 FAQ, C5:2020 has 121 criteria and C5:2026 has 168, organised in 17 subject areas and split into basic and additional criteria. The audit runs under ISAE 3000 or a national equivalent. A Type 1 report tests design at a point in time, a Type 2 report tests operating effectiveness over a past period of 3 to 12 months. C5:2026 applies to Type 2 periods beginning on or after 1 June 2027.
Who holds what matters for architecture. Your IaaS or PaaS provider holds SecNumCloud, and you benefit from it only inside its qualified scope. BSI is explicit that only cloud services, not companies, receive a C5 attestation, so you can inherit part of your provider's report through complementary subservice organisation controls and then get your own attestation for your SaaS.
That asymmetry decides the architecture: C5 is portable across clouds, SecNumCloud is not.
A provider's C5 report also lists the controls you, the customer, must implement. Those are exactly the controls your Kubernetes platform should produce evidence for automatically. You will meet adjacent frameworks too: ISO 27001, SOC 2, BSI IT-Grundschutz questions in some German public tenders, and EUCS, which ENISA still lists as a candidate scheme with no adopted text.
This is engineering guidance, not legal advice. Confirm scope with ANSSI, your provider and your auditor.
Dimension
SecNumCloud 3.2
BSI C5 (2020, 2026)
Issuing body
ANSSI, the French national cybersecurity agency, grants it
An independent auditor issues it; BSI publishes the catalogue but does not check reports
Legal nature
A qualification (security visa) for a named service
An attestation report under ISAE 3000, Type 1 or Type 2
Who holds it
The cloud provider, for specific services and datacentres
Any cloud service, including your own SaaS
Size of the framework
One referential covering technical, operational and legal requirements
121 criteria (C5:2020) or 168 (C5:2026) in 17 subject areas
Validity
Three years, with annual surveillance audits
Covers a past period; buyers expect a fresh report every year
Jurisdiction and ownership criteria
Yes: EU seat, EU operations, 24%/39% non-EU ownership caps, extraterritorial-law immunity
Transparency only: the report discloses data location and jurisdiction
Constrains your hosting provider
Yes, the service must be on the ANSSI list
Rarely; all three hyperscalers publish C5 reports
Typical buyer
French State administrations and their operators handling sensitive data
German enterprises, regulated finance, and German public bodies
Portable across clouds
No
Yes
Which cloud providers are SecNumCloud-qualified, and which publish a BSI C5 attestation?
SecNumCloud qualification is held by a short list of mostly French providers published by ANSSI, and that list does not include the native regions of AWS, Google Cloud or Microsoft Azure. All three hyperscalers publish BSI C5 attestations, so the German side rarely constrains provider choice.
Start from the authoritative source: the ANSSI catalogue of qualified services and the SecNumCloud providers page. Qualification is per service and expires, so re-check before signing anything. The statuses below reflect the catalogue and provider announcements as of October 2026.
On the qualified side, 3DS Outscale, OVHcloud, Cloud Temple, Worldline and Cegedim hold IaaS qualifications, and Numspot announced its IaaS qualification on 1 September 2026. Outscale's current IaaS qualification runs to 30 November 2026, so check the renewal if your contract crosses that date.
Scaleway is also still in progress. Its SecNumCloud page says the qualification is "not yet granted", and nothing published puts Kapsule inside the initial scope.
Managed Kubernetes is the weak spot. OVHcloud Managed Kubernetes Service and Scaleway Kapsule sit outside any qualified scope today, and Outscale's OKS qualification status is not confirmed. A qualified region with no managed Kubernetes control plane means you operate etcd yourself, along with upgrades and certificates.
On the German side, AWS completed a 2025 C5 Type 2 attestation covering 183 services across nine regions for October 2024 to September 2025. Google Cloud holds a C5:2020 Type 2 attestation, and Microsoft Azure publishes a combined C5 report through its Service Trust Portal.
The practical consequence: the French public sector deal picks your provider for you, and the German enterprise deal lets you pick.
Provider
SecNumCloud status (Oct 2026)
BSI C5 report
Managed Kubernetes
EU-headquartered
Where to verify
OVHcloud
Qualified: Hosted Private Cloud powered by VMware, Bare Metal Pod; SNC Cloud Platform en cours
What does a two-cluster, one-platform architecture actually look like?
The working pattern is one internal developer platform driving two or more Kubernetes clusters: a SecNumCloud-qualified cluster for in-scope French public sector tenants and their data, and a standard EU cluster for German and other enterprise customers. Both run identical manifests and identical RBAC and feed one audit trail, so everything above the cluster is shared and everything that stores data is duplicated.
This is multi-cluster Kubernetes with a hard legal boundary in the middle. Git repositories, CI definitions and Helm charts stay single. You build container images once, sign them, and mirror them into a registry inside the qualified footprint, with signature verification enforced as an admission policy so nothing pulls from an unqualified registry at deploy time.
Data residency is the hard boundary. Customer data, backups, logs containing personal data, and secrets must stay inside the qualified footprint. This is what breaks naive single-cluster designs during the first audit.
For tenancy, assume a dedicated cluster for in-scope SecNumCloud workloads, or at minimum dedicated node pools, network policies and separate storage. Namespace-only isolation shares a control plane, nodes and etcd with unqualified tenants, and an auditor will ask you to prove that boundary from scratch.
Control plane reach is the question auditors ask first. Document exactly which platform components touch the sovereign cluster, with which credentials, from which jurisdiction, and how that access is logged. Keep ingress, DNS zones and identity provider tenants (or at least realms) separate, so an access review maps cleanly to one footprint.
Then plan for the narrower catalogue. The sovereign footprint usually offers fewer managed services, so decide which queues, caches and search engines you self-host on Kubernetes before you promise a feature parity date. For the workflow side, I wrote up how to run the same Kubernetes workloads on an EU sovereign cloud and AWS.
Architecture layer
Shared or duplicated
Compliance driver
Git repositories, CI definitions, Helm charts
Shared, one source of truth
Change management evidence stays identical for both audits
Container images
Built and signed once, mirrored into a registry per footprint
Supply chain integrity; no runtime pulls from outside the qualified scope
Policy rules (admission, network, image signing)
Shared rules, enforced in each cluster
One control definition satisfies both frameworks
RBAC model and roles
Shared model, separate bindings per footprint
Least privilege, clean per-footprint access reviews
Kubernetes cluster and node pools
Duplicated
SecNumCloud scope covers named services and datacentres
Databases, object storage and backups
Duplicated, never cross-region
Data residency and SecNumCloud localisation
Secrets manager and keys
Duplicated under the same policy
Key control stays inside each jurisdiction
Logs and metrics
Collected per footprint, aggregated only where legally allowed
Personal data in logs must not leave the qualified footprint
Ingress, DNS and identity provider tenant
Duplicated
Network and identity boundaries map to one audit scope each
How much compliance evidence can you reuse across SecNumCloud, C5, ISO 27001 and SOC 2?
Most of it. SecNumCloud, BSI C5, ISO 27001 and SOC 2 overlap heavily on access control, change management, logging, encryption, backup, vulnerability management and incident response, so the duplicated cost sits in hosting and data residency rather than in writing policies twice.
BSI states that the C5 basic criteria include all ISO/IEC 27001 criteria and that C5 requires a management system based on ISO 27001, with published cross-reference tables for C5:2020 (BSI C5 FAQ). So use ISO 27001 as the spine, then layer the SecNumCloud delta and the C5 delta on top.
One platform produces most of the evidence once: immutable deployment history from Git, per-environment RBAC exports, audit logs of who deployed what where and when, backup and restore records, and cluster patch and upgrade history. Define one control per requirement and tag it with every framework it satisfies, so an auditor-facing export becomes a filter.
Some evidence does not transfer. SecNumCloud's jurisdictional, ownership and staff-localisation criteria belong to your provider and have no C5 equivalent. C5 adds the ISAE 3000 reporting format and the customer-side controls your auditor expects you to own.
Type 2 reports change the economics. A C5 Type 2 covers operating effectiveness over 3 to 12 months, so evidence has to be continuous. Automated deployment and access logs are what make that affordable.
Drift kills audits. Once the two footprints diverge, every artefact has to be produced twice and the two audits stop telling the same story.
Control family
SecNumCloud expects
BSI C5 expects
ISO 27001:2022 Annex A anchor
Evidence one platform produces once
Identity and access management
Strong authentication and least privilege for administrators
DEV and OPS areas: approved, tested, documented changes
A.8.32
Git history linked to every deployment
Logging and monitoring
Security event logging kept within the qualified scope
OPS area: logging, monitoring and log protection
A.8.15, A.8.16
Deployment and audit logs per footprint
Encryption and key management
Encryption with keys under the provider's EU control
CRY area: cryptography and key management
A.8.24
Cluster and storage encryption configuration
Backup and restore
Backups kept inside the qualified footprint
OPS area: backup, restore tests
A.8.13
Automated backup schedules and restore records
Vulnerability and patch management
Timely patching and vulnerability handling
OPS area: vulnerability management
A.8.8
Cluster upgrade and image scan history
Incident response
Incident handling and notification procedures
SIM area: security incident management
A.5.24 to A.5.28
Deployment timeline for post-incident review
Physical and jurisdictional criteria
EU seat, EU operations, ownership caps, extraterritorial-law immunity
PS area plus transparency on location and jurisdiction
A.7, A.5.31
None; this comes from your provider
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, Google Cloud, Azure or Scaleway account, or on your existing Kubernetes cluster. Start deploying in under 10 minutes.
What does the two-footprint approach cost compared with running two separate stacks?
A second sovereign footprint mostly costs infrastructure, data services and audit fees, provided both footprints share one platform. Teams that duplicate the platform team and the tooling end up paying for a second DevOps function they never needed, and that headcount is typically the largest line item of the whole programme.
Split the cost into five buckets. Qualified hosting is usually priced above hyperscaler equivalents. Data services and backups are duplicated. Audit fees split by framework: the SecNumCloud qualification is your provider's cost, your C5 attestation is yours. Then come tooling licences and people.
Audit fees vary too much to quote a credible public figure. Expect a C5 Type 2 engagement to scale with scope, the number of services and the observation period, and get quotes from at least two audit firms.
The usual cost-control levers still work inside a regulated footprint: environment auto-stop for non-production, right-sized node pools, ephemeral preview environments per pull request, and keeping non-production in the cheaper footprint when no regulated data is present.
BYOC (running workloads in your own cloud account) keeps the commercial terms yours. Committed-use discounts, Savings Plans and negotiated pricing stay in your name in both footprints, which resold or fully managed hosting does not give you.
Budget engineering time for the narrower managed-service catalogue at qualified providers, and for the operational burden of whatever you self-host to fill it. The rule of thumb I give every CTO: a second cluster is a line item, a second platform team is a budget.
Cost bucket
One platform, two footprints
Two fully separate stacks
What drives the difference
Hosting
Two clusters, sized per footprint
Two clusters, often oversized by two teams
Shared sizing practices and auto-stop
Data services and backups
Duplicated per footprint
Duplicated per footprint
Same in both models; data residency forces it
Platform tooling
One set of licences and configuration
Two sets, often from different vendors
Tool sprawl and double integration work
Audit and attestation
One evidence pipeline, filtered per framework
Two evidence pipelines that drift apart
Whether controls are defined once
Platform engineering headcount
One team operating both footprints
One team per footprint
The largest line item in the programme
Time to first deployment of a new service
Once, then promoted to both footprints
Built twice, by two teams
Shared manifests and environment templates
What traps force teams back into two separate stacks?
Five recurring mistakes force the split teams were trying to avoid: configuration drift between footprints, dependency on non-portable managed services, logs or backups leaving the qualified region, a control plane in a jurisdiction the auditor rejects, and undocumented vendor support access. Drift costs the most because it doubles every audit artefact.
Managed-service lock-in. Teams build on a provider-specific service with no equivalent in the qualified footprint. Prefer Kubernetes-native, portable components and database engines that exist on both sides.
Observability leakage. Logs, traces or metrics containing personal data get shipped to a SaaS outside the qualified jurisdiction. Auditors find this often, and usually late.
Control-plane jurisdiction. Know where your platform, CI runners, secret manager and vendor support access physically sit, and who can reach production. Scope it, document it, log it.
Drift. Two clusters built by hand diverge within a quarter. Declarative manifests, managed cluster upgrades and identical environment definitions keep one audit story true for both footprints.
Personnel and support model. SecNumCloud expects administration from within the EU, which changes how you staff on-call and how you grant break-glass access to the sovereign cluster.
No exit plan. If a qualification lapses or its scope changes, you need to know how fast you can move that tenant. Outscale's renewal date next month is a good reminder. Treat portability as a compliance control and test it with a real redeploy.
How does Qovery let one team run a sovereign cluster and a standard cluster side by side?
Qovery is an internal developer platform that deploys into your own cloud accounts and your own existing Kubernetes clusters, so a SecNumCloud-qualified cluster and a German or EU cluster become two targets of the same workflow. You get the same git-push deployment, the same per-environment RBAC and the same audit trail, run by one platform team, while the qualification and the attestation stay with your provider and your auditor.
Workloads and data stay in your accounts on AWS, Google Cloud, Azure, Scaleway, or your own Kubernetes cluster, and the cloud bill plus any discounts stay in your name. That matters for the data residency argument and for FinOps.
The sovereign footprint is usually the bring-your-own-Kubernetes case. You connect Qovery to a cluster you already run, including OpenShift on Cloud Temple or vanilla Kubernetes on OVHcloud or Outscale. The sovereignty decision stays with your provider choice, and the developer workflow does not change.
Several capabilities generate audit evidence as a side effect:
What Qovery does not do: Qovery is not a SecNumCloud qualification and does not make you C5 attested. Your hosting provider holds the qualification, and your auditor issues your attestation. Qovery reduces the operational and evidence work of running both footprints consistently.
The alternatives are credible. Red Hat OpenShift and Rancher by SUSE are strong choices for operating regulated clusters, and Cloud Temple's qualified PaaS runs on OpenShift. Humanitec and Northflank are solid internal developer platforms. Platform.sh and Clever Cloud are good European PaaS options if you want the provider and the platform in one. Qovery's differentiator is BYOC plus bring-your-own-Kubernetes across EU providers, driven by one workflow.
This setup fits teams selling into regulated European markets that cannot justify a dedicated platform team per footprint.
Approach
Deploys into your own cloud account
Uses your existing cluster
Works across EU sovereign providers
Per-environment RBAC out of the box
Managed cluster upgrades
Platform headcount required
Qovery (BYOC internal developer platform)
Yes: AWS, Google Cloud, Azure, Scaleway
Yes
Yes, through your own cluster
Yes
Yes on Qovery-managed clusters
No dedicated team per footprint
Red Hat OpenShift
Yes
It is the distribution you install
Yes; qualified as a PaaS at Cloud Temple
Yes, through projects and Kubernetes RBAC
Yes, through cluster operators
A team to operate the clusters
Rancher / SUSE
Yes
Yes, imports any conformant cluster
Yes
Yes, through projects
Yes for clusters it provisions
A team to operate Rancher and the clusters
Humanitec
Yes
Yes
Yes, any reachable cluster
Yes
No, it does not run clusters
A platform team to build and own the platform
Northflank
Yes on supported clouds
Yes on supported targets; check your provider
Check per provider
Yes
Yes on clusters it manages
Low
In-house Terraform plus Argo CD
Yes
Yes
Yes
You build it
You do it
A platform team, often one per footprint
How do I set this up with Qovery from Claude Code or Cursor?
Install the Qovery Agent Skills once, then ask your coding agent in plain language to deploy the same application to each footprint. The skills handle onboarding, deployment and troubleshooting, and the MCP Server stays read-only until you enable writes in both the command and the Qovery Console.
Install the Agent Skills globally for Claude Code, Cursor, Codex, OpenCode or Gemini CLI:
Add the MCP Server to Claude Code with OAuth. It is read-only by default, which is what you want for inspecting existing clusters and environments:
BASH
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242
Enable write access only when you want the agent to change things. This also requires enabling write access in the Qovery Console:
BASH
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242
The skills are qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. Skills deploy, and the MCP Server operates what already exists.
Then ask in plain language, for example "deploy this service to my Scaleway cluster and to my Azure cluster with the same environment variables", and approve each action the agent proposes. The full reference is in the AI agent quickstart and the Claude Code integration page.
Frequently asked questions
Can one Kubernetes platform satisfy both SecNumCloud and BSI C5 at the same time?
Yes, at the platform layer: one pipeline, one set of manifests, one RBAC model and one audit trail can serve both. The hosting layer must split, because in-scope SecNumCloud workloads need a service on the ANSSI qualified list. In practice that means two clusters driven by one platform.
What is the difference between a SecNumCloud qualification and a BSI C5 attestation?
A SecNumCloud qualification is granted by ANSSI to a cloud provider for named services, with legal criteria on EU ownership and immunity from non-EU law. A BSI C5 attestation is an ISAE 3000 report an independent auditor issues about a specific cloud service. You inherit SecNumCloud from your provider, while you can get a C5 attestation for your own SaaS.
Are AWS, Microsoft Azure or Google Cloud SecNumCloud-qualified?
No, their native regions are not on the ANSSI qualified list. Google Cloud technology is available in a qualified form through S3NS's PREMI3NS offer, announced as qualified in December 2025. Bleu, which runs Microsoft technology, was still "en cours de qualification" as of October 2026.
Does BSI C5 require hosting in Germany or in the EU?
No, C5 does not mandate a hosting location. It requires transparency: the report discloses where data is processed and which jurisdiction applies, and the buyer decides whether that is acceptable. Many German buyers still prefer EU regions, so check the tender or contract.
Can I obtain a BSI C5 attestation while running on a SecNumCloud-qualified French provider?
Yes. BSI attests cloud services regardless of where they run, and your auditor treats your provider as a subservice organisation. It is easier if the provider has its own C5 report, so ask for it before the engagement starts.
Do I need two Kubernetes clusters, or can namespace isolation satisfy SecNumCloud?
Plan for a dedicated cluster for in-scope SecNumCloud workloads. Namespaces share the control plane, nodes and etcd, which makes the boundary hard to prove to an auditor. If you must share, use dedicated node pools, strict network policies and separate storage, and confirm the design with your provider.
Does using Qovery make my platform SecNumCloud-qualified or BSI C5 attested?
No. Your hosting provider holds the SecNumCloud qualification and your auditor issues the C5 attestation. Qovery runs the same deployment workflow, RBAC and audit trail across both footprints, which reduces the evidence work.
How will EUCS change the SecNumCloud and C5 picture?
Not yet. ENISA still lists EUCS as a candidate scheme, and the sovereignty requirements that would align it with SecNumCloud remain unresolved. Plan around SecNumCloud and C5 today and revisit when a scheme is adopted.
Morgan co-founded Qovery and leads engineering. He writes about Kubernetes architecture, DevOps best practices, and building resilient infrastructure at scale.
Next step
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, Google Cloud, Azure or Scaleway account, or on your existing Kubernetes cluster. Start deploying in under 10 minutes.
