Dans quel délai devez-vous signaler un incident NIS2 ?
L’article 23 de la NIS2 impose une procédure de notification en trois étapes pour les incidents importants. Vous devez soumettre une alerte rapide dans les 24 heures suivant la prise de connaissance de l’incident. Une notification détaillée de l’incident suit dans les 72 heures. Un rapport final, comprenant une analyse des causes profondes et des mesures correctives, doit être présenté dans un délai d’un mois. Si vous ne respectez pas le délai de 24 heures, votre organisation s’expose à des mesures d’application, à des amendes et à une responsabilité personnelle potentielle des membres du conseil d’administration.
NIS2 est la directive de l’UE qui impose des obligations en matière de cybersécurité aux organisations de 18 secteurs, dont l’énergie, les soins de santé, les transports, l’industrie manufacturière et les services numériques. En Belgique, la loi est active depuis octobre 2024 et s’applique aux entités comptant 50 employés ou plus, ou dont le chiffre d’affaires annuel est supérieur à 10 millions d’euros. De toutes les exigences du NIS2, c’est le rapport d’incident qui comporte les délais les plus serrés et la pression opérationnelle la plus immédiate. Pour avoir une vue d’ensemble de ce que NIS2 signifie pour les équipes du mid-market, consultez notre aperçu de la conformité NIS2.
L’alerte rapide dans les 24 heures est le délai qui fait défaut à la plupart des organisations du marché intermédiaire. Ce n’est pas par manque de volonté de signaler les incidents, mais parce qu’elles n’ont pas la visibilité nécessaire pour les classer assez rapidement. Lorsque vos journaux sont dispersés dans cinq outils distincts, le simple fait de confirmer si un événement peut être qualifié de « significatif » peut absorber toute la fenêtre. La journalisation centralisée change cette équation. Une piste d’audit unique qui met en corrélation les événements d’accès, les violations de règles et les alertes de sécurité vous permet de passer de la détection à la classification en quelques minutes plutôt qu’en quelques heures.
Ce guide décrit en détail les trois phases de notification, explique le contenu de chaque notification, couvre les procédures de notification belges, néerlandaises et britanniques, et fournit un processus de réponse aux incidents étape par étape que vous pouvez adapter à votre organisation.
Ce qu’exige l’article 23 du NIS2
L’article 23 remplace les termes vagues « sans retard excessif » de la directive NIS initiale par trois échéances précises. Chaque phase a un objectif différent et les informations requises à chaque étape sont délibérément différentes.
| Phase | Date limite | Objectif | Ce qu’il faut inclure |
|---|---|---|---|
| Alerte précoce | 24 heures après la prise de conscience | Alerter les autorités que quelque chose est en train de se passer | Confirmation d’un incident important, cause malveillante présumée (oui/non), impact transfrontalier potentiel, premières mesures d’endiguement |
| Notification de l’incident | 72 heures après la prise de conscience | Fournir des détails validés pour une réponse coordonnée | Évaluation de la gravité, indicateurs de compromission (IOC), nombre d’utilisateurs touchés, état des mesures correctives, analyse de l’impact sectoriel. |
| Rapport final | 1 mois après la notification des 72 heures | Registre permanent de responsabilité | Analyse complète des causes profondes, chronologie des événements, mesures correctives permanentes, leçons tirées de l’expérience. |
Le délai commence à courir lorsque votre organisation « prend conscience » que l’incident répond aux critères d’importance. Pas lorsque l’attaque a commencé. Pas lorsque vous avez terminé votre enquête. La fenêtre de 24 heures s’ouvre dès que vous disposez de suffisamment d’informations pour classer l’événement comme significatif.
Si l’incident est toujours en cours au bout d’un mois, vous soumettez un rapport d’avancement. Le rapport final suit dans le mois qui suit la résolution de l’incident.
Un détail qui prend les organisations au dépourvu : L’article 23, paragraphe 5, exige que l’autorité destinataire réponde à votre alerte rapide dans les 24 heures, si possible, et qu’elle fournisse des conseils initiaux sur les mesures d’atténuation. Il ne s’agit pas d’une voie à sens unique. L’autorité est censée vous aider, en particulier si l’incident a des implications transfrontalières.
Qu’est-ce qu’un incident significatif ?
L’obligation de notification ne s’applique pas à tous les événements liés à la sécurité. L’article 23, paragraphe 3, définit un incident significatif comme un incident qui atteint un seuil qualitatif ou quantitatif.
Perturbation opérationnelle. L’incident a causé ou pourrait causer une grave perturbation des services que vous fournissez. Une attaque par ransomware qui crypte les systèmes de production remplit les conditions requises. Une tentative d’hameçonnage ratée que vos filtres ont détectée ne l’est pas.
Perte financière. L’incident a causé ou pourrait causer des pertes financières importantes. Les coûts directs, les frais de recouvrement, les pertes de revenus et les pénalités contractuelles sont tous pris en compte.
Dommages aux tiers. L’incident a affecté ou pourrait affecter d’autres personnes ou organisations. Les violations de données qui exposent des informations personnelles ou les perturbations de la chaîne d’approvisionnement qui se répercutent sur vos clients entrent dans cette catégorie.
Intention malveillante. Les activités suspectées d’être parrainées par un État, l’espionnage ou les attaques susceptibles d’avoir un impact transfrontalier sont traités en priorité à des fins d’alerte rapide.
Le règlement d’exécution 2024/2690 de la Commission européenne ajoute des seuils techniques spécifiques pour les fournisseurs d’infrastructures numériques tels que les services en nuage, les centres de données et les opérateurs DNS. Pour la plupart des entreprises de taille moyenne, le test pratique est simple : si l’incident perturbe vos services, compromet des données personnelles ou risque de s’étendre à d’autres organisations, il est significatif et le délai commence à courir.
Construisez votre matrice de classification interne autour de ces quatre critères avant qu’un incident ne se produise. Lorsqu’une alerte se déclenche à 2 heures du matin, votre ingénieur de garde ne doit pas avoir à interpréter un texte réglementaire. Il a besoin d’un arbre de décision d’une page qui lui dise : significatif ou non significatif, signaler ou surveiller. Les plateformes comme Jimber simplifient cette étape car chaque décision d’accès, violation de politique et alerte de sécurité passe déjà par un plan de contrôle unique. L’ingénieur voit l’utilisateur concerné, l’état de la posture de l’appareil et la portée de l’événement en une seule vue, plutôt que d’extraire des données de trois consoles avant qu’une classification ne soit possible.
Où faire une déclaration en Belgique, aux Pays-Bas et au Royaume-Uni ?
Belgique
Le Centre pour la cybersécurité en Belgique (CCB) est l’autorité nationale. Tous les incidents NIS2 importants doivent être signalés via le portail Safeonweb@Work. CERT.be, la branche opérationnelle du CCB, assure la coordination des incidents et peut fournir une assistance technique lors d’incidents actifs.
), la date et l’heure exactes de la détection, une description de la manière dont vous avez détecté l’événement, une évaluation préliminaire de l’impact, si des effets transfrontaliers sont suspectés, et la confirmation que l’authentification multifactorielle était active sur les systèmes affectés.
La Belgique a été l’un des premiers États membres de l’UE à transposer le NIS2 en droit national le 26 avril 2024. Les obligations de déclaration d’incidents sont actives depuis le 18 octobre 2024. Il ne s’agit pas d’une exigence future. Elle s’applique dès à présent.
Pour les organisations travaillant dans le cadre des CyberFundamentals (CyFun), les rapports d’incidents relèvent directement de la fonction Respond. Le contrôle RS.CO (Communications) de la CyFun exige un processus documenté pour le signalement à la fois à la direction interne et aux autorités externes, y compris la DGCC. Le guide d’auto-évaluation de la CyFun couvre ces contrôles en détail. L’outil de conformité CRACy de Jimber compare votre configuration existante aux contrôles Respond, en montrant où votre procédure de rapport d’incident répond déjà aux exigences de la CyFun et où des lacunes subsistent.
Les Pays-Bas
Le NCSC-NL (Nationaal Cyber Security Centrum) sert de CSIRT principal pour les entités essentielles. Les Pays-Bas ont activé leur Cyberbeveiligingswet (loi sur la cybersécurité) au premier trimestre 2026, transposant le NIS2 dans la législation néerlandaise. Les rapports suivent la même cadence de 24/72/1 mois par l’intermédiaire du portail du NCSC.
Royaume-Uni
Le Royaume-Uni applique ses propres réglementations NIS 2018 (telles que modifiées), qui sont antérieures à NIS2 et dont le champ d’application diffère. Le gouvernement britannique a proposé des mises à jour pour s’aligner plus étroitement sur le NIS2, mais le cadre actuel utilise des autorités compétentes sectorielles plutôt qu’un portail national unique. Vérifiez auprès de l’autorité de régulation de votre secteur la procédure de déclaration applicable.
Comment respecter le délai de 24 heures
C’est ici que la théorie rencontre la réalité opérationnelle. La fenêtre de 24 heures semble étroite. Pour les organisations disposant d’une visibilité centralisée, elle est tout à fait gérable. Pour les organisations qui collectent encore manuellement des journaux à partir de pare-feux, d’outils pour terminaux et d’applications en nuage distincts, c’est presque impossible.
Le problème ne réside pas dans la rédaction du rapport. L’alerte précoce est délibérément légère : confirmer l’incident, indiquer s’il semble malveillant, noter le risque transfrontalier, décrire le confinement initial. Vous pouvez remplir ce formulaire en 30 minutes.
Le problème est d’atteindre le point où vous pouvez dire en toute confiance « oui, c’est important » dans les premières heures. Pour cela, il faut corréler des données provenant de sources multiples afin de comprendre ce qui s’est passé, ce qui a été touché et jusqu’où l’incident s’est propagé.
Pourquoi l’exploitation forestière dispersée ne respecte pas la date limite. Dans une configuration typique de marché intermédiaire, les journaux de pare-feu se trouvent dans une console, les alertes de points d’extrémité dans une autre, les journaux d’applications en nuage dans une troisième et les enregistrements d’accès VPN dans une toute autre. Extraire les données de chaque système, normaliser les horodatages et recouper les événements manuellement est un exercice de plusieurs heures avant même de commencer l’analyse. Selon le rapport 2025 Cost of a Data Breach d’IBM, il faut en moyenne 186 jours pour identifier les incidents impliquant des informations d’identification compromises. Même les équipes les mieux dotées en ressources ne parviennent que rarement à effectuer le triage initial en moins de 8 heures lorsqu’elles travaillent avec des outils déconnectés les uns des autres.
Comment l’enregistrement centralisé résout le problème. Lorsque toutes les décisions d’accès, l’activité du réseau et les alertes de sécurité passent par une plateforme unique, la corrélation se fait automatiquement. Une connexion anormale à partir d’un lieu inconnu, suivie d’un mouvement latéral vers un serveur de fichiers, puis d’une tentative d’exfiltration de données, apparaît comme une séquence connectée plutôt que comme trois alertes isolées dans trois tableaux de bord distincts.
La console de gestion unique de Jimber met en corrélation les événements d’accès, les violations de politique et les alertes de sécurité dans une piste d’audit unique. Comme tout le trafic passe par le plan de contrôle SASE, le chemin complet de l’attaque est visible à partir d’une seule interface : le point d’entrée initial, le mouvement latéral, les systèmes et les données affectés. Cela permet à votre responsable de la sécurité de déterminer si un incident atteint le seuil d’importance en quelques minutes plutôt qu’en quelques heures, transformant le délai de 24 heures d’une course effrénée en un processus structuré.
La même piste d’audit génère les preuves horodatées et immuables dont le rapport final a besoin un mois plus tard. Les plateformes telles que Jimber produisent des journaux contrôlés par version de chaque décision d’accès et de chaque changement de politique, qui peuvent être exportés directement vers le portail de reporting de la BCC. Pas d’agrégation manuelle des journaux. Pas de lacunes dans les preuves.
Conseil pratique. Organisez un exercice sur table simulant un incident de ransomware. Démarrez le chronomètre lorsque la première alerte se déclenche. Suivez le temps qu’il faut à votre équipe pour confirmer l’importance de l’information en utilisant vos outils actuels. Si vous ne parvenez pas à prendre une décision de classification dans les 4 heures, vous avez un problème de visibilité que les améliorations de processus ne suffiront pas à résoudre.
Élaborer votre procédure de signalement des incidents
Une procédure documentée que votre équipe peut suivre sous pression vaut plus que n’importe quel diagramme. Voici un flux de travail étape par étape, structuré autour des phases du rapport NIS2.
Étape 1 : Détection et triage (heures 0 à 2)
Vos systèmes de surveillance signalent une anomalie. L’ingénieur d’astreinte vérifie l’alerte par rapport à votre matrice de classification. Dans un environnement SASE consolidé comme Jimber, cette alerte contient déjà l’identité de l’utilisateur, l’état de la posture de l’appareil et les ressources accédées, ce qui donne à l’ingénieur le contexte nécessaire pour classifier en quelques minutes plutôt qu’en quelques heures. Questions clés à ce stade : la disponibilité du service est-elle affectée ? Les données personnelles sont-elles potentiellement compromises ? L’incident semble-t-il malveillant ? Peut-il affecter d’autres organisations ?
Si l’une des réponses est « oui » ou « probablement oui », classez-la comme significative et lancez l’horloge des 24 heures.
Étape 2 : Contenir et intensifier (heures 2 à 6)
Isoler les systèmes affectés. Désactiver les comptes compromis. Bloquez les adresses IP malveillantes. Faites remonter simultanément l’information à votre responsable de la réponse aux incidents et à votre contact juridique/conformité. Les personnes qui émettront l’alerte rapide doivent être informées maintenant, et non à l’heure 22.
Étape 3 : Introduction de l’alerte précoce (heure 6-24)
Rédigez et envoyez la notification 24 heures sur 24 via le portail Safeonweb@Work (Belgique), le portail NCSC (Pays-Bas) ou le régulateur de votre secteur (Royaume-Uni). N’indiquez que ce que vous savez à ce stade. La DGCCRF préfère un « inconnu » honnête dans un délai raisonnable à un rapport détaillé soumis à l’heure 25.
Étape 4 : Enquêter et recueillir des preuves (heures 24 à 72)
Utilisez vos journaux centralisés pour reconstituer la chronologie de l’attaque. Identifiez les indicateurs de compromission : adresses IP, hachages de fichiers, vulnérabilités exploitées. Quantifiez l’impact : nombre d’utilisateurs, de systèmes, d’enregistrements de données touchés. Évaluez si l’incident a des répercussions sur le secteur ou la chaîne d’approvisionnement.
Étape 5 : Soumettre la notification de 72 heures (heures 48-72)
Cette mise à jour doit contenir des détails techniques validés. L’évaluation de la gravité, les CIO, les mesures de remédiation prises et une analyse de l’incidence éventuelle de l’incident sur d’autres organisations ou secteurs. Si vous avez également une obligation de notification GDPR (données personnelles concernées), synchronisez les soumissions 72 heures pour plus de cohérence.
Étape 6 : Analyse des causes profondes et rapport final (semaine 1-4)
Une fois l’incident maîtrisé, procédez à une analyse rétrospective. Identifiez la cause première, documentez la chronologie complète de l’incident et décrivez les mesures permanentes que vous mettez en œuvre pour éviter que l’incident ne se reproduise. Soumettez le rapport final dans un délai d’un mois.
Que préparer avant qu’un incident ne se produise ?
Le fait de disposer de ces éléments avant d’en avoir besoin permet de gagner des heures lors d’un incident réel :
- Des modèles de rapport pré-remplis avec les détails de l’enregistrement de votre organisation auprès de la DGCC, la classification sectorielle et les informations de contact.
- Une matrice de classification mettant en correspondance les types d’incidents et les critères d’importance du NIS2
- Une matrice d’escalade avec les noms, les rôles et les coordonnées des personnes à contacter pour la présentation des rapports dans les 24 heures, les 72 heures et le rapport final.
- Un plan de communication couvrant la notification interne (conseil d’administration, service juridique, relations publiques) et la notification externe (CCB, DPA, tiers concernés).
- Preuves de tests réguliers : rapports d’exercices sur table, résultats de simulations, dates de révision des procédures.
Votre liste de contrôle de conformité NIS2 couvre la préparation de l’audit au sens large, y compris les contrôles des rapports d’incidents que les organismes d’évaluation de la conformité s’attendent à voir documentés.
Rapports NIS2 vs GDPR vs DORA : quand se chevauchent-ils ?
Un seul incident cybernétique peut déclencher des obligations de déclaration en vertu de plusieurs règlements simultanément. Il ne s’agit pas d’un cas limite théorique. Une attaque de ransomware contre un hôpital qui crypte les dossiers des patients déclenche le NIS2 (interruption de service), le GDPR (violation de données à caractère personnel) et potentiellement des réglementations sectorielles en matière de santé. L’attaque par ransomware d’un hôpital belge au début de l’année a illustré exactement ce chevauchement.
| Aspect | NIS2 | GDPR | DORA |
|---|---|---|---|
| Focus | Disponibilité et intégrité des services | Confidentialité des données personnelles | Résilience opérationnelle des TIC (secteur financier) |
| Calendrier | Alerte précoce dans les 24 heures, notification dans les 72 heures, décision finale dans un délai d’un mois | Notification à l’autorité de protection des données dans les 72 heures | Varie en fonction de la gravité de l’incident ; les incidents majeurs liés aux TIC ont des délais spécifiques. |
| Autorité | CSIRT national / CCB (Belgique) | Autorité de protection des données | Régulateur financier (NBB/FSMA en Belgique, DNB aux Pays-Bas) |
| Champ d’application | Entités essentielles et importantes dans 18 secteurs | Toute organisation traitant des données à caractère personnel | Entités financières et leurs fournisseurs de TIC essentiels |
| Les relations | Cadre général | Fonctionne en parallèle ; notification séparée | Lex specialis pour le secteur financier ; prime sur le NIS2 pour les incidents liés aux TIC |
Pour les organisations de services financiers, la loi DORA prévaut généralement sur la loi NIS2 en tant que lex specialis. Mais les régulateurs belges et néerlandais ont confirmé qu’une double obligation de déclaration peut exister pour les incidents qui affectent à la fois la résilience des TIC et la sécurité générale du réseau. Si vous opérez dans le secteur des services financiers, le registre d’information DORA et les guides SASE pour les services financiers sous DORA couvrent en profondeur les exigences du secteur financier.
En pratique, il faut tenir un registre unique des incidents qui permette de suivre toutes les notifications dans le cadre de toutes les réglementations applicables. Horodatez chaque soumission. Veillez à ce que les faits que vous signalez à la DGCC, à l’autorité de protection des données et à votre autorité de réglementation financière soient cohérents. Les incohérences entre des notifications parallèles créent un risque juridique qui peut être évité. Une plateforme SASE comme Jimber génère les mêmes journaux d’événements horodatés pour les trois flux de rapports à partir d’une piste d’audit, de sorte que les faits dans votre alerte précoce NIS2, votre notification GDPR et votre rapport DORA sont toujours alignés.
FAQ
Combien de temps avez-vous pour signaler un incident NIS2 ?
Vous devez soumettre une alerte rapide dans les 24 heures qui suivent le moment où vous avez connaissance d’un incident important. Une notification détaillée de l’incident suit dans les 72 heures. Un rapport final comprenant une analyse des causes profondes doit être présenté dans un délai d’un mois. Si l’incident est toujours en cours au bout d’un mois, soumettez un rapport d’avancement et déposez le rapport final dans un délai d’un mois après la résolution de l’incident.
Que se passe-t-il si vous ne respectez pas le délai de 24 heures ?
Si vous ne notifiez pas votre autorité nationale dans les délais requis, vous vous exposez à des amendes administratives. Pour les entités essentielles en Belgique, les amendes peuvent atteindre 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Pour les entités importantes, le plafond est de 7 millions d’euros ou de 1,4 % du chiffre d’affaires. Outre les amendes, le CCB peut suspendre les certifications, rendre publique la non-conformité et, en cas de négligence répétée, restreindre temporairement les fonctions de direction. Le NIS2 responsabilité du conseil d’administration en Belgique couvre les implications de la responsabilité personnelle des administrateurs et des dirigeants.
Le rapport d’incident NIS2 fait-il double emploi avec le GDPR ?
Oui. Si un cyberincident implique des données à caractère personnel, vous devrez peut-être notifier à la fois votre CSIRT national (dans le cadre du NIS2) et votre autorité de protection des données (dans le cadre du GDPR) dans un délai de 72 heures. Les deux notifications ont des objectifs différents : NIS2 se concentre sur la continuité des services tandis que GDPR se concentre sur la protection des données. Préparez les deux soumissions en parallèle et assurez-vous que les faits rapportés sont cohérents.
Qui est responsable du rapport NIS2 en Belgique ?
Le Centre pour la cybersécurité en Belgique (CCB) est l’autorité compétente. Tous les incidents importants doivent être signalés via le portail Safeonweb@Work. CERT.be assure la coordination opérationnelle des incidents. C’est à l’organe de direction de l’organisation qu’il incombe de veiller à ce que les incidents soient signalés en temps utile. En vertu de la législation belge, les membres du conseil d’administration qui ne supervisent pas la mise en œuvre de la cybersécurité engagent leur responsabilité personnelle.
Quels sont les outils qui permettent de respecter le délai de 24 heures ?
La fenêtre de 24 heures exige une classification rapide des incidents, qui dépend de la visibilité centralisée de votre réseau, de vos terminaux et de vos applications en nuage. Une plateforme SASE comme Jimber consolide tous les journaux d’accès, les événements de politique et les alertes de sécurité dans une piste d’audit unique, réduisant ainsi le temps de classification de plusieurs heures à quelques minutes. Les outils SIEM peuvent remplir une fonction de corrélation similaire, mais les entreprises de taille moyenne trouvent souvent qu’une plateforme SASE unifiée fournit à la fois les contrôles de sécurité et la visibilité des logs sans la complexité d’un déploiement SIEM autonome.
Les organisations belges doivent-elles suivre la CyFun pour la notification des incidents ?
CyFun est le cadre de mise en œuvre de la CCB pour NIS2 en Belgique. Sa fonction de réponse (contrôle RS.RP, RS.CO, RS.AN, RS.MI) correspond directement aux exigences de déclaration de l’article 23. Les entités essentielles doivent obtenir au moins une vérification CyFun de base ou importante d’ici le 18 avril 2026. Même si votre organisation est classée comme importante plutôt qu’essentielle, la mise en œuvre des contrôles Respond fournit une approche structurée et vérifiable de la déclaration des incidents qui satisfait à la fois aux exigences du NIS2 et de la CyFun.
Le délai de déclaration de 24 heures récompense la préparation et non l’improvisation. Les organisations qui disposent d’un système d’enregistrement centralisé et d’une procédure d’établissement de rapports préétablie peuvent aisément respecter ce délai. Celles qui travaillent encore avec des outils déconnectés les uns des autres auront des difficultés à chaque fois. La plateforme SASE de Jimber fournit une piste d’audit unique, des alertes en temps réel et des journaux d’événements immuables qui transforment les rapports d’incidents NIS2 d’une course à la réglementation en un processus documenté et reproductible. Réservez une démonstration pour voir comment une visibilité consolidée rend la fenêtre de 24 heures gérable pour votre équipe.
