{"id":12945,"date":"2026-04-17T09:00:57","date_gmt":"2026-04-17T07:00:57","guid":{"rendered":"https:\/\/jimber.io\/?p=12945"},"modified":"2026-04-17T09:00:57","modified_gmt":"2026-04-17T07:00:57","slug":"rapport-dincident-nis2-delais-modeles-et-etapes-pratiques","status":"publish","type":"post","link":"https:\/\/jimber.io\/fr\/blog\/rapport-dincident-nis2-delais-modeles-et-etapes-pratiques\/","title":{"rendered":"Rapport d’incident NIS2 : d\u00e9lais, mod\u00e8les et \u00e9tapes pratiques"},"content":{"rendered":"

Dans quel d\u00e9lai devez-vous signaler un incident NIS2 ?<\/h2>\n

L’article 23 de la NIS2 impose une proc\u00e9dure de notification en trois \u00e9tapes 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\u00e9taill\u00e9e de l’incident suit dans les 72 heures. Un rapport final, comprenant une analyse des causes profondes et des mesures correctives, doit \u00eatre pr\u00e9sent\u00e9 dans un d\u00e9lai d’un mois. Si vous ne respectez pas le d\u00e9lai de 24 heures, votre organisation s’expose \u00e0 des mesures d’application, \u00e0 des amendes et \u00e0 une responsabilit\u00e9 personnelle potentielle des membres du conseil d’administration. <\/p>\n

\n

NIS2 est la directive de l’UE qui impose des obligations en mati\u00e8re de cybers\u00e9curit\u00e9 aux organisations de 18 secteurs, dont l’\u00e9nergie, les soins de sant\u00e9, les transports, l’industrie manufacturi\u00e8re et les services num\u00e9riques. En Belgique, la loi est active depuis octobre 2024 et s’applique aux entit\u00e9s comptant 50 employ\u00e9s ou plus, ou dont le chiffre d’affaires annuel est sup\u00e9rieur \u00e0 10 millions d’euros. De toutes les exigences du NIS2, c’est le rapport d’incident qui comporte les d\u00e9lais les plus serr\u00e9s et la pression op\u00e9rationnelle la plus imm\u00e9diate. Pour avoir une vue d’ensemble de ce que NIS2 signifie pour les \u00e9quipes du mid-market, consultez notre aper\u00e7u de la conformit\u00e9 NIS2<\/a>. <\/p>\n<\/div>\n

L’alerte rapide dans les 24 heures est le d\u00e9lai qui fait d\u00e9faut \u00e0 la plupart des organisations du march\u00e9 interm\u00e9diaire. Ce n’est pas par manque de volont\u00e9 de signaler les incidents, mais parce qu’elles n’ont pas la visibilit\u00e9 n\u00e9cessaire pour les classer assez rapidement. Lorsque vos journaux sont dispers\u00e9s dans cinq outils distincts, le simple fait de confirmer si un \u00e9v\u00e9nement peut \u00eatre qualifi\u00e9 de \u00ab\u00a0significatif\u00a0\u00bb peut absorber toute la fen\u00eatre. La journalisation centralis\u00e9e change cette \u00e9quation. Une piste d’audit unique qui met en corr\u00e9lation les \u00e9v\u00e9nements d’acc\u00e8s, les violations de r\u00e8gles et les alertes de s\u00e9curit\u00e9 vous permet de passer de la d\u00e9tection \u00e0 la classification en quelques minutes plut\u00f4t qu’en quelques heures. <\/p>\n

Ce guide d\u00e9crit en d\u00e9tail les trois phases de notification, explique le contenu de chaque notification, couvre les proc\u00e9dures de notification belges, n\u00e9erlandaises et britanniques, et fournit un processus de r\u00e9ponse aux incidents \u00e9tape par \u00e9tape que vous pouvez adapter \u00e0 votre organisation.<\/p>\n

Ce qu’exige l’article 23 du NIS2<\/h2>\n

L’article 23 remplace les termes vagues \u00ab\u00a0sans retard excessif\u00a0\u00bb de la directive NIS initiale par trois \u00e9ch\u00e9ances pr\u00e9cises. Chaque phase a un objectif diff\u00e9rent et les informations requises \u00e0 chaque \u00e9tape sont d\u00e9lib\u00e9r\u00e9ment diff\u00e9rentes. <\/p>\n

\n\n\n\n\n\n\n\n
Phase<\/th>\nDate limite<\/th>\nObjectif<\/th>\nCe qu’il faut inclure<\/th>\n<\/tr>\n<\/thead>\n
Alerte pr\u00e9coce<\/td>\n24 heures apr\u00e8s la prise de conscience<\/td>\nAlerter les autorit\u00e9s que quelque chose est en train de se passer<\/td>\nConfirmation d’un incident important, cause malveillante pr\u00e9sum\u00e9e (oui\/non), impact transfrontalier potentiel, premi\u00e8res mesures d’endiguement<\/td>\n<\/tr>\n
Notification de l’incident<\/td>\n72 heures apr\u00e8s la prise de conscience<\/td>\nFournir des d\u00e9tails valid\u00e9s pour une r\u00e9ponse coordonn\u00e9e<\/td>\n\u00c9valuation de la gravit\u00e9, indicateurs de compromission (IOC), nombre d’utilisateurs touch\u00e9s, \u00e9tat des mesures correctives, analyse de l’impact sectoriel.<\/td>\n<\/tr>\n
Rapport final<\/td>\n1 mois apr\u00e8s la notification des 72 heures<\/td>\nRegistre permanent de responsabilit\u00e9<\/td>\nAnalyse compl\u00e8te des causes profondes, chronologie des \u00e9v\u00e9nements, mesures correctives permanentes, le\u00e7ons tir\u00e9es de l’exp\u00e9rience.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Le d\u00e9lai commence \u00e0 courir lorsque votre organisation \u00ab\u00a0prend conscience\u00a0\u00bb que l’incident r\u00e9pond aux crit\u00e8res d’importance. Pas lorsque l’attaque a commenc\u00e9. Pas lorsque vous avez termin\u00e9 votre enqu\u00eate. La fen\u00eatre de 24 heures s’ouvre d\u00e8s que vous disposez de suffisamment d’informations pour classer l’\u00e9v\u00e9nement comme significatif. <\/p>\n

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\u00e9solution de l’incident. <\/p>\n

Un d\u00e9tail qui prend les organisations au d\u00e9pourvu : L’article 23, paragraphe 5, exige que l’autorit\u00e9 destinataire r\u00e9ponde \u00e0 votre alerte rapide dans les 24 heures, si possible, et qu’elle fournisse des conseils initiaux sur les mesures d’att\u00e9nuation. Il ne s’agit pas d’une voie \u00e0 sens unique. L’autorit\u00e9 est cens\u00e9e vous aider, en particulier si l’incident a des implications transfrontali\u00e8res. <\/p>\n

Qu’est-ce qu’un incident significatif ?<\/h2>\n

L’obligation de notification ne s’applique pas \u00e0 tous les \u00e9v\u00e9nements li\u00e9s \u00e0 la s\u00e9curit\u00e9. L’article 23, paragraphe 3, d\u00e9finit un incident significatif comme un incident qui atteint un seuil qualitatif ou quantitatif. <\/p>\n

Perturbation op\u00e9rationnelle.<\/strong> L’incident a caus\u00e9 ou pourrait causer une grave perturbation des services que vous fournissez. Une attaque par ransomware qui crypte les syst\u00e8mes de production remplit les conditions requises. Une tentative d’hame\u00e7onnage rat\u00e9e que vos filtres ont d\u00e9tect\u00e9e ne l’est pas. <\/p>\n

Perte financi\u00e8re.<\/strong> L’incident a caus\u00e9 ou pourrait causer des pertes financi\u00e8res importantes. Les co\u00fbts directs, les frais de recouvrement, les pertes de revenus et les p\u00e9nalit\u00e9s contractuelles sont tous pris en compte. <\/p>\n

Dommages aux tiers.<\/strong> L’incident a affect\u00e9 ou pourrait affecter d’autres personnes ou organisations. Les violations de donn\u00e9es qui exposent des informations personnelles ou les perturbations de la cha\u00eene d’approvisionnement qui se r\u00e9percutent sur vos clients entrent dans cette cat\u00e9gorie. <\/p>\n

Intention malveillante.<\/strong> Les activit\u00e9s suspect\u00e9es d’\u00eatre parrain\u00e9es par un \u00c9tat, l’espionnage ou les attaques susceptibles d’avoir un impact transfrontalier sont trait\u00e9s en priorit\u00e9 \u00e0 des fins d’alerte rapide.<\/p>\n

Le r\u00e8glement d’ex\u00e9cution 2024\/2690 de la Commission europ\u00e9enne ajoute des seuils techniques sp\u00e9cifiques pour les fournisseurs d’infrastructures num\u00e9riques tels que les services en nuage, les centres de donn\u00e9es et les op\u00e9rateurs DNS. Pour la plupart des entreprises de taille moyenne, le test pratique est simple : si l’incident perturbe vos services, compromet des donn\u00e9es personnelles ou risque de s’\u00e9tendre \u00e0 d’autres organisations, il est significatif et le d\u00e9lai commence \u00e0 courir. <\/p>\n

Construisez votre matrice de classification interne autour de ces quatre crit\u00e8res avant qu’un incident ne se produise. Lorsqu’une alerte se d\u00e9clenche \u00e0 2 heures du matin, votre ing\u00e9nieur de garde ne doit pas avoir \u00e0 interpr\u00e9ter un texte r\u00e9glementaire. Il a besoin d’un arbre de d\u00e9cision d’une page qui lui dise : significatif ou non significatif, signaler ou surveiller. Les plateformes comme Jimber simplifient cette \u00e9tape car chaque d\u00e9cision d’acc\u00e8s, violation de politique et alerte de s\u00e9curit\u00e9 passe d\u00e9j\u00e0 par un plan de contr\u00f4le unique. L’ing\u00e9nieur voit l’utilisateur concern\u00e9, l’\u00e9tat de la posture de l’appareil et la port\u00e9e de l’\u00e9v\u00e9nement en une seule vue, plut\u00f4t que d’extraire des donn\u00e9es de trois consoles avant qu’une classification ne soit possible. <\/p>\n

O\u00f9 faire une d\u00e9claration en Belgique, aux Pays-Bas et au Royaume-Uni ?<\/h2>\n

Belgique<\/h3>\n

Le Centre pour la cybers\u00e9curit\u00e9 en Belgique (CCB) est l’autorit\u00e9 nationale. Tous les incidents NIS2 importants doivent \u00eatre signal\u00e9s via le portail Safeonweb@Work<\/a>. CERT.be, la branche op\u00e9rationnelle du CCB, assure la coordination des incidents et peut fournir une assistance technique lors d’incidents actifs. <\/p>\n

), la date et l’heure exactes de la d\u00e9tection, une description de la mani\u00e8re dont vous avez d\u00e9tect\u00e9 l’\u00e9v\u00e9nement, une \u00e9valuation pr\u00e9liminaire de l’impact, si des effets transfrontaliers sont suspect\u00e9s, et la confirmation que l’authentification multifactorielle \u00e9tait active sur les syst\u00e8mes affect\u00e9s.<\/p>\n

La Belgique a \u00e9t\u00e9 l’un des premiers \u00c9tats membres de l’UE \u00e0 transposer le NIS2 en droit national le 26 avril 2024. Les obligations de d\u00e9claration d’incidents sont actives depuis le 18 octobre 2024. Il ne s’agit pas d’une exigence future. Elle s’applique d\u00e8s \u00e0 pr\u00e9sent. <\/p>\n

Pour les organisations travaillant dans le cadre des CyberFundamentals (CyFun), les rapports d’incidents rel\u00e8vent directement de la fonction Respond. Le contr\u00f4le RS.CO (Communications) de la CyFun exige un processus document\u00e9 pour le signalement \u00e0 la fois \u00e0 la direction interne et aux autorit\u00e9s externes, y compris la DGCC. Le guide d’auto-\u00e9valuation de la CyFun<\/a> couvre ces contr\u00f4les en d\u00e9tail. L’outil de conformit\u00e9 CRACy<\/a> de Jimber compare votre configuration existante aux contr\u00f4les Respond, en montrant o\u00f9 votre proc\u00e9dure de rapport d’incident r\u00e9pond d\u00e9j\u00e0 aux exigences de la CyFun et o\u00f9 des lacunes subsistent. <\/p>\n

Les Pays-Bas<\/h3>\n

Le NCSC-NL (Nationaal Cyber Security Centrum) sert de CSIRT principal pour les entit\u00e9s essentielles. Les Pays-Bas ont activ\u00e9 leur Cyberbeveiligingswet (loi sur la cybers\u00e9curit\u00e9) au premier trimestre 2026, transposant le NIS2 dans la l\u00e9gislation n\u00e9erlandaise. Les rapports suivent la m\u00eame cadence de 24\/72\/1 mois par l’interm\u00e9diaire du portail du NCSC. <\/p>\n

Royaume-Uni<\/h3>\n

Le Royaume-Uni applique ses propres r\u00e9glementations NIS 2018 (telles que modifi\u00e9es), qui sont ant\u00e9rieures \u00e0 NIS2 et dont le champ d’application diff\u00e8re. Le gouvernement britannique a propos\u00e9 des mises \u00e0 jour pour s’aligner plus \u00e9troitement sur le NIS2, mais le cadre actuel utilise des autorit\u00e9s comp\u00e9tentes sectorielles plut\u00f4t qu’un portail national unique. V\u00e9rifiez aupr\u00e8s de l’autorit\u00e9 de r\u00e9gulation de votre secteur la proc\u00e9dure de d\u00e9claration applicable. <\/p>\n

Comment respecter le d\u00e9lai de 24 heures<\/h2>\n

C’est ici que la th\u00e9orie rencontre la r\u00e9alit\u00e9 op\u00e9rationnelle. La fen\u00eatre de 24 heures semble \u00e9troite. Pour les organisations disposant d’une visibilit\u00e9 centralis\u00e9e, elle est tout \u00e0 fait g\u00e9rable. Pour les organisations qui collectent encore manuellement des journaux \u00e0 partir de pare-feux, d’outils pour terminaux et d’applications en nuage distincts, c’est presque impossible. <\/p>\n

Le probl\u00e8me ne r\u00e9side pas dans la r\u00e9daction du rapport. L’alerte pr\u00e9coce est d\u00e9lib\u00e9r\u00e9ment l\u00e9g\u00e8re : confirmer l’incident, indiquer s’il semble malveillant, noter le risque transfrontalier, d\u00e9crire le confinement initial. Vous pouvez remplir ce formulaire en 30 minutes. <\/p>\n

Le probl\u00e8me est d’atteindre le point o\u00f9 vous pouvez dire en toute confiance \u00ab\u00a0oui, c’est important\u00a0\u00bb dans les premi\u00e8res heures. Pour cela, il faut corr\u00e9ler des donn\u00e9es provenant de sources multiples afin de comprendre ce qui s’est pass\u00e9, ce qui a \u00e9t\u00e9 touch\u00e9 et jusqu’o\u00f9 l’incident s’est propag\u00e9. <\/p>\n

Pourquoi l’exploitation foresti\u00e8re dispers\u00e9e ne respecte pas la date limite.<\/strong> Dans une configuration typique de march\u00e9 interm\u00e9diaire, les journaux de pare-feu se trouvent dans une console, les alertes de points d’extr\u00e9mit\u00e9 dans une autre, les journaux d’applications en nuage dans une troisi\u00e8me et les enregistrements d’acc\u00e8s VPN dans une toute autre. Extraire les donn\u00e9es de chaque syst\u00e8me, normaliser les horodatages et recouper les \u00e9v\u00e9nements manuellement est un exercice de plusieurs heures avant m\u00eame 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\u00eame les \u00e9quipes les mieux dot\u00e9es en ressources ne parviennent que rarement \u00e0 effectuer le triage initial en moins de 8 heures lorsqu’elles travaillent avec des outils d\u00e9connect\u00e9s les uns des autres. <\/p>\n

Comment l’enregistrement centralis\u00e9 r\u00e9sout le probl\u00e8me.<\/strong> Lorsque toutes les d\u00e9cisions d’acc\u00e8s, l’activit\u00e9 du r\u00e9seau et les alertes de s\u00e9curit\u00e9 passent par une plateforme unique, la corr\u00e9lation se fait automatiquement. Une connexion anormale \u00e0 partir d’un lieu inconnu, suivie d’un mouvement lat\u00e9ral vers un serveur de fichiers, puis d’une tentative d’exfiltration de donn\u00e9es, appara\u00eet comme une s\u00e9quence connect\u00e9e plut\u00f4t que comme trois alertes isol\u00e9es dans trois tableaux de bord distincts. <\/p>\n

La console de gestion unique de Jimber met en corr\u00e9lation les \u00e9v\u00e9nements d’acc\u00e8s, les violations de politique et les alertes de s\u00e9curit\u00e9 dans une piste d’audit unique. Comme tout le trafic passe par le plan de contr\u00f4le SASE, le chemin complet de l’attaque est visible \u00e0 partir d’une seule interface : le point d’entr\u00e9e initial, le mouvement lat\u00e9ral, les syst\u00e8mes et les donn\u00e9es affect\u00e9s. Cela permet \u00e0 votre responsable de la s\u00e9curit\u00e9 de d\u00e9terminer si un incident atteint le seuil d’importance en quelques minutes plut\u00f4t qu’en quelques heures, transformant le d\u00e9lai de 24 heures d’une course effr\u00e9n\u00e9e en un processus structur\u00e9. <\/p>\n

La m\u00eame piste d’audit g\u00e9n\u00e8re les preuves horodat\u00e9es et immuables dont le rapport final a besoin un mois plus tard. Les plateformes telles que Jimber produisent des journaux contr\u00f4l\u00e9s par version de chaque d\u00e9cision d’acc\u00e8s et de chaque changement de politique, qui peuvent \u00eatre export\u00e9s directement vers le portail de reporting de la BCC. Pas d’agr\u00e9gation manuelle des journaux. Pas de lacunes dans les preuves. <\/p>\n

Conseil pratique.<\/strong> Organisez un exercice sur table simulant un incident de ransomware. D\u00e9marrez le chronom\u00e8tre lorsque la premi\u00e8re alerte se d\u00e9clenche. Suivez le temps qu’il faut \u00e0 votre \u00e9quipe pour confirmer l’importance de l’information en utilisant vos outils actuels. Si vous ne parvenez pas \u00e0 prendre une d\u00e9cision de classification dans les 4 heures, vous avez un probl\u00e8me de visibilit\u00e9 que les am\u00e9liorations de processus ne suffiront pas \u00e0 r\u00e9soudre. <\/p>\n

\u00c9laborer votre proc\u00e9dure de signalement des incidents<\/h2>\n

Une proc\u00e9dure document\u00e9e que votre \u00e9quipe peut suivre sous pression vaut plus que n’importe quel diagramme. Voici un flux de travail \u00e9tape par \u00e9tape, structur\u00e9 autour des phases du rapport NIS2. <\/p>\n

\u00c9tape 1 : D\u00e9tection et triage (heures 0 \u00e0 2)<\/h3>\n

Vos syst\u00e8mes de surveillance signalent une anomalie. L’ing\u00e9nieur d’astreinte v\u00e9rifie l’alerte par rapport \u00e0 votre matrice de classification. Dans un environnement SASE consolid\u00e9 comme Jimber, cette alerte contient d\u00e9j\u00e0 l’identit\u00e9 de l’utilisateur, l’\u00e9tat de la posture de l’appareil et les ressources acc\u00e9d\u00e9es, ce qui donne \u00e0 l’ing\u00e9nieur le contexte n\u00e9cessaire pour classifier en quelques minutes plut\u00f4t qu’en quelques heures. Questions cl\u00e9s \u00e0 ce stade : la disponibilit\u00e9 du service est-elle affect\u00e9e ? Les donn\u00e9es personnelles sont-elles potentiellement compromises ? L’incident semble-t-il malveillant ? Peut-il affecter d’autres organisations ? <\/p>\n

Si l’une des r\u00e9ponses est \u00ab\u00a0oui\u00a0\u00bb ou \u00ab\u00a0probablement oui\u00a0\u00bb, classez-la comme significative et lancez l’horloge des 24 heures.<\/p>\n

\u00c9tape 2 : Contenir et intensifier (heures 2 \u00e0 6)<\/h3>\n

Isoler les syst\u00e8mes affect\u00e9s. D\u00e9sactiver les comptes compromis. Bloquez les adresses IP malveillantes. Faites remonter simultan\u00e9ment l’information \u00e0 votre responsable de la r\u00e9ponse aux incidents et \u00e0 votre contact juridique\/conformit\u00e9. Les personnes qui \u00e9mettront l’alerte rapide doivent \u00eatre inform\u00e9es maintenant, et non \u00e0 l’heure 22. <\/p>\n

\u00c9tape 3 : Introduction de l’alerte pr\u00e9coce (heure 6-24)<\/h3>\n

R\u00e9digez et envoyez la notification 24 heures sur 24 via le portail Safeonweb@Work (Belgique), le portail NCSC (Pays-Bas) ou le r\u00e9gulateur de votre secteur (Royaume-Uni). N’indiquez que ce que vous savez \u00e0 ce stade. La DGCCRF pr\u00e9f\u00e8re un \u00ab\u00a0inconnu\u00a0\u00bb honn\u00eate dans un d\u00e9lai raisonnable \u00e0 un rapport d\u00e9taill\u00e9 soumis \u00e0 l’heure 25. <\/p>\n

\u00c9tape 4 : Enqu\u00eater et recueillir des preuves (heures 24 \u00e0 72)<\/h3>\n

Utilisez vos journaux centralis\u00e9s pour reconstituer la chronologie de l’attaque. Identifiez les indicateurs de compromission : adresses IP, hachages de fichiers, vuln\u00e9rabilit\u00e9s exploit\u00e9es. Quantifiez l’impact : nombre d’utilisateurs, de syst\u00e8mes, d’enregistrements de donn\u00e9es touch\u00e9s. \u00c9valuez si l’incident a des r\u00e9percussions sur le secteur ou la cha\u00eene d’approvisionnement. <\/p>\n

\u00c9tape 5 : Soumettre la notification de 72 heures (heures 48-72)<\/h3>\n

Cette mise \u00e0 jour doit contenir des d\u00e9tails techniques valid\u00e9s. L’\u00e9valuation de la gravit\u00e9, les CIO, les mesures de rem\u00e9diation prises et une analyse de l’incidence \u00e9ventuelle de l’incident sur d’autres organisations ou secteurs. Si vous avez \u00e9galement une obligation de notification GDPR (donn\u00e9es personnelles concern\u00e9es), synchronisez les soumissions 72 heures pour plus de coh\u00e9rence. <\/p>\n

\u00c9tape 6 : Analyse des causes profondes et rapport final (semaine 1-4)<\/h3>\n

Une fois l’incident ma\u00eetris\u00e9, proc\u00e9dez \u00e0 une analyse r\u00e9trospective. Identifiez la cause premi\u00e8re, documentez la chronologie compl\u00e8te de l’incident et d\u00e9crivez les mesures permanentes que vous mettez en \u0153uvre pour \u00e9viter que l’incident ne se reproduise. Soumettez le rapport final dans un d\u00e9lai d’un mois. <\/p>\n

Que pr\u00e9parer avant qu’un incident ne se produise ?<\/h3>\n

Le fait de disposer de ces \u00e9l\u00e9ments avant d’en avoir besoin permet de gagner des heures lors d’un incident r\u00e9el :<\/p>\n