ISO 27001, SOC 2, NIS2, DORA, HDS, SecNumCloud : à quoi sert chaque référentiel et lequel vous concerne

Sous l'étiquette « norme cybersécurité » se rangent des objets de natures différentes : des lois, des certifications, une qualification délivrée par l'État, un rapport d'experts-comptables américains et des guides. NIS2, ISO 27001, SOC 2 et SecNumCloud n'ont ni le même objet, ni le même contrôleur, ni le même résultat. Les confondre conduit à chercher un certificat là où un texte attend des mesures, ou à présenter une mesure là où un acheteur attend une preuve externe.

Cet article range chaque référentiel par nature, puis donne pour chacun son objectif, qui est concerné, qui vérifie, ce que l'on obtient et, quand une source officielle la fixe, la cadence. Il propose ensuite deux arbres de décision et un ordre de traitement pour une scale-up SaaS. Il ne remplace pas la qualification juridique de votre entreprise.

Cinq natures de référentiels, cinq façons d'être vérifié

Devant une exigence, la première question n'est pas « quelle norme ? » mais « de quelle nature ? ». La nature dit qui fixe la règle, qui contrôle et ce que l'on obtient.

• Obligation légale. Un règlement européen s'applique directement ; une directive doit d'abord être transposée en droit national. L'entreprise visée applique le texte et en répond devant l'autorité compétente, qui contrôle et peut sanctionner.
• Certification. Un organisme de certification, tiers indépendant de l'entreprise, vérifie qu'un système de management ou un service satisfait aux exigences d'une norme ou d'un référentiel, puis délivre un certificat. L'ISO elle-même ne certifie pas et ne délivre aucun certificat.
• Qualification. L'ANSSI qualifie des produits et des services au regard d'un référentiel. La qualification est une recommandation de l'État, octroyée pour une durée définie, généralement deux à trois ans selon le type de produit ou de service. SecNumCloud qualifie des offres de services cloud ; PASSI, des prestataires d'audit de la sécurité des systèmes d'information.
• Attestation. Un professionnel indépendant examine les contrôles d'une organisation et émet un rapport contenant son opinion, que les clients lisent. SOC 2, défini par l'AICPA, l'institut américain des experts-comptables, en est l'exemple type.
• Guide ou cadre. Des mesures, des recommandations et un vocabulaire communs, sans vérification qui leur soit propre.

CTN Solutions n'est ni organisme de certification, ni prestataire d'audit qualifié PASSI, ni cabinet de CPA : nous ne délivrons aucun certificat, aucune qualification et aucun rapport SOC 2.

Conséquence pratique : un client qui exige le respect d'une obligation légale attend des mesures et des preuves de leur fonctionnement ; un client qui exige un certificat ou un rapport demande une preuve externe précise, dont il lira le périmètre et la date.

Référentiel par référentiel : objectif, périmètre et contrôleur

Le tableau résume ; les sections qui suivent donnent l'objectif de chaque texte et le point qui change une décision.

NIS2 : où en est la transposition française

La directive (UE) 2022/2555, dite NIS2, devait être transposée par les États membres au plus tard le 17 octobre 2024. Au 7 octobre 2026, la loi française de transposition n'est pas adoptée. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, déposé au Sénat le 15 octobre 2024 en procédure accélérée, y a été adopté en première lecture le 12 mars 2025. La commission spéciale de l'Assemblée nationale a établi son texte, n° 1779, le 10 septembre 2025. La discussion en séance publique, inscrite aux séances des 7 et 9 octobre 2026, a été retirée de l'ordre du jour par la Conférence des présidents du 6 octobre 2026. Le 8 juillet 2026, la Commission européenne a décidé de saisir la Cour de justice de l'Union européenne d'un recours contre la France, l'Irlande, l'Espagne et les Pays-Bas pour défaut de notification des mesures de transposition de la directive.

DORA : la résilience opérationnelle numérique du secteur financier

Le règlement (UE) 2022/2554, dit DORA, s'applique depuis le 17 janvier 2025, sans transposition, aux vingt catégories d'entités financières énumérées à son article 2, des établissements de crédit et de paiement aux entreprises d'assurance. Il fixe des exigences de gestion du risque lié aux technologies de l'information et de la communication (TIC), de notification des incidents majeurs, de tests de résilience opérationnelle numérique et de gestion du risque lié aux prestataires tiers de services TIC. Selon l'entité, l'autorité compétente est notamment l'Autorité de contrôle prudentiel et de résolution (ACPR), l'Autorité des marchés financiers (AMF) ou, pour les établissements de crédit classés comme importants, la Banque centrale européenne.

Pour un fournisseur qui vend à une banque, un assureur ou un établissement de paiement, DORA arrive par le contrat : les dispositions contractuelles de l'article 30 ; les informations que l'entité inscrit dans son registre d'information sur ses accords avec des prestataires de services TIC, selon les modèles du règlement d'exécution (UE) 2024/2956 ; la stratégie de sortie exigée pour les services qui soutiennent des fonctions critiques ou importantes ; la participation éventuelle aux tests de pénétration fondés sur la menace (TLPT), que les entités désignées mènent au moins tous les trois ans. Le 18 novembre 2025, les autorités européennes de surveillance ont publié la liste des prestataires tiers critiques de services TIC qu'elles surveillent directement.

Le détail côté fournisseur se trouve dans « DORA pour les fournisseurs TIC : ce que votre client banque, assureur ou fintech va vous demander » ; la stratégie de sortie rejoint la question traitée dans « Frais de sortie cloud : ce que le Data Act supprime à partir du 12 janvier 2027, et le plan d'action du CTO et du DAF ». Pour outiller ces preuves, voir la page Accompagnement DORA : outiller les preuves techniques.

RGPD : le socle commun

Le RGPD est aussi une obligation de sécurité. Son article 32 impose au responsable du traitement et au sous-traitant des mesures techniques et organisationnelles appropriées pour garantir un niveau de sécurité adapté au risque. Son article 33 impose au responsable du traitement de notifier à la CNIL une violation de données personnelles dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, à moins qu'elle ne soit pas susceptible d'engendrer un risque pour les droits et libertés des personnes. La CNIL contrôle.

Cyber Resilience Act : le logiciel distribué, pas le service opéré

Le règlement (UE) 2024/2847, dit Cyber Resilience Act (CRA), en vigueur depuis le 10 décembre 2024, impose aux fabricants de produits comportant des éléments numériques des exigences essentielles de cybersécurité, dont la gestion des vulnérabilités. Le fabricant établit une déclaration UE de conformité et appose le marquage CE ; selon le produit, l'évaluation de la conformité peut faire intervenir un organisme notifié. Depuis le 11 septembre 2026, les fabricants notifient les vulnérabilités activement exploitées et les incidents graves ayant des répercussions sur la sécurité de leurs produits ; les autres obligations des fabricants s'appliquent à partir du 11 décembre 2027.

Selon ses considérants 11 et 12, le traitement de données à distance n'entre dans son champ que s'il est nécessaire à une fonction d'un produit, et les services en nuage qui ne sont pas conçus et développés sous la responsabilité du fabricant d'un produit en sont exclus. Un SaaS pur n'est donc en principe pas visé en tant que tel, mais un agent installé chez le client, une application mobile, un outil en ligne de commande ou une version sur site peuvent l'être, avec le service distant qui leur est nécessaire. Voir « DevSecOps en pratique : scanner, signer et promouvoir l'image qu'on déploie vraiment ».

ISO/IEC 27001 : la norme du système de management

ISO/IEC 27001:2022, amendée en 2024, fixe les exigences pour établir, mettre en œuvre, tenir à jour et améliorer en continu un SMSI, y compris l'appréciation et le traitement des risques. Ses exigences sont génériques et s'appliquent à toute organisation, quels que soient son type, sa taille ou sa nature. La norme n'impose pas la certification : selon l'ISO, chaque organisation qui la met en œuvre décide de se faire certifier ou non, sauf si un contrat ou une réglementation sectorielle l'exige. Son rythme vient d'ISO/IEC 17021-1, la norme que respecte tout organisme accrédité pour certifier des systèmes de management : un audit initial en deux étapes, des audits de surveillance la première et la deuxième année, un audit de renouvellement la troisième année avant l'échéance du certificat, et au moins un audit par année civile.

Un certificat couvre un périmètre déclaré : c'est la première ligne à lire. Un périmètre qui exclut la plateforme produit ne répond pas à la question d'un client SaaS. Pour la manière de prouver que les mesures fonctionnent, voir « ISO 27001 sur Kubernetes : preuve de conception contre preuve d'efficacité, mesure par mesure de l'annexe A ».

HDS : se reporter aux textes officiels

La certification HDS est prévue par l'article L. 1111-8 du code de la santé publique ; ses conditions sont précisées aux articles R. 1111-9 à R. 1111-11 du même code, qui renvoient à un référentiel de certification approuvé par arrêté du ministre chargé de la santé.

SecNumCloud : une qualification de l'ANSSI

SecNumCloud est le référentiel d'exigences de l'ANSSI pour qualifier des offres de services cloud ; la version en vigueur est la 3.2. La qualification reconnaît une offre précise, pas un fournisseur ni une infrastructure. Elle est valable trois ans, sous réserve du respect des engagements, avec des audits annuels de surveillance. Les offres de type SaaS, PaaS, IaaS et CaaS sont éligibles ; une offre hébergée sur une offre qualifiée n'est pas qualifiée pour autant, même si son évaluation peut alors être adaptée. Selon l'ANSSI, le référentiel est fondamentalement basé sur l'annexe A d'ISO/IEC 27001.

Pour les données d'une sensibilité particulière de l'État, l'article 31 de la loi n° 2024-449 du 21 mai 2024 (loi SREN) et son décret d'application n° 2026-272 du 14 avril 2026 exigent des services cloud dont les critères de sécurité sont attestés par une qualification de l'ANSSI ou par une certification européenne d'un niveau au moins équivalent. Voir « Cloud souverain en 2026 : SecNumCloud, offres qualifiées et Kubernetes, comment choisir ».

SOC 2 : un rapport d'examen, pas un certificat

SOC 2 est un rapport d'attestation défini par l'AICPA : un cabinet de CPA (Certified Public Accountants) examine les contrôles d'une organisation de services au regard des Trust Services Criteria et émet un rapport contenant son opinion, pas un certificat. Voir « SOC 2 ou ISO 27001 : lequel choisir pour un SaaS français, et comment préparer un premier SOC 2 ».

Les guides : ISO/IEC 27002 et NIST CSF 2.0

ISO/IEC 27002:2022 fournit un ensemble de référence de mesures de sécurité de l'information génériques, avec des recommandations de mise en œuvre, notamment pour un SMSI fondé sur ISO/IEC 27001. Le NIST CSF 2.0, publié le 26 février 2024, organise la gestion du risque cyber autour de six fonctions : gouverner, identifier, protéger, détecter, répondre, rétablir ; il s'adresse à toutes les organisations, quels que soient leur secteur et leur taille. Ces guides servent à construire et à comparer ; ils ne constituent pas une preuve à eux seuls.

Ce qu'ISO 27001 couvre déjà, et ce qui reste à produire

ISO/IEC 27001 sert de point d'appui à plusieurs référentiels, et des sources officielles l'en rapprochent explicitement : selon l'ANSSI, SecNumCloud est fondamentalement basé sur l'annexe A d'ISO/IEC 27001 ; l'AICPA publie une correspondance entre les Trust Services Criteria de 2017 et ISO 27001. Une correspondance n'est pas une équivalence : une mesure peut ne couvrir qu'une partie d'une exigence.

Le tableau suivant est une lecture professionnelle, pas une correspondance officielle. NIS2 n'y figure pas : ses exigences françaises dépendront de la loi de transposition, non adoptée au 7 octobre 2026.

Deux limites sont à vérifier avant de faire valoir un certificat. Un certificat dont le périmètre se limite au siège ou aux fonctions support ne dit rien de la plateforme vendue. Et le certificat ou la qualification d'un fournisseur cloud couvre ses services, dans le périmètre qu'il a déclaré, pas l'usage que vous en faites : ce qui est construit au-dessus reste à démontrer. La même lecture vaut quand l'exploitation est confiée à un tiers : voir « Externaliser l'exploitation cloud et Kubernetes : que confier, à qui et avec quel contrat ».

Lequel vous concerne : deux arbres de décision

Deux questions distinctes se posent : que vous impose la loi, et quelle preuve vos clients vous demandent-ils ? Dans chaque arbre, les réponses se cumulent : une réponse positive ajoute un référentiel, puis la lecture continue. Les arbres orientent ; la qualification juridique de votre entité relève de votre conseil juridique.

Dans quel ordre s'y prendre pour une scale-up SaaS

Ce qui suit est un avis professionnel, pas une règle. Il suppose un éditeur SaaS B2B qui vend en Europe à des entreprises, sans données de carte de paiement ni données de santé ; l'ordre change dès qu'un de ces paramètres change.

1. Qualifier avant de construire. Faire établir par votre conseil juridique ce qui s'impose à l'entreprise : DORA, NIS2, Cyber Resilience Act, RGPD. Cela fixe ce qui est obligatoire ; le reste relève d'un choix commercial.
2. Poser le socle RGPD et l'inventaire. Données, sous-traitants, actifs et flux : la matière première de tous les autres référentiels.
3. Construire le SMSI selon ISO/IEC 27001 avant de décider de la certification. Appréciation des risques, mesures, politiques, gestion des incidents. Dimensionner le circuit d'incident sur les délais de notification applicables, par exemple 72 heures au plus tard, si possible, pour notifier à la CNIL une violation de données. Collecter les preuves depuis les configurations réelles : elles resserviront lors d'une levée de fonds ou d'une cession, comme le décrit « Data room technique d'un SaaS : ce que l'acquéreur vérifie et comment préparer les preuves ».
4. Répondre aux questionnaires depuis ce socle. Chaque réponse renvoie à une mesure et à une preuve existantes ; voir « Questionnaire sécurité d'une banque ou d'un assureur : répondre vite sans surpromettre ».
5. Choisir la première preuve externe selon ce que les acheteurs exigent par écrit. Un certificat ISO/IEC 27001, un rapport SOC 2, ou les deux, qui peuvent reposer sur un même SMSI.
6. Ajouter les couches sectorielles quand elles apparaissent. Clients financiers : dispositions de l'article 30 de DORA, données du registre d'information, stratégie de sortie. Données d'une sensibilité particulière de l'État : vérifier si le service lui-même doit être qualifié, l'hébergement sur une offre qualifiée ne valant pas qualification.
7. Suivre les jalons datés. La loi française de transposition de NIS2, non adoptée au 7 octobre 2026 ; pour un logiciel distribué, les notifications exigées par le Cyber Resilience Act depuis le 11 septembre 2026, puis les autres obligations des fabricants au 11 décembre 2027.

Trois erreurs sont à éviter dans les réponses commerciales : écrire « conforme NIS2 » avant la loi française et avant la qualification juridique de l'entité ; présenter un certificat dont le périmètre exclut le produit ; présenter les certifications ou qualifications de son fournisseur cloud comme les siennes. Pour passer de l'exigence à la preuve technique, la page Conformité technique : de l'exigence à la preuve décrit ce que nous mettons en œuvre, sans nous substituer à l'organisme de certification, au cabinet de CPA ni au conseil juridique.

Sources officielles et limites de lecture

Les faits réglementaires cités ont été vérifiés le 7 octobre 2026 sur les sources officielles listées ci-dessous. Les pages de l'ISO citées ont été lues le 7 octobre 2026 ; les éditions des normes ont été contrôlées dans les métadonnées ouvertes de l'ISO. Les normes ISO elles-mêmes et le guide SOC 2 de l'AICPA, payants, n'ont pas été consultés en entier ; le cycle de certification est repris de documents d'organismes d'accréditation.

Cette lecture ne remplace pas la qualification juridique de votre entité, qui dépendra notamment du texte français définitif de NIS2. Elle décrit les référentiels à une date et doit être relue à chaque étape législative ou nouvelle version : l'ordre du jour de l'Assemblée nationale peut changer à chaque Conférence des présidents. Elle s'appuie sur la lecture directe des textes et sur une méthode de mise en œuvre technique, jamais sur une pratique juridique ou de certification, que nous n'exerçons pas.

Sources

1. Projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, dossier législatif, Assemblée nationale, https://www.assemblee-nationale.fr/dyn/17/dossiers/DLR5L17N50731, consulté le 07/10/2026.
2. Relevé de conclusions de la Conférence des présidents du mardi 6 octobre 2026, Assemblée nationale, https://www2.assemblee-nationale.fr/17/la-conference-des-presidents/releve-de-conclusions/reunion-du-mardi-6-octobre-2026, consulté le 07/10/2026.
3. Résilience des infrastructures critiques et renforcement de la cybersécurité, dossier législatif pjl24-033, Sénat, https://www.senat.fr/dossier-legislatif/pjl24-033.html, consulté le 07/10/2026.
4. La Commission saisit la Cour de justice d'un recours contre l'Irlande, l'Espagne, la France et les Pays-Bas pour défaut de transposition des règles en matière de cybersécurité (IP/26/1499, 8 juillet 2026), Commission européenne, https://ec.europa.eu/commission/presscorner/detail/fr/ip_26_1499, consulté le 07/10/2026.
5. Directive (UE) 2022/2555 du 14 décembre 2022 (NIS 2), articles 2 et 41, annexes I et II, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022L2555, consulté le 07/10/2026.
6. Règlement (UE) 2022/2554 du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier (DORA), articles 1, 2, 26, 28, 30, 46 et 64, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022R2554, consulté le 07/10/2026.
7. Règlement d'exécution (UE) 2024/2956 de la Commission du 29 novembre 2024 (modèles types pour le registre d'informations), EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32024R2956, consulté le 07/10/2026.
8. European Supervisory Authorities designate critical ICT third-party providers under the Digital Operational Resilience Act (18 novembre 2025), AEAPP (EIOPA), https://www.eiopa.europa.eu/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital-2025-11-18_en, consulté le 07/10/2026.
9. Digital Operational Resilience Act (DORA), ACPR, https://acpr.banque-france.fr/fr/reglementation/focus-sur-la-reglementation/transverse/digital-operational-resilience-act-dora, consulté le 07/10/2026.
10. The Regulation on Digital Operational Resilience in the Financial Sector (DORA), AMF, https://www.amf-france.org/en/news-publications/depth/dora, consulté le 07/10/2026.
11. Règlement européen sur la protection des données, chapitre IV, articles 32 et 33, CNIL, https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre4, consulté le 07/10/2026.
12. Règlement (UE) 2024/2847 du 23 octobre 2024 (Cyber Resilience Act), considérants 11 et 12, articles 2, 14, 28, 30, 32, 52 et 71, annexe I, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32024R2847, consulté le 07/10/2026.
13. Métadonnées ouvertes des normes ISO (ISO/IEC 27001:2022, ISO/IEC 27001:2022/Amd 1:2024, ISO/IEC 27002:2022, ISO/IEC 17021-1:2015), ISO Open Data, https://isopublicstorageprod.blob.core.windows.net/opendata/_latest/iso_deliverables_metadata/json/iso_deliverables_metadata.jsonl, consulté le 07/10/2026.
14. ISO/IEC 27001:2022, Information security management systems, Requirements, ISO, https://www.iso.org/standard/27001, consulté le 07/10/2026.
15. Certification, ISO, https://www.iso.org/certification.html, consulté le 07/10/2026.
16. Question 37.12, ISO 17021-1:2015, clause 9.1.3, European co-operation for Accreditation, https://european-accreditation.org/sp_accordion_faqs/question-37-12-iso-17021-12015-clause-9-1-3/, consulté le 07/10/2026.
17. ISO/IEC 17021-1:2015, section 9, exigences relatives aux processus (support publié par l'organisme d'accréditation IAS), https://www.iasonline.org/wp-content/uploads/2021/02/17021-1-2015-Section-9.pdf, consulté le 07/10/2026.
18. Article L1111-8 du code de la santé publique (version en vigueur depuis le 1er juillet 2025), Légifrance, https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000049577902, consulté le 07/10/2026.
19. Code de la santé publique, articles R1111-9 à R1111-11, Légifrance, https://www.legifrance.gouv.fr/codes/section_lc/LEGITEXT000006072665/LEGISCTA000006196138/, consulté le 07/10/2026.
20. FAQ avant de se lancer dans la qualification SecNumCloud, ANSSI, https://cyber.gouv.fr/enjeux-technologiques/cloud/faq-qualification-secnumcloud/, consulté le 07/10/2026.
21. FAQ, vos questions sur la qualification et la certification, ANSSI, https://cyber.gouv.fr/offre-de-service/solutions-certifiees-et-qualifiees/comprendre-levaluation-de-securite/faq-qualification-certification/, consulté le 07/10/2026.
22. Loi n° 2024-449 du 21 mai 2024 visant à sécuriser et à réguler l'espace numérique, article 31, Légifrance, https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000049563368, consulté le 07/10/2026.
23. Décret n° 2026-272 du 14 avril 2026 relatif à la protection des données d'une sensibilité particulière des administrations, opérateurs et groupements d'intérêt public de l'Etat traitées par un service d'informatique en nuage fourni par un prestataire privé, articles 1 et 2, Légifrance, https://www.legifrance.gouv.fr/loda/id/JORFTEXT000053900789, consulté le 07/10/2026.
24. Arrêté du 12 août 2026 portant approbation du référentiel d'exigences relatif aux prestataires de services d'informatique en nuage, Légifrance, https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000054678082, consulté le 07/10/2026.
25. SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy, AICPA & CIMA, https://www.aicpa-cima.com/cpe-learning/publication/soc-2-reporting-on-an-examination-of-controls-at-a-service-organization-relevant-to-security-availability-processing-integrity-confidentiality-or-privacy, consulté le 07/10/2026.
26. SOC 3, SOC for Service Organizations: Trust Services Criteria for General Use Report, AICPA & CIMA, https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-3, consulté le 07/10/2026.
27. Mapping: 2017 Trust Services Criteria to ISO 27001, AICPA & CIMA, https://www.aicpa-cima.com/resources/download/mapping-2017-trust-services-criteria-to-iso-27001, consulté le 07/10/2026.
28. NIST Releases Version 2.0 of Landmark Cybersecurity Framework (26 février 2024), NIST, https://www.nist.gov/news-events/news/2024/02/nist-releases-version-20-landmark-cybersecurity-framework, consulté le 07/10/2026.