Qualification SecNumCloud 3.2 de l’ANSSI, exigences et limites

SecNumCloud est le référentiel d’exigences de l’ANSSI (Agence nationale de la sécurité des systèmes d’information) qui sert à qualifier les prestataires de services d’informatique en nuage. Cette page lit la version 3.2 du 8 mars 2022 (55 pages), en vigueur d’après le site de l’ANSSI consulté le 11 octobre 2026, et cite chapitres et exigences par leur numéro. Position défendue : la qualification est le meilleur plancher disponible pour choisir un hébergeur, à condition de la lire comme l’attestation d’un service dans une portée, pas comme un brevet d’invulnérabilité décerné à une entreprise.

→ Lire l’explication complète de la marmotte

Référentiel SecNumCloud 3.2 : structure et filiation avec ISO 27001

Le document porte son histoire en tête, dans son historique des versions. Version 1.3 du 30 juillet 2014 publiée pour commentaires, version 2.0 du 20 mars 2015 pour la procédure expérimentale, version 3.0 du 8 décembre 2016 comme première version applicable. La 3.1 a pris en compte le RGPD (Règlement général sur la protection des données) et retiré la mention d’un niveau de qualification avancé. La 3.2 intègre « principalement des critères de protection vis-à-vis du droit extra-européen » et retouche, entre autres, les chapitres 3.2, 3.3.2, 4, 19.1 et 19.6 ainsi que les annexes 1 et 2.

Conséquence pratique : les critères du chapitre 19.6 sont l’apport de la 3.2. Avant d’invoquer une protection contre le droit extra-européen, on vérifie la version du référentiel visée par l’attestation. Un logo sur une plaquette ne porte pas de numéro de version, c’est d’ailleurs son principal avantage commercial.

Le plan tient en peu de lignes. Chapitre 2 : les activités visées. Chapitre 3 : les modalités et la portée de la qualification. Chapitre 4 : le niveau de sécurité visé. Chapitres 5 à 19 : les exigences. Annexe 2 : les recommandations aux commanditaires, que l’acheteur lit rarement alors qu’elle lui est destinée.

Les chapitres 5 à 18 suivent un découpage familier : politique de sécurité et gestion du risque, organisation, ressources humaines, actifs, contrôle d’accès, cryptologie, sécurité physique, exploitation, communications, développement, tiers, incidents, continuité, conformité. Le chapitre 1.1.1 l’assume : le référentiel s’appuie sur ISO (International Organization for Standardization) 27001, « dont il reprend d’ailleurs la structure de l’annexe A ». Il ajoute aussitôt que ses exigences additionnelles « n’induisent pas l’équivalence entre les deux ensembles de règles ». Un certificat ISO 27001 ne vaut donc pas qualification, et le texte ne prétend pas l’inverse non plus. Ce que la certification garantit de son côté est traité dans la page ISO 27001 : ce que la certification garantit.

Deux détails de lecture changent la valeur d’une phrase :

Le chapitre 3.1 distingue les exigences (« doit »), vérifiées pour obtenir la qualification, des recommandations (« il est recommandé »), données comme bonnes pratiques et non vérifiées. Une recommandation du référentiel n’a pas été auditée.
Le chapitre 1.1.1 précise que le référentiel couvre aussi l’hébergement externe partagé classique, et le chapitre 1.1.2 qu’il ne présume d’aucune technologie : « informatique en nuage » n’y implique pas forcément de virtualisation.

Portée de la qualification : un service, pas une entreprise

Le chapitre 3.2 est le plus court et le plus mal lu. Pour être qualifié, un prestataire répond à toutes les exigences « sur la portée choisie », et cette portée est définie par tout ou partie des activités du chapitre 2 :

SaaS (Software as a Service) : application hébergée, le commanditaire ne garde que quelques paramétrages métier ;
PaaS (Platform as a Service) : plateforme d’hébergement, le commanditaire maîtrise les applications déployées ;
CaaS (Container as a Service) : outils de déploiement et d’orchestration de conteneurs, le commanditaire maîtrise outils système, bibliothèques, intergiciels et code ;
IaaS (Infrastructure as a Service) : ressources abstraites, le commanditaire garde la main sur le système d’exploitation, le stockage, les applications et certains composants réseau comme le pare-feu.

La suite du chapitre 3.2 fait tout le sel de l’affaire : un prestataire qualifié garde la faculté de réaliser des prestations hors de son périmètre, sans pouvoir s’en prévaloir. L’annexe 2.c en tire la règle d’achat. Choisir le prestataire dans le catalogue publié par l’ANSSI est une condition « nécessaire mais pas suffisante » ; il faut en plus exiger que la convention de service stipule que la prestation réalisée est une prestation qualifiée. L’exigence 19.1.o fournit le pendant côté prestataire : la convention précise que le service est qualifié et inclut l’attestation.

Le schéma montre la frontière qui passe à l’intérieur d’un même prestataire, et qu’une architecture franchit sans s’en apercevoir dès qu’elle consomme un service voisin.

La règle d’architecture qui en découle : chaque brique consommée (calcul, stockage, base managée, journalisation, gestion de clés) se vérifie une par une dans la portée. Une seule brique hors portée qui voit passer les données suffit à sortir ces données du périmètre qualifié.

Second effet de la portée : en IaaS, tout ce que le commanditaire maîtrise reste son affaire. Un IaaS qualifié héberge avec la même rigueur un système durci et un serveur oublié depuis trois versions majeures. La répartition est détaillée dans la page sur la responsabilité partagée.

Ce que la qualification SecNumCloud ne garantit pas

L’ANSSI écrit elle-même les limites, ce qui dispense de les deviner. Le chapitre 3.3.2 en aligne quatre.

Pas de garantie technique contre le prestataire. Le référentiel « n’apporte pas de garanties techniques fortes contre un accès du prestataire aux données traitées sur le système d’information du service, uniquement des engagements contractuels ». Qui veut une protection technique doit mettre en œuvre « des moyens complémentaires de chiffrement, sous [sa] maîtrise ». Traduction opérationnelle : des clés générées et conservées hors du service. Une clé confiée au service pour qu’il chiffre à la place du commanditaire ramène la garantie au niveau contractuel, quel que soit le nom du produit.

La virtualisation n’est pas une séparation physique. Le texte le rappelle sans détour : elle « ne doit pas être considérée comme un mécanisme de cloisonnement équivalent ». Un besoin de séparation physique ne se satisfait pas par une qualification.

Les produits qualifiés, quand ils existent. Les clauses qui exigent des produits qualifiés s’appliquent « dans la mesure où ces produits existent ».

Pas de substitution aux régimes légaux particuliers. La conformité ne remplace pas les exigences applicables à certaines données, dont le niveau Diffusion Restreinte.

Le chapitre 4 situe le niveau : des données « pour lesquelles un incident de sécurité aurait une conséquence significative », et le respect de l’hygiène informatique décrite par le guide d’hygiène de l’ANSSI. Il ajoute deux refus nets. La conformité n’atteste pas de la conformité à la PSSIE (Politique de sécurité des systèmes d’information de l’État). Et l’hébergement de données soumises à des exigences légales ou réglementaires demande des exigences complémentaires, déterminées par une démarche d’homologation avec appréciation des risques ; la méthode est discutée dans la page EBIOS RM.

L’annexe 2 complète : la qualification n’atteste pas de la capacité à accéder à des informations classifiées de défense ou à en détenir (2.f), ni pour les ACSSI (articles contrôlés de la sécurité des systèmes d’information) (2.g).

Le compromis central se lit ici. On gagne un contrôle par un tiers sur quatorze chapitres d’exigences (5 à 18) et sur les exigences supplémentaires du chapitre 19, des critères capitalistiques vérifiés et une convention de service au contenu imposé. On paie par la contrainte de portée (l’architecture se dessine avec les seules briques qualifiées) et par un reste à faire que le sigle fait oublier. Recommandation : exiger la prestation qualifiée dès que l’appréciation des risques conclut à une conséquence significative, puis poser une seule question. Le prestataire lui-même figure-t-il parmi les menaces retenues ? Si non, la qualification et son chapitre 19.6 répondent. Si oui, il faut un chiffrement sous maîtrise du commanditaire en plus, et aucun label ne le fournit.

Chapitre 19.6 : protection vis-à-vis du droit extra-européen, exigence par exigence

Le chapitre 19.6 compte six exigences. Le schéma en donne l’arbre : deux conditions sur la société, deux sur les tiers auxquels elle recourt, une d’appréciation, une d’information.

19.6.a. Siège statutaire, administration centrale et principal établissement établis dans un État membre. Les trois, pas un au choix.

19.6.b. Le capital social et les droits de vote ne doivent pas être, directement ou indirectement, « individuellement détenus à plus de 24 % » et « collectivement détenus à plus de 39 % » par des entités dont le siège, l’administration centrale ou le principal établissement se trouve hors Union. Pour des actions cotées sur un marché réglementé, les entités visées sont celles déclarées au titre du I de l’article L.233-7 du code de commerce. Ces mêmes entités ne peuvent ni disposer d’un droit de veto, ni désigner la majorité des membres des organes d’administration, de direction ou de surveillance, par contrat ou par clause statutaire. Le texte ferme donc la porte du pacte d’actionnaires, qui est celle par où passe le contrôle quand le capital a l’air sage.

19.6.c. C’est l’exigence qui concerne l’architecte. Une société tierce (sous-traitant compris) établie hors Union, ou appartenant à une société domiciliée hors Union ou contrôlée par elle au sens du II de l’article L233-3 du code de commerce, « ne doit pas avoir la possibilité technique d’obtenir les données opérées au travers du service ». Le périmètre est large : données confiées par les commanditaires, mais aussi données techniques comportant des informations sur eux (identités des bénéficiaires et des administrateurs, données du Software Defined Network, journaux de l’infrastructure, annuaire, certificats, configuration des accès). Les métadonnées sont dans le champ. Vingt ans de métier apprennent que ce sont toujours les journaux qui partent en premier chez l’éditeur, « pour le support ».

19.6.d. Toute société tierce visée par 19.6.c doit garantir au prestataire une « autonomie d’exploitation continue », ou être elle-même qualifiée SecNumCloud. L’autonomie est définie : maintenir le service avec les compétences propres du prestataire ou avec des prestations disponibles auprès d’au moins deux sociétés tierces. Cette exigence vise la continuité, pas la confidentialité : un fournisseur étranger qui coupe l’accès ne doit pas pouvoir arrêter le service.

19.6.e. Respect de la législation sur les droits fondamentaux et des valeurs de l’Union ; les liens avec un gouvernement ou un organisme public étrangers peuvent entrer dans l’appréciation. Rien ici ne se mesure avec un outil.

19.6.f. Information formelle du commanditaire, sous un mois, de tout changement juridique, organisationnel ou technique pouvant affecter la conformité au chapitre 19.6.

Deux lectures à ne pas rater. D’abord l’asymétrie : 19.6.c exige une impossibilité technique pour les tiers extra-européens, alors que le chapitre 3.3.2 ne promet que du contractuel face au prestataire lui-même. Le chapitre protège contre une contrainte venue d’un droit étranger par la structure de la société et de ses fournisseurs ; il ne protège ni contre le prestataire, ni contre une demande fondée sur le droit d’un État membre, qui n’est pas son objet. Ensuite, le chapitre ne nomme aucune loi étrangère. Le cas le plus commenté est traité dans la page sur le Cloud Act (Clarifying Lawful Overseas Use of Data Act).

Localisation des données et exception du support hors Union européenne (chapitre 19.2)

Le chapitre 19.2 parle d’Union européenne, pas de France. Quatre obligations : documenter et communiquer la localisation du stockage et du traitement (19.2.a), stocker et traiter les données du commanditaire dans l’Union (19.2.b), administrer et superviser le service depuis l’Union (19.2.c), stocker et traiter dans l’Union les données techniques (19.2.d), avec la même liste que celle de 19.6.c.

Puis vient l’exception. L’exigence 19.2.e autorise des opérations de support aux commanditaires depuis un État hors Union. Elle impose en contrepartie la liste documentée de ces opérations et des mécanismes qui en assurent le contrôle d’accès et la supervision depuis l’Union. L’exigence 19.1.b oblige à préciser la localisation de ce support dans la convention, et 19.1.n à y indiquer si un accès distant est autorisé pour l’administration ou le support.

« Données dans l’Union » ne signifie donc pas « aucune main hors de l’Union ». Le document à réclamer est la liste de 19.2.e, et la question à instruire est ce qu’un opérateur de support voit réellement quand il ouvre un ticket. Ce que la localisation garantit, et surtout ce qu’elle ne garantit pas, est développé dans l’éditorial sur la souveraineté du cloud.

Le chapitre 19.3 ajoute des interfaces disponibles au moins en français et un support de premier niveau en français. La sécurité y gagne peu, la lecture des messages d’erreur à trois heures du matin davantage.

Convention de service et fin de contrat : chapitres 19.1 et 19.4

Le chapitre 19.1 impose le contenu du contrat, ce qui évite de le négocier ligne à ligne. Les clauses qui pèsent sur l’architecture :

Droit applicable (19.1.c). Le prestataire doit proposer une convention appliquant le droit d’un État membre, et ce droit doit y être identifié. « Proposer » : on vérifie que c’est bien celle-là qui est signée.
Risque de droit non européen (19.1.e). Les éléments d’appréciation des risques liés à la soumission des données au droit d’un État tiers sont remis sur demande. Il faut donc les demander.
Perte de qualification (19.1.g). Résiliation sans pénalité pour le commanditaire.
Réversibilité (19.1.h et 19.1.i). Récupération de l’ensemble des données, fournies ou produites par le service, par fichiers dans des formats documentés et exploitables hors du service, ou par des interfaces documentées de type API (Application Programming Interface). Les modalités figurent dans la convention.
Disponibilité (19.1.j). Le niveau doit être indiqué. L’exigence impose une valeur écrite, elle n’en fixe aucune.
Sauvegarde (19.1.m). La convention dit si les données sont sauvegardées automatiquement ou non ; dans la négative, le prestataire indique les opérations à mener par le commanditaire. Un service qualifié peut donc ne rien sauvegarder du tout, en toute conformité.
Audits (19.1.o à 19.1.q). Réclamation possible auprès de l’ANSSI, audit par l’ANSSI et l’organisme de qualification, audit par un PASSI (prestataire d’audit de la sécurité des systèmes d’information) qualifié mandaté par le prestataire, et mise à disposition des informations nécessaires aux audits de l’article 28 du RGPD.

La fin de contrat est réglée par 19.4.a : effacement sécurisé de l’intégralité des données, précédé d’un préavis formel de vingt et un jours calendaires. Trois méthodes sont admises : réécriture complète des supports, effacement des clés de chiffrement des espaces de stockage (chapitre 10.1), recyclage sécurisé (chapitre 11.9). L’exigence 19.4.b y ajoute la suppression des données techniques. Vingt et un jours forment un préavis d’effacement, pas un calendrier de migration : la réversibilité se répète avant d’en avoir besoin. Pour le reste du contrat, voir la page sur les clauses de sécurité d’un contrat fournisseur.

Charge du commanditaire : prérequis, surface d’attaque et exploitation d’un service qualifié

Prérequis, avant de signer. Une appréciation des risques qui dit si l’incident aurait une conséquence significative et si un régime légal particulier s’applique (chapitre 4). Une cartographie brique par brique face à la portée qualifiée. Des postes dédiés à l’administration pour accéder aux interfaces de gestion du service, recommandés par l’annexe 2.i. Une autorité administrative ou un opérateur d’importance vitale peut demander à l’ANSSI de participer à la définition du cahier des charges (annexe 2.a).

Surface d’attaque résiduelle, et d’où vient la contre-mesure.

Accès du prestataire aux données : engagement contractuel seulement (3.3.2). Contre-mesure : chiffrement avec des clés hors du service, par exemple dans un module cryptographique matériel détenu par le commanditaire.
Voisinage sur une infrastructure virtualisée : non équivalent à une séparation physique (3.3.2). Contre-mesure : ne pas y placer ce que l’appréciation des risques destine à du matériel séparé.
Glissement hors portée : un service annexe non qualifié branché sur les données. Contre-mesure : revue de la cartographie à chaque évolution d’architecture.
Support hors Union : permis par 19.2.e. Contre-mesure : lire la liste des opérations et en tirer des restrictions d’accès.
Console d’administration du commanditaire : hors du champ de l’audit du prestataire. Comptes, droits et authentification restent à durcir côté client, voir la rubrique Identités.

Exploitation. Clés sous maîtrise du commanditaire : génération, rotation et séquestre lui reviennent, et une clé perdue est une donnée perdue, puisque c’était le but. Sauvegarde : tranchée par la clause 19.1.m, pas par le sigle. Supervision : traiter comme un événement de sécurité toute notification reçue au titre de 19.6.f, et vérifier périodiquement que le service figure toujours au catalogue de l’ANSSI. Reprise : un scénario de sortie écrit, fondé sur les formats de 19.1.i. En cas de manquement dans une prestation qualifiée, l’annexe 2.e ouvre une réclamation ; la qualification peut être suspendue, retirée, ou sa portée réduite.

SecNumCloud et EUCS : aucune équivalence invocable

L’EUCS (European Cybersecurity Certification Scheme for Cloud Services) est le schéma européen de certification des services cloud prévu au titre du règlement (UE) 2019/881. Au 7 octobre 2026, il n’est toujours pas adopté par acte d’exécution de la Commission. Seul le projet candidat de décembre 2020 est public ; les versions ultérieures n’ont pas été publiées officiellement par l’ENISA (European Union Agency for Cybersecurity).

La conséquence tient en une phrase : tant que le schéma n’est pas adopté, aucune équivalence avec SecNumCloud ne peut être invoquée, dans un sens comme dans l’autre. Une offre qui se dit « alignée EUCS » s’aligne sur un texte qui n’existe pas encore en droit, ce qui est une forme d’avance sur son temps. Les critères du chapitre 19.6 ne se lisent aujourd’hui que dans le référentiel français.

Exemple : arbre de décision et grille de questions avant de signer une offre SecNumCloud

Le schéma enchaîne les vérifications dans l’ordre où elles éliminent des offres : sensibilité d’abord, portée ensuite, contrat enfin, puis les deux compléments que la qualification ne fournit pas.

La première branche rappelle que le référentiel sert aussi hors qualification : le chapitre 3.3.1 recommande d’obtenir d’un prestataire non qualifié la liste des exigences qu’il ne couvre pas. Les deux dernières ne s’excluent pas et se cumulent souvent.

La grille de questions à poser par écrit, chacune adossée à un numéro :

Quelle version du référentiel et quelle portée figurent sur l’attestation jointe à la convention ? (19.1.o, chapitre 3.2)
Quelles sociétés tierces interviennent dans le service, lesquelles relèvent de 19.6.c, et par quel mécanisme sont-elles privées de la possibilité technique d’obtenir données et données techniques ?
Comment l’autonomie d’exploitation de 19.6.d est-elle assurée pour chacune ?
Quelle est la liste des opérations de support réalisables hors Union, et comment sont-elles contrôlées et supervisées depuis l’Union ? (19.2.e, 19.1.b)
Les données sont-elles sauvegardées automatiquement ? (19.1.m)
Quel niveau de disponibilité est écrit ? (19.1.j)
Sous quels formats ou par quelles interfaces les données sont-elles restituées, et quel délai d’effacement suit le préavis de vingt et un jours ? (19.1.i, 19.4.a)
Quels éléments d’appréciation des risques liés au droit d’un État non membre sont disponibles ? (19.1.e)

Une réponse orale à l’une de ces questions vaut ce que vaut une réponse orale.

FAQ

Une certification ISO 27001 dispense-t-elle de la qualification SecNumCloud ?

Non. Le chapitre 1.1.1 indique que le référentiel reprend la structure de l’annexe A d’ISO 27001, mais que ses exigences additionnelles n’induisent pas d’équivalence entre les deux ensembles de règles.

Un service qualifié SecNumCloud suffit-il pour des données de niveau Diffusion Restreinte ?

Pas à lui seul. Les chapitres 3.3.2 et 4 et l’annexe 2.h le répètent : la conformité ne se substitue pas aux exigences légales ou réglementaires applicables à ces données. Les exigences complémentaires se déterminent par une démarche d’homologation comprenant une appréciation des risques.

Les données d’un service qualifié restent-elles en France ?

Le référentiel exige l’Union européenne, pas la France : stockage, traitement, administration, supervision et données techniques (19.2.b à 19.2.d). La localisation exacte doit être communiquée (19.2.a), et le support peut opérer depuis un État tiers dans les conditions de 19.2.e.

🐝 Ce qui arrive si on s’en passe

Sans prestation qualifiée, la vérification retombe sur chaque commanditaire : négocier la sécurité contrat par contrat et auditer soi-même une offre intégrée, démarche dont le chapitre 1.1.1 constate les limites. Un changement d’actionnaire ou de sous-traitant passe inaperçu, faute d’obligation d’information. Rien n’interdit à une société tierce établie hors Union d’atteindre les journaux, l’annuaire ou les certificats de l’infrastructure. La sortie se négocie le jour où elle devient urgente : ni format de restitution promis, ni préavis avant effacement, ni résiliation sans pénalité. La réclamation auprès de l’ANSSI ne s’applique pas, puisque rien n’a été qualifié. Le chapitre 3.3.1 donne le palliatif minimal : exiger la liste écrite des exigences du référentiel que l’offre ne couvre pas.

🦫 Explication de la marmotte 🍫

Une organisation qui confie ses données à un hébergeur ne peut pas vérifier elle-même ce qui se passe dans ses salles de machines. L’agence française chargée de la sécurité informatique a donc écrit une liste d’exigences : qui peut accéder aux machines, où les données sont stockées, comment les attaques sont traitées, à qui appartient l’entreprise. Un hébergeur qui respecte toute la liste pour un service précis obtient une qualification pour ce service, et seulement pour lui : ses autres offres n’en profitent pas. Le client doit donc faire écrire dans son contrat que ce qu’il achète est bien le service qualifié. La liste impose que les données restent dans l’Union européenne et que l’hébergeur ne soit pas contrôlé par des sociétés d’autres pays, pour qu’une loi étrangère ne puisse pas le forcer à les livrer. Elle impose aussi de rendre les données au client en fin de contrat, puis de les effacer après un préavis de vingt et un jours. La qualification n’empêche pas techniquement l’hébergeur de lire les données : il s’y engage seulement par contrat. Pour s’en protéger, le client doit rendre ses données illisibles avec des clés secrètes qu’il garde chez lui. S’il perd ces clés, les données sont perdues. Si l’hébergeur perd sa qualification, le client peut partir sans pénalité.

Pages voisines

Qualification SecNumCloud 3.2 de l'ANSSI, exigences et limites

Elle cite

: les deux pages se citent l’une l’autre.