L’article 23 de la directive NIS2 tient en une page. Il impose un calendrier de notification pour les incidents importants, et ce calendrier est le point où une exploitation bien tenue se distingue d’une exploitation qui se croit bien tenue. Pas parce que les délais sont courts, mais parce qu’ils supposent que vous savez, heure par heure, ce qui s’est passé.
Le calendrier de l’article 23
| Échéance | Document | Contenu exigé |
|---|---|---|
| 24 heures après la prise de connaissance | Alerte précoce | Indiquer si l’incident semble résulter d’un acte illicite ou malveillant, et s’il peut avoir un impact transfrontalier |
| 72 heures après la prise de connaissance | Notification d’incident | Mettre à jour l’alerte, donner une première évaluation : gravité, impact, indicateurs de compromission disponibles |
| Sur demande | Rapport intermédiaire | Mises à jour pertinentes de la situation |
| Un mois après la notification | Rapport final | Description détaillée (gravité, impact), type de menace ou cause racine probable, mesures d’atténuation appliquées et en cours, impact transfrontalier le cas échéant |
| Si l’incident dure encore | Rapport d’avancement, puis rapport final un mois après la fin du traitement | Idem |
S’y ajoute une obligation souvent oubliée : informer sans retard les destinataires de vos services lorsque l’incident est susceptible de les affecter, et leur indiquer les mesures qu’ils peuvent prendre face à une menace importante. Pour un hébergeur ou un opérateur de datacenters, ces destinataires sont vos clients : leur liste doit sortir de l’inventaire, pas d’un tableur tenu à part.
Ce qu’est un incident « important »
Le paragraphe 3 donne deux critères, dont un seul suffit :
- l’incident a causé, ou peut causer, une perturbation opérationnelle grave des services ou des pertes financières pour l’entité ;
- l’incident a affecté, ou peut affecter, d’autres personnes en causant des dommages matériels, corporels ou moraux considérables.
Le mot qui compte est « peut ». La qualification se fait sur le potentiel, pas sur le bilan final. Pour la faire vite, il faut savoir quels services dépendent de l’élément touché et qui les utilise. C’est une question d’inventaire, pas de sécurité.
L’horloge cachée
L’article 23, paragraphe 4, point a), exige l’alerte précoce « sans retard injustifié et en tout état de cause dans les 24 heures après avoir eu connaissance de l’incident important ». Tout se joue dans la fin de cette phrase. Elle fixe le départ du délai au moment de la détection, pas au moment du diagnostic. Trois conséquences pratiques :
- L’horodatage de votre première alerte est votre preuve. S’il est dans un outil de supervision, il est opposable. S’il est dans la mémoire de l’astreinte, il ne l’est pas.
- Il faut une règle écrite sur ce qui vaut prise de connaissance. Une alerte automatique non lue à 3 heures du matin compte-t-elle ? Un signalement d’utilisateur au support ? Décidez-le avant l’incident.
- Le temps de qualification entame les 24 heures. Si votre équipe met six heures à comprendre quels services sont touchés, il vous reste dix-huit heures pour alerter. Voir comment mesurer ce temps.
Ce que chaque échéance exige de l’exploitation
Lisez le calendrier comme un cahier des charges adressé à vos outils et à vos équipes, pas à votre juriste.
| Échéance | Ce qu’il faut avoir sous la main | D’où ça vient |
|---|---|---|
| 24 h | Heure de détection, périmètre touché, premier avis sur l’origine | Supervision horodatée, inventaire à jour, astreinte joignable |
| 72 h | Services et utilisateurs impactés, gravité, indicateurs techniques | Dépendances modélisées dans l’inventaire, journaux conservés, ticket unique qui agrège les faits |
| 1 mois | Chronologie complète, cause racine, mesures prises, ce qui reste à faire | Ticket tenu pendant tout l’incident, revue post-incident écrite |
Si une case de la colonne du milieu vous fait hésiter, c’est là que votre prochain incident important vous mettra en retard.
Les trois ruptures classiques
L’alerte sans propriétaire. La supervision remonte un défaut sur un équipement. Personne ne sait quel service il porte ni quelle équipe le traite. L’alerte attend dans une file. Le délai court.
L’inventaire périmé. On sait qu’un serveur est tombé. On ne sait plus ce qui tourne dessus depuis la dernière migration. La qualification « important ou pas » prend une demi-journée d’appels.
La chronologie reconstituée de mémoire. À J+30, il faut écrire le rapport final. Les échanges sont dans trois messageries, les heures sont approximatives, la cause racine est une hypothèse que personne n’a vérifiée.
Ces trois ruptures ont une cause commune : la supervision, l’inventaire et le suivi des incidents sont trois outils qui ne se parlent pas. C’est le constat de départ de Hopwise Labs.
Un circuit qui tient les délais
Ce circuit n’a rien de sophistiqué. Il demande que chaque étape sache à qui passer la main.
- L’alerte crée ou alimente un ticket, avec son horodatage d’origine conservé. Le ticket devient l’unique dossier de l’incident.
- Le ticket porte le contexte : élément touché, services qui en dépendent, équipe responsable, criticité déjà connue. Il vient de l’inventaire, pas d’une recherche à chaud.
- Une question explicite à la qualification : « important au sens de l’article 23 ? » Oui, non, pas encore. La réponse et son heure sont enregistrées.
- Trois modèles pré-remplis pour l’alerte précoce, la notification et le rapport final, nourris par le ticket. Le travail à 24 heures devient une relecture, pas une rédaction.
- Une revue post-incident avant la clôture, qui produit la cause racine et les mesures. Elle alimente le rapport final et, surtout, évite la répétition.
Ce que ce circuit change : le rapport final ne se rédige plus, il se compile.
L’exercice qui dit la vérité
Prenez votre dernier incident sérieux, même s’il n’était pas « important » au sens de la directive. Rejouez-le sur le papier avec le calendrier de l’article 23 :
- À quelle heure l’auriez-vous détecté ? Avez-vous cette heure quelque part ?
- Auriez-vous pu dire, à 24 heures, s’il était malveillant ?
- Auriez-vous pu lister à 72 heures les services et les utilisateurs touchés ?
- Auriez-vous pu écrire la cause racine à un mois sans réunion de reconstitution ?
Chaque « non » désigne un chantier. Aucun d’eux n’est d’abord un chantier de sécurité : ce sont des chantiers d’inventaire, de supervision et de suivi d’incident. Le dernier est le plus répétitif : reconstituer la chronologie depuis les alertes, les tickets et les journaux, un script le fait en grande partie, et Hopwise Labs l’inscrit dans vos outils. La décision de notifier reste la vôtre.
Questions fréquentes
Quand démarre le délai de 24 heures ?
À partir du moment où l’entité a connaissance de l’incident important, pas du moment où elle a fini de le comprendre. En pratique, c’est l’horodatage de la première alerte ou du premier signalement qualifié. D’où l’intérêt d’une supervision qui horodate automatiquement et d’une règle écrite sur ce qui vaut prise de connaissance.
Que faire si on ne sait pas encore si l’incident est important ?
L’alerte précoce est conçue pour ça : elle ne demande qu’une indication sur l’origine (acte malveillant soupçonné ou non) et sur un éventuel impact transfrontalier. Elle n’engage pas sur la cause. Mieux vaut une alerte précoce retirée ensuite qu’une alerte tardive.
Faut-il notifier les incidents non significatifs ?
Non. L’obligation de l’article 23 porte sur les incidents importants au sens du paragraphe 3. Les autres incidents restent dans votre gestion interne, mais leur chronologie sert à démontrer la maîtrise de votre exploitation lors d’un contrôle.
Qui reçoit la notification ?
Le CSIRT ou l’autorité compétente désignée par l’État membre. En France, l’ANSSI porte le dispositif. Les destinataires de vos services doivent aussi être informés lorsque l’incident est susceptible de les affecter.
Un prestataire peut-il notifier à notre place ?
La responsabilité de la notification reste celle de l’entité concernée. Un prestataire peut préparer le dossier et fournir la chronologie, et c’est souvent lui qui détient les horodatages, mais l’entité doit organiser qui déclenche, qui valide et qui envoie.