Notification d’incident NIS2 : le guide pratique des 72 heures

Un incident cyber frappe un mardi matin. Le mardi midi, la question sur la table du comex n'est plus que se passe-t-il — c'est que doit-on remonter au régulateur, et quand. L'article 23 de la directive (UE) 2022/2555 est la partie de NIS2 qui fait tourner le compteur. C'est aussi celle que les conseils d'administration lisent le plus mal.

Voici le guide pratique des 72 heures, heure par heure, avec le texte juridique lu au plus près et la traduction opérationnelle qui va avec.

Quand le compteur démarre : « connaissance », pas « détection »

L'article 23, paragraphe 1, impose aux entités de notifier les incidents importants au CSIRT ou à l'autorité compétente sans retard injustifié. Le compteur référencé tout au long de l'article court à partir du moment où l'entité a connaissance de l'incident.

La distinction compte. La « connaissance » n'est pas l'instant où une alerte SIEM s'allume. C'est l'instant où une personne dans l'entité, avec l'autorité et l'information pour trancher, a des motifs raisonnables de croire qu'un incident s'est produit et qu'il franchit le seuil d'importance. Le considérant 101 de la directive cadre cela comme un jugement, pas un déclenchement automatique.

En pratique, la « connaissance » est l'instant où votre RSSI de garde, ou le responsable des opérations de sécurité, ou le permanencier en astreinte, décide que l'alerte sous ses yeux ressemble à un incident important. Cette décision doit être horodatée. Les CSIRT nationaux — l'ANSSI/CERT-FR en France, le BSI/CERT-Bund en Allemagne, l'INCIBE-CERT en Espagne, l'ACN/CSIRT Italia, le NCSC-IE en Irlande — attendent tous cet horodatage dans la notification.

Heure 24 : l'alerte précoce

L'article 23, paragraphe 4, point a) impose une alerte précoce dans les 24 heures suivant la connaissance. L'alerte précoce est courte. Elle doit indiquer :

• si l'entité soupçonne que l'incident est dû à des actes illicites ou malveillants,
• s'il pourrait avoir un impact transfrontalier, et
• (en pratique, même si ce n'est pas strictement listé) les informations d'identification minimales pour que le CSIRT puisse acheminer le dossier.

C'est tout le contenu. Pas de forensique détaillé, pas d'évaluation d'impact complète, pas de patient zéro. L'alerte précoce est un signal de routage, pas un rapport.

L'erreur fréquente consiste à traiter l'alerte précoce comme la notification complète et à manquer la fenêtre parce que l'entité était encore en investigation. La directive est explicite : l'alerte précoce est un drapeau, pas une conclusion. Envoyez-la sur des informations partielles ; corrigez ou complétez à la notification de 72 heures si nécessaire.

Heure 72 : la notification d'incident

L'article 23, paragraphe 4, point b) impose une notification d'incident dans les 72 heures suivant la connaissance, mettant à jour l'alerte précoce avec des informations substantielles. Elle doit contenir :

• une évaluation initiale de l'importance de l'incident (gravité, impact, périmètre),
• lorsque disponibles, des indicateurs de compromission (IoC).

C'est ici que les régulateurs cherchent la preuve que l'entité a un processus de réponse aux incidents qui fonctionne. Les attentes publiées par les CSIRT nationaux européens, avec renvoi aux lignes directrices de l'ENISA sur la déclaration d'incidents, sont cohérentes sur ce que veut dire « substantielles » :

• une description des services touchés et de l'impact opérationnel (en langage clair et quantifié si possible — nombre d'utilisateurs concernés, durée de l'interruption),
• le type de menace (rançongiciel, accès non autorisé, exfiltration de données, déni de service, compromission de la chaîne d'approvisionnement),
• les IoC disponibles au moment de la notification (empreintes de fichiers, domaines malveillants, IP attaquantes),
• les actions de remédiation déjà prises ou en cours.

La notification est soumise via le canal national de déclaration — pour la plupart des États membres, un portail authentifié opéré par le CSIRT ou l'autorité compétente. Le format varie ; le fond, non.

Un mois : le rapport final

L'article 23, paragraphe 4, point d) impose un rapport final au plus tard un mois après la notification d'incident. Il doit contenir :

• une description détaillée de l'incident, y compris sa gravité et son impact,
• le type de menace ou la cause probable qui a déclenché l'incident,
• les mesures de remédiation appliquées et en cours,
• le cas échéant, l'impact transfrontalier de l'incident.

Si l'incident est toujours en cours au moment du rapport à un mois, l'article 23, paragraphe 4, point c) prévoit un rapport intermédiaire à la place, avec un rapport final remis dans le mois suivant la résolution de l'incident.

Le rapport final est le document qui clôt la boucle réglementaire. C'est aussi le document qui, dans les juridictions où la responsabilité des dirigeants est engagée, devient la pièce maîtresse de toute revue d'application ultérieure. Les conseils doivent le traiter en conséquence : lire, challenger, valider, en minuter la discussion.

Qu'est-ce qu'un « incident important » ?

L'article 23, paragraphe 3, définit l'incident important comme celui qui :

• a causé ou est susceptible de causer une perturbation opérationnelle grave des services ou des pertes financières pour l'entité, ou
• a touché ou est susceptible de toucher d'autres personnes physiques ou morales en causant un préjudice matériel ou non matériel considérable.

La Commission a publié des seuils pour les fournisseurs de services numériques et certaines autres catégories (règlement d'exécution (UE) 2024/2690). Pour les autres secteurs concernés, l'évaluation est qualitative et incombe à l'entité en première instance, sous réserve de contestation par l'autorité nationale compétente.

Le piège, en pratique, n'est pas la sous-déclaration — c'est la sur-déclaration de cas limites par excès de prudence, qui noie le CSIRT sous le bruit. La doctrine ENISA est claire : c'est l'importance qui est le test, pas la gravité absolue. Une interruption de 30 minutes sur un parcours de paiement peut être importante pour un acquéreur à grande échelle ; la même interruption sur un outil de back-office peut ne pas l'être.

Le compteur de 72 heures n'est pas une deadline d'exhaustivité. C'est une deadline de divulgation honnête et structurée de ce qui est connu à ce stade.

Ce à quoi ça ressemble quand c'est bien fait

Trois signaux reviennent systématiquement dans les revues post-incident des régulateurs :

1. Une chronologie d'incident datée qui marque l'instant de la connaissance et montre l'heure de l'alerte précoce, de la notification à 72 heures, et du rapport final. Les écarts entre ces jalons sont tolérés ; les horodatages manquants ne le sont pas.
2. Une autorité signataire unique pour la chaîne de notification — typiquement le RSSI de garde avec un chemin d'escalade documenté vers le PDG ou le représentant légal. Plusieurs notifications non coordonnées émanant de différentes parties de l'entité sont un drapeau rouge.
3. La preuve que le conseil a été informé à chaque jalon. Un procès-verbal de conseil mentionnant l'alerte précoce suffit. Le silence sur la chronologie laisse la place au régulateur pour demander pourquoi.

Aucun de ces documents n'est à inventer dans l'instant de la crise. Ce sont des documents qui doivent avoir été répétés à l'avance. Le compteur de 72 heures est court ; le délai de préparation, lui, ne l'est pas.

Sources

1. Directive (UE) 2022/2555, article 23 (« Obligations de déclaration »).
2. Directive (UE) 2022/2555, article 23, paragraphe 3 (définition de l'« incident important »).
3. Directive (UE) 2022/2555, considérants 100 à 102 (processus de déclaration des incidents et critères d'importance).
4. Règlement d'exécution (UE) 2024/2690 (seuils d'importance des incidents pour les fournisseurs de services numériques et catégories assimilées).
5. Lignes directrices publiées par les autorités nationales compétentes et les CSIRT : ANSSI / CERT-FR (FR), BSI / CERT-Bund (DE), INCIBE-CERT (ES), ACN / CSIRT Italia (IT), NCSC-IE (IE), ainsi que par l'ENISA.