This pattern shows up repeatedly in procurement conversations across EU financial services. A team evaluates cloud providers for a workload with high sovereignty requirements. The vendor’s pitch deck includes SecNumCloud prominently. The website references it. The security questionnaire comes back positive. Everyone’s happy until someone asks to see the actual ANSSI qualification certificate, and it turns out the provider is en cours de qualification. In the process. Not qualified. Not the same thing.
The gap matters. Under DORA (the Digital Operational Resilience Act, the EU regulation setting ICT risk and resilience requirements for financial entities), you need to understand the actual legal and technical properties of your cloud services, not the anticipated ones. “We’re pursuing SecNumCloud certification” is a business plan, not a compliance statement.
What SecNumCloud Actually Is
SecNumCloud is a qualification framework managed by ANSSI (Agence nationale de la sécurité des systèmes d’information, France’s national cybersecurity agency). The current version, 3.2, covers around 360 technical and organisational requirements across fourteen themes, including data protection, key management, personnel security, supply chain visibility, network partitioning, incident management, and legal jurisdiction. That last category carries the most weight for financial services: a qualified provider cannot be subject to non-EU legal orders requiring data handover. This rules out direct subsidiaries of US hyperscalers unless they’ve restructured in ways that genuinely place EU operations beyond the reach of US law (a high bar to clear convincingly, and one that requires more than a press release to substantiate).
What makes SecNumCloud different from certifications like ISO 27001 is that it can’t be self-declared. A provider can’t claim it in their marketing without going through a formal evaluation by an ANSSI-accredited evaluation body (typically a PASSI-qualified audit provider, Prestataire d’Audit de la Sécurité des Systèmes d’Information, or an equivalent authorised lab such as LSTI), followed by review and qualification by ANSSI itself. There’s a published catalog at cyber.gouv.fr. Either your provider is in it, or they aren’t.
For what the référentiel actually requires, including the controls the auditor works through, the companion analysis on SecNumCloud qualification covers it in detail. Here, the focus is on what qualification status actually tells you when you’re evaluating providers.
The Qualification Process
The path to qualification runs through several distinct phases. The provider first engages an ANSSI-accredited audit body to conduct a detailed technical audit against the SecNumCloud référentiel. This isn’t a paper exercise. The audit body reviews architecture, operational procedures, personnel controls, and legal structure. Scope is defined at this stage: a provider can seek qualification for specific service tiers or product lines, not necessarily their entire portfolio.
Once the audit body completes its work, the evaluation report goes to ANSSI. ANSSI reviews it, can request clarifications or additional evidence, and makes the final qualification decision. Only after ANSSI issues its qualification notice does the provider appear in the official qualified products catalog.
Qualification isn’t permanent. It’s typically issued for three years, with annual surveillance audits in between. If a provider makes significant architecture changes or fails a surveillance audit, the qualification can be suspended or withdrawn. Worth tracking: a provider that was qualified when you signed your contract should still be qualified when you’re audited under DORA. Checking the catalog once during procurement is not enough.
The en cours de qualification list exists for providers that have started the process but haven’t completed it. Being in qualification is a meaningful signal, but the timelines are long. Eighteen to twenty-four months from start to qualification is common. There’s no guarantee of success, and scope can change during evaluation.
How to Read the Catalog
Each entry in the catalog at cyber.gouv.fr includes the provider name, specific product or service, version covered, qualification date, and (the part most buyers skip) the scope. That scope definition is where procurement assumptions typically fall apart.
A provider might be qualified for an IaaS offering in a specific data centre configuration but not for their managed Kubernetes service, their object storage tier, or their disaster recovery offering. If your architecture depends on a particular service combination, check whether each component sits within the qualification scope. “Our provider is SecNumCloud qualified” can be technically true and still not cover the services you actually plan to use.
The catalog also shows which référentiel version was used for qualification. Version 3.2 introduced stricter requirements on legal structure and supply chain visibility. A provider qualified under an earlier version may need to re-qualify under 3.2, particularly given the evolving EUCS (European Cybersecurity Certification Scheme for Cloud Services, the pan-EU cloud cybersecurity certification framework that SecNumCloud is expected to align with over time). Ask your provider which version they’re qualified against.
The Market Reality
The qualified IaaS providers at scale are still a short list. OVHcloud and Outscale (part of Dassault Systèmes) have achieved qualification for specific IaaS offerings. Oodrive holds qualification for document and collaboration services. A handful of specialist providers operate in niche segments.
S3NS (the Thales/Google joint venture) achieved SecNumCloud qualification in December 2025, moving it from “credible effort in progress” into the qualified catalog. Bleu (the Orange/Capgemini joint venture distributing Microsoft Azure) is still working through the process, having validated the J1 milestone in September 2025 and targeting full qualification in the first half of 2026. The pace of this cohort has been faster than many expected. Scope still applies though: confirm what S3NS is actually qualified for before assuming it covers your target services.
A European fintech went through a full architecture redesign targeting a SecNumCloud-qualified provider, only to discover that the service tier they needed (managed database offerings) wasn’t within the qualification scope. They ended up running the database on a separately-managed stack, introducing operational overhead and a more complex audit trail under DORA. Not a disaster, but an avoidable detour that cost several months. Confirm scope before you confirm architecture.
SEAL-Level Mapping
SecNumCloud qualification places a provider solidly at SEAL-3 for the services within their qualification scope. SEAL-3 is the Digital Resilience level in the EU Cloud Sovereignty Framework: the service, technology, and operations are immune from non-EU supply-chain disruption, with EU actors exercising meaningful control and only marginal non-EU influence remaining. SecNumCloud qualification clears that bar for the infrastructure layer: EU jurisdiction, EU-based operations, ownership caps on non-EU shareholders, and an ANSSI-supervised audit trail. For most EU financial services workloads requiring a strong sovereignty posture, that covers the primary data residency and jurisdiction requirements.
SEAL-4, the Full Digital Sovereignty tier, goes further and requires a full EU supply chain from silicon to software. Few commercial stacks clear that bar today, and SecNumCloud does not by itself deliver it: qualification validates legal and operational sovereignty at the service layer, but the underlying hardware and technology supply chain still largely sits outside EU control. For financial-services workloads, that gap is typically acceptable; SEAL-3 remains the realistic target.
What qualification doesn’t automatically give you is SEAL-3 across your entire architecture. The provider qualification covers the infrastructure layer. Your data handling, encryption key management, and application-layer choices still determine where your overall deployment lands. A SecNumCloud-qualified IaaS combined with an application that logs telemetry to a US-based monitoring SaaS isn’t a SEAL-3 deployment. The chain matters.
Before You Sign
Check the ANSSI qualified products catalog directly. Don’t rely on sales materials, questionnaire responses, or the provider’s certification landing page. The catalog is the authoritative source.
For services you’re evaluating, confirm the scope covers the specific products you plan to use. Ask for the qualification certificate reference, the effective date, and the expiry date. These are straightforward questions. If the provider can’t answer quickly, that tells you something.
If your target provider is on the in-qualification list, get contractual clarity on what happens if they don’t achieve qualification, or if the timeline extends past your migration deadline. Include a review clause tied to their qualification status. And if your compliance team needs to reference sovereign cloud capabilities in your DORA ICT risk framework documentation, use only confirmed qualified services, not anticipated ones.
SecNumCloud is one of the strongest sovereignty signals available in the EU cloud market right now. The key is making sure the catalog actually says what your architecture assumes it does.
Framework analysis, not legal advice. SecNumCloud is a technical and organisational qualification framework, and the SEAL levels are architectural assessment tools. Nothing here constitutes legal advice on compliance obligations or data protection. Consult your legal counsel and compliance team before making procurement decisions based on SecNumCloud status or SEAL-level assessments.