If you’ve spent more than ten minutes reading about EU cloud sovereignty, someone’s probably dropped SecNumCloud into the conversation like it’s the answer to everything. It gets quoted in pitch decks, invoked in compliance meetings, whispered like a magic word that banishes all sovereignty concerns. But ask most people what SecNumCloud actually requires (not the marketing summary, the full 360+ requirements) and you’ll get a long pause. “It’s, uh, the French certification thing, right?”
Right. And also quite a bit more than that.
What SecNumCloud Actually Is
SecNumCloud is a security qualification from ANSSI, France’s national cybersecurity agency. Think of it as ISO 27001’s demanding older sibling, if that sibling worked for the government and had opinions about where your data lives.
It starts with the same security controls you’d find in ISO 27001, then adds a second half that’s entirely about sovereignty. The current version (3.2, published March 2022) covers IaaS, PaaS, and SaaS. Over 360 requirements. Fourteen security themes. Getting certified takes roughly 12-18 months. The cert lasts three years, with a mandatory surveillance audit every 18 months. An independent PASSI-qualified auditor verifies your compliance, then ANSSI makes the final call.
Here’s what makes it different. Most cloud security certifications ask: “Is the data secure?” SecNumCloud asks that too. Then it adds a second question that most others skip: “Secure from whom?”
The Requirements That Actually Matter
I could walk through all fourteen themes, but you’d lose interest around minute three and I wouldn’t blame you. So I’m going to focus on what actually sets SecNumCloud apart from every other cloud certification that exists.
Jurisdictional immunity. This is the big one. SecNumCloud 3.2 explicitly requires protection against non-EU laws, with ANSSI’s public commentary naming the US CLOUD Act and FISA as the specific extraterritorial regimes the update was designed to counter. A qualified provider must demonstrate architectural and legal controls that shield customer data from extraterritorial legal compulsion. This requirement alone makes half the world’s cloud providers ineligible. It’s why the hyperscalers can’t just open a French office and call it sovereign.
Ownership caps. No single non-EU entity can hold more than 24% of share capital or voting rights. Non-EU ownership collectively is capped at 39%. No veto rights. No majority board seats. This means AWS, Azure, and Google Cloud can’t simply rebrand a subsidiary and call it qualified. The control has to be genuinely European.
Operational independence. All system support happens within the EU, by EU-based personnel. You can’t have a US engineering team with admin access to infrastructure in Paris. The people running the systems matter as much as the location of the data centres.
Data localisation. All customer data and technical data stays in the EU. Not “primarily in the EU.” Not “with EU residency options.” In the EU, full stop.
Customer-controlled encryption. External key management where the customer controls the keys. The provider can’t decrypt your data. Neither can anyone who pressures the provider.
Put these together and you get something most “sovereign cloud” marketing promises but doesn’t deliver: an independently verified framework that covers legal jurisdiction, operational control, ownership structure, data residency, and key management all at once. This is why I think SecNumCloud is the closest thing we have to a SEAL-4 checklist actually running in production.
Who Actually Has It
As of early 2026, approximately nine providers hold SecNumCloud 3.2 qualification. The market is small. Heavily French. And to be honest, not going to out-feature a hyperscaler anytime soon.
The qualified providers are OVHcloud (IaaS, Bare Metal Pod), Outscale (a Dassault Systèmes subsidiary, IaaS, and the first to get 3.2 at the end of 2023), Cloud Temple (IaaS and PaaS), Worldline (IaaS), Orange Business (Cloud Avenue SecNum, IaaS), Cegedim.cloud (healthcare-focused IaaS), Oodrive (SaaS collaborative suite), Whaller (DONJON, the first SaaS collaborative platform qualified by composition), and the most strategically interesting one: S3NS.
About a dozen more are in the pipeline, including Bleu (the Orange-Capgemini joint venture distributing Microsoft Azure and 365) and NumSpot (built on top of Outscale’s qualified IaaS).
The S3NS Question
S3NS deserves its own section because it represents something genuinely interesting happening in European cloud right now.
S3NS is a joint venture. Thales (French defence and technology) holds the majority stake. Google Cloud provides the underlying technology. In December 2025, S3NS got SecNumCloud 3.2 qualification for PREMI3NS. They became the only provider qualified across IaaS, CaaS, and PaaS simultaneously in a single ANSSI decision. That’s unusual.
The architecture works like this. Google provides the technology platform. Thales runs it through S3NS. Google’s ownership stays below 24%. Operations run from three interconnected data centres in the Paris region, staffed entirely by S3NS employees. Every Google software update goes through a quarantine zone first, where S3NS engineers analyse and validate it before it touches production. Customer encryption keys are externally managed and customer-controlled.
Is this genuine sovereignty or an elaborate wrapper around Google Cloud? I’d say it’s both. And that’s exactly what makes it interesting. ANSSI looked at the structure and said: this works. The quarantine zone, the French-only operations, the capped ownership. These aren’t cosmetic. They’re real architectural controls that address real sovereignty concerns.
But there’s honest tension here. The underlying technology is still Google’s. If Google changed licensing, left Europe, or restructured the partnership, S3NS would face a dependency problem similar to the one we explored in the Broadcom-VMware article. The technology layer stays non-EU even when everything else is locked down.
I’d put S3NS at SEAL-3 with strong SEAL-4 characteristics. It’s the best “US tech plus EU sovereignty” model available. Calling it SEAL-4 would mean pretending the technology dependency doesn’t exist, and I’d rather not do that.
The EUCS Elephant in the Room
Here’s the part that frustrates me. SecNumCloud was supposed to become the blueprint for EUCS, the EU-wide Cybersecurity Certification Scheme. France, Italy, Spain, and Germany all wanted sovereignty requirements included at the “high” assurance level, modelled directly on SecNumCloud.
Then the sovereignty requirements got dropped. Under sustained lobbying pressure from US industry groups (ITI, BSA, CCIA, AmCham EU) and parallel WTO-compliance concerns raised by US trade commentators through the EU-US Trade and Technology Council, but also from a bloc of seven EU member states (Denmark, Estonia, Greece, Ireland, Netherlands, Poland, Sweden) who argued the requirements excluded US firms and politicised a technical scheme, the “high” level got watered down. Technical security controls only. No ownership caps. No jurisdictional immunity. No requirement for independence from non-EU laws.
France’s CNIL warned in July 2024 that the EUCS “no longer allows providers to demonstrate that they protect stored data against access by a foreign power, unlike the SecNumCloud qualification in France.” They weren’t wrong. What we ended up with is a European certification scheme that can give its highest label to providers who are fully subject to the US CLOUD Act. That’s not a gap. It’s a canyon.
This is why SecNumCloud remains the reference. Until EUCS regrows its sovereignty teeth (or CADA introduces EU-level sovereignty tiers), SecNumCloud 3.2 is the only independently verified framework that answers the real question: is this cloud actually sovereign, or just marketed that way?
What This Means for Financial Services
If you’re responsible for cloud procurement at a European bank, here’s how I’d think about SecNumCloud.
It’s not required by DORA, but it answers DORA’s hardest questions. DORA requires you to manage ICT concentration risk (Article 29), maintain migration plans away from critical providers (Article 28), and ensure operational resilience. SecNumCloud-qualified providers address all three. Multiple providers reduce concentration risk. The qualification standards ensure operational resilience. The structural independence makes migration planning credible.
It’s the strongest procurement shortcut available. Building your own sovereignty assessment for every cloud provider is expensive. If a provider holds SecNumCloud 3.2, ANSSI has already verified 360+ requirements including jurisdiction, ownership, operations, and encryption. You still need your own due diligence, but the baseline is higher than anything else on the market.
Nine qualified providers is a beginning, not a mature market. You will trade sovereignty assurance for service breadth. A hyperscaler offers hundreds of managed services. A SecNumCloud provider might offer a dozen. For sensitive workloads (core banking data, customer PII, regulatory reporting), that trade-off is worth it. For commodity compute, you have options.
Watch the non-French providers entering the pipeline. SecNumCloud is French, but the pattern is portable. As CADA takes shape and other EU members look for reference frameworks, SecNumCloud’s requirements will influence whatever EU-wide sovereignty tier emerges. Understanding it now puts you ahead of what’s coming.
A Practical Decision Framework
Here’s how I’d approach this for a specific workload.
Start with the data. What’s the sensitivity? If it’s customer PII, core financial data, or regulatory reporting, you want the highest sovereignty assurance available. SecNumCloud-qualified providers belong on your shortlist.
Then check jurisdiction. Are you regulated in France? SecNumCloud may be required for certain government contracts and is increasingly referenced in procurement specs. If you’re regulated elsewhere in the EU, it’s not required. But it’s the strongest available signal of sovereignty.
Then assess features. Can a SecNumCloud provider deliver what you need? If yes, the sovereignty premium is worth it. If no, ask whether the S3NS model (hyperscaler tech under sovereignty controls) fills the gap. If neither works, document it in your risk register and plan for when the market matures.
What Comes Next
SecNumCloud is the most rigorous cloud sovereignty standard in production today. It’s also French, limited in provider scope, and not yet recognised at EU level. All true simultaneously.
The direction is clear. CADA is expected to introduce EU-wide cloud sovereignty tiers. When it does, that debate will look a lot like the SecNumCloud requirements list. The providers who’ve already cleared SecNumCloud will have a head start. The financial institutions who understand the framework will know exactly what to ask for.
You don’t have to wait for EU harmonisation. SecNumCloud exists now. The qualified providers are real. The framework gives you something most sovereignty conversations lack: a concrete, verifiable set of requirements against which you can evaluate your options.
The gold standard happens to be French.
This article is not legal advice. SecNumCloud qualification status should be verified directly with ANSSI’s published catalogue. DORA compliance obligations depend on your specific classification and jurisdiction. Consult qualified counsel for definitive guidance.