Lorsque l’on parle de l’escalade des incidents dans le cadre de NIS2, l’attention se porte presque toujours sur les délais de notification. Les organisations se préparent à l’alerte précoce dans les 24 heures, à la notification d’incident dans les 72 heures et aux obligations de rapport qui suivent. Ces exigences sont importantes, mais elles restent relativement simples à gérer. Les délais peuvent être intégrés dans les processus, mesurés et audités.
Le véritable défi apparaît bien plus tôt, généralement dans les premières heures d’un incident, lorsque les informations sont encore incomplètes et que la pression commence déjà à monter. À ce stade, la question centrale n’est pas technique, mais organisationnelle : « À partir de quel moment un incident de cybersécurité devient-il suffisamment “important” pour être escaladé et déclaré ? » Étonnamment, cette décision reçoit peu d’attention, alors qu’il s’agit pourtant de l’un des problèmes opérationnels et de gouvernance les plus complexes introduits par NIS2.
La plupart des entreprises disposent déjà d’un processus de réponse aux incidents. Elles ont une matrice d’impact, des procédures d’escalade, des cellules de crise et des capacités de détection. Beaucoup ont investi massivement dans des outils, l’automatisation et la visibilité sur les menaces. Pourtant, même les organisations présentant une forte maturité technique rencontrent souvent des difficultés lorsqu’il faut prendre des décisions d’escalade en pleine gestion d’incident. Non pas parce qu’elles sont incapables de détecter une activité malveillante, mais parce que l’escalade a des conséquences.
Dès qu’un incident est officiellement escaladé en interne ou signalé à l’extérieur, la dynamique change. Les équipes juridiques sont impliquées. La direction générale est impliquée. Les préoccupations liées à la communication prennent de l’ampleur. Les clients, fournisseurs, régulateurs et partenaires devront peut-être être informés à leur tour. Ce qui n’était au départ qu’une enquête technique devient alors un événement d’entreprise avec des implications en matière de réputation.
Aujourd’hui, les discussions autour de NIS2 portent principalement sur la conformité : les obligations de notification, les structures de gouvernance, les contrôles requis ou encore les secteurs concernés. Ces sujets sont importants, mais ce n’est pas là que la plupart des entreprises rencontreront leurs plus grandes difficultés sur le plan opérationnel.
La véritable difficulté réside dans l’interprétation. Les organisations peinent à interpréter des éléments de preuve incomplets, des impacts métier encore incertains et la notion même d’« incident significatif » dans un contexte concret. La directive NIS2 évite volontairement de définir des seuils techniques précis, car les incidents varient d’un secteur à l’autre et d’une organisation à l’autre. Cette approche est logique d’un point de vue réglementaire, mais elle crée une zone d’ambiguïté sur le plan opérationnel.
Un même incident technique peut avoir des conséquences totalement différentes selon l’environnement dans lequel il survient. Une infection par ransomware dans un environnement de développement n’a rien à voir avec une infection identique affectant une plateforme de planification de production ou un système de gestion des rendez-vous hospitaliers.
Cette distinction est essentielle, car elle signifie que le caractère significatif d’un incident ne peut pas être déterminé uniquement par une analyse technique. Les entreprises qui tentent de réduire les décisions de notification NIS2 à de simples scores de gravité risquent rapidement de se heurter à des limites. Les modèles de sévérité traditionnels sont conçus pour prioriser les opérations, pas pour soutenir un jugement réglementaire.
La plupart des organisations classent déjà leurs incidents selon des catégories telles que faible, moyen, élevé ou critique. Ces classifications sont utiles car elles permettent aux équipes de réponse de prioriser leurs ressources et d’évaluer l’urgence opérationnelle. Mais elles montrent souvent leurs limites lorsqu’elles sont utilisées pour déterminer la significativité réglementaire d’un incident.
Un incident techniquement grave n’est pas automatiquement déclarable au titre de NIS2. À l’inverse, un incident qui semble techniquement maîtrisé peut tout de même devenir significatif en raison de son impact sur les clients ou d’un risque systémique plus large. Du point de vue réglementaire, ce qui importe n’est pas uniquement ce qui s’est produit sur le plan technique, mais aussi l’impact potentiel de l’incident sur la continuité des activités.
Les équipes de sécurité analysent naturellement les incidents sous un angle technique. Elles s’intéressent aux mouvements latéraux, aux mécanismes de persistance, à l’escalade de privilèges ou encore aux indices d’exfiltration. La direction et les parties prenantes juridiques évaluent souvent le même incident sous un angle différent. Leurs préoccupations portent davantage sur les perturbations opérationnelles, les obligations contractuelles, les exigences de divulgation, la confiance des clients ou l’exposition réputationnelle. Ces deux perspectives sont pertinentes, mais aucune n’est suffisante à elle seule dans le cadre de NIS2. Les organisations ont besoin de modèles d’escalade capables de relier ces deux mondes.
Dans la pratique, l’hésitation à escalader un incident est rarement liée à un manque d’outils ou à des capacités de détection insuffisantes. Cette hésitation provient surtout des conséquences associées à l’escalade elle-même.
Les organisations savent que dès qu’un incident est officiellement considéré comme potentiellement significatif, les exigences documentaires augmentent, la visibilité de l’entreprise augmente et l’exposition juridique augmente également. Par conséquent, beaucoup préfèrent attendre davantage de certitude avant d’escalader la situation. Or, cette certitude n’existe généralement pas durant les premières phases d’un incident.
Les investigations en cybersécurité reposent sur des probabilités. Les premiers indicateurs sont toujours incomplets et souvent fragmentaires. Les hypothèses initiales s’avèrent régulièrement incorrectes à mesure que l’enquête progresse. Pourtant, de nombreuses organisations continuent de penser que les décisions d’escalade ne devraient être prises qu’une fois tous les faits établis.
Cette approche n’est pas compatible avec NIS2. Les processus de réponse aux incidents doivent être repensés pour soutenir la prise de décision malgré l’incertitude, et non une fois que celle-ci a disparu.
L’objectif de l’escalade des incidents dans le cadre de NIS2 n’est pas de garantir que chaque décision de notification soit parfaite. Cela serait irréaliste alors qu’un incident est toujours en cours d’investigation. L’objectif est de s’assurer que les décisions prises sont raisonnables au regard des informations disponibles à ce moment précis.
Nous devons comprendre que la gravité technique seule est insuffisante et que les responsabilités en matière d’escalade doivent être définies avant qu’un incident ne survienne. Nous devons également reconnaître qu’attendre la confirmation d’un impact peut créer davantage de risques que l’évaluation précoce d’un impact plausible. Et surtout, nous devons accepter explicitement l’incertitude au lieu de l’utiliser comme prétexte pour repousser les décisions.
Pour y parvenir, il est essentiel de distinguer clairement l’urgence opérationnelle de la significativité réglementaire. Un score de sévérité attribué par un SOC ne devrait pas automatiquement déterminer si un incident doit être déclaré. La sévérité technique mesure un risque opérationnel. La significativité réglementaire nécessite une évaluation plus large prenant en compte la dépendance métier, l’impact sur les clients, l’exposition des tiers, les implications juridiques et la portée systémique de l’incident.
Cette évaluation globale n’est possible que si l’on définit à l’avance comment l’analyse technique, l’interprétation juridique, la responsabilité de la direction et la prise de décision réglementaire interagissent en situation de crise.
Cela ne signifie pas que chaque événement suspect doit être déclaré. Cela signifie simplement que l’incertitude elle-même doit être considérée comme un facteur du processus d’évaluation des risques.
Les entreprises ont besoin de critères décisionnels structurés permettant d’évaluer les incidents de manière cohérente selon des dimensions techniques, opérationnelles et réglementaires.
Chez Cingulum, nous encourageons nos clients à répondre simultanément à quatre questions :
En parallèle, l’un des aspects les plus souvent négligés de la gouvernance des incidents est la traçabilité des décisions. Les entreprises devraient être en mesure de reconstituer la manière dont les décisions d’escalade ont été prises : quelles informations étaient disponibles à ce moment-là, quelles hypothèses ont influencé l’évaluation, qui a participé aux discussions et pourquoi la décision retenue était considérée comme raisonnable dans le contexte donné.
Les autorités de contrôle savent qu’il est impossible d’obtenir une visibilité parfaite durant un incident en cours. Ce qui devient difficile à défendre, en revanche, ce sont des raisonnements incohérents, des décisions non documentées ou des responsabilités mal définies. Dans la pratique, une documentation insuffisante génère souvent davantage de risques réglementaires qu’une évaluation technique imparfaite.
L’une des conséquences les plus sous-estimées de NIS2 est qu’elle modifie les attentes à l’égard des responsables cybersécurité.
Historiquement, la réponse aux incidents était avant tout considérée comme une capacité opérationnelle technique. La réussite se mesurait à travers la rapidité de détection, l’efficacité du confinement et le temps de rétablissement. Ces capacités restent essentielles, mais elles ne sont plus suffisantes.
Aujourd’hui, les responsables cybersécurité doivent également jouer un rôle de gouvernance. Ils doivent être capables d’équilibrer simultanément les réalités opérationnelles, les obligations réglementaires, les risques réputationnels et les enjeux de continuité des activités.
Pour de nombreuses organisations, cela constituera probablement le défi le plus complexe.
L’auteur de cet article est Willem Magerman, Expert Consultant & Lead Auditor chez Cingulum.
Découvrez-en plus sur Cingulum : https://cingulum.eu