Article 23 de la directive NIS2 établit le régime de notification obligatoire des incidents significatifs. Contrairement à NIS1 qui laissait une large marge d'interprétation aux États membres, NIS2 impose des délais harmonisés applicables à toutes les entités essentielles et importantes à travers l'Union Européenne. Voici comment structurer votre processus de notification pour tenir les échéances 24h, 72h et 1 mois — sans sous-déclarer ni surcharger vos équipes.
Qu'est-ce qu'un « incident significatif » au sens de NIS2 ?
NIS2 définit un incident significatif comme un événement qui :
- A causé ou est susceptible de causer une perturbation opérationnelle grave des services fournis ou des pertes financières pour l'entité, OU
- A affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant des dommages matériels, corporels ou moraux considérables
La Commission Européenne a publié un règlement d'exécution (implementing regulation) précisant les seuils sectoriels (perte de disponibilité > X heures, impact financier > Y, nombre d'utilisateurs impactés > Z, etc.). Ces seuils doivent être considérés en combinaison avec l'évaluation qualitative de la gravité.
Exemples courants d'incidents significatifs
- Indisponibilité d'un service cœur de métier > 2 heures (secteur financier) ou > 4 heures (autres secteurs)
- Compromission avérée de données personnelles (souvent croisée avec obligation RGPD)
- Accès non autorisé à des systèmes critiques, même sans exfiltration confirmée
- Attaque ransomware même si la remédiation est rapide
- Dégradation significative de performance > 50 % sur > 1 heure
- Perte d'intégrité de données critiques (corruption, modification non autorisée)
Les incidents qui ne nécessitent pas de notification
- Incidents mineurs (dysfonctionnement interne sans impact utilisateur)
- Incidents préventifs (patches appliqués avant exploitation)
- Exercices et tests de crise
- Incidents entièrement contenus sans impact service
La règle prudente : en cas de doute, notifier. L'autorité préfère un sur-signalement qu'un sous-signalement, et la non-notification d'un incident qui se révèle grave expose l'entité à des sanctions majorées.
Les trois jalons de notification
Jalon 1 — Early warning (alerte initiale) : 24 heures
Délai : au plus tard 24 heures après que l'entité a eu connaissance de l'incident.
Contenu minimal :
- Indication que l'incident est susceptible de provenir d'actes illicites ou malveillants
- Impact transfrontalier potentiel (autres États membres affectés ?)
- Actions immédiates déjà prises pour limiter la propagation
C'est une pré-alerte, pas un rapport détaillé. L'objectif est de permettre à l'autorité compétente (CSIRT national) d'activer son propre dispositif de surveillance et d'alerter les autres autorités si pertinent.
Qui notifier en France : ANSSI via le portail de signalement Qui notifier en Belgique : CCB (Centre pour la Cybersécurité Belgique) via le portail dédié Qui notifier dans les autres États membres : CSIRT national ou autorité compétente NIS2
Jalon 2 — Incident notification (signalement) : 72 heures
Délai : au plus tard 72 heures après que l'entité a eu connaissance de l'incident.
Contenu attendu :
- Description initiale de l'incident et de ses causes probables
- Évaluation de la gravité et de l'impact
- Indicateurs de compromission (IoC) si identifiés
- Mises à jour sur les actions correctives en cours
- Estimation du nombre d'utilisateurs/clients affectés
- Portée géographique (pays, régions)
- Impact opérationnel mesuré
Le signalement 72h est cumulatif avec l'early warning 24h — vous ne « remplacez » pas, vous mettez à jour et enrichissez. Les informations non disponibles à 24h deviennent obligatoires à 72h.
Jalon 3 — Final report (rapport final) : 1 mois
Délai : au plus tard 1 mois après l'incident significatif.
Contenu attendu :
- Description détaillée et définitive de l'incident
- Type de menace ou cause racine (root cause)
- Mesures d'atténuation appliquées et leur efficacité
- Impact transfrontalier réel (si applicable)
- Mesures préventives adoptées pour éviter la récurrence
- Leçons apprises
Si l'incident est toujours en cours à 1 mois, l'entité doit fournir un rapport d'étape à cette échéance, puis un rapport final définitif au plus tard 1 mois après que l'incident a été traité.
Tableau récapitulatif
| Jalon | Délai | Objectif | Contenu principal |
|---|---|---|---|
| Early warning | 24 h | Alerter | Acte malveillant suspecté + impact transfrontalier potentiel |
| Signalement | 72 h | Qualifier | Description, gravité, IoC, portée, impact |
| Rapport final | 1 mois | Clôturer | Cause racine, remédiation, leçons apprises |
Le compteur démarre quand ?
L'article 23 parle de « connaissance » (awareness) de l'incident. Cette notion est cruciale et a fait l'objet de clarifications de la Commission.
Interprétation pratique
Le compteur démarre lorsque l'entité :
- Reçoit des informations fiables (interne ou externe) indiquant un incident significatif
- A confirmé que l'événement répond aux critères NIS2 (test de seuil + évaluation qualitative)
Ce n'est pas le moment où l'incident s'est produit (qui peut être beaucoup plus tôt — cas typique : compromission silencieuse détectée 3 semaines après).
C'est pas non plus le moment où l'entité a un doute ou une suspicion — un ticket SOC en niveau 2 ne déclenche pas le compteur. La confirmation que l'incident est significatif déclenche le compteur.
Exemple chronologique
- J-30 : Intrusion silencieuse dans le SI (compromission de compte admin)
- J-5 : Alerte EDR déclenchée, ticket SOC P1
- J-2 : Analyse forensique confirme : exfiltration de 2000 comptes utilisateurs
- J0, 14:00 : Le RSSI confirme que l'incident répond aux critères NIS2 significatifs → démarrage du compteur
- J0+24h (J+1, 14:00) : Early warning dû
- J0+72h (J+3, 14:00) : Signalement dû
- J0+1 mois (J+30, 14:00) : Rapport final dû
Tracer précisément le timestamp de connaissance est donc un pré-requis opérationnel majeur. Un ticket horodaté dans votre ITSM avec le moment de la confirmation est la preuve usuellement acceptée.
Coordination avec les autres notifications obligatoires
Un incident significatif NIS2 peut également déclencher d'autres obligations de notification :
RGPD / GDPR (72h)
Si des données personnelles sont concernées : notification CNIL/DPA nationale sous 72 heures au titre de l'article 33 du RGPD. C'est une notification distincte mais avec un timing aligné sur le 72h NIS2.
DORA (pour les entités financières)
Les entités financières soumises à DORA notifient sous un régime spécifique (early warning, intermédiaire, final). Les délais DORA et NIS2 se chevauchent partiellement. En pratique, le CSIRT national transmet au superviseur financier pour éviter la double notification formelle. Pour en savoir plus, consultez notre guide DORA 2026 et notre comparatif DORA vs NIS2.
Directive CER (entités critiques physiques)
Pour les entités également couvertes par la directive CER (Critical Entities Resilience), une notification complémentaire à l'autorité CER peut être requise pour les incidents hors-cyber (catastrophes physiques, défaillances infrastructure).
Secteur de l'aviation, santé, etc.
Des obligations sectorielles préexistent (EASA, EMA, etc.). NIS2 ne les remplace pas : elles coexistent.
Notre conseil
Construire une matrice de notifications qui croise :
- Type d'incident (cyber, physique, mixte)
- Données concernées (personnelles, financières, sanitaires)
- Autorités à notifier + délais
- Modèle de formulaire pour chaque autorité
Cette matrice fait partie intégrante de votre plan de réponse à incident. ResiPlan automatise cette matrice en cartographiant chaque type d'incident à ses obligations de notification.
Les 7 étapes opérationnelles pour tenir les délais
1. Détection et escalade (continu)
- Outillage SIEM + EDR + SOAR pour détection proactive
- Procédure d'escalade L1 → L2 → RSSI clairement documentée
- Astreinte RSSI 24/7 pour les entités essentielles
2. Qualification (J0)
- Checklist NIS2 : seuils dépassés ? impact transfrontalier ? acte malveillant suspecté ?
- Décision documentée : incident significatif OUI / NON
- Horodatage officiel de la connaissance (timestamp ITSM)
3. Mobilisation cellule de crise (J0+1h à 4h)
- Cellule de crise active : RSSI, DSI, Dirigeant, Juridique, Communication, DPO
- Point de contact unique désigné pour les autorités
- Préparation de l'early warning 24h
4. Early warning (J0 à J+24h)
- Envoi du formulaire via portail national (ANSSI, CCB, etc.)
- Archivage horodaté de l'envoi
- Communication interne : instructions de ne pas communiquer à l'externe sans coordination
5. Signalement 72h (J+24h à J+72h)
- Enrichissement progressif : forensique, logs, comportement attaquant
- Estimation impacts : nombre de victimes, portée géographique, perte financière
- Préparation de la communication externe si pertinent
6. Remédiation et suivi (J+3 à J+30)
- Plans correctifs + monitoring continu
- Mises à jour régulières à l'autorité sur demande
- Coordination avec d'autres entités si incident chaîne d'approvisionnement
7. Rapport final et RETEX (J+30)
- Soumission du rapport final
- RETEX interne : qu'est-ce qui a marché, qu'est-ce qui doit être amélioré ?
- Mise à jour des playbooks + formation des équipes
Erreurs courantes à éviter
Erreur 1 — Attendre la « complétude » avant de notifier Non. NIS2 impose les jalons même si l'information est partielle. Il vaut mieux notifier tôt avec les informations disponibles et enrichir ensuite que de manquer le délai en cherchant l'exhaustivité.
Erreur 2 — Ne pas horodater la « connaissance » Le timestamp officiel est critique. Il doit être inscriptible dans votre ITSM ou votre SIEM et opposable en cas d'audit. Un simple email au RSSI ne suffit pas.
Erreur 3 — Confondre notification et communication externe La notification à l'autorité NIS2 est une obligation légale. La communication externe (clients, presse, médias) relève d'une décision stratégique séparée, à coordonner avec le juridique et la direction.
Erreur 4 — Considérer la notification comme une affaire technique uniquement NIS2 engage la responsabilité personnelle des dirigeants. La décision de notifier ou non, le contenu du rapport, et les délais doivent être validés par la direction, pas seulement par le RSSI.
Erreur 5 — Ignorer les notifications sectorielles parallèles RGPD, DORA, directive CER, obligations sectorielles… assurez-vous de votre matrice exhaustive.
Comment ResiPlan accélère votre conformité NIS2
ResiPlan inclut nativement :
- Un module de gestion d'incidents avec workflow automatique 24h/72h/1 mois
- Des formulaires pré-remplis pour les autorités ANSSI, CCB, et autres CSIRT
- Un suivi du timestamp de connaissance horodaté et opposable
- Une matrice de notifications croisant NIS2, RGPD, DORA par type d'incident
- Un audit trail complet pour les contrôles de l'autorité
Démarrez votre essai gratuit 14 jours pour voir le module incident en action.
Conclusion
NIS2 transforme la notification d'incident d'un exercice administratif en un processus critique, minuté et engageant la responsabilité des dirigeants. Les délais 24h/72h/1 mois sont stricts et les sanctions en cas de manquement sont substantielles (jusqu'à 2 % du CA mondial pour les entités essentielles).
La clé opérationnelle : préparer le processus avant qu'un incident survienne. Playbooks clairs, outils automatisés, cellule de crise pré-qualifiée, relations établies avec les CSIRT. Le jour J, il est trop tard pour improviser.
Pour approfondir, consultez :