La directive NIS 2

Une directive européenne

La directive (UE) 2022/2555 aussi appelée directive NIS 2 (Network and Information Security 2) est une directive européenne adoptée fin 2022. Elle vise à renforcer la cybersécurité et la résilience des entités essentielles (EE) et importantes (EI) opérant dans des secteurs critiques au sein de l’Union européenne.

Elle a été officiellement publiée le 27 décembre 2022 et impose aux États membres de transposer ses dispositions dans leur législation nationale au plus tard le 17 octobre 2024.

La directive est complétée par plusieurs textes et documents qui en précisent la mise en œuvre, en particulier :

• et détaille les exigences applicables à certains types de fournisseurs de services numériques : fournisseur de DNS, registres de domaines TLD, prestataires de sécurité… (lien)
• Les recommandations de l’ENISA proposant des guides pour la mise en œuvre de la directive NIS 2 : NIS 2 Technical Implementation Guidance | ENISA. Ces recommandations ne sont cependant pas des exigences réglementaires et servent uniquement d’aide à la mise en conformité.

La transposition à l’échelle nationale

La transposition de la directive NIS 2 en France est en cours, via un processus législatif national et un travail de cadrage des exigences par l’ANSSI. Une 1^ère version de travail, non encore opposable, du Référentiel Cyber France (ReCyF) a été publiée par l’ANSSI le 17 mars 2026. Elle propose un ensemble d’objectifs de sécurité (au nombre de 20) destinés à préciser les exigences applicables aux entités importantes ou essentielles.

En parallèle, l’ANSSI a également mis à disposition des guides afin d’accompagner les organisations dans l’identification de leur statut au regard de NIS 2, notamment pour déterminer si elles relèvent du périmètre des entités soumises à cette réglementation.

Focus sur l’impact de NIS 2 sur les SOC

La sécurité opérationnelle dans NIS 2

Un SOC (Security Operations Center) regroupe les capacités humaines, organisationnelles et techniques dédiées à la supervision de la sécurité du système d’information. Ses missions couvrent notamment la collecte et l’analyse des événements de sécurité, la détection des activités suspectes, la qualification et l’escalade des alertes, ainsi que l’appui à la réponse aux incidents.

Bien que la directive NIS 2 ne cible pas directement le SOC en tant que fonction, elle impose plusieurs exigences directement liées à la gestion des risques cyber et, en particulier, à la gestion des incidents de sécurité. À ce titre, NIS 2 a un impact direct sur l’organisation, les processus et les capacités attendues des SOC au sein des entités assujetties, notamment au travers de deux articles clés :

• L’article 21, qui définit les mesures de gestion des risques en matière de cybersécurité.
• L’article 23, qui définit les obligations de notification et d’information en cas d’incident significatif.

Focus sur le cas du SOC externalisé

Aujourd’hui, de nombreuses organisations ont recours à un modèle externe ou hybride, confiant à des MSSP tout ou partie des activités du SOC. Cette externalisation complexifie la mise en conformité aux réglementations, en particulier NIS 2.

Dans ce cas, il convient de distinguer les obligations qui pèsent sur l’entité assujettie de celles qui peuvent s’appliquer directement au MSSP.

La directive NIS 2 définit les exigences de cybersécurité applicables aux entités essentielles et importantes. Ces exigences sont de la responsabilité de l’entité, qui peut toutefois s’appuyer sur des prestataires (par exemple des MSSP) pour tout ou partie de leur mise en œuvre. L’entité n’est pas responsable de la conformité de ses prestataires aux exigences de NIS 2 qui leur sont applicables, mais doit s’assurer que ses prestataires critiques présentent un niveau de sécurité approprié.

L’ENISA travaille actuellement à l’élaboration d’un schéma européen de certification (EUMSS) pour les fournisseurs de services de sécurité. Ce schéma vise à harmoniser les exigences au sein de l’UE, à renforcer la confiance dans ces prestataires en facilitant l’évaluation de leur niveau de sécurité et de leur conformité aux exigences réglementaires européennes (NIS 2, DORA…).

Pour les MSSP, la Commission européenne a publié le Règlement d’exécution de la Commission C(2024) 7151 fixant les exigences de gestion des risques et des incidents applicables directement aux MSSP (et à certains autres prestataires numériques). Ce règlement d’exécution exige des MSSP d’être capables de gérer les risques et incidents de cybersécurité de bout en bout, non seulement pour leurs clients, mais également sur leur propre périmètre. Il impose notamment aux MSSP de :

• Mettre en place une gestion des risques cyber sur leur propre périmètre (identifier les risques et appliquer des mesures de sécurité adaptées) ;
• Être en mesure de démontrer leur conformité aux exigences de NIS 2 ;
• Disposer de capacités opérationnelles de détection, de qualification, et de réponse aux incidents, incluant la notification aux autorités, clients et parties prenantes lorsque requis ;
• Évaluer les risques liés à leurs propres fournisseurs.

Les objectifs des SOC dans le ReCyF

Le ReCyf couvre notamment la gestion des incidents de sécurité via les objectifs :

• Objectif 12 : Identification et réaction aux incidents de sécurité
• Objectif 20 : Supervision de la sécurité des systèmes d’information

Ces deux objectifs traduisent une attente simple : l’entité doit être capable de détecter un incident, de le qualifier et d’y répondre de façon structurée. Cela suppose des procédures claires, une exploitation effective des événements de sécurité et une capacité à identifier et traiter les alertes.

Ces objectifs s’appliquent principalement aux entités essentielles (EE). Le point 12.3, qui impose de définir un processus d’analyse et de qualification des événements anormaux, fait toutefois exception, puisqu’il concerne à la fois les entités importantes (EI) et les entités essentielles (EE).

Définir une feuille de route de mise en conformité

Comment se mettre en conformité ?

La directive NIS 2, ainsi que les référentiels nationaux comme ceux de l’ANSSI, définissent avant tout des objectifs de sécurité à atteindre. En revanche, elles restent volontairement peu prescriptives sur les moyens à mettre en œuvre. Dès lors, quelles sont concrètement les actions nécessaires pour se mettre en conformité ?

La première étape consiste à réaliser une analyse d’écarts, visant à évaluer le niveau actuel de conformité de l’entité au regard des exigences réglementaires, sur l’ensemble de son périmètre. Cela implique notamment d’identifier précisément les activités opérées en interne et celles externalisées auprès de prestataires (notamment les MSSP ou SOC externalisés). Il est essentiel de rappeler que, même en cas d’externalisation, la responsabilité de la conformité reste pleinement portée par l’entité.

Nous identifions une liste de 8 points clés à actionner pour adresser les principales exigences de NIS 2, issus de notre synthèse des exigences les plus structurantes pour le SOC, et des recommandations de l’ENISA. Cette liste est une aide pour la mise en conformité, mais ne dispense pas d’une analyse d’écarts se référant directement aux textes réglementaires.

Afin de faciliter la lisibilité, les points clés ont été regroupés pour être couverts au travers de la définition et de la mise en place de 2 politiques : politique de gestion des incidents, et politique de supervision. Pour chaque point clé, nous proposons des étapes clés à mettre en place, principalement issues des recommandations de l’ENISA.

Politique de gestion des incidents

Définir un processus de signalement des événements anormaux.

Avant de mettre en place une supervision complexe par la collecte et l’analyse de journaux informatiques, il convient de s’assurer qu’un dispositif de signalement et d’analyse des événements anormaux est en place. En effet, la première ligne de détection est déjà l’implication des employés qui peuvent détecter et signaler les signaux faibles et les signaler (mail de phishing, comportement anormal d’un système).

Il est donc essentiel de :

• Mettre à disposition des employés, des fournisseurs et des clients un dispositif leur permettant de signaler des événements suspects. Prévoir plusieurs canaux de signalement et s’assurer de leur facilité d’accès et d’utilisation.
• Former les employés à l’usage du mécanisme de remontée d’incidents et communiquer le processus de signalement aux fournisseurs et clients.
• Définir les événements suspects selon des critères (non-exhaustifs) et lister les éléments à inclure dans les signalements.

Définir un processus de gestion des incidents

Quelle que soit la source d’un incident, qu’il provienne d’un signalement par un employé ou d’une alerte levée par un outil de détection, il doit être traité selon un processus cadré. C’est pourquoi, l’ANSSI demande de définir une procédure de traitement des incidents. Pour cela, nous recommandons de :

• Définir une politique de gestion des incidents incluant :
  • un système de catégorisation des incidents : sévérité, type… ainsi que des critères permettant la catégorisation : impact opérationnel, criticité des périmètres affectés, impact réglementaire… ainsi que les critères pour classer les événements comme incidents. S’assurer que la couvre différents types d’incident.
  • un plan de triage et d’escalade des incidents, et
  • les rôles et responsabilités des parties prenantes dans le traitement de l’incident.

• Revoir régulièrement la politique de gestion des incidents et les fiches réflexes. En particulier, revoir les rôles, responsabilités et procédures au moins une fois par an.
• Définir un plan de communication pour communiquer les incidents aux parties prenantes et au personnel concernés.

Aligner la politique avec les enjeux locaux

L’article 23 de la réglementation NIS 2 impose aux entités de signaler les incidents aux autorités compétentes. Cela illustre qu’il est indispensable de s’assurer que la politique de gestion des incidents est cohérente avec les lois, réglementations et normes, ainsi qu’avec les besoins métiers, et notamment de :

• Veiller à ce que la procédure respecte les lois, réglementations et normes industrielles applicables.
• Aligner la procédure de gestion des incidents avec les besoins métiers et le plan de continuité des activités et de reprise après sinistre.
• Définir un plan de communication conforme aux réglementations, incluant notamment :
  • Une procédure de notification du CSIRT et des autorités compétentes ;
  • Une procédure de communication aux clients et fournisseurs.

Anticiper la réponse aux principaux incidents

La politique de gestion des incidents doit être globale et permettre de traiter tous les types d’incidents. Elle peut être complétée avec des documents ciblant des incidents identifiés comme probables ou critiques :

• Mettre en place des fiches réflexes et procédures pour la réponse aux incidents couvrant le confinement, l’éradication et la restauration du service (retour à la normale) après l’incident.
• Définir les rôles et responsabilités pour les actions identifiées dans les fiches réflexes.

Conserver les relevés des incidents

Les objectifs fixés par l’ANSSI insistent sur la nécessité de conserver les relevés des incidents, à des fins de traçabilité interne, mais également en vue d’un potentiel usage juridique. En particulier il est recommandé de :

• Conserver les relevés techniques ayant permis la détection de l’incident.
• Conserver les relevés des actions menées pour la réponse à l’incident :
  • Heure de détection, et de clôture de l’incident
  • Indicateurs de compromission et description de l’incident
  • Actions prises pour l’investigation, la qualification, et la résolution de l’incident
  • Communications aux clients, fournisseurs et parties prenantes pendant et après la résolution de l’incident
  • Notifications au CSIRT et aux autorités
  • Compte rendu des analyses post-incident
• Conserver les relevés lors des tests des procédures de réponse à incident.
• Mettre en place une infrastructure de stockage des relevés techniques permettant leur conservation.
• Restreindre les accès aux relevés techniques, en particulier les accès en écriture, afin d’éviter tout accès ou modification non autorisés.

Il convient cependant de rappeler que le stockage de ces relevés doit être fait dans le respect des réglementations en vigueur, notamment en ce qui concerne la protection des données à caractère personnel.

Mener des analyses post-incident

Si la conservation des relevés des incidents peut servir à des fins légales, elle est également précieuse pour l’amélioration des processus de réponse à incident. Il faut donc :

• Conduire des analyses post-incident pour en déterminer les causes profondes et identifier les actions nécessaires pour éviter de nouvelles occurrences de l’incident.
• S’assurer que les rapports d’analyse post-incident sont pris en compte dans la définition des politiques de sécurité.
• Revoir régulièrement les incidents récents afin de s’assurer que des analyses post-incident ont été conduites lorsque c’est pertinent.

Politique de détection

Si les procédures de réponse à incident guident l’entité une fois l’incident détecté, il est également crucial de définir une politique de détection, qui vise à définir la stratégie de détection et le type d’événement à détecter.

Définir une stratégie de détection

La politique de détection doit tout d’abord définir la stratégie de détection, c’est-à-dire :

• Identifier les périmètres à superviser, des objectifs de détection, et les données, algorithmes et outils nécessaires à leur détection.
• S’appuyer sur les outils de détection pour automatiser la détection et minimiser les faux positifs et les faux négatifs.
• Garantir que le traitement des alertes se fasse conformément aux procédures documentées et dans des délais maîtrisés.
• Effectuer des exercices pour tester les procédures de réponse à incident (au moins une fois par an).
• Effectuer des analyses post-incident pour identifier les axes d’amélioration dans les processus, tracer les actions prises pour résoudre l’incident et identifier les actions nécessaires pour améliorer la réponse à ce type d’incidents.
• Revoir régulièrement les incidents récents afin de s’assurer que des analyses post-incident ont été conduites lorsque c’est pertinent.
• Mettre à jour la politique de détection régulièrement et après chaque incident majeur ou changement d’organisation ou dans la stratégie de sécurité, en prenant également en compte les rapports post-incident.

Collecter les journaux appropriés

Une fois la stratégie de détection définie, il convient de la mettre en place :

• S’assurer de la collecte des données de supervision sur les périmètres pertinents, par exemple : réseau, gestion des utilisateurs, accès aux systèmes, authentifications, événements de sécurité (alerte antivirus), accès physiques…
• Mettre en place l’analyse des journaux collectés (volume, typologie…) pour détecter toute tendance inhabituelle ou indésirable. Lorsque c’est pertinent, des alarmes peuvent être mises en place en cas d’anomalie (interruption de la collecte), accompagnées de réponses adaptées.
• Protéger les journaux et données de supervision contre les accès non-autorisés et les modifications.
• Conserver des sauvegardes des données de supervision et les protéger contre les accès non-autorisés et les modifications. Tester régulièrement la complétude et la fiabilité des sauvegardes, ainsi que les processus de récupération.

Conclusion

La conformité à la réglementation NIS 2 est un travail global, qui couvre tous les aspects de la cybersécurité. La sécurité opérationnelle et le rôle du SOC ne doivent pas être négligés, notamment pour répondre aux exigences en matière de réponse à incident.

Parce que le SOC mobilise de nombreuses équipes et, dans certains cas, des prestataires de services, sa stratégie peut s’avérer difficile à piloter. C’est pourquoi, nous avons ici détaillé les principaux points à considérer pour assurer la conformité du SOC à la réglementation NIS 2. Nous recommandons donc aux entités soumises à la réglementation d’anticiper sa mise en application en France et d’évaluer, dès maintenant, le niveau de conformité de leurs capacités de réponse à incident à la réglementation afin de définir un plan d’action de mise en conformité si nécessaire.

Cet article NIS 2 : quel impact sur le SOC ? est apparu en premier sur RiskInsight.

Ce chiffre révèle un changement profond : les sauvegardes, souvent considérées dernier recours, sont désormais des cibles à part entière. Face à une cyberattaque majeure, les plans de continuité traditionnels ne suffisent plus. En effet, ils ne fonctionnent pas en milieu industriel, notamment via la nature des enjeux : sécurité physique, impact environnemental, production continue, etc.

C’est pourquoi les organisations les plus avancées construisent aujourd’hui des programmes de cyber-résilience OT dédiés, conçus pour gérer la crise face à une perturbation ou un incident majeur, assurer la continuité des activités essentielles et restaurer les éléments altérés.

La Directive NIS2, notamment le référentiel RECYF de l’ANSSI, vient supporter cet effort en intégrant des obligations claires sur la cyber-résilience pour les entités essentielles et importantes.

Par où commencer, quels obstacles anticiper, et comment bâtir une résilience OT à la hauteur des exigences de NIS 2 ?

NIS 2 et la résilience industrielle : exigences et état des lieux

Ce que NIS 2 impose concrètement

L’intégration croissante de l’IT dans les processus industriels (MES, ERP connectés aux lignes, abandon progressif des processus papier) a profondément modifié la réalité opérationnelle des usines. Les dépendances sont nombreuses, souvent mal cartographiées, et une défaillance IT peut bloquer l’OT même lorsque les équipements physiques sont intacts. A ce titre, la capacité des milieux industriels à être plus résilient aux attaques cyber apparaît comme un chantier prioritaire.

La directive NIS 2, élargit significativement le périmètre des entités soumises par rapport à sa version antérieure, et vise à adresser parmi ses priorités, la cyber-résilience des entités. Deux objectifs sont particulièrement structurants en matière de résilience :

Etat des lieux sur la cyber-résilience en milieu industriel 

Si les organisations industrielles ont progressivement investi dans la sécurisation de leurs environnements OT, la maturité sur la continuité et la reprise reste insuffisante pour répondre aux exigences de NIS 2. Plusieurs lacunes sont systématiquement observées :

• Manque de connaissance formelle des assets et de leur criticité :
  • Cartographie des actifs souvent non formalisé ou incomplet
  • BIA absent ou partiellement réalisé
• Les PCA métiers existants sont conçus pour des scénarios physiques ou IT traditionnels mais pas pour des enjeux cyber OT
• Les capacités de continuité et de reprise ne sont pas testées : les organisations se limitent à des tests unitaires ou des restaurations de VM isolées, sans jamais couvrir une ligne de production complète ou un scénario bout en bout. Plusieurs facteurs expliquent cette situation :

Sans maturation sur ces sujets, un incident cyber peut se traduire par des semaines d’arrêt. 

Par où commencer pour bâtir une résilience OT à la hauteur de NIS 2 ?

Fondations et prérequis

Avant de construire un plan de reprise ou de tester quoi que ce soit, il faut établir les fondations : définir ce qu’on protège, définir comment l’activité se maintient en cas d’incident, et déterminer ce qui doit être sauvegardé. 

Quels acteurs intégrer au démarrage ? 

Un programme de cyber-résilience piloté uniquement par les équipes Cyber ou IT risque de ne pas refléter les réalités opérationnelles et de ne pas répondre aux véritables enjeux métiers : sans la participation et compréhension de l’enjeu par les opérateurs, le chantier aura du mal à avancer. Cela passe par une phase d’évangélisation : expliquer concrètement ce qu’un incident coûte à leur activité, et identifier dès le départ les bons interlocuteurs dans chaque direction.

Quels périmètres métiers prioriser ? 

L’objectif pour la cyber-résilience n’est pas de produire un inventaire exhaustif du parc industriel. Il s’agit d’identifier les actifs qui portent les processus critiques pour l’activité. Le point de départ est de créer un PCA à l’échelle de l’entreprise, puis un BIA à l’échelle des sites qui permettront de définir les DMIA et PRD par processus critique. 

La collecte s’appuie sur une approche hybride : 

• Entretiens opérationnels avec les équipes terrain 
• Exploitation des documents d’architecture et des configurations afin d’identifier les dépendances supplémentaires 

Les sondes peuvent apparaître comme un bon choix mais elles ne détectent que les assets qui émettent du trafic. Un équipement qui ne communique pas à un instant T disparaît de la cartographie. En OT, bon nombre d’équipements sont configurés une fois puis fonctionnent en autonomie, ce qui limite fortement leur visibilité réseau. De plus, certains systèmes sont totalement standalone et n’émettent aucun trafic, alors même qu’ils peuvent être critiques pour l’activité. Se reposer uniquement sur des sondes donne donc une vision partielle et parfois trompeuse de l’environnement, avec un risque réel de passer à côté d’équipements essentiels. 

Quelles données sauvegarder et comment ? 

La cartographie permet de recenser et prioriser les systèmes à protéger en fonction de leur criticité validée avec les équipes métiers. Ensuite, pour chaque asset, on définit le contenu minimum à sauvegarder et leur fréquence : 

Indépendamment de la fréquence planifiée, il est recommandé d’effectuer une sauvegarde après tout changement majeur afin de limiter la perte de configuration en cas d’incident. 

Plusieurs principes structurent ensuite la stratégie de sécurisation des sauvegardes : 

• Redondance, chiffrement, et immuabilité des sauvegardes 
• Air-gapping pour les environnements les plus sensibles 
• Politique de rétention différenciée par type d’actif
• Clauses contractuelles encadrant les obligations de sauvegarde des tiers 

Les infrastructures de sauvegarde ne sont pas de simples supports techniques : elles constituent elles-mêmes des cibles sensibles et doivent être traitées comme des systèmes critiques, avec le niveau de protection approprié. 

Comment assurer la continuité en cas d’incident ? 

La première étape du PCA consiste à identifier les scénarios de crise à adresser, car ceux-ci déterminent les interlocuteurs à impliquer, les procédures à définir et les modes de fonctionnement à adopter. Ce travail est mené conjointement avec les équipes HSE, métiers, cybersécurité, risk management. 

Pour chaque processus critique identifié, il convient ensuite de définir, avec les équipes production, maintenance, et qualité : 

Validation et reprise 

Comment valider le fonctionnement de la reprise ? 

Un PRA non testé est un PRA théorique.

Les tests peuvent être effectués, pour limiter l’impact sur la production : 

• Sur une infrastructure globale de test, mutualisée entre les différents sites, 
• Sur une ligne de test, 
• Pendant les fenêtres de maintenance, 
• En utilisant des jumeaux numériques. 

Ces tests doivent être validé au minimum une fois par an. 

La progression est graduelle :

Chaque test est documenté : DMIA et PRD réels mesurés, comparaison avec les cibles théoriques, écarts identifiés, actions correctives planifiées. 

Les objectifs de DMIA/PRD peuvent ne pas être réalistes dans le contexte d’une crise cyber majeure. Ils ne doivent donc pas constituer un facteur bloquant pour la réalisation des tests ni pour la validation des principes de cyber‑résilience au sens de NIS2. 

Comment reconstruire après un incident ? 

Le PRA définit comment redémarrer les systèmes critiques après un sinistre. Il couvre plusieurs scénarios : panne matérielle, ransomware, perte du réseau OT. 

Pour chaque scénario, il est nécessaire de : 

• Définir le séquençage de redémarrage selon les dépendances entre systèmes 
• Documenter la chaîne d’escalade et de décision 
• Définir clairement l’implication des tiers : conditions d’intervention, modalités de coordination, et exigences préalables de sécurisation (éradication du ransomware, environnement contrôlé type « salle blanche », reprise progressive avec cloisonnement) 

Deux logiques de reprise doivent être distinguées : la perte de disponibilité (bascule vers des ressources de secours) et la perte d’intégrité (reconstruction complète depuis les sauvegardes). Les procédures ne sont pas les mêmes et doivent être traitées séparément. 

De la résilience des assets à la gestion de crise 

Ce que nous avons décrit ici constitue le socle minimum pour enclencher une démarche de reprise en environnement OT. Mais NIS 2 exige d’aller plus loin : c’est l’ensemble du SI qui est concerné, et la question n’est plus seulement technique, c’est celle d’un programme structuré, piloté dans la durée, capable de prouver la conformité et la résilience des assets. 

Cela implique de déployer cette démarche de façon pragmatique, en tenant compte des risques cyber, des contraintes réglementaires et des moyens disponibles. Cela implique aussi de ne pas en faire un projet ponctuel : la cyber-résilience doit être intégrée par design, avec des chantiers suivis, des preuves documentées, et des équipes métier embarquées sur le long terme. 

Enfin, le marché propose aujourd’hui des solutions dédiées à la résilience OT. Une veille active sur ce sujet peut s’avérer précieuse pour identifier les outils adaptés. 

Par ailleurs, la résilience ne s’arrête pas à la reprise technique, elle intègre aussi la gestion de crise : Repenser sa stratégie de préparation à la gestion de crise d’origine cyber – RiskInsight

Glossaire 

Cet article Cyber-résilience industrielle : par où commencer face à NIS 2 ? est apparu en premier sur RiskInsight.