Le cadre de signalement des incidents NIS2 : guide étape par étape
Qui devrait lire ceci : les équipes de réponse aux incidents, les RSSI, les responsables de la conformité, les équipes juridiques et toute personne responsable du signalement des incidents et de la notification réglementaire.
L'une des obligations les plus concrètes du NIS2 est le signalement des incidents. En cas de problème, qu'il s'agisse d'une cyberattaque, d'une violation de données ou d'une défaillance du système, vous devez en informer votre organisme de réglementation. Les délais de notification sont serrés : 24 ou 72 heures, selon le type d'entité. Il n'y a aucune flexibilité. Si vous ne respectez pas la date limite, vous risquez des sanctions.
L'article 23 définit le cadre. Ce guide décrit les exigences en matière de rapports, les délais, ce que vous devez signaler et comment renforcer les capacités nécessaires pour respecter ces obligations.
Qu'est-ce qu'un « incident important » ?
Vous ne signalez pas tous les incidents. Vous ne signalez que les « incidents significatifs » tels que définis à l'article 23, paragraphe 3.
Un incident est significatif si :
a) Il a causé ou est susceptible de provoquer de graves perturbations opérationnelles des services ou des pertes financières pour l'entité concernée, ou
b) Il a affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant des dommages matériels ou immatériels considérables.
Concrètement, un incident significatif est un incident qui perturbe sensiblement vos services, entraîne des pertes financières importantes ou porte préjudice à d'autres personnes ou organisations. Un seul ordinateur infecté rapidement isolé n'atteint pas ce seuil. Une attaque par rançongiciel qui chiffre vos systèmes critiques et les met hors service pendant des heures ou des jours, c'est le cas.
Le mot « capable de » est important. Vous n'attendez pas pour évaluer l'impact réel. Si vous pensez qu'un incident pourrait provoquer de graves perturbations s'il n'est pas résolu, il est important. Cela signifie que vous devez évaluer les incidents rapidement et privilégier les signalements plutôt que de les sous-signaler.
L'article 23, paragraphe 3, donne aux régulateurs la possibilité de publier des actes d'exécution définissant l'importance de manière plus spécifique pour des types d'entités particuliers. Par exemple, pour les fournisseurs de cloud ou les opérateurs DNS, l'importance peut être définie de manière plus précise (par exemple, une panne DNS affectant X % du trafic, ou une interruption du fournisseur de cloud affectant X clients). Si vous êtes un fournisseur de DNS, de cloud, de centre de données ou de CDN, consultez les actes de mise en œuvre de votre secteur pour connaître les seuils de signification précis.
Le calendrier de présentation des rapports : processus en trois étapes
Le NIS2 nécessite un processus de reporting en trois étapes avec des délais stricts.
Étape 1 — Alerte précoce (24 heures)
Dans les 24 heures suivant la prise de connaissance d'un incident significatif, vous devez envoyer une alerte précoce à votre autorité compétente ou au CSIRT.
L'alerte précoce est brève. Il doit indiquer :
Que vous avez identifié un incident significatif (nom de l'entité, description de l'incident).
Si l'incident est soupçonné d'être causé par des actes illégaux ou malveillants (c'est-à-dire s'agit-il d'une cyberattaque, d'une panne technique, d'une catastrophe naturelle ou d'un accident ?).
Si l'incident pourrait avoir un impact transfrontalier (affecte-t-il les services aux clients d'autres États membres ou d'autres pays ?).
L'alerte précoce donne aux régulateurs une connaissance immédiate de l'incident afin qu'ils puissent coordonner la réponse, alerter les autres États membres si un impact transfrontalier est probable et fournir des orientations initiales.
Les prestataires de services de confiance ont un délai plus serré : 24 heures pour la notification complète de l'incident (voir ci-dessous), et pas seulement pour l'alerte précoce.
Étape 2 — Notification des incidents (72 heures)
Dans les 72 heures suivant la prise de connaissance de l'incident significatif, vous devez soumettre une notification d'incident complète.
La notification d'incident doit inclure :
Informations mises à jour à partir de l'alerte précoce (son caractère malveillant est-il confirmé ? L'impact transfrontalier est-il confirmé ?).
Une évaluation initiale de l'incident comprenant :
Gravité (quelle est la gravité de l'impact ? Faible, moyen, élevé, critique ?).
Impact (quels systèmes sont concernés ? Quels services ? Combien d'utilisateurs/clients ?).
Indicateurs de compromission (s'il s'agit d'une cyberattaque, quels indicateurs techniques permettent d'identifier l'attaque : adresses IP, domaines, hachages de fichiers, etc.) Ils aident le régulateur à comprendre la menace et à assurer la coordination avec les autres États membres).
La notification d'incident est plus détaillée que l'alerte précoce. Votre équipe de réponse aux incidents devrait avoir rassemblé suffisamment d'informations au bout de 72 heures pour fournir une évaluation initiale.
Pour les prestataires de services de confiance, c'est là que s'applique le délai le plus serré : ils doivent soumettre leur notification initiale dans les 24 heures, et non dans les 72 heures.
Étape 3 — Rapports intermédiaires et finaux
Après la notification de l'incident dans les 72 heures, le processus dépend de l'état de l'incident.
Si l'incident est toujours en cours et que vous avez besoin de plus de temps pour mener à bien votre enquête, vous pouvez fournir des rapports intermédiaires à la demande de votre CSIRT ou de l'autorité compétente. Ces rapports les mettent à jour sur vos progrès en matière d'atténuation ou de résolution de l'incident.
Dans le mois suivant la soumission de la notification initiale de l'incident (72 heures), vous devez soumettre un rapport final comprenant :
Une description détaillée de l'incident, y compris sa gravité et ses répercussions.
Type de menace ou cause première susceptible de déclencher l'incident (par exemple, hameçonnage et collecte d'informations d'identification, application Web vulnérable, menace interne, attaque de la chaîne d'approvisionnement, infection par un logiciel malveillant, etc.).
Mesures d'atténuation appliquées et continues (qu'avez-vous fait pour contenir et résoudre l'incident ? Les systèmes sont-ils en cours de restauration ? D'autres améliorations sont-elles apportées pour prévenir les récidives ?).
Le cas échéant, impact transfrontalier (l'incident affecte-t-il des clients ou des services dans d'autres États membres de l'UE ou hors UE ?).
Si l'incident est toujours en cours au moment où vous soumettez le rapport final, vous devez fournir un rapport d'avancement à ce moment-là et un rapport final dans le mois suivant le traitement de l'incident.
À qui faites-vous rapport ?
Vous vous adressez à votre CSIRT (Computer Security Incident Response Team) ou, le cas échéant, à votre autorité compétente.
L'article 23, paragraphe 1, précise : « Chaque État membre veille à ce que les entités essentielles et importantes notifient, sans retard injustifié, son CSIRT ou, le cas échéant, son autorité compétente conformément au paragraphe 4 de tout incident ayant un impact significatif... »
Dans la plupart des États membres, vous êtes soumis au CSIRT national. Quelques États membres désignent une autre autorité compétente pour recevoir les rapports NIS2. Vous devez déterminer laquelle s'applique dans votre État membre. Contactez l'autorité nationale de cybersécurité de votre État membre (généralement une agence gouvernementale responsable de la cybersécurité, souvent rattachée au ministère de l'Intérieur, au ministère de la Défense ou au département des affaires numériques) pour confirmer si vous vous rapportez au CSIRT ou à une autorité compétente spécifique.
Le mécanisme de signalement est généralement un courrier électronique sécurisé ou un portail en ligne. Votre CSIRT publie des informations de contact et des instructions sur la manière de soumettre des notifications. Utilisez uniquement les canaux officiels ; n'envoyez pas de notifications à des adresses e-mail aléatoires.
Si vous informez l'autorité compétente (plutôt que le CSIRT directement), l'autorité compétente est tenue de transmettre votre notification au CSIRT. Dans les deux cas, votre autorité compétente et le CSIRT verront votre notification.
Notification des bénéficiaires de services
En plus d'informer votre régulateur, vous devez également informer les clients ou les bénéficiaires de services s'ils sont susceptibles d'être affectés par l'incident.
L'article 23, paragraphe 1, stipule : « Le cas échéant, les entités concernées notifient, sans retard injustifié, les destinataires de leurs services des incidents significatifs susceptibles de nuire à la fourniture de ces services. »
L'expression « sans retard injustifié » est vague. Dans la pratique, vous devez informer les bénéficiaires des services dès que vous pouvez confirmer qu'ils sont concernés et dès que vous disposez de suffisamment d'informations pour fournir des conseils utiles.
L'article 23, paragraphe 2, ajoute : « Le cas échéant, les États membres veillent à ce que les entités essentielles et importantes communiquent, sans retard injustifié, aux destinataires de leurs services susceptibles d'être affectés par une cybermenace significative les mesures ou remèdes que ces destinataires sont en mesure de prendre pour faire face à cette menace. »
Cela signifie que vous devez non seulement informer les clients qu'il y a un incident, mais également leur dire ce qu'ils peuvent faire pour y remédier. Par exemple, si une campagne de phishing cible vos clients, dites-leur de se méfier des e-mails de phishing et modifiez leur mot de passe. Si votre service présente une vulnérabilité, demandez aux clients d'appliquer des correctifs ou de procéder à une mise à niveau.
La notification doit être claire, opportune et exploitable. Les notifications remplies de jargon ou différées minent la confiance.
Quelles informations devez-vous communiquer ?
La directive précise certaines informations qui doivent figurer dans votre notification :
Informations sur l'entité : nom, secteur, taille, principal service ou activité de votre entité.
Description de l'incident : Que s'est-il passé ? Quand en avez-vous pris conscience pour la première fois ? Quels systèmes ou services ont été concernés ?
Acte malveillant ou illégal : s'agit-il d'une cyberattaque délibérée, d'un accident, d'une panne technique ou d'une catastrophe naturelle ?
Gravité et impact : quel est le degré de gravité ? Combien d'utilisateurs/clients sont concernés ? Votre service est-il en panne, dégradé ou totalement opérationnel ?
Indicateurs de compromission : s'il s'agit d'une cyberattaque, quels indicateurs techniques permettent d'identifier l'attaque (adresses IP malveillantes, domaines, hachages de fichiers, serveurs de commande et de contrôle, etc.) ?
Cause fondamentale : quelle est la cause probable ? Par exemple, hameçonnage et ingénierie sociale, application vulnérable, système non corrigé, menace interne, compromission de la chaîne d'approvisionnement, infection par un logiciel malveillant, etc.
Mesures d'atténuation : qu'avez-vous fait pour contenir, corriger et empêcher que cela ne se reproduise ?
Impact transfrontalier : l'incident affecte-t-il les clients d'autres États membres de l'UE ou de pays non membres de l'UE ?
Votre État membre peut demander des informations supplémentaires par le biais d'actes d'exécution. Consultez les directives de votre organisme de réglementation national.
Renforcer la capacité de réponse aux incidents
Pour vous conformer à l'article 23, vous devez être en mesure de détecter, d'enquêter et de signaler les incidents dans des délais serrés. Cela nécessite :
Capacité de détection
Vous devez être capable de détecter les incidents significatifs. Cela nécessite :
Outils de surveillance de la sécurité (SIEM, détection des intrusions, détection et réponse des terminaux) qui génèrent des alertes en cas d'activité suspecte.
Collecte de journaux à partir de systèmes critiques (serveurs, pare-feux, contrôleurs de domaine, applications) afin que vous ayez une visibilité sur ce qui se passe.
Des processus de triage et d'escalade des alertes permettent d'identifier les alertes importantes et de les transmettre rapidement aux intervenants en cas d'incident.
Une définition de l'incident significatif que votre équipe comprend afin de pouvoir classer les incidents avec précision.
Équipe de réponse aux incidents
Vous avez besoin d'une équipe dotée de rôles clairement définis et d'une disponibilité 24 h/24 et 7 j/7 :
Coordinateur des incidents : gère la réponse globale aux incidents, veille à une escalade appropriée et assure la coordination avec les autres équipes.
Investigateur technique : analyse les journaux, rassemble des preuves médico-légales, identifie la cause première et les indicateurs de compromission.
Communications : rédige les notifications aux clients, communique avec les régulateurs, informe la haute direction.
Juridique/conformité : fournit des conseils sur les obligations réglementaires en matière de notification, les exigences en matière de protection des données et la responsabilité légale.
Point de contact permanent : lorsqu'un incident est identifié, il doit exister un moyen de contacter immédiatement les intervenants en cas d'incident, 24 heures sur 24, 7 jours sur 7.
Manuels et procédures
Votre équipe a besoin de procédures documentées pour gérer les différents types d'incidents :
Ransomware : contenir l'attaque (isoler les systèmes infectés), évaluer l'impact, activer les systèmes de sauvegarde si nécessaire, évaluer les demandes de rançon et les obligations réglementaires en matière de rapports, rechercher la cause première.
Violation de données : identifiez les données qui ont été consultées ou exfiltrées, déterminez s'il s'agit de données personnelles (déclenchant la notification du RGPD), évaluez l'impact commercial, limitez la violation, informez les clients et les régulateurs.
Panne du système : évaluez la cause première, rétablissez le service à l'aide de systèmes de sauvegarde ou alternatifs, recherchez la cause première, communiquez avec les clients.
Compromis de la chaîne d'approvisionnement : identifiez la manière dont votre chaîne d'approvisionnement a été affectée, isolez les systèmes compromis, alertez les clients en aval si vous êtes un fournisseur de services, remédiez.
Tests externes : vous souhaiterez peut-être effectuer des exercices de réponse aux incidents sur table tous les trimestres, au cours desquels votre équipe simule la gestion de différents scénarios d'incidents. Cela renforce la mémoire musculaire et identifie les lacunes dans vos capacités.
Conservation de la documentation et des preuves
Lors de la réponse à un incident, vous devez conserver les preuves :
Préservez les journaux système et les données d'investigation des systèmes concernés (ne les remplacez pas).
Documentez les étapes et les résultats de votre enquête (qu'avez-vous découvert ? Qu'est-ce que cela signifie ?).
Préservez les communications (e-mails, messages) pertinentes à l'incident.
Maintenir la chaîne de traçabilité si des preuves peuvent être nécessaires pour une procédure judiciaire (enquête des forces de l'ordre).
Ces preuves font partie de votre rapport final aux régulateurs et peuvent être nécessaires pour des enquêtes internes, des procédures judiciaires ou des réclamations de cyberassurance.
Protection des informations lors de la production de rapports
L'article 23, paragraphe 6, stipule : « Le cas échéant... le CSIRT, l'autorité compétente ou le point de contact unique préserve, conformément au droit de l'Union ou au droit national, la sécurité et les intérêts commerciaux de l'entité ainsi que la confidentialité des informations fournies. »
Cela signifie que les informations que vous fournissez aux régulateurs sont protégées. Vos informations techniques sensibles concernant vos systèmes, votre analyse des causes profondes, vos mesures correctives ne devraient pas être divulguées publiquement par les régulateurs sans votre consentement.
Cependant, l'article 23 (7) autorise la divulgation publique si « la sensibilisation du public est nécessaire pour prévenir un incident significatif ou pour faire face à un incident significatif en cours, ou lorsque la divulgation... est par ailleurs dans l'intérêt public ». Par exemple, s'il existe une vulnérabilité généralisée affectant de nombreuses entités, le régulateur peut divulguer l'incident pour alerter le public.
Votre notification aux régulateurs est confidentielle, mais cette confidentialité n'est pas absolue. Il est mis en balance avec l'intérêt du public à être conscient des menaces.
La disposition relative à la « sphère de sécurité »
L'article 23 (1) comprend une disposition importante : « Le simple fait de notifier n'expose pas l'entité notifiante à une responsabilité accrue ».
Il s'agit d'une « sphère de sécurité » : le fait d'informer un régulateur d'un incident ne peut pas être utilisé contre vous pour augmenter votre responsabilité légale. Cependant, la sphère de sécurité se limite à l'acte de notification lui-même. Elle ne vous protège pas de toute responsabilité si vous êtes à l'origine de l'incident par négligence ou imprudence (par exemple, en omettant de corriger les vulnérabilités connues).
La sphère de sécurité encourage les organisations à signaler les incidents de manière honnête et complète sans craindre que le rapport lui-même ne soit utilisé contre elles.
Incidents transfrontaliers
Si votre incident significatif touche des clients ou des services dans plusieurs États membres, vous devez en informer le CSIRT ou l'autorité compétente de chaque État membre concerné.
L'article 23 (1) vous oblige à « communiquer, entre autres, toute information permettant au CSIRT ou, le cas échéant, à l'autorité compétente de déterminer tout impact transfrontalier de l'incident ».
L'article 23, paragraphe 8, permet au point de contact unique d'un État membre de transmettre votre notification aux points de contact uniques des autres États membres concernés à la demande du CSIRT ou de l'autorité compétente.
Dans la pratique, en cas d'incident transfrontalier (par exemple, un fournisseur de cloud dont les clients sont répartis dans plusieurs États membres), vous devez identifier tous les États membres concernés et leurs CSIRT, et vous assurer que des notifications sont envoyées à chacun d'eux.
Liste de contrôle pratique pour signaler les incidents
Voici une liste de contrôle pratique pour le signalement des incidents :
Avez-vous identifié votre CSIRT national ou l'autorité compétente ? Disposez-vous de leur adresse e-mail ou de leur portail de signalement sécurisé ?
Votre équipe de réponse aux incidents dispose-t-elle des informations de contact et des procédures d'escalade nécessaires pour activer la réponse aux incidents dans les heures suivant la découverte d'un incident ?
Avez-vous défini ce qui constitue un « incident significatif » pour votre organisation (en consultation avec votre régulateur et les actes d'exécution s'ils sont disponibles) ?
Votre manuel de réponse aux incidents comprend-il des étapes pour recueillir les informations requises par l'article 23 (gravité, impact, indicateurs de compromission, cause première, mesures d'atténuation, impact transfrontalier) ?
Disposez-vous d'une capacité de détection (outils de surveillance, collecte de journaux) pour identifier rapidement les incidents ?
Avez-vous documenté vos procédures de réponse aux incidents et les avez-vous testées (exercices sur table, exercices en cas d'incident) ?
Disposez-vous d'un point de contact 24h/24 et 7j/7 pour l'activation de la réponse aux incidents ?
Connaissez-vous vos délais de notification (24 heures pour les prestataires de services de confiance pour la notification initiale ; 72 heures pour les autres ; un mois pour le rapport final) ?
Avez-vous identifié les clients ou les bénéficiaires de services que vous devez informer en cas d'incident ?
Disposez-vous de modèles de notifications aux clients conformes à l'article 23, paragraphe 2 (expliquant quelles mesures les destinataires peuvent prendre) ?
Avez-vous coordonné le signalement des incidents avec vos équipes juridiques et de conformité afin de comprendre les exigences de notification relatives à la protection des données (RGPD), la responsabilité légale potentielle et les implications en matière de cyberassurance ?
Principaux points à retenir
- Un incident significatif est un incident qui cause ou est susceptible de provoquer de graves perturbations opérationnelles ou des pertes financières pour votre entité, ou des dommages considérables à d'autres personnes ou organisations ; vous devez déterminer rapidement son importance afin de pouvoir respecter les délais de déclaration.
- Le calendrier de notification du NIS2 comporte trois étapes : alerte précoce dans les 24 heures (indiquant si l'incident est malveillant et s'il a un impact transfrontalier), notification de l'incident dans les 72 heures avec évaluation initiale de la gravité et de l'impact (24 heures pour les prestataires de services de confiance), et rapport final dans un délai d'un mois avec une analyse détaillée des causes profondes et des mesures d'atténuation.
- Vous devez vous présenter à votre CSIRT national ou à l'autorité compétente désignée par les canaux sécurisés officiels ; vous devez également informer les destinataires des services « sans retard injustifié » s'ils sont susceptibles d'être concernés et leur expliquer les mesures qu'ils peuvent prendre pour se protéger.
- Le renforcement des capacités de conformité nécessite des outils de détection, une équipe de réponse aux incidents 24 heures sur 24, 7 jours sur 7, avec des rôles clairs, des manuels documentés pour les différents types d'incidents, des procédures de préservation des preuves et des exercices de simulation réguliers pour tester vos capacités.
- La disposition relative à la sphère de sécurité vous protège contre une responsabilité accrue simplement pour avoir informé les régulateurs d'un incident, mais ne vous dégage pas de toute responsabilité si vous avez causé l'incident par négligence ; les informations que vous signalez ne sont pas divulguées au public, sauf si la divulgation est nécessaire pour la sécurité publique.
- Les prestataires de services de confiance sont confrontés à des délais plus serrés : obligation de notification 24 heures (au lieu de 72 heures) pour la notification initiale d'un incident lorsque l'incident affecte leurs services de confiance.
