Notification des incidents NIS 2 : alerte en 24 h, notification en 72 h, rapport final en un mois

La directive définit un incident comme un événement qui compromet la disponibilité, l'authenticité, l'intégrité ou la confidentialité des données, ou des services que les systèmes d'information offrent ou rendent accessibles. Tous les incidents ne se notifient pas : seul l'incident important le doit. Selon l'article 23, paragraphe 3, il l'est s'il remplit l'un de ces deux critères :

• il a causé ou peut causer une perturbation opérationnelle grave des services ou des pertes financières pour l'entité ;
• il a affecté ou peut affecter d'autres personnes, physiques ou morales, en causant des dommages matériels, corporels ou moraux considérables.

Pour certains fournisseurs numériques (DNS, informatique en nuage, centres de données, services gérés, places de marché, réseaux sociaux…), le règlement d'exécution (UE) 2024/2690 chiffre ces critères. Est notamment important un incident qui cause ou peut causer une perte financière directe supérieure à 500 000 euros ou à 5 % du chiffre d'affaires annuel, le montant le plus faible étant retenu, l'exfiltration de secrets d'affaires, le décès d'une personne ou un accès non autorisé, suspecté d'être malveillant, susceptible de causer une perturbation grave. Des incidents répétés, de même cause apparente, peuvent aussi devenir importants une fois cumulés.

Pour les autres entités, la FAQ de l'ANSSI indique que des critères nationaux seront précisés par décret en Conseil d'État. En attendant, les seuils du règlement 2024/2690 donnent un ordre d'idée utile pour construire sa propre grille de qualification.

L'article 23, paragraphe 4, découpe la notification en étapes successives. Chacune se fait sans retard injustifié, et au plus tard dans le délai indiqué :

Une exception : un prestataire de services de confiance dont les services sont touchés notifie l'incident au plus tard 24 heures après en avoir eu connaissance, au lieu de 72 heures. En retour, le CSIRT ou l'autorité répond à l'alerte précoce sans retard injustifié et, si possible, dans les 24 heures, avec un premier retour et, à la demande de l'entité, des conseils pour atténuer l'incident.

La notification va au CSIRT (centre de réponse aux incidents de sécurité informatique) national ou, le cas échéant, à l'autorité compétente. En France, le projet de loi confie ce rôle à l'ANSSI, dont le CERT-FR est le centre gouvernemental de réponse aux incidents. L'agence propose déjà une rubrique de déclaration d'incident sur son portail ClubSSI ; les modalités propres à NIS 2 seront fixées par décret après l'adoption de la loi.

La directive demande aussi à l'entité d'informer sans retard injustifié, le cas échéant, les destinataires de ses services des incidents importants susceptibles de nuire à la fourniture du service. Face à une cybermenace importante, elle leur communique les mesures qu'ils peuvent prendre eux-mêmes. Lorsque c'est dans l'intérêt public, l'autorité peut informer le public ou exiger que l'entité le fasse, après l'avoir consultée.

Et le RGPD, et DORA ?

Un même incident peut déclencher plusieurs obligations. Si des données personnelles sont touchées, la violation se notifie aussi à la CNIL dans les 72 heures (article 33 du RGPD), selon ses propres critères. Une entité financière soumise à DORA suit le régime de notification des incidents liés aux TIC de ce règlement, qui prime sur NIS 2 pour ces points. Mieux vaut prévoir dès maintenant, dans sa procédure, qui notifie quoi et à qui.

Tenir 24 heures se prépare à froid. Une procédure de notification NIS 2 tient en quelques éléments :

• une grille de qualification qui dit, en quelques questions, si un incident est important (services touchés, durée, pertes, personnes affectées) ;
• un circuit de décision court : qui qualifie, qui valide l'envoi, qui remplace en cas d'absence, y compris la nuit et le week-end ;
• des modèles pour l'alerte précoce et la notification, avec les champs attendus déjà prêts ;
• les contacts de l'autorité, de l'assureur, des prestataires clés et du délégué à la protection des données ;
• un registre des incidents qui garde trace des décisions de notifier ou non, et de leurs motifs ;
• des exercices réguliers, qui testent la procédure en même temps que le plan de continuité d'activité et la gestion de crise.

Dans cet exemple, l'incident renvoie directement à deux des dix mesures de l'article 21 : la gestion des incidents et la sécurité de la chaîne d'approvisionnement. Retrouvez-les dans le chapitre Les obligations de l'article 21, et lisez notre article sur les rançongiciels qui entrent par les VPN et pare-feu.