NIS2 a un délai qu'une entreprise de logiciels ne peut pas externaliser : la notification d'un incident important, à l'article 23, en trois étapes avec trois délais comptés en heures et en mois à partir du moment où l'entité en a connaissance. Le CRA a son propre délai pour les vulnérabilités activement exploitées et le RGPD ses 72 heures pour une violation de données à caractère personnel, et l'article d'aiguillage dit lequel court ; celui-ci porte sur le délai NIS2 lui-même, sur ce que chacun de ses trois rapports contient, et sur le moment où un incident est assez important pour le déclencher, lu au regard du catalogue que StandardOS tient de la directive et de la page gratuite qui calcule les délais et rédige les rapports.

Les trois délais de l'article 23, paragraphe 4

L'article 23, paragraphe 4, compte à partir de la connaissance d'un incident important. Point a) : une alerte précoce sans retard injustifié et en tout état de cause dans les 24 heures, qui, le cas échéant, indique si l'incident est soupçonné d'être causé par des actes illicites ou malveillants et s'il pourrait avoir un impact transfrontière. Point b) : une notification d'incident sans retard injustifié et en tout état de cause dans les 72 heures, qui met à jour l'alerte précoce et donne une évaluation initiale de l'incident, y compris sa gravité et son impact, ainsi que, lorsqu'ils sont disponibles, les indicateurs de compromission ; un prestataire de services de confiance donne cette notification dans les 24 heures (article 23, paragraphe 4, deuxième alinéa). Point c) : un rapport intermédiaire sur les mises à jour pertinentes de la situation, à la demande du CSIRT ou de l'autorité compétente. Point d) : un rapport final au plus tard un mois après la soumission de la notification, avec quatre éléments : une description détaillée de l'incident, y compris sa gravité et son impact, le type de menace ou la cause profonde qui l'a probablement déclenché, les mesures d'atténuation appliquées et en cours, et, le cas échéant, l'impact transfrontière. Point e) : lorsque l'incident est encore en cours à l'échéance du rapport final, un rapport d'avancement à ce moment-là et le rapport final dans le mois qui suit le traitement de l'incident. Le destinataire est le CSIRT ou, lorsque l'État membre le prévoit, l'autorité compétente (article 23, paragraphe 1), et le cas échéant les destinataires des services sont informés sans retard injustifié d'un incident important susceptible de les affecter. La page gratuite nomme le CSIRT de l'État d'après le registre du réseau des CSIRT, calcule les trois délais et compte le mois du rapport final à partir du délai de la notification tant que l'heure de soumission n'est pas saisie.

Ce qui rend un incident important

L'article 23, paragraphe 3, de la directive pose deux conditions, dont chacune rend un incident important : il a causé ou est susceptible de causer une perturbation opérationnelle grave des services ou des pertes financières pour l'entité, ou il a affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant un dommage matériel ou moral considérable. Pour les fournisseurs numériques, le règlement d'exécution (UE) 2024/2690 va plus loin et dit en chiffres quand ces conditions sont remplies. L'article 3, paragraphe 1, énumère sept critères généraux dont un seul suffit : une perte financière directe supérieure à 500 000 EUR ou à 5 % du chiffre d'affaires annuel total de l'entité au cours de l'exercice précédent, le montant le plus bas étant retenu ; l'exfiltration de secrets d'affaires ; le décès d'une personne physique ; un dommage considérable à la santé d'une personne physique ; un accès réussi, soupçonné d'être malveillant et non autorisé, aux réseaux et systèmes d'information, susceptible de causer une perturbation opérationnelle grave ; des incidents récurrents qui ensemble remplissent le critère financier (article 4 : au moins deux fois en six mois, la même cause profonde apparente) ; ou l'un des critères par service des articles 5 à 14. Pour un fournisseur de services d'informatique en nuage, l'article 7 en fixe quatre : le service totalement indisponible pendant plus de 30 minutes ; sa disponibilité limitée pour plus de 5 % de ses utilisateurs dans l'Union ou plus de 1 million d'entre eux, le nombre le plus petit étant retenu, pendant plus d'une heure ; l'intégrité, la confidentialité ou l'authenticité des données compromise à la suite d'une action soupçonnée d'être malveillante ; ou une telle compromission avec un impact sur plus de 5 % ou 1 million des utilisateurs dans l'Union, le nombre le plus petit étant retenu. L'article 10 fixe les quatre mêmes pour les fournisseurs de services gérés et de services de sécurité gérés. L'article 3, paragraphe 2, exclut les interruptions programmées et la maintenance planifiée. Une panne SaaS de 31 minutes est donc un incident important et déclenche le délai de 24 heures ; une fenêtre de maintenance planifiée de deux heures ne l'est pas ; un courriel d'hameçonnage parvenu dans une boîte ne l'est pas, sauf si le compte a servi à atteindre les systèmes.

Ce que chaque rapport dit, et ce qu'il ne doit pas attendre

L'alerte précoce, ce sont deux indications et un horodatage : malveillant ou non, transfrontière ou non, envoyés dans les 24 heures même quand les réponses sont « pas encore connu ». La notification est la première évaluation : ce qui s'est passé, quelle gravité, ce qui est affecté, avec les indicateurs de compromission là où l'entreprise les a ; elle est due dans les 72 heures et n'est pas retenue en attendant le rapport forensique. Le rapport final est l'enregistrement : la description avec la gravité et l'impact, la cause profonde ou le type de menace, les mesures appliquées et encore en cours, et l'impact transfrontière s'il y en a un, un mois après la notification. Aucun des trois n'attend que l'incident soit terminé : l'article 23, paragraphe 4, point e), est écrit précisément pour l'incident encore ouvert à l'échéance du rapport final, et le rapport d'avancement en est la réponse. Une entreprise de logiciels qui notifie en retard parce qu'elle voulait le tableau complet a notifié en retard ; la directive est conçue pour que le tableau se construise en trois étapes.

Deux délais à côté

Une entreprise de logiciels qui est une entité NIS2 est souvent aussi responsable du traitement ou sous-traitant au titre du RGPD, et le même incident qui atteint le CSIRT dans les 24 heures atteint l'autorité de contrôle dans les 72 lorsque des données à caractère personnel sont affectées, sur le délai de violation RGPD, et le fabricant d'un produit comportant des éléments numériques notifie une vulnérabilité activement exploitée à la plateforme unique de notification de l'ENISA sur le délai du CRA de 24 heures, 72 heures et 14 jours. Les trois délais courent à partir d'un même moment de connaissance avec trois destinataires et trois seuils différents, et c'est pourquoi la seule chose à régler d'avance est l'enregistrement qui les déclenche : l'incident consigné avec son horodatage, les systèmes affectés, les données affectées et les produits affectés, pour que chaque rapport soit un rendu du même enregistrement et non une enquête à part.

Quoi en faire

Décidez aujourd'hui quel type de fournisseur l'entreprise est au titre du règlement d'exécution et mettez ses seuils dans la procédure d'incident comme test de « important ». Nommez le CSIRT de l'État, ou l'autorité compétente là où la loi de transposition l'a choisie, avec son portail et son contact, avant le premier incident. Faites tourner la page gratuite une fois avec un incident passé pour voir les trois rapports qu'elle rédige, puis gardez son lien avec le moment de la connaissance comme premier enregistrement de l'incident. StandardOS ouvre le délai à partir de l'enregistrement de l'incident et rédige les trois rapports à partir de lui ; l'outil de champ d'application dit si l'entreprise est une entité essentielle ou importante en premier lieu.