Élaborer une procédure de notification d'incident pour les délais de 24 et 72 heures de NIS2
Les délais de notification NIS2 courent à partir du moment où vous avez connaissance d'un incident significatif, et non au début de la semaine de travail. Voici comment élaborer une procédure qui les respecte.

L'article 23 de NIS2 fixe trois délais de notification pour les incidents significatifs. Une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification d'incident dans les 72 heures, et un rapport final dans un délai d'un mois. ISO 27001 et la plupart des référentiels exigent la gestion des incidents, mais aucun n'impose de notifier un régulateur dans ce délai. Voici comment élaborer une procédure qui y répond.
Les trois rapports
| Rapport | Délai | Contenu |
|---|---|---|
| Alerte précoce | 24 heures à compter de la prise de connaissance | Indication selon laquelle l'incident est soupçonné d'être malveillant, et s'il pourrait avoir un impact transfrontalier |
| Notification d'incident | 72 heures à compter de la prise de connaissance | Une mise à jour, une évaluation initiale de la gravité et de l'impact, et les indicateurs de compromission lorsqu'ils sont disponibles |
| Rapport final | Un mois après la notification | Description détaillée, cause racine probable, mesures d'atténuation appliquées et en cours, impact transfrontalier |
L'autorité peut également demander des mises à jour intermédiaires. Si l'incident est toujours en cours au terme d'un mois, vous fournissez un rapport d'avancement, puis un rapport final dans un délai d'un mois à compter de la clôture du traitement.
Étape 1 : définir « significatif » pour votre organisation
Le critère de l'article 23, paragraphe 3, est large : perturbation opérationnelle grave ou perte financière, ou dommages considérables causés à des tiers. Pour certains fournisseurs numériques, le règlement d'exécution fixe des critères plus précis. Traduisez-les en une courte grille de décision que votre responsable d'astreinte peut appliquer en quelques minutes, avec des exemples, et indiquez clairement qu'en cas de doute, vous envoyez l'alerte précoce.
Étape 2 : désigner les personnes
- Qui décide de la significativité (et un suppléant, à toute heure).
- Qui transmet au CSIRT ou à l'autorité, avec un accès au portail de notification testé à l'avance.
- Qui approuve le contenu, sans que l'approbation ne devienne un goulot d'étranglement. Une alerte précoce nécessite peu de détails.
- Qui informe la direction, qui, en vertu de l'article 20, est responsable.

Étape 3 : intégrer la procédure à votre processus de gestion des incidents
Ajoutez un point de décision relatif à la notification dans votre plan de réponse aux incidents existant : lors du tri, demandez-vous « cet incident pourrait-il être significatif ? », et consignez dès ce moment le début du décompte. Enregistrez soigneusement l'heure de prise de connaissance : c'est le moment à partir duquel tous les délais sont calculés.
Étape 4 : coordonner les autres délais
Un incident significatif déclenche souvent plusieurs obligations :
- RGPD (GDPR) : notifier l'autorité de contrôle dans les 72 heures si des données personnelles sont violées (article 33).
- Contrats : clauses de notification aux clients, souvent de 24 à 72 heures.
- Autres régimes : marques de cartes de paiement pour les données de cartes, régulateurs sectoriels, et DORA pour les entités financières.
Un coordinateur unique devrait tenir cette liste, afin qu'aucun délai ne soit manqué parce qu'une autre équipe pensait qu'il ne la concernait pas.
Étape 5 : modèles et exercices
Préparez des modèles pour chacun des trois rapports, avec les champs requis, pré-remplis avec les informations de l'entreprise. Organisez ensuite un exercice au moins une fois par an, idéalement en commençant un vendredi soir, et chronométrez-le.
Un scénario d'exercice
Pour tester la procédure, réalisez un court exercice de ce type, idéalement en démarrant tard un vendredi :
- Heure 0 : la supervision signale une activité de chiffrement inhabituelle sur un serveur de fichiers qui soutient un service destiné aux clients.
- Heure 2 : l'ingénieur d'astreinte confirme un rançongiciel sur plusieurs serveurs ; le service est dégradé pour certains clients.
- Point de décision : s'agit-il d'un incident significatif ? Appliquez votre grille et consignez la décision et l'heure.
- Avant l'heure 24 : envoyez une alerte précoce à l'aide du modèle, en indiquant l'activité malveillante soupçonnée et l'impact transfrontalier possible.
- Avant l'heure 72 : transmettez la notification avec une évaluation initiale et les indicateurs de compromission.
- Délais parallèles : des données personnelles déclenchent-elles une notification au titre du RGPD ? Les contrats exigent-ils un avis aux clients ?
Chronométrez chaque étape. Les lacunes que vous identifiez (qui a accès au portail, qui peut approuver, où se trouvent les modèles) sont les véritables faiblesses de la procédure.
Conserver les registres
Consignez chaque incident évalué au regard de sa significativité, y compris ceux que vous avez décidé de ne pas notifier, avec le raisonnement. Les autorités de contrôle demanderont comment vous décidez, et pas seulement ce que vous avez notifié.
Les pages de sujet Incident Response et Reporting comparent les exigences entre référentiels, et le guide NIS2 couvre le reste du règlement.
Questions
Qu'est-ce qu'un incident significatif au titre de NIS2 ?
Au sens de l'article 23, paragraphe 3, un incident ayant causé ou pouvant causer une perturbation opérationnelle grave ou une perte financière pour l'entité, ou ayant affecté ou pouvant affecter d'autres personnes en causant un dommage matériel ou immatériel considérable. Le règlement d'exécution fixe des seuils plus précis pour certains fournisseurs numériques.
À qui signaler un incident au titre de NIS2 ?
Le CSIRT national ou l'autorité compétente désignée en vertu de la loi NIS2 de votre État membre. Certains pays recourent à un point de signalement unique.
Données au 2026-10-27 : les chiffres de cet article sont calculés à partir de la correspondance actuelle et sont mis à jour lorsqu'elle évolue. Correspondance une table de correspondance publiée (NIST, ENISA, CIS, PCI SSC) établit le lien · Éditorial Jugement de ControlMapping lorsqu'aucune table de correspondance n'existe ; le motif est affiché · partage seulement un résultat CSF 2.0 : à vérifier, mais ce n'est pas une correspondance · Aucune correspondance dans nos données rien de mappé dans nos données ; souvent un travail nouveau, mais consultez les notes de couverture. Pas un conseil en conformité.