NIS2, DORA, II901, ISO 27001, PASSI, HDS, SecNumCloud… Les sigles cyber s’accumulent et donnent souvent l’impression de se contredire. En réalité, ils ne répondent pas aux mêmes questions et sont souvent complémentaires.
Toutes ces exigences cyber ne jouent pas au même niveau :
- Certaines s’imposent à votre activité : obligations réglementaires (NIS2, DORA, …)
- D’autres structurent votre organisation : standards de management (ISO/IEC 27001, ISO/IEC 27701, ISO 22301)
- D’autres sécurisent un périmètre sensible précis (II901)
- Et d’autres servent à choisir le bon prestataire ou à répondre aux attentes de votre filière : qualifications de prestataires (PASSI, PACS, PAMS, etc.).
C’est précisément pour cela que les entreprises s’y perdent : on met souvent dans la même phrase des lois, des référentiels techniques, des normes ISO, des cadres sectoriels et des qualifications de prestataires, alors qu’ils ne répondent pas à la même question.
Le plus utile est de les classer par niveau d’intervention.
Ce guide vous aide à comprendre à quel niveau intervient chaque cadre, comment il se met en œuvre et comment identifier ce qui s’applique réellement à votre activité.
Les grandes familles d’exigences cyber
1. Les réglementations et obligations sectorielles (“Vous devez”)
Elles répondent à la question : qu’est-ce que mon activité m’impose ?
Ce sont les cadres réglementaires ou quasi-réglementaires, qui s’imposent selon votre secteur, vos clients ou votre type d’activité.
On y trouve notamment :
- NIS2 : cadre européen général de cybersécurité pour 18 secteurs critiques, avec obligations de gestion des risques, de gouvernance et de notification d’incidents.
- DORA : règlement européen sectoriel pour les entités financières, applicable depuis le 17 janvier 2025.
- II901 / SIDR : cadre français pour les systèmes d’information sensibles ou Diffusion Restreinte, avec logique d’analyse de risques, d’homologation, de PSSI, d’architecture et de chiffrement.
- LPM / SIIV / OIV, pour les opérateurs d’importance vitale ;
- RGS, surtout pour les échanges électroniques de l’administration ;
- Cyber Resilience Act (CRA), pour les produits comportant des éléments numériques mis sur le marché de l’Union européenne.
- HDS : certification française obligatoire pour les prestataires qui hébergent des données de santé à caractère personnel, afin d’en garantir la sécurité et la conformité.
- PCI DSS : standard international de sécurité qui définit les exigences techniques et organisationnelles pour protéger les données de cartes de paiement.
- MiCA : règlement européen qui encadre l’émission de crypto-actifs ainsi que les services et acteurs associés dans l’Union européenne.
- Cadre SWIFT CSP / CSCF pour les utilisateurs de SWIFT
- Exigences propres à certains marchés, donneurs d’ordre ou secteurs sensibles
- Exigences de filière comme TISAX dans l’automobile (mécanisme d’évaluation et d’échange des résultats d’évaluation en sécurité de l’information, très utilisé pour réduire les efforts entre donneurs d’ordre et fournisseurs).
2. Les standards d’organisation et de management
Ils répondent à la question : comment structurer ma cybersécurité ?
Ici, on est sur des normes de management. Elles n’imposent pas forcément quelque chose par la loi, mais elles servent à structurer l’organisation, la gouvernance, les preuves, les politiques, les audits et l’amélioration continue.
On y trouve notamment :
- ISO/IEC 27001 : le socle pour le SMSI ;
- ISO/IEC 27002 : le catalogue de mesures / contrôles ;
- ISO/IEC 27005 : la gestion des risques SSI ;
- ISO 22301 : la continuité d’activité ;
- ISO/IEC 27035 : la gestion des incidents ;
- ISO/IEC 27036 : la sécurité dans la relation fournisseurs ;
- ISO/IEC 27017 : la sécurité cloud ;
- ISO/IEC 27018 : la protection des données personnelles dans le cloud public.
- ISO/IEC 27701 : système de management de la vie privée, pour les traitements de données personnelles.
- NIST Cybersecurity Framework (CSF) 2.0
- CIS Controls
3. Les référentiels techniques, métiers ou d’environnement
Ils répondent à la question : comment sécuriser un contexte technique spécifique ?
Il s’agit de cadres très utiles quand la cybersécurité doit être traitée dans un contexte particulier.
On y trouve notamment :
- Pour les environnements industriels, et plus précisément les systèmes OT (Operational Technology) qui pilotent les équipements et processus de production, la référence la plus connue est ISA/IEC 62443, qui définit des exigences et bonnes pratiques pour les systèmes d’automatisation et de contrôle industriels.
- Pour l’automobile, il faut connaître ISO/SAE 21434, qui couvre l’ingénierie cybersécurité des systèmes électriques et électroniques des véhicules sur tout leur cycle de vie.
- Pour l’IoT grand public, la référence utile est ETSI EN 303 645, qui fixe des dispositions de haut niveau pour les objets connectés grand public, notamment autour de la gestion des vulnérabilités et de la sécurité après mise sur le marché.
- Pour le cloud, au-delà d’ISO 27017/27018, il existe en France SecNumCloud, qualification ANSSI des offres cloud dites “de confiance”, avec un niveau d’exigence technique, opérationnel et juridique élevé.
- Pour la santé, il faut ajouter HDS : l’hébergement de données de santé sur support numérique doit passer par des hébergeurs certifiés HDS, la certification s’appuyant notamment sur ISO 27001 avec des exigences complémentaires spécifiques à la santé.
- Pour les paiements par carte, la référence incontournable est PCI DSS, aujourd’hui en v4.0.1 selon le PCI Security Standards Council.
4. Les qualifications de prestataires
Elles répondent à la question : quel type d’acteur doit m’auditer ou m’accompagner ?
Côté ANSSI, il faut notamment distinguer :
- PASSI pour l’audit ;
- PACS pour l’assistance et le conseil ;
- PDIS pour la détection ;
- PRIS pour la réponse à incident.
Cela répond à une autre question : “qui est légitime / qualifié pour m’auditer ou m’accompagner ?” et non “quelle règle dois-je appliquer ?”.
Netsystem est ainsi qualifié PASSI sur les portées “audit organisation et physique”, “audit d’architecture” et “audit de configuration”. Cette qualification confirme la solidité de notre expertise technique en matière d’audit de sécurité.
À quel niveau chaque cadre intervient-il ?
NIS2
NIS2 intervient au niveau de l’organisation et de son activité, lorsqu’elle entre dans le périmètre d’un secteur critique ou important. Il s’agit d’un cadre de gouvernance, de gestion des risques, de notification d’incidents, de continuité et de sécurité de la chaîne d’approvisionnement.
DORA
DORA intervient au niveau de l’organisation financière. Il encadre la résilience opérationnelle numérique des entités du secteur financier, avec un focus fort sur les risques ICT, les incidents, les tests et les tiers.
II901 / SIDR
II901 intervient au niveau d’un périmètre SI sensible. Il ne s’applique pas automatiquement à tout le SI d’une entreprise, mais au périmètre amené à traiter des informations sensibles ou Diffusion Restreinte.
ISO 27001
ISO 27001 intervient au niveau de l’organisation. C’est un cadre de management qui permet de structurer la sécurité, d’organiser les responsabilités, les politiques, les audits et l’amélioration continue.
PASSI
PASSI n’intervient pas comme une norme à appliquer. Il qualifie un prestataire d’audit. Ce n’est donc pas une obligation de management interne, mais une exigence possible sur la manière de faire réaliser un audit.
TISAX
TISAX intervient au niveau de la relation client / fournisseur dans la filière automobile et mobilité. Ce n’est pas une norme ISO ni une certification publique au sens classique, mais un mécanisme d’évaluation et d’échange de résultats de sécurité de l’information, souvent porté par une exigence de donneur d’ordre.
MiCA
MiCA intervient au niveau de l’activité liée aux crypto-actifs. Il encadre les émetteurs de certains crypto-actifs et les prestataires de services sur crypto-actifs. Pour les acteurs concernés, il faut aussi examiner DORA sur la résilience opérationnelle numérique, car les prestataires sur crypto-actifs figurent parmi les entités financières couvertes par ce règlement.
Dispositif SAIV / LPM
Le dispositif SAIV intervient au niveau des opérateurs d’importance vitale et de leurs systèmes d’information d’importance vitale. Il impose notamment des obligations de déclaration de périmètre, de notification d’incidents et de contrôle de sécurité. Il ne se confond ni avec NIS2 ni avec ISO 27001, même si les démarches peuvent se compléter.
SWIFT CSCF
Le cadre SWIFT intervient au niveau de l’environnement SWIFT des établissements qui utilisent ce réseau. Il s’agit d’un socle de contrôles de sécurité obligatoire pour les utilisateurs SWIFT, distinct d’un SMSI global mais très structurant sur le périmètre concerné.
Cyber Resilience Act
Le Cyber Resilience Act intervient au niveau du produit comportant des éléments numériques mis sur le marché européen. Il vise la cybersécurité du produit lui-même et la gestion des vulnérabilités sur son cycle de vie, ce qui le distingue de cadres comme ISO 27001 ou NIS2 centrés d’abord sur l’organisation.
Comment savoir ce qui s’applique à votre activité ?
1. Regardez votre secteur
Finance, santé, industrie, administration, recherche, défense, services numériques : votre secteur donne déjà une première orientation sur les cadres à examiner.
2. Regardez les informations que vous traitez
Données personnelles, données de santé, données de paiement, informations Diffusion Restreinte, données industrielles critiques : le type d’information est déterminant.
3. Regardez vos clients et vos contrats
Un grand donneur d’ordre, un marché sensible, une activité de sous-traitance critique ou un programme de recherche stratégique peuvent faire émerger des exigences complémentaires.
4. Regardez votre niveau de maturité
Une organisation peut être tenue par une réglementation, tout en ayant besoin d’un standard comme ISO 27001 pour structurer son pilotage, sa documentation et ses preuves.
5. Regardez votre chaîne de valeur et votre mode de mise sur le marché
Dans certains cas, ce ne sont ni votre taille ni votre secteur au sens large qui déclenchent l’exigence principale, mais votre position dans un écosystème : fournisseur automobile soumis à une demande TISAX, utilisateur SWIFT, prestataire ou émetteur crypto concerné par MiCA et DORA, fabricant ou éditeur d’un produit numérique concerné par le Cyber Resilience Act, ou opérateur critique relevant du SAIV.
Quelques cas concrets pour mieux comprendre
Cas 1 — PME industrielle de défense / spatial
Elle peut avoir intérêt à un ISO 27001 pour structurer son SMSI, mais si elle traite du DR ou relève de la PPST, elle devra surtout cadrer un SIDR sous II901 sur le périmètre concerné. Si elle fait auditer ce périmètre, elle pourra vouloir un PASSI ; si elle se fait accompagner pour cadrer, architecture, risques et homologation, le registre PACS est plus pertinent.
Cas 2 — Banque / assureur
Le cadre principal est DORA, avec risque ICT, tiers, registres, contractualisation, incidents et tests. NIS2 n’est pas le régime principal sur ces sujets pour les entités financières couvertes par DORA. ISO 27001 et ISO 22301 peuvent aider à structurer la réponse. Si cette entité traite en plus un périmètre DR, II901 peut s’ajouter sur ce périmètre spécifique.
Cas 3 — Prestataire IT / infogérant travaillant pour des banques
Il n’est pas automatiquement “sous DORA” comme une banque, mais il subira fortement les exigences contractuelles et de contrôle issues de DORA ; et s’il relève par ailleurs des catégories numériques visées, il peut rester concerné par NIS2 sur son propre périmètre. C’est exactement le genre de cas où les clients ont l’impression de subir plusieurs couches à la fois.
Cas 4 — SaaS RH
Le sujet central est souvent RGPD, avec éventuellement ISO 27701 et ISO 27001 comme cadres de structuration. NIS2 n’entre en jeu que si l’activité, la catégorie et la taille font tomber l’entreprise dans le périmètre visé. II901 n’a pas vocation à s’appliquer sauf traitement d’informations DR/sensibles concernées.
Les erreurs les plus fréquentes
- Croire qu’une certification ISO suffit à répondre automatiquement à toutes les obligations réglementaires
- Penser que PASSI est une norme interne à appliquer
- Traiter II901 comme une simple extension d’ISO 27001 alors qu’il vise un périmètre sensible spécifique
- Sous-estimer la chaîne de sous-traitance (voir notre livre blanc sur le TPRM : gestion des risques tiers)
- Lancer un projet de conformité sans d’abord vérifier l’applicabilité réelle des textes
- Confondre TISAX avec une certification ISO ou une obligation générale applicable à toutes les entreprises
- Penser que MiCA dispense d’examiner DORA sur la résilience ICT pour les acteurs crypto concernés
- Oublier les cadres imposés par un écosystème précis, comme SWIFT ou TISAX
- Raisonner uniquement au niveau de l’entreprise alors que certains textes visent un produit, un périmètre sensible ou un environnement spécifique
Notre recommandation
Avant de lancer un programme de mise en conformité, commencez par une cartographie d’applicabilité.
C’est le moyen le plus simple de distinguer :
- Ce qui est obligatoire pour votre activité
- Ce qui est recommandé
- Ce qui structure votre organisation
- Ce qui s’applique à un périmètre sensible particulier
- Ce qui est différenciant commercialement
