L'obligation de notification des incidents est l'une des exigences les plus opérationnelles de la Directive NIS2 (2022/2555). Elle impose des délais stricts, une procédure en trois étapes et des contenus précis pour chaque communication. Une mauvaise gestion de cette obligation est l'une des causes les plus fréquentes de sanction — non pas parce que l'incident a eu lieu, mais parce que la notification a été tardive ou incomplète.
L'Obligation Légale : Article 23 de la Directive 2022/2555
L'article 23 de NIS2 établit les obligations de notification des incidents "significatifs". Il s'applique aux entités essentielles et importantes sans distinction.
Un incident est qualifié de significatif selon la directive lorsqu'il :
- A causé ou est susceptible de causer une perturbation opérationnelle grave des services
- A causé ou est susceptible de causer des pertes financières importantes
- A affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant des dommages considérables
En pratique, cela couvre : les attaques ransomware ayant chiffré vos systèmes, les intrusions ayant conduit à une exfiltration de données, les indisponibilités prolongées de services critiques, les sabotages logiciels d'infrastructures.
La notification s'effectue auprès de l'autorité nationale compétente — en France, le CERT-FR (qui relève de l'ANSSI) et, selon le secteur, l'autorité sectorielle concernée.
La Timeline NIS2 : Trois Étapes Obligatoires
C'est la grande nouveauté de NIS2 par rapport à NIS1 : la notification n'est plus un acte unique mais un processus en trois phases.
Étape 1 : Alerte Initiale — 24 Heures Maximum
Dans les 24 heures suivant la prise de conscience d'un incident significatif, l'entité doit transmettre une alerte initiale.
Cette alerte précoce doit indiquer :
- La nature de l'incident (type d'attaque présumé, systèmes affectés)
- Si l'incident est soupçonné d'être malveillant
- Si l'incident est susceptible d'avoir un impact transfrontière
L'objectif est de permettre à l'autorité compétente d'être informée rapidement et de mobiliser une assistance si nécessaire. Cette alerte ne doit pas être parfaite — elle doit être rapide. L'exactitude et l'exhaustivité viennent aux étapes suivantes.
Le point de départ du délai est la "prise de conscience" de l'incident, pas le début de l'incident lui-même. Si votre équipe IT détecte l'incident à 14h un mardi, l'alerte doit être transmise avant 14h le mercredi.
Étape 2 : Notification Complète — 72 Heures Maximum
Dans les 72 heures suivant la prise de conscience, la notification complète doit être soumise. Elle comprend :
- Évaluation initiale de l'incident : gravité, impact, indicateurs de compromission
- Description de l'incident : cause probable, mesures d'atténuation prises ou en cours
- Classification du type de menace ou de la cause
- Éventuelles mesures transfrontalières si d'autres États membres sont affectés
À ce stade, une analyse approfondie n'est pas encore requise, mais les éléments factuels connus doivent être documentés. Si des investigations sont encore en cours, le mentionner explicitement avec un calendrier prévisionnel de rapport final.
Étape 3 : Rapport Final — 1 Mois Maximum
Dans le mois suivant la notification complète, un rapport final détaillé doit être soumis. Ce rapport comprend :
- Description détaillée de l'incident : chronologie complète, systèmes affectés, étendue de la compromission
- Type de menace ou de cause profonde (root cause analysis)
- Mesures d'atténuation appliquées et leur efficacité
- Impact transfrontière le cas échéant
- Mesures préventives adoptées pour éviter la récurrence
Ce rapport final constitue la pièce maîtresse de votre dossier de conformité post-incident. Il est conservé par l'autorité compétente et peut être réexaminé lors d'un contrôle ultérieur.
Cas Particulier : Incident en Cours
Si l'incident est toujours en cours au moment du délai de 1 mois, un rapport d'avancement doit être soumis dans ce délai, suivi du rapport final dans le mois suivant la clôture de l'incident.
Ce Que Vous Devez Signaler : Critères de Qualification
La question la plus difficile en pratique est "cet incident doit-il être notifié ?". Voici une grille de qualification.
Incidents Clairement Notifiables
- Ransomware ayant chiffré des systèmes de production
- Exfiltration de données prouvée ou fortement suspectée
- Indisponibilité de service supérieure à 4 heures affectant des clients
- Compromission d'un compte à privilèges (administrateur, directeur)
- Sabotage de systèmes industriels ou OT
- Attaque DDoS ayant rendu le service inaccessible pendant une durée significative
Incidents à Analyser au Cas par Cas
- Tentatives d'intrusion détectées et bloquées (généralement non notifiables, sauf si un doute persiste sur l'efficacité du blocage)
- Phishing ayant abouti à une compromission de compte non-privilégié (notifiable si accès à des données sensibles)
- Vulnérabilité critique découverte avant exploitation (non notifiable en tant qu'incident, mais peut déclencher une obligation de signalement de vulnérabilité dans certains États membres)
Incidents Non Notifiables à NIS2
Les incidents ne rentrant pas dans la définition de "significatif" (impact limité, service non perturbé, aucun accès à des données confirmé) n'ont pas à être notifiés. Ils doivent néanmoins être documentés en interne.
À Qui Notifier ?
En France : Le CERT-FR
La notification NIS2 en France s'effectue via le portail du CERT-FR (cert-fr.eu ou le portail dédié ANSSI). Le CERT-FR peut vous orienter vers l'autorité sectorielle compétente si votre secteur a une autorité spécifique (Banque de France pour le secteur financier, DGACI pour les opérateurs d'importance vitale, etc.).
En Cas d'Impact Transfrontière
Si l'incident affecte des services dans d'autres États membres, vous devez en informer l'autorité nationale compétente, qui se chargera de la coordination avec ses homologues européens via les mécanismes du Réseau CyCLONe et de l'ENISA.
Template de Rapport d'Incident NIS2
Voici une structure de base pour vos notifications :
ALERTE INITIALE (24h)
- Date/heure de détection :
- Nature de l'incident (type présumé) :
- Systèmes/services affectés :
- Cause malveillante suspectée : Oui / Non / Inconnu
- Impact transfrontière potentiel : Oui / Non / Inconnu
- Mesures d'urgence prises :
- Contact opérationnel (nom, email, téléphone) :
NOTIFICATION COMPLÈTE (72h)
- Informations de l'alerte initiale (rappel ou mise à jour)
- Classification de la menace :
- Indicateurs de compromission identifiés :
- Périmètre exact affecté (systèmes, données, utilisateurs) :
- Mesures d'atténuation en cours :
- Estimation de la résolution :
- Autres autorités notifiées (CNIL si données personnelles, etc.) :
RAPPORT FINAL (1 mois)
- Chronologie détaillée de l'incident :
- Root cause analysis :
- Données/services impactés (quantification) :
- Mesures correctrices implémentées :
- Mesures préventives adoptées :
- Leçons apprises :
L'Obligation Connexe : La CNIL
Si l'incident implique des données personnelles (très fréquent en cas d'intrusion), une notification à la CNIL est également requise dans les 72 heures en vertu de l'article 33 du RGPD. Les deux obligations peuvent être menées en parallèle mais sont indépendantes. Le même incident peut donc déclencher une notification NIS2 auprès du CERT-FR et une notification de violation de données auprès de la CNIL.
WarDek : Alerting et Gestion des Notifications d'Incident
Le respect des délais NIS2 (24h, 72h, 1 mois) est impossible sans un dispositif d'alerte automatisé. WarDek intègre un module de gestion des incidents qui déclenche automatiquement les workflows de notification dès qu'un incident significatif est identifié.
La plateforme pré-remplit les rapports réglementaires avec les données disponibles, suit les délais de chaque étape, et archive l'ensemble des notifications avec leurs accusés de réception. En cas de contrôle ANSSI, votre dossier de notification est disponible en un clic, daté et intègre.
Pour comprendre le périmètre complet de NIS2, consultez notre guide sur la directive NIS2 pour les PME.