Dimanche, 22h40. Une alerte tombe sur le téléphone de l'administrateur système : des fichiers se chiffrent sur un serveur de fichiers. Il isole le serveur en vingt minutes. Beau réflexe.
Puis les vraies questions arrivent, et aucune n'est technique. Est-ce que c'est un incident « significatif » au sens de NIS2 ? Qui décide, un dimanche soir ? Qui possède les accès au portail du CCB ? Et à quelle heure, exactement, l'entreprise a-t-elle « pris connaissance » de l'incident ?
Lundi 9h, tout le monde est autour de la table. Il s'est écoulé trente-quatre heures. La première échéance légale est dépassée depuis dix heures.
En bref
- NIS2 impose trois échéances pour un incident significatif : alerte précoce sous 24 heures, notification sous 72 heures, rapport final sous un mois.
- Le délai court à partir du moment où l'entité a pris connaissance de l'incident, pas du moment où l'attaque a commencé.
- En Belgique, les notifications passent par le Centre pour la Cybersécurité Belgique (CCB), qui héberge le CSIRT national.
- Ce qui fait rater le délai n'est presque jamais technique : c'est l'absence de critère de qualification décidé à l'avance et de responsable joignable le week-end.
Qu'est-ce qu'un incident « significatif » ?
La directive fixe deux critères, et un seul suffit. Un incident est significatif s'il a causé ou est susceptible de causer une perturbation opérationnelle grave des services ou des pertes financières pour l'entité, ou s'il a affecté ou est susceptible d'affecter d'autres personnes en causant des dommages matériels ou immatériels considérables.
Deux mots méritent l'attention. « Susceptible » d'abord : vous n'avez pas à attendre que le dommage se matérialise. Et « considérables » ensuite : c'est une appréciation, ce qui signifie qu'elle doit être préparée à froid, pas improvisée à 23h un dimanche par des gens fatigués qui ont peur de déclencher une procédure pour rien.
Les trois échéances
- Alerte précoce — 24 heures. Un signalement court, qui indique notamment si l'incident est soupçonné d'être causé par un acte malveillant et s'il pourrait avoir un impact transfrontalier. Ce n'est pas un rapport : c'est un signal. Il n'exige ni cause racine, ni périmètre complet.
- Notification d'incident — 72 heures. Elle actualise l'alerte précoce et ajoute une évaluation initiale : gravité, impact, et les indicateurs de compromission lorsqu'ils sont disponibles.
- Rapport final — un mois après la notification. Description détaillée, type de menace ou cause racine, mesures d'atténuation appliquées et en cours, impact transfrontalier le cas échéant. Si l'incident est toujours en cours à cette échéance, un rapport d'avancement est transmis, et le rapport final suit dans le mois qui suit la clôture du traitement.
Entre les deux premières échéances, l'autorité compétente ou le CSIRT peut demander un rapport intermédiaire. Et selon les cas, vous pouvez également devoir informer les destinataires de vos services.
Le piège : le chronomètre part de la prise de connaissance
C'est le point que presque tout le monde comprend de travers. Les 24 heures ne partent pas du début de l'attaque, ni de la réunion de crise du lundi matin. Elles partent du moment où l'entité a pris connaissance de l'incident.
Ce qui déplace le problème là où on ne le cherchait pas : à quelle heure votre organisation est-elle réputée avoir su ? Si une alerte est arrivée sur le téléphone d'un administrateur à 22h40, la réponse par défaut est 22h40. Le seul moyen de maîtriser cette date, c'est de l'horodater vous-même, dans un registre, au moment où elle se produit.
Les cinq choses qui font rater le délai
- Aucun critère de qualification écrit. Personne ne veut décider seul qu'un incident est « significatif », alors tout le monde attend une réunion.
- Aucun responsable désigné hors heures ouvrables. L'incident arrive un vendredi soir dans deux cas sur trois, et ce n'est pas un hasard.
- Aucun accès au portail de notification. L'enregistrement auprès du CCB et les comptes d'accès se préparent en temps calme, pas pendant la crise.
- Aucun horodatage fiable. Sans registre, vous ne pouvez ni démontrer que vous avez notifié à temps, ni dater votre prise de connaissance.
- Aucun modèle de notification. Rédiger la première communication officielle de l'entreprise sous stress, à partir d'une page blanche, coûte plusieurs heures.
Ce qu'il faut avoir prêt : une page
La bonne nouvelle, c'est que la préparation ne demande pas un projet. Elle tient sur une page affichée là où les gens la trouveront, et elle répond à six questions : qui qualifie l'incident, selon quels critères, qui notifie, par quel canal et avec quels accès, où se trouve le registre, et qui prévient la direction.
Une entreprise qui a cette page tient les 24 heures. Une entreprise qui ne l'a pas les tiendra par chance, une fois.
Comment Prism GRC structure la réponse dans Odoo
Prism GRC est un module Odoo natif. Le journal d'incidents n'est pas un tableur de plus : il est relié aux actifs, aux risques et aux contrôles déjà cartographiés. Concrètement :
- L'enregistrement de l'incident horodaté dès la prise de connaissance, avec son auteur, ce qui fixe et documente le point de départ du délai.
- Les critères de qualification intégrés au formulaire, pour que la décision « significatif ou non » soit guidée et tracée, pas laissée à l'appréciation du moment.
- Les échéances 24h / 72h / un mois calculées automatiquement, avec responsable et relance, de sorte que personne n'ait à se souvenir du calendrier pendant une crise.
- L'analyse des causes racines et les actions correctives rattachées à l'incident, ce qui alimente directement le rapport final.
- Le lien vers les actifs concernés, pour faire apparaître les récurrences : trois incidents sur le même actif en six mois, c'est un contrôle qui ne tient pas.
- Le chatter Odoo qui conserve la chronologie complète des échanges et des décisions, exactement ce qu'un auditeur demandera ensuite.
Questions fréquentes
Faut-il notifier un incident qui n'a finalement pas eu d'impact ?
Le critère inclut ce qui est susceptible de causer une perturbation grave. Une tentative bloquée n'entre généralement pas dans le champ, mais une compromission contenue de justesse peut y entrer. C'est précisément pour ces cas-là qu'il faut des critères écrits à l'avance : la décision doit pouvoir s'expliquer après coup.
Qui doit notifier en Belgique ?
Les entités essentielles et importantes au sens de la loi belge de transposition de NIS2, qui doivent par ailleurs être enregistrées auprès du CCB. Si vous ignorez votre classification, c'est le premier sujet à traiter, avant la procédure d'incident.
Une cyberassurance dispense-t-elle de notifier ?
Non. Ce sont deux obligations distinctes, avec deux interlocuteurs et deux calendriers différents. Votre assureur a aussi ses propres délais de déclaration, souvent courts : les deux circuits se préparent ensemble.
Passez à l'action
Prism Technology est partenaire Odoo officiel en Belgique, basé en Brabant wallon. Nous avons développé Prism GRC, un module natif Odoo pour piloter les risques, les contrôles, les incidents et la conformité. En 30 minutes, nous parcourons votre procédure de notification telle qu'elle existe aujourd'hui, et nous identifions ce qui vous ferait dépasser les 24 heures.
👉 Réservez votre démo de 30 minutes — Contactez-nous
