Journalisation et surveillance NIS 2 au titre de l'article 21(2)(b)
La journalisation est la couche de visibilité du traitement des incidents. L'article 21(2)(b) est l'endroit où réside l'obligation, le §3.2 du CIR nomme les douze types d'événements et les règles opérationnelles, et l'Allemagne inscrit la même règle au §30(2)(2) BSIG.
La version courte
La journalisation et la surveillance ne constituent pas une obligation distincte au titre de NIS 2. Elles s'inscrivent dans la mesure de traitement des incidents de l'article 21(2)(b). La logique est simple : si vous ne pouvez pas voir ce qui se passe sur votre réseau, vous ne pouvez pas détecter un incident de sécurité, et vous ne pouvez pas le confiner.
Le §3.2 du CIR (UE) 2024/2690 fournit le détail. Il nomme douze types d'événements que vous devez journaliser, fixe les règles relatives aux alertes et à la réponse qualifiée, fixe une durée de conservation définie, et exige des systèmes synchronisés dans le temps ainsi qu'une surveillance redondante. C'est le plancher pour les secteurs nommés dans l'Annexe du CIR.
L'Allemagne inscrit la même règle au §30(2)(2) BSIG. Le socle pratique est l'IT-Grundschutz OPS.1.1.5 « Protokollierung » et DER.1 « Detektion ». Cette page parcourt la directive, le règlement d'exécution de l'UE qui en découle, et la transposition allemande, dans cet ordre.
Article 21(2)(b) de la directive NIS 2 (2022/2555)
Traitement des incidents.
Il s'agit du point (b) de la liste des dix mesures de cybersécurité que chaque entité essentielle et importante doit mettre en place. Le §3 du CIR le rend ensuite opérationnel. La journalisation et la surveillance s'inscrivent dans le §3.2.
CIR (UE) 2024/2690, Annexe §3.2.1
Les entités concernées établissent des procédures et utilisent des outils pour surveiller et journaliser les activités sur leurs réseaux et systèmes d'information afin que les événements pouvant être considérés comme des incidents de sécurité puissent être détectés et traités pour en confiner l'impact.
Parce qu'il s'agit d'un règlement (et non d'une directive), c'est du droit de l'UE directement contraignant. Le §3.2 se décompose ensuite en sept sous-points couvrant les types d'événements à journaliser, l'alerte, la conservation, la synchronisation du temps et la redondance. Aucune transposition nationale n'est nécessaire.
§30(2)(2) BSIG (Allemagne)
Traitement des incidents.
L'Allemagne recopie le texte de l'UE mot pour mot. Le « comment » pratique passe par l'IT-Grundschutz : OPS.1.1.5 « Protokollierung » pour la conception de la journalisation, et DER.1 « Detektion » pour le volet alerte et réponse.
Journaliser les douze types d'événements
Construisez la liste à partir de votre inventaire des actifs. Lorsque cela est approprié, capturez : le trafic réseau entrant et sortant, les modifications d'utilisateurs et de privilèges, les accès aux systèmes et aux applications, les événements d'authentification, toute activité à privilèges et d'administration, l'accès aux fichiers critiques de configuration ou de sauvegarde, les journaux des outils de sécurité (antivirus, IDS, pare-feu), l'utilisation des ressources système, l'accès physique, l'utilisation des équipements réseau, l'activation ou la suspension des journaux eux-mêmes, et les événements ambiants.
Revue, alarme, réponse qualifiée
Collecter des journaux ne suffit pas. Examinez-les à une cadence régulière pour repérer les tendances inhabituelles ou indésirables. Lorsque cela est approprié, fixez des seuils. Lorsqu'un seuil est dépassé, déclenchez une alarme automatisée. Et assurez-vous qu'une personne qualifiée réponde effectivement à temps. Le stockage sans revue n'est pas une journalisation au sens du §3.2.
Protéger, conserver, synchroniser le temps, rendre redondant
Les journaux eux-mêmes constituent des preuves. Conservez-les pendant une durée de conservation définie, protégez-les contre tout accès et toute modification non autorisés, synchronisez tous les systèmes dans le temps afin que les événements puissent être corrélés, et exploitez le système de surveillance de manière redondante. La surveillance du système de surveillance est elle-même indépendante des systèmes qu'elle surveille.
Les journaux sont un actif, pas un sous-produit
Le §3.2.5 traite les journaux comme des données critiques. Durée de conservation définie, protection contre l'altération, protection contre tout accès non autorisé. Si un attaquant peut supprimer les journaux qui montrent ce qu'il a fait, l'obligation de journalisation n'est pas satisfaite. C'est aussi pourquoi le §3.2.3(k) énumère explicitement « l'activation, la désactivation ou la suspension » des journaux comme un événement que vous devez journaliser.
Examiner les journaux est une obligation, pas un agrément optionnel
Le §3.2.4 exige des contrôles réguliers des tendances inhabituelles, des seuils lorsque cela est approprié, des alarmes automatisées en cas de dépassement de seuil, et une réponse qualifiée en temps utile. Un SIEM que personne ne regarde ne satisfait pas à cette exigence. Un auditeur demandera qui a examiné quelles alertes, quand, et ce qu'il en a fait.
BSI / IT-Grundschutz OPS.1.1.5 + DER.1
Le BSI renvoie à l'IT-Grundschutz comme voie pratique. OPS.1.1.5 « Protokollierung » est l'endroit où réside la conception de la journalisation (quoi journaliser, conservation, protection). DER.1 « Detektion » couvre le volet alerte et réponse (cadence de revue, règles SIEM, traitement qualifié). Les deux ensemble correspondent au §3.2 du CIR.
Orientations techniques de mise en œuvre de l'ENISA
Le TIG de l'ENISA fournit des exemples concrets de preuves pour le §3.2 : modèles de politique de journalisation, exemples de seuils d'alerte, valeurs par défaut de conservation, et une correspondance avec l'Annexe A d'ISO/IEC 27001:2022 (A.8.15 Journalisation, A.8.16 Activités de surveillance). Si vous appliquez déjà ISO 27001, vous réutilisez la plupart des mesures.
Lois nationales de transposition
Chaque État membre a sa propre transposition (Pays-Bas : Cyberbeveiligingswet, Autriche : NISG, Belgique : NIS2-Wet). L'obligation du §3.2 est la même parce que le CIR est directement applicable. Ce qui diffère : à quelle autorité nationale vous vous adressez, et comment les canaux de notification et les cadences d'audit sont gérés localement.
Nous conservons tous les journaux pour toujours, donc nous sommes couverts.
Le §3.2.5 exige une durée de conservation définie, et non une durée infinie. Tout conserver pour toujours pose un problème de protection des données (limitation de la conservation, art. 5(1)(e) du GDPR) et un problème de coût. Décidez d'une fenêtre de conservation par type de journal, consignez-la, justifiez-la au regard de votre profil de risque, et tenez-vous-y.
Le SIEM s'en charge, donc tout va bien.
Presque, mais pas tout à fait. Le §3.2.4 n'exige pas seulement le stockage. Il exige une revue régulière, des seuils lorsque cela est approprié, des alarmes automatisées en cas de dépassement, et une personne qualifiée qui répond effectivement. Un SIEM qui fonctionne sans règles, ou avec des règles que personne n'ajuste, échoue au regard du §3.2.4.
Nous journalisons l'activité des utilisateurs mais pas celle des administrateurs.
Le §3.2.3(e) est explicite : tout accès à privilèges aux systèmes et aux applications ainsi que les activités des comptes d'administration. Les administrateurs sont les utilisateurs à plus fort impact sur votre réseau. Ne pas les journaliser est le premier écart qu'un auditeur trouve.
Ce que nous voyons en pratique : la plupart des entreprises du Mittelstand disposent de journaux de pare-feu et de journaux Active Directory. Elles couvrent rarement de manière systématique les douze types d'événements du §3.2.3. L'accès à privilèges, les modifications de fichiers de configuration et l'accès physique sont les trois écarts habituels.
La solution la moins coûteuse : construire la liste du §3.2.3 à partir de votre inventaire des actifs (RSK 2.2), tout diriger vers un seul endroit (un magasin central de journaux ou un petit SIEM), fixer des seuils sur les événements à forte valeur, et examiner chaque semaine. Vous n'avez pas besoin d'un SOC managé dès le premier jour. Vous avez besoin de quelqu'un qui regarde les alertes et sait quoi faire.
Le module INC couvre la stratégie de journalisation du §3.2 : quels types d'événements vous journalisez, en regard de quels actifs, avec quelle fenêtre de conservation. Vous la rédigez une fois, vous la validez, et elle devient votre politique de journalisation prête pour l'audit.
Le module EFF couvre le volet revue du §3.2.4 : seuils d'alarme, cadence de revue, preuves de réponse qualifiée. Les validations et la piste d'audit montrent à un auditeur que quelqu'un a regardé les alertes et a agi en conséquence. Pas de pile de tableurs. Pas de second outil.
- 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.2 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Loi sur le BSI (BSIG), §30(2)(2) telle que modifiée par la loi de mise en œuvre de NIS2 et de renforcement de la cybersécurité
- IT-Grundschutz Kompendium, OPS.1.1.5 « Protokollierung » et DER.1 « Detektion » — bsi.bund.de/grundschutz
- Orientations techniques de mise en œuvre de l'ENISA pour le CIR (UE) 2024/2690 (état de mai 2026)