Traitement des incidents NIS2 : pourquoi l'article 21(2)(b) fait échouer plus d'audits que l'article 23
Une analyste sécurité d'un prestataire de services managés néerlandais repère un trafic sortant anormal depuis le serveur de fichiers d'un client, samedi à 02h14. Elle ouvre un ticket, le marque « à examiner » et reprend sa file d'attente. Le responsable de compte le lit lundi à 09h30, appelle le client, et quelqu'un pose enfin la question qui compte : est-ce notifiable ?
À cet instant, la fenêtre de 24 heures pour l'alerte précoce est fermée depuis 31 heures.
Ce n'est pas un échec de notification. C'est un échec de traitement des incidents NIS2 — article 21(2)(b) — et c'est la mesure qui décide silencieusement si toutes les autres échéances de la directive sont atteignables.
L'article 23 attire l'attention. L'article 21(2)(b) détermine si vous le respectez
La plupart des discussions de conformité commencent par l'horloge de notification : 24 heures, 72 heures, un mois. Ces délais viennent de l'article 23. Ils sont visibles, quantifiables et faciles à mettre sur une diapositive.
L'article 21(2)(b) est la mesure qui les soutient. Il exige un traitement des incidents — un processus documenté et éprouvé de détection, analyse, confinement, réponse et rétablissement.
La relation est à sens unique. On ne notifie pas un incident qu'on n'a pas classifié. On ne classifie pas un incident que personne n'a escaladé. Et on n'escalade pas un incident qui dort tout un week-end dans une file de tickets étiquetée « à examiner ».
Quand une autorité de contrôle constate un délai de 24 heures dépassé, elle ne s'arrête pas au délai. Elle demande comment l'entité a eu connaissance, qui a décidé et selon quels critères. Cette ligne de questions atterrit directement sur l'article 21(2)(b) — et n'y trouve généralement rien d'écrit.
Ce que le texte contraignant exige réellement
L'article 21(2)(b) de la directive tient en une ligne. Le détail se trouve dans le règlement d'exécution (UE) 2024/2690 de la Commission, directement applicable dans les 27 États membres, sans transposition nationale.
Le CIR lie une liste précise de types d'entités : fournisseurs de services DNS, registres de noms de domaine de premier niveau, fournisseurs de services d'informatique en nuage, fournisseurs de services gérés et de services de sécurité gérés, places de marché en ligne, moteurs de recherche en ligne, plateformes de réseaux sociaux et prestataires de services de confiance. Si vous exploitez un MSP ou un MSSP, vous figurez sur cette liste — non comme fournisseur, mais comme entité réglementée à part entière. Nous avons traité cette double obligation dans NIS2 pour les MSP et MSSP.
Pour tous les autres — énergie, santé, transport, industrie, administration publique — le CIR n'est pas formellement contraignant, mais il constitue l'énoncé le plus autorisé de ce que signifie « approprié et proportionné ». Partez du principe que votre régulateur le lira ainsi, faute de meilleure référence.
Le point 3 de l'annexe du CIR couvre le traitement des incidents. Il exige une politique et des procédures de détection, analyse, confinement, réponse et rétablissement ; des rôles et responsabilités définis ; la journalisation ; des voies d'escalade et de communication ; et une revue post-incident structurée qui réinjecte les enseignements dans les autres mesures.
C'est cette dernière clause que les équipes sautent. Le traitement des incidents n'est pas une boucle qui se referme au rétablissement du système. C'est une entrée pour votre analyse de risque, votre programme de formation et votre évaluation d'efficacité au titre de l'article 21(2)(f).
Article 21 — 10 Mesures de Cybersécurité NIS2
Article 21
10 Mesures de Cybersécurité
Gouvernance & Stratégie
1Analyse des risques & politiques de sécurité de l'information6Évaluation de l'efficacité des mesures de sécuritéIncidents & Continuité
2Gestion des incidents & notification3Continuité des activités & reprise après sinistreChaîne d'approvisionnement & Systèmes
4Sécurité de la chaîne d'approvisionnement5Sécurité dans le développement des systèmes d'informationContrôles Techniques
8Cryptographie & chiffrement10Authentification multifacteur & communications sécuriséesPersonnel & Actifs
7Cyber-hygiène & formation9Sécurité RH & contrôle d'accès
Votre seuil d'importance est un contrôle, pas une appréciation
Le CIR ne laisse pas « important » à l'interprétation. L'article 3 fixe des critères : un incident est important s'il cause une perte financière directe supérieure à 500 000 EUR ou à 5 % du chiffre d'affaires annuel, s'il entraîne l'exfiltration de secrets d'affaires, ou s'il provoque un décès ou des dommages considérables à la santé.
L'article 4 ajoute une règle que la plupart des processus ignorent complètement : des incidents récurrents qui, pris isolément, restent sous le seuil peuvent être agrégés et traités comme un incident important unique s'ils remplissent collectivement les critères sur une période de six mois. Cinq petits épisodes de credential stuffing dans un parc client ne sont pas cinq non-événements. Ils peuvent constituer un incident notifiable, et personne ne le voit si personne ne suit l'agrégat.
L'article 5 durcit encore le régime pour les fournisseurs DNS et les registres TLD : une disponibilité inférieure à 99,9 % sur n'importe quelle période suffit à elle seule.
Conséquence pratique pour les consultants : les critères de classification de votre client doivent être écrits avant l'incident, alignés sur ces seuils et confiés à un rôle nommé. Une analyste à 02h14 un samedi ne doit pas inventer un test d'importance. Elle doit en appliquer un.
L'horloge part de la connaissance, pas de l'accord
L'article 23(3) déclenche la fenêtre de 24 heures dès que l'entité a connaissance d'un incident important. Pas quand la direction convient qu'il est important. Pas quand le contrat de réponse à incident est activé. Pas le lundi.
C'est de cette distinction que naissent la plupart des délais manqués. L'organisation avait l'information le samedi et la décision le lundi, et considère l'écart comme un processus interne. Le régulateur y voit 31 heures de retard.
Construisez plutôt le processus à rebours de l'échéance. Si l'alerte précoce est due sous 24 heures, l'escalade vers un décideur doit prendre des heures, donc la détection doit produire une alerte classifiée, donc quelqu'un doit être joignable hors heures ouvrées avec autorité pour décider. Chacun de ces points est un choix de conception que vous faites maintenant ou que vous découvrez pendant un incident.
La séquence complète — alerte précoce à 24 heures, notification à 72 heures, rapport final à un mois — figure dans notre guide des délais de notification, et les modèles officiels de notification indiquent exactement les champs à remplir sous pression.
Calendrier de Notification des Incidents NIS2
24hAlerte Précoce
Notifiez l'autorité compétente (CSIRT/ANC) dans les 24 heures suivant la prise de connaissance d'un incident significatif.
Étape 172hNotification d'Incident
Soumettez une notification détaillée dans les 72 heures avec une première évaluation de la gravité, de l'impact et des indicateurs de compromission.
Étape 21moRapport Final
Remettez un rapport final complet dans un délai d'un mois couvrant l'analyse des causes, les mesures prises et l'impact transfrontalier.
Étape 324hAlerte Précoce
Notifiez l'autorité compétente (CSIRT/ANC) dans les 24 heures suivant la prise de connaissance d'un incident significatif.
72hNotification d'Incident
Soumettez une notification détaillée dans les 72 heures avec une première évaluation de la gravité, de l'impact et des indicateurs de compromission.
1moRapport Final
Remettez un rapport final complet dans un délai d'un mois couvrant l'analyse des causes, les mesures prises et l'impact transfrontalier.
Cinq points de rupture du traitement des incidents chez un client réel
La détection produit des alertes, pas des incidents. Un SIEM qui génère 400 alertes par jour ne fait pas de la détection d'incidents. La détection au sens du point 3 de l'annexe suppose un tri des alertes selon un modèle de gravité défini, avec un responsable et un délai de réponse.
L'escalade repose sur une seule personne. Le processus fonctionne parce que Marco sait quoi faire. Marco est en congé. Documentez le rôle, pas la personne, et nommez un suppléant.
La couverture hors heures ouvrées est supposée, pas contractualisée. Posez la question directe : entre vendredi 18h00 et lundi 08h00, qui a autorité pour déclarer un incident important ? Si la réponse nécessite une réunion, la réponse est : personne.
Les dépendances tierces sont hors du processus. L'incident de votre client peut démarrer chez son fournisseur cloud, ou chez vous. Les obligations de l'article 21 ne se transfèrent pas avec la charge de travail. Les obligations contractuelles de notification vers les fournisseurs font partie du plan — voir contrats fournisseurs et NIS2.
La revue post-incident est un débriefing, pas un enregistrement. Une conversation n'est pas une preuve. Le CIR attend une revue structurée avec constats, responsables et modifications apportées. Pas de document, pas de mesure.
La supervision s'intensifie en l'absence de traitement
Les entités essentielles relèvent d'une supervision ex ante — les autorités peuvent auditer de façon proactive, sans attendre un incident. Les entités importantes relèvent d'une supervision ex post, déclenchée par un incident ou par des informations crédibles de non-conformité.
Les deux voies aboutissent au même point si le traitement des incidents fait défaut. Les autorités peuvent émettre des instructions contraignantes, ordonner des remédiations précises, exiger la notification des clients concernés, publier la non-conformité et infliger des amendes administratives. Pour les entités essentielles, le plafond est de 10 millions EUR ou 2 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Les conséquences non financières sont souvent les plus dures — nous les avons traitées dans 7 sanctions NIS2 pires que l'argent.
En 2026, tout cela a cessé d'être théorique. La transposition dans les États membres est largement achevée, la loi néerlandaise Cyberbeveiligingswet est entrée en vigueur le 15 août 2026, et la Commission a saisi en juillet la Cour de justice contre l'Irlande, l'Espagne, la France et les Pays-Bas pour transposition incomplète. Les autorités de contrôle mènent des inspections sur la base d'un droit national qui existe.
Escalade des sanctions NIS2 — Au-delà de l'amende
!Déclencheur
Non-conformité détectée ou incident survenu
Une autorité de contrôle identifie une lacune de conformité ou une organisation ne respecte pas les exigences NIS2
Les autorités peuvent imposer▼Sanctions non financières1Ordres de mise en conformité avec délais contraignants
2Audits de sécurité obligatoires à vos frais
3Divulgation publique des violations
4Instructions contraignantes sur des mesures de sécurité spécifiques
Escalade vers▼Conséquences opérationnelles et personnelles1Suspension de certifications ou licences d'exploitation
2Interdiction temporaire de fonctions de direction pour les individus
3Désignation publique des personnes physiques responsables
DéclencheurNon financierOpérationnel / personnel
Les preuves qui démontrent l'existence du processus
Un auditeur n'évalue pas vos intentions. Il évalue ce que vous pouvez produire. Pour l'article 21(2)(b), le dossier doit contenir :
- Une politique de traitement des incidents approuvée par la direction, avec une date de revue de moins de 12 mois
- Des critères de classification écrits, alignés sur les seuils de l'article 3 du CIR
- Une chaîne d'escalade nommée, avec suppléants et joignabilité hors heures ouvrées
- Des tickets d'incident distinguant l'heure de détection, l'heure de classification et l'heure de décision
- Au moins un exercice ou un tabletop de l'année écoulée, avec les constats produits
- Des revues post-incident avec responsables assignés et preuve de clôture des actions
- Une configuration et une rétention de journalisation permettant de reconstituer la chronologie a posteriori
Ce dernier point pèse plus lourd qu'il n'y paraît. Si votre rétention est de 30 jours et que vous déposez un rapport final à un mois, vous écrivez peut-être sur des événements que vous ne pouvez plus prouver.
Commencez par les horodatages. Sortez les cinq derniers incidents d'un environnement client et vérifiez si détection, classification et décision sont enregistrées séparément. Si ce n'est pas le cas, la fenêtre de 24 heures n'a jamais été testée — et vous découvrirez sa durée réelle pendant l'incident qui compte.
Si vous voulez une vue structurée de la position d'un client sur les dix mesures de l'article 21 avant de vous engager sur un plan de remédiation, lancez un quick scan NIS2 gratuit. Cela prend quelques minutes et donne un point de départ défendable pour la discussion.
Le traitement des incidents est la mesure qui transforme tous les autres contrôles en réponse. Réglez le processus, les critères et l'horloge, et l'article 23 devient une formalité administrative. Ratez-les, et aucun outillage ne tiendra le délai.