La transposition de NIS 2 en France approche, et avec elle un renforcement concret des exigences en matière de cybersécurité. Pour les entités concernées, la question n’est plus de savoir si la sécurité opérationnelle sera impactée, mais comment. Cet article décrypte les principaux impacts de NIS 2 sur les SOC, dont les missions, les processus et le niveau d’exigence sont appelés à évoluer.

 

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.