Gestion des incidents NIS 2 au titre de l'article 21(2)(b)
L'article 21(2)(b) est l'obligation interne : détecter, contenir, rétablir, documenter, apprendre. L'article 23 est l'obligation externe : informer le BSI ou votre CSIRT national. Deux obligations distinctes, souvent confondues. Le §3 du CIR (UE) 2024/2690 détaille l'obligation interne.
En bref
La gestion des incidents est le point (b) de la liste des dix obligations de cybersécurité de l'article 21(2). Elle porte sur ce que vous faites au sein de l'entreprise lorsque quelque chose tourne mal : le repérer, le contenir, rétablir, consigner ce qui s'est passé, en tirer des enseignements.
Le §3 du CIR (UE) 2024/2690 en précise le détail en six sous-sections : §3.1 un concept écrit de gestion des incidents, §3.2 la surveillance et la journalisation, §3.3 l'escalade interne des événements, §3.4 la classification, §3.5 la réponse elle-même (confinement, éradication, rétablissement), §3.6 la revue post-incident. Si vous exploitez un DNS, du cloud, un centre de données, un MSP ou tout autre secteur de l'annexe du CIR, cela vous lie directement.
L'Allemagne inscrit la même obligation en droit national via le §30(2)(2) BSIG. L'expression est « Bewältigung von Sicherheitsvorfällen », les mêmes termes que la directive. Cette page parcourt la directive, le règlement d'exécution de l'UE et la transposition allemande dans cet ordre.
Article 21(2)(b) de la directive NIS 2 (2022/2555)
Incident handling.
Le point (b) de la liste des dix mesures de cybersécurité. Deux mots dans le texte de la directive. Le §3 du CIR transforme ces deux mots en détail opérationnel. Important : c'est l'obligation de gestion interne. L'obligation externe de notifier le CSIRT figure à l'article 23 et fait l'objet d'une page distincte.
CIR (UE) 2024/2690, annexe §3
For the purposes of Article 21(2)(b) of Directive (EU) 2022/2555, the relevant entities shall establish and implement a policy on incident handling, defining roles, responsibilities and procedures for the timely detection, analysis, containment or response, recovery as well as documentation and reporting of incidents.
Parce qu'il s'agit d'un règlement, c'est du droit de l'UE directement contraignant. Aucune transposition nationale n'est nécessaire. L'annexe §3 décompose l'obligation en six sous-sections : concept (§3.1), journalisation (§3.2), escalade interne (§3.3), classification (§3.4), réponse (§3.5), revue post-incident (§3.6).
§30(2)(2) BSIG (Allemagne)
Bewältigung von Sicherheitsvorfällen.
L'Allemagne reprend la formulation de la directive mot pour mot. La substance est identique à l'article 21(2)(b). Le BSI utilise ensuite les blocs de construction IT-Grundschutz (en particulier DER.2 « Vorfall-Bewältigung ») pour montrer à quoi ressemble un concept écrit de gestion des incidents en pratique.
Un concept écrit de gestion des incidents
Consignez qui fait quoi lorsque quelque chose tourne mal. Rôles, responsabilités, étapes de détection, d'analyse, de confinement, de rétablissement, de documentation et de notification interne. Le §3.1.1 du CIR exige que le concept existe avant l'incident, pas après. L'organe de direction doit le valider.
Surveillance et journalisation
Vous ne pouvez pas gérer ce que vous ne pouvez pas voir. Le §3.2 du CIR énumère douze types d'événements que vous devez journaliser (tentatives de connexion, modifications de privilèges, détections de logiciels malveillants, anomalies réseau et autres). Les journaux doivent être inaltérables et conservés suffisamment longtemps pour permettre l'analyse. C'est la couche de détection.
Phases de réponse : confinement, éradication, rétablissement
Le §3.5 du CIR divise la réponse en trois phases. Le confinement empêche l'incident de se propager. L'éradication supprime la cause racine. Le rétablissement ramène les systèmes à un état sain connu. Chaque phase doit être documentée au fur et à mesure, afin que le §3.6 (revue post-incident) ait matière à travailler.
La gestion interne n'est pas la notification externe
L'article 21(2)(b) est ce que vous faites au sein de l'entreprise. L'article 23 est ce que vous communiquez au régulateur (alerte précoce à 24 heures, notification d'incident à 72 heures, rapport final à un mois au BSI ou à votre CSIRT national). Deux obligations distinctes. Effectuer la notification ne libère pas de la gestion, et effectuer la gestion ne libère pas de la notification.
La revue post-incident réalimente la gestion des risques
Le §3.6 du CIR boucle la boucle. Les enseignements de chaque incident réalimentent le cadre de gestion des risques du §2 du CIR. De nouveaux risques sont ajoutés, les plans de traitement sont mis à jour, les contrôles sont ajustés. C'est le cycle PDCA. Un incident que vous gérez mais dont vous ne tirez pas d'enseignements n'est qu'un travail à moitié fait.
BSI / §30(2)(2) BSIG
Le BSI classe la gestion des incidents dans les Infopakete comme la deuxième des dix mesures de l'article 21(2). La transposition allemande utilise la même expression que la directive. Le BSI désigne le bloc de construction IT-Grundschutz DER.2 (« Vorfall-Bewältigung ») comme la voie pratique. DER.2 vous guide à travers le concept, le manuel d'intervention, les rôles et la revue post-incident.
Orientations techniques de mise en oeuvre d'ENISA
Le TIG d'ENISA reprend le §3 du CIR et vous montre à quoi ressemblent les preuves en pratique : le concept écrit, le manuel d'intervention, les enregistrements de simulation, les notes de revue post-incident. Il met également en correspondance le §3 avec les contrôles établis dans l'ISO/IEC 27001:2022 (clauses A.5.24 à A.5.28) et le NIST CSF 2.0 (les fonctions Respond et Recover), de sorte qu'une certification existante vous donne une longueur d'avance.
Lois de transposition nationales
Chaque État membre a sa propre loi de transposition (Pays-Bas : Cyberbeveiligingswet, Autriche : NISG, Belgique : NIS2-Wet). L'obligation est la même car la directive fixe une norme unique à l'échelle de l'UE. Ce qui diffère : à quel CSIRT vous vous adressez pour la notification de l'article 23, et comment chaque autorité nationale formule les orientations pratiques.
Nous notifions le BSI quand quelque chose se produit, donc nous sommes couverts.
Cela couvre l'article 23, pas l'article 21(2)(b). La notification au CSIRT est l'obligation externe. L'article 21(2)(b) est l'obligation interne : détecter, contenir, rétablir, documenter, examiner. Les deux doivent exister. Un auditeur demandera à voir le concept de gestion des incidents (§3.1 du CIR) en plus du journal de notification de l'article 23.
Nous rédigerons le manuel d'intervention quand quelque chose se produira.
Le §3.1.1 du CIR est explicite : le concept doit être « établi et mis en oeuvre » avant l'incident. Rôles, responsabilités, procédures, tout sur le papier, validés par la direction. Le rédiger pendant l'incident n'est pas de la gestion, c'est de l'improvisation. Les auditeurs vérifient d'abord l'existence du concept daté et signé.
L'équipe informatique s'en charge, cela suffit.
Le §3.1.1 du CIR exige des rôles et des responsabilités documentés. Qui déclare un incident. Qui décide du confinement. Qui parle au service juridique. Qui valide le rétablissement. L'organe de direction doit approuver le concept. « L'équipe informatique s'en charge » n'est pas une structure, c'est une hypothèse.
La lacune type du Mittelstand est documentaire, pas capacitaire. La détection a lieu (quelqu'un remarque, l'informatique enquête, le problème est résolu). La documentation, non. Sans l'enregistrement daté de qui a fait quoi, l'auditeur n'a aucun moyen de vérifier que le §3 a été suivi. La solution consiste à construire d'abord le manuel d'intervention, puis à simuler deux fois par an, puis à consigner les enseignements dans le modèle de revue post-incident.
Deux simulations par an, c'est ce sur quoi la plupart des praticiens auxquels nous parlons s'accordent. Une sur table (des personnes autour d'une table parcourant le manuel à travers un scénario), une technique (une restauration contrôlée à partir d'une sauvegarde, un exercice de réponse à l'hameçonnage, quelque chose qui éprouve les outils). L'objectif est de trouver les lacunes avant qu'un auditeur ne le fasse, ou avant qu'un incident réel ne le fasse. La proportionnalité de l'article 21(1) vous permet d'adapter la simulation à votre taille et à votre profil de risque ; elle ne vous permet pas de les sauter.
Nous avons intégré le §3 du CIR à la plateforme sous la forme du module INC. Vous enregistrez un incident, saisissez la classification au titre du §3.4, parcourez les phases de réponse (confinement, éradication, rétablissement) avec horodatages, et exécutez la revue post-incident à la fin. La piste d'audit enregistre chaque étape. Pas de pile de tableurs.
La revue post-incident du §3.6 est la partie que la plupart des équipes négligent. Nous en avons fait un champ obligatoire avant qu'un incident puisse être clôturé : ce qui a mal tourné, ce qui a fonctionné, quels changements sont réinjectés dans le cadre de gestion des risques du §2 du CIR. La notification de l'article 23 (24h / 72h / un mois) est un module distinct qui utilise le même enregistrement d'incident, de sorte que vous ne saisissez pas les faits deux fois.
- Directive (UE) 2022/2555 (NIS 2), article 21(2)(b) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Règlement d'exécution (UE) 2024/2690 de la Commission (CIR), annexe §3 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Loi sur le BSI (BSIG), §30(2)(2) tel que modifié par la loi de mise en oeuvre de NIS2 et de renforcement de la cybersécurité
- Bloc de construction IT-Grundschutz DER.2 « Vorfall-Bewältigung » du BSI — bsi.bund.de/grundschutz
- Orientations techniques de mise en oeuvre d'ENISA pour le CIR (UE) 2024/2690, correspondance du §3 avec l'ISO/IEC 27001:2022 et le NIST CSF 2.0