Déclaration des incidents NIS2 sous 24 et 72 heures : procédure, responsabilités et exercice de préparation

La procédure de déclaration des incidents sous 24 et 72 heures ne peut ni commencer par un formulaire ni se limiter à la responsabilité du service informatique. Son efficacité dépend du moment où l’organisation considère avoir pris connaissance de l’incident, de la personne qui en qualifie les impacts, de celle qui décide et de la capacité à préparer puis transmettre une notification malgré des données incomplètes, l’absence de personnes clés ou l’indisponibilité des systèmes principaux. La préparation doit donc être conçue comme un processus transverse, puis éprouvée lors d’un exercice mené sous contrainte de temps.

Pourquoi le délai commence souvent plus tôt que ne le pense la direction

Le point de départ du délai ne doit pas être rattaché uniquement à une confirmation technique complète ni à la transmission du dossier à la personne habilitée à effectuer la déclaration. L’organisation doit distinguer l’événement — une anomalie ou une alerte observée — de l’incident de sécurité affectant la confidentialité, l’intégrité, la disponibilité ou l’authenticité des ressources et des services. Le niveau suivant correspond à l’incident répondant aux critères légaux de notification. Toute alerte ne déclenche donc pas nécessairement les échéances de 24 et 72 heures, mais chaque signal doit être qualifié selon des règles définies.

Le risque de retard est particulièrement élevé lorsque la procédure ne définit pas le moment auquel l’organisation est réputée avoir pris connaissance de l’incident. La première information peut être reçue par le support, un opérateur de ligne, un administrateur, un prestataire ou le service client. Si le délai n’est comptabilisé qu’à partir de l’information d’un membre de la direction ou du coordinateur sécurité, une rupture artificielle apparaît entre la détection réelle de la perturbation et la réaction formelle. La procédure doit donc préciser les sources de signalement internes et externes, les critères d’escalade ainsi que le rôle chargé de déterminer si la perturbation dépasse le seuil d’une panne courante.

Lorsqu’un prestataire chargé de maintenir un système de production informe le support d’une perte de disponibilité et d’un soupçon d’action externe, la cause, l’étendue complète et le délai prévisionnel de rétablissement peuvent encore être inconnus. Cela ne justifie pas d’attendre le rapport technique final. Pour déclencher l’escalade, il suffit de disposer d’informations sur l’heure de détection du signal, les services et sites concernés, les impacts observés, les conséquences possibles et les mesures de limitation déjà engagées. Sur cette base, une personne habilitée réalise une évaluation initiale et documente la décision d’activer ou non le processus de notification.

Les étapes de 24 et 72 heures doivent être considérées comme l’enrichissement progressif des connaissances relatives à un même incident : une alerte précoce est d’abord transmise à partir des éléments disponibles, puis l’évaluation est complétée par des constatations plus précises. Il ne s’agit pas de deux obligations administratives indépendantes. Les délais exacts, les seuils de qualification et les canaux applicables doivent être systématiquement vérifiés au regard du droit national en vigueur transposant NIS2 et des exigences de l’autorité compétente, plutôt que de fonder la procédure sur la seule directive. L’efficacité des dispositions adoptées peut être évaluée dans le cadre de l’audit NIS2 dans une entreprise industrielle : comment vérifier si l’organisation est prête à répondre aux nouvelles obligations.

Où l’organisation perd ses premières heures

Les premières heures sont souvent perdues non pas dans l’analyse technique, mais dans l’attente. Le signalement reste dans l’outil de support, aucun circuit de contact ne fonctionne en dehors des heures ouvrées, le prestataire prépare son avis, les services discutent de l’ampleur des impacts et le décideur habilité reste injoignable. La collecte manuelle d’informations provenant de plusieurs sources accentue encore le retard. Les difficultés apparaissent principalement aux interfaces entre informatique, technologies opérationnelles, production, qualité, juridique, communication, protection des données, achats et direction, chacun de ces domaines ne détenant qu’une partie des informations.

Dans une entreprise industrielle, la perte d’accès au système de planification associée à l’instabilité de certains équipements ne fournit pas immédiatement une vision complète. Elle peut traduire une panne de systèmes interdépendants, une perturbation des technologies opérationnelles ou un incident de plus grande ampleur. L’organisation doit simultanément sécuriser les opérations et la continuité de la production, identifier les actifs et sites affectés et poursuivre l’escalade. La limitation des impacts techniques ne peut attendre une décision formelle ; inversement, la décision de notifier ne doit pas être repoussée jusqu’à l’identification de la cause ou au rétablissement complet.

Les goulots d’étranglement apparaissent le plus clairement lors d’un exercice sur scénario intégrant un cas nocturne et l’indisponibilité d’une personne clé. Il convient de mesurer le temps écoulé entre le premier signal et l’escalade, la qualification, la prise de contact avec le décideur et la collecte du socle minimal d’informations. Les clauses contractuelles applicables aux prestataires de services numériques doivent également être vérifiées. Un prestataire peut contribuer à la préparation des informations, mais une notification effectuée au nom de l’organisation suppose une base explicite, une habilitation appropriée et le respect de la procédure en vigueur. La simple maintenance du système ne transfère pas la responsabilité.

L’évaluation de la préparation doit porter sur l’ensemble de l’organisation, et non sur le seul service informatique : rôles, circulation de l’information, prestataires, technologies opérationnelles et gestion de crise. Les preuves du fonctionnement de ces mécanismes doivent être cohérentes avec le périmètre présenté dans l’article Documentation NIS2 et KSC avant un contrôle : quelles politiques, quels registres et quelles preuves faut-il réellement préparer ?.

La procédure, du premier signal à la notification

La procédure doit conduire du premier signal à un envoi documenté sans subordonner la décision à l’achèvement de l’analyse technique. Le flux comprend la réception du signal, l’enregistrement de l’heure et de la source, la qualification initiale, la préservation des éléments de preuve et l’évaluation de l’impact sur le service. Viennent ensuite l’escalade, la décision, la préparation du message, son envoi par le canal approprié et la conservation de l’accusé de réception. Chaque étape doit avoir un pilote, un suppléant, un délai interne et un enregistrement défini. Les délais internes doivent préserver une marge pour la validation et le traitement d’éventuels problèmes de transmission, au lieu de coïncider avec l’échéance légale.

Pour la première étape, dans les 24 heures, un socle minimal d’informations confirmées est nécessaire : identification de l’entité, heure de détection, service affecté, impacts observés, étendue connue et mesures engagées. Les informations incertaines doivent être signalées comme provisoires, avec leur source et la méthode prévue pour les vérifier. L’absence d’informations sur la cause, l’étendue complète ou l’heure de fin de l’événement ne doit ni conduire à présenter une complétude artificielle ni bloquer automatiquement la communication. La procédure doit préciser qui valide la notification, qui assure la suppléance et comment les informations déjà transmises sont actualisées.

Lorsqu’un site perd l’accès au système pilotant l’exécution des commandes, le coordinateur enregistre l’alerte, l’heure de détection et les constats des utilisateurs, tandis que l’équipe technique sécurise en parallèle les journaux d’événements et limite les impacts. Le responsable du service évalue les conséquences sur la production, la logistique et les clients ; le décideur qualifie ensuite l’obligation de notification à partir des données disponibles. Si l’incident se poursuit, si le système d’enregistrement est indisponible ou si l’événement provient d’un prestataire, le canal de secours prévu doit être utilisé sans attendre le rapport final. Dans un groupe composé de plusieurs sociétés, il faut déterminer séparément les services affectés, l’entité concernée et l’habilitation à agir au nom de chacune d’elles.

À l’étape des 72 heures, l’organisation complète son évaluation de la nature et de la gravité de l’incident, de ses impacts, des indicateurs de compromission disponibles et des mesures de limitation, dans le périmètre prévu par les dispositions et formulaires en vigueur. Si des constatations ultérieures modifient l’ampleur, la cause ou la qualification de l’événement, l’information antérieure doit être corrigée de manière maîtrisée, sans être remplacée au prix d’une perte de traçabilité. Avant de déployer la procédure, il convient donc de vérifier, selon la catégorie de l’entité, l’autorité ou l’équipe de réponse compétente, le canal de notification, les règles de calcul des délais ainsi que les exigences d’actualisation et de rapports ultérieurs. Le champ d’application est présenté plus largement dans NIS2 pour les entreprises industrielles : entités concernées, nouvelles obligations et préparation de l’organisation sans réduire le sujet à l’informatique.

Le circuit d’information doit s’appuyer sur un registre unique de l’incident comprenant la chronologie, les versions successives des constatations, les sources des données, les décisions et leur justification, le contenu des communications ainsi que les preuves d’envoi. La messagerie électronique et les outils de communication instantanée peuvent servir à donner l’alerte, mais ne doivent pas créer plusieurs versions concurrentes de la description de l’événement. La préparation du processus doit être mesurée par les délais entre le signal et l’enregistrement, l’escalade, la décision et l’envoi, par la proportion d’entrées dont la source est identifiée et par la capacité à reconstituer qui a modifié l’évaluation de l’incident, quand et sur quelle base.

Rôles, suppléances et seuil de décision

Le processus de notification exige une répartition claire des tâches, des responsabilités et des pouvoirs. La personne qui détecte l’événement l’enregistre et déclenche l’escalade. Le coordinateur de l’incident tient la chronologie et organise la circulation de l’information ; l’expert technique évalue la nature de l’événement et préserve les données. Le responsable du service ou du processus détermine l’impact opérationnel, la personne disposant des compétences juridiques évalue l’obligation d’information, l’autorité de validation décide de la notification, tandis qu’un collaborateur habilité procède à l’envoi et en conserve la preuve. Une même personne peut cumuler plusieurs rôles, à condition de ne pas brouiller le pouvoir de décision ni créer un point unique de dépendance.

Une matrice des responsabilités n’est réellement utile que si elle précise, au-delà de l’intitulé de fonction, le périmètre de la tâche, le délai de réaction attendu, le pouvoir de décision, le suppléant et la preuve d’exécution requise. Elle doit également définir qui peut décider à partir de données incomplètes et comment arbitrer entre continuité de la production, sécurité et obligation d’information. La direction valide le modèle de réponse, les seuils d’escalade et les ressources disponibles. Elle ne peut transférer l’intégralité du risque décisionnel à l’administrateur des systèmes ou au responsable qualité, qui ne disposent généralement pas du mandat nécessaire pour arbitrer les conséquences métier et juridiques.

Chaque notification ne doit pas nécessairement être validée par un membre de la direction si le modèle interne de compétences prévoit une délégation ou une habilitation adaptée, conforme aux exigences applicables à l’entité et au canal de notification. La suppléance exige la désignation nominative de la personne suivante, des coordonnées accessibles à toute heure ainsi qu’une règle de reprise du dossier après l’expiration sans résultat d’un délai défini. Le suppléant doit disposer d’un accès effectif au registre, au formulaire, à la boîte de messagerie, aux signatures électroniques requises et au canal de secours. Une simple mention dans la procédure, sans attribution des droits correspondants, n’assure pas la continuité du processus.

Si l’incident survient la nuit, le coordinateur ne doit pas attendre indéfiniment la personne chargée de valider la notification. À l’expiration du délai de contact interne, il sollicite son suppléant, puis la personne habilitée à prendre une décision d’urgence. Les échéances internes doivent être sensiblement plus courtes que les délais externes afin de préserver une marge pour vérifier les données, réaliser l’analyse juridique, obtenir la validation, résoudre les difficultés techniques et documenter l’envoi. Les temps écoulés entre la détection, l’escalade, la décision et la transmission doivent être mesurés pendant les exercices.

Ce modèle nécessite le financement des astreintes, des accès, des formations et des outils. Il doit donc être intégré à la planification présentée dans Combien coûte la mise en œuvre de NIS2 et de l’uKSC : construire le budget des audits, de la documentation, des formations et des mesures de sécurité sans erreurs coûteuses. Ne conserver qu’un seul décideur ou qu’un seul détenteur des droits d’accès constitue une fausse économie : lors d’un incident, une indisponibilité organisationnelle devient la cause directe d’un retard formel.

Un exercice qui révèle le niveau réel de préparation

La connaissance de la procédure ne démontre pas la capacité à notifier un incident. Celle-ci doit pouvoir être exécutée sous contrainte de temps et avec des informations incomplètes. Le scénario d’exercice doit reposer sur une divulgation progressive des informations. Le signal initial peut être ambigu, certains systèmes et documents indisponibles, le prestataire peut répondre tardivement et l’impact opérationnel augmenter au fil des messages. Cette construction montre si l’organisation sait déclencher l’escalade sans attendre une analyse technique exhaustive.

L’exercice doit suivre une chronologie réaliste en enregistrant l’heure de réception et de consignation du signal, sa transmission au coordinateur, la réunion de l’équipe, la qualification initiale, la préparation du contenu, sa validation et la tentative d’envoi. Le test ne doit pas entraîner de déclaration réelle, sauf si un environnement d’essai sécurisé et une méthode d’identification des données ont été préalablement convenus. La participation de tiers doit faire l’objet d’une décision distincte. Il est pertinent d’associer le prestataire lorsque ses informations, ses accès ou son intervention sont indispensables à la qualification de l’incident. La direction doit au minimum participer à une variante exigeant une décision métier, l’acceptation d’un risque ou l’activation d’une suppléance.

Un scénario type peut commencer par le signalement d’un ralentissement du système de production. L’animateur révèle ensuite l’impossibilité d’accéder au registre des événements, l’indisponibilité de la personne chargée de valider, des données contradictoires sur le nombre de processus affectés et l’absence de réponse du prestataire. Les observateurs ne guident pas l’équipe : ils consignent les temps réels et les preuves. Ils évaluent le délai nécessaire pour que le signal parvienne au coordinateur, la disponibilité des suppléants, le nombre de responsabilités non clarifiées, l’exhaustivité de la chronologie, les écarts entre les sources et la possibilité d’utiliser le canal de secours. Ils relèvent également les fonctions sans suppléant, les droits d’accès manquants et les coordonnées obsolètes.

L’évaluation ne peut se limiter à vérifier si le projet de notification a été préparé avant l’échéance interne. Il faut déterminer si les participants :

• distinguaient les faits confirmés des hypothèses,
• identifiaient les sources des informations,
• documentaient le fondement de la qualification,
• signalaient les données devant être complétées ultérieurement,
• activaient les suppléances conformément aux règles établies,
• savaient utiliser le canal de notification de secours.

La manière d’agir dans l’incertitude constitue également un résultat essentiel. L’équipe ne doit ni qualifier automatiquement toute perturbation d’incident soumis à notification, ni suspendre l’escalade jusqu’à l’achèvement d’une analyse technique exhaustive.

L’exercice doit se conclure par un plan d’actions correctives, et non par un simple compte rendu. Chaque écart nécessite un responsable, une échéance, un critère mesurable d’efficacité et l’identification de l’élément à tester de nouveau. Il convient de suivre la proportion des actions clôturées et dont l’efficacité a été vérifiée dans le délai défini par l’organisation. La fréquence des exercices suivants et la variation des scénarios sont déterminées selon les risques, les résultats de l’exercice précédent et les changements organisationnels. De nouveaux rôles, prestataires, systèmes ou canaux de notification, ainsi que des écarts significatifs, justifient notamment un exercice supplémentaire. Ces dispositions doivent rester cohérentes avec le calendrier décrit dans Mise en œuvre de NIS2 après l’inscription au registre KSC : plan d’action jusqu’au 3 avril 2027.

Le socle minimal de préparation attendu par la direction

La direction ne peut considérer le processus de notification des incidents comme opérationnel qu’après validation de son dispositif organisationnel complet. Celui-ci comprend la procédure, les critères d’escalade, une liste de contacts à jour, les rôles et suppléances attribués, l’accès aux canaux de notification principal et de secours, les modèles de communication, un registre unique de l’incident, les règles de préservation et de conservation des preuves ainsi qu’un exercice effectivement réalisé. L’absence de l’un de ces éléments doit être traitée comme un risque opérationnel, et non comme une simple lacune rédactionnelle.

La preuve de la préparation ne réside pas dans le nombre de documents approuvés, mais dans une traçabilité cohérente du traitement : de la détection de l’événement à la qualification et à la décision, puis à la préparation et à l’envoi de la notification. Cette traçabilité doit indiquer les horaires, les sources d’information, les décideurs, le fondement de la qualification et le contenu transmis au destinataire compétent. L’organisation doit également démontrer sa capacité à agir en cas d’absence de personnes clés, d’indisponibilité des systèmes principaux et d’accès limité aux données.

Après l’exercice, une revue de direction doit convertir les constats en décisions avant un audit ou un contrôle. Le pilote du processus peut améliorer l’instruction, le registre ou la liste de contacts dans les limites de son autorité. La direction doit en revanche statuer sur les insuffisances nécessitant l’acceptation du risque résiduel, le financement de changements, des ressources supplémentaires ou une modification des responsabilités. Chaque action doit avoir un responsable, une échéance et une date de nouvelle vérification de son efficacité.

La notification des incidents doit s’inscrire dans un programme de mise en œuvre plus large, avec une vérification systématique de l’actualité des délais et des exigences. L’évaluation de la maturité doit également prendre en compte le sujet NIS2 et NF EN ISO 27001 : ce qu’apporte la certification et ce qui reste nécessaire pour répondre aux exigences du KSC. L’organisation n’est réellement prête que lorsqu’elle sait prendre la bonne décision, l’exécuter et en apporter la preuve dans un délai contraint et à partir d’informations incomplètes.