ILR — Notification NIS 2: 24 h pour alerter, votre SOC doit suivre

Excerpt. En juin 2026, l’ILR a publié un guide « Notification d’incident NIS 2 » détaillant l’alerte précoce sous 24 h, la notification à 72 h et le rapport final à 1 mois. Voici la pile SIEM/SOC qui permet d’y parvenir sans panique.

Les faits

Au Luxembourg, la loi du 5 mai 2026 transposant NIS 2 est entrée en vigueur le 10 mai 2026. Dans la foulée, l’Institut Luxembourgeois de Régulation (ILR) a mis en ligne un guide opérationnel sur la notification d’incident qui précise un processus en trois temps : alerte précoce « sans retard injustifié et au plus tard 24 heures » après détection, notification formelle à 72 heures, puis rapport final au plus tard un mois après la notification (avec possibilité d’extension d’un mois si l’incident n’est pas clôturé). Le site NIS 2 de l’ILR rappelle aussi que les entités essentielles et importantes doivent signaler les incidents via le portail central SERIMA et distingue clairement « détection » et « devenir conscient » d’un incident significatif (ILR – Incident notification ; ILR – FAQ NIS 2). Pour le cadre local et les attentes de l’autorité, voir NIS 2 au Luxembourg.

Pourquoi c’est critique aujourd’hui ? Parce que l’actualité le confirme : un incident majeur se mesure en heures, pas en semaines. L’attaque par ransomware contre CDK Global a ainsi paralysé des milliers de concessions automobiles en Amérique du Nord à partir du 18–19 juin 2024, avec un impact opérationnel massif et des tentatives de vishing opportunistes — un scénario qui, en Europe, déclencherait le cycle NIS 2 de 24 h/72 h/1 mois (BleepingComputer ; TechCrunch).

Le cadre légal qui s’applique

L’article 23 de la directive (UE) 2022/2555 (NIS 2) impose :

• Alerte précoce sous 24 h après être « devenu conscient » d’un incident significatif, même si l’impact n’est pas encore pleinement qualifié ;
• Notification sous 72 h mettant à jour la sévérité, l’impact et, si disponibles, les IoC ;
• Rapport final sous 1 mois (ou rapport intermédiaire si l’incident perdure).

L’ILR a traduit ces exigences en attentes pratiques et canaux de saisie (SERIMA), tout en rappelant la distinction clef entre l’occurrence technique et le moment de la prise de conscience qui démarre l’horloge réglementaire (ILR – Notification d’incident ; ILR – NIS 2 Act).

La solution technique à déployer

Pour tenir les 24 heures, il faut deux choses : voir vite et rassembler des preuves exploitables. Concrètement :

• SIEM managé + capteurs : agrégation en temps réel des logs/événements (EDR, pare-feu, VPN, AD/Entra, SaaS, IaaS), corrélation et détection par règles et modèles comportementaux. Standards : ISO/IEC 27001:2022 Annexe A 8.15 (journalisation), A 8.16 (surveillance), A 5.23 (gestion des incidents) ; NIST CSF 2.0 : Detect/DE.AE, Respond/RS.AN ; CIS Controls 8 : 8.2, 8.3, 17.4.
• Runbooks NIS 2 intégrés : playbooks qui extraient automatiquement, dès la qualification « significatif », les champs exigés pour l’alerte précoce : contexte, suspicion d’acte illicite, possible impact transfrontalier, périmètre touché. Puis un second jeu pour la « 72 h » (sévérité, disponibilité des IoC, mesures d’atténuation) et un troisième pour le « 1 mois » (chronologie, causes racines, leçons). Le mapping doit coller au formulaire SERIMA/ILR (ILR – Incident notification).
• Supervision 24/7 : sans équipe de garde, le délai tombe un weekend. Un SOC managé déclenche l’early warning dans le fuseau adéquat et sécurise la chaîne de décision.
• Gestion de preuves : rétention immuable des logs (WORM), time-stamping, hashage des exports, conservation des artefacts forensiques pour étayer la notification, l’enquête et le rapport final (ISO 27001 A 8.12, A 8.13).
• Catalogue de « significativité » : critères documentés pour décider rapidement si l’incident est « significatif » au sens NIS 2 (impact opérationnel/financier, dommages à des tiers, effets transfrontières). Les FAQ de l’ILR expliquent comment ancrer l’horloge à la détection consciente de cet état (ILR – FAQ).

Comment Luxgap déploie cela

• Notre SOC managed 24/7 : intégration de vos sources (EDR/XDR, cloud, réseau, IAM, SaaS), corrélation dans un SIEM de référence, et watch officers francophones en rotation. Nous configurons des use cases alignés NIS 2 Art. 23 et des timers d’escalade (T0 = « devenu conscient »), avec documentation horodatée pour l’ILR.
• Notre gouvernance ISO 27001 : nos lead implementers structurent vos procédures d’alerte 24 h/72 h/1 mois, vos critères de « significativité », les modèles d’early warning et de rapports finaux, et la chaîne RACI jusqu’au COMEX.
• Nos consultants DPO/CISO externalisés : coordination entre NIS 2 et autres cadres (p.ex. RGPD art. 33 : 72 h à l’autorité de protection des données, DORA pour les entités financières) afin d’éviter les incohérences de délais et de contenu. Pour le pilotage opérationnel, nos CISO externalisés alignent cybersécurité et exigences de reporting.

Cas concret au Luxembourg ou en UE

Une entreprise d’infrastructures numériques opérant au Luxembourg (entité « importante » NIS 2) nous sollicite après un incident d’authentification ayant dégradé un service client critique un samedi soir. En six semaines, nous :

1. déployons des collecteurs SIEM et intégrons les journaux VPN/SSO, pare-feu, SaaS et EDR ;
2. configurons des use cases NIS 2 Art. 23 et des playbooks « 24 h / 72 h / 1 mois » ;
3. mettons en place une astreinte SOC 24/7 et une procédure d’early warning ILR (SERIMA) ;
4. testons, en exercice, un enchaînement détection → qualification « significatif » → alerte 24 h avec contenu minimal exigé, puis notification 72 h avec IoC.

Résultat : lors d’un véritable incident ultérieur (compte cloud compromis un dimanche), l’early warning est parti à H+6 via le SOC, la notification « 72 h » a consolidé les IoC et actions de remédiation, et le rapport final (J+30) a aligné causes racines et mesures correctives, répondant point par point au canevas ILR.

Premiers pas concrets

• Cartographier vos signaux : identifiez, cette semaine, les 10 sources d’événements qui « font foi » (EDR, SSO, VPN, pare-feu, M365/Entra, Google Workspace, AWS/Azure/GCP, ERP/CRM, IDS, DLP) et branchez-les au SIEM.
• Décider l’ancre temporelle : formalisez par écrit ce qui déclenche le T0 (« devenu conscient » d’un incident significatif) et qui a l’autorité pour qualifier « significatif ». Alignez-vous sur la FAQ ILR sur la détection vs prise de conscience.
• Pré-remplir les gabarits ILR : créez des modèles d’early warning, de notification 72 h et de rapport final, mappés aux champs SERIMA, et intégrez-les à vos playbooks.
• Tester un weekend : exécutez un exercice un samedi : en < 12 heures, le SOC doit déclencher l’alerte, agréger les éléments minimaux (périmètre, suspicion de malveillance, effets transfrontières potentiels) et soumettre une ébauche au management.
• Assurer la preuve : activez la rétention WORM des journaux critiques et documentez la chain of custody pour soutenir le rapport final d’un mois.

Sources officielles

• ILR — La notification d’incident sous NIS 2 (24 h / 72 h / 1 mois)
• ILR — Incident notification (SERIMA, définitions et délais)
• ILR — FAQ NIS 2 (détection vs prise de conscience, périmètre ILR)
• EUR‑Lex — Directive (UE) 2022/2555 (NIS 2), art. 23 « Obligations de notification »
• BleepingComputer — CDK Global outage caused by BlackSuit ransomware
• TechCrunch — US car dealerships face ongoing outage after CDK cyberattacks