Incident important au sens de NIS 2
Deux critères de déclenchement qualitatifs, un règlement chiffré pour l'infrastructure numérique, et un journal de décision écrit pour tous les autres.
Pourquoi la définition est déterminante
L'importance est ce qui déclenche toute l'horloge de notification de l'article 23 de NIS 2 : une alerte précoce dans les 24 heures, une notification d'incident dans les 72 heures, un rapport final dans un délai d'un mois. Si l'événement est important, l'horloge démarre dès que vous en avez connaissance. S'il ne l'est pas, vous ne devez rien au CSIRT ni à l'autorité compétente.
L'article 23, paragraphe 3, de NIS 2 ne vous donne que deux formulations générales. Le règlement d'exécution (UE) 2024/2690 de la Commission (CIR) ajoute des chiffres précis, mais uniquement pour un petit groupe de fournisseurs numériques (DNS, TLD, cloud, centre de données, CDN, MSP, MSSP, place de marché, moteur de recherche, réseau social, services de confiance). Pour tous les autres secteurs de NIS 2, le test reste qualitatif.
La plupart des RSSI sous-estiment cet écart. Si vous êtes dans la fabrication, l'alimentation, la santé ou la gestion des déchets, il n'y a pas de montant en euros, pas de décompte en minutes, pas de seuil d'utilisateurs. Vous devez décider, vous devez décider vite, et vous devez être en mesure d'expliquer pourquoi par la suite.
Directive NIS 2 (UE) 2022/2555, art. 23, paragraphe 3
Un incident est considéré comme important : a) s'il a causé ou est susceptible de causer une perturbation opérationnelle grave des services ou des pertes financières pour l'entité concernée ; b) s'il a affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant un dommage matériel ou moral considérable.
Il s'agit de la seule définition générale d'un incident important en droit de l'Union. Les deux points emploient « est susceptible de causer », vous devez donc apprécier le dommage potentiel aussi bien que le dommage effectif. Le texte ne quantifie jamais grave, considérable ou matériel.
CIR (UE) 2024/2690, art. 3
Un incident est considéré comme important lorsqu'il a causé ou est susceptible de causer : a) une perte financière directe supérieure à 500 000 EUR ou à 5 pour cent du chiffre d'affaires annuel total de l'exercice précédent, le montant le plus faible étant retenu ; b) l'exfiltration de secrets d'affaires de l'entité au sens de l'article 2, point 1, de la directive (UE) 2016/943 ; c) le décès d'une personne physique ; d) un dommage considérable à la santé d'une personne physique ; e) un accès réussi, soupçonné d'être malveillant et non autorisé à des réseaux et des systèmes d'information susceptible de causer une perturbation opérationnelle grave ; f) les critères énoncés à l'article 4 (incidents récurrents) ; ou g) un ou plusieurs des critères énoncés aux articles 5 à 14 (spécifiques à l'entité). Un seul critère suffit.
Sept critères (lettres a à g) — cinq substantiels plus deux renvois. L'article 1er du CIR précise que ces chiffres ne s'appliquent qu'à des fournisseurs numériques spécifiques (DNS, TLD, cloud, centre de données, CDN, MSP, MSSP, place de marché en ligne, moteur de recherche, plateforme de réseau social, services de confiance). Les articles 5 à 14 ajoutent des planchers de disponibilité par secteur pour le même groupe. Si votre secteur ne figure pas sur cette liste, ces chiffres ne vous lient pas et le test qualitatif de l'article 23, paragraphe 3, est tout ce dont vous disposez.
§32 BSIG (Allemagne, exemple de transposition)
Wesentliche und wichtige Einrichtungen melden dem BSI erhebliche Sicherheitsvorfälle unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung als Frühwarnung, innerhalb von 72 Stunden als Sicherheitsvorfallsmeldung und innerhalb eines Monats als Abschlussbericht.
Chaque État membre transpose l'article 23 en droit national. Le §32 BSIG reprend la cascade et désigne le BSI comme destinataire. Il n'ajoute aucun chiffre propre pour les secteurs non numériques. Les Pays-Bas, l'Autriche et la France suivent le même schéma.
Sept critères (lettres a à g)
Cinq critères de déclenchement substantiels plus deux renvois. a) 500 000 EUR ou 5 pour cent du chiffre d'affaires (le montant le plus faible étant retenu), b) secrets d'affaires exfiltrés, c) une personne tuée, d) un dommage grave à la santé d'une personne, e) une intrusion malveillante réussie susceptible de causer une perturbation grave, f) incidents récurrents au titre de l'art. 4, g) seuils spécifiques à l'entité au titre des art. 5 à 14. L'un quelconque déclenche l'importance pour les fournisseurs numériques concernés.
Incidents récurrents
Les petits incidents s'additionnent. Si la même cause profonde produit au moins deux incidents en six mois et que, pris ensemble, ils franchissent le seuil de perte financière de l'art. 3, paragraphe 1, point a), le CIR les traite comme un seul incident important. Les compter séparément est une erreur.
Spécificités DNS et TLD
Pour les résolveurs DNS et les registres de domaines de premier niveau (TLD) : résolution de noms indisponible pendant plus de 30 minutes, temps de réponse moyen supérieur à 10 secondes pendant plus d'une heure, ou intégrité des données rompue pour plus de 1 000 domaines ou 1 pour cent du portefeuille. Les articles 6 à 14 fixent des planchers similaires pour le cloud, le CDN, le MSP, le MSSP, les places de marché, la recherche, les réseaux sociaux et les services de confiance.
Critère A : perturbation opérationnelle grave ou perte financière pour votre entité
Il s'agit du critère tourné vers l'intérieur. La directive ne vous donne aucun montant en euros, aucune durée, aucun pourcentage. Le considérant 101 nomme trois éléments à examiner : la part du service affectée, la durée de l'incident et le nombre d'utilisateurs touchés. Utilisez-les pour structurer votre raisonnement. Ne les traitez pas comme une liste de cases à cocher.
Critère B : dommage matériel ou moral considérable à des tiers
Il s'agit du critère tourné vers l'extérieur. Clients, citoyens, opérateurs en aval, votre chaîne d'approvisionnement. Le dommage moral inclut l'atteinte à la réputation et à la confiance. Une brève interruption qui rompt le flux de travail d'un hôpital, divulgue des données de clients ou met hors ligne un service municipal peut satisfaire ce critère même si votre propre perte est faible.
Un rançongiciel arrête la production pendant deux jours
Les opérations s'arrêtent. Le critère A de l'art. 23, paragraphe 3, de NIS 2 (perturbation opérationnelle grave) est rempli. Alerte précoce 24 h, notification d'incident 72 h, rapport final 1 mois (art. 23 NIS 2 / §32 BSIG).
E-mail d'hameçonnage cliqué, aucun mot de passe saisi
Confinement réussi, aucune incidence sur les services ou les tiers. Une notification volontaire au titre de l'art. 30 de NIS 2 reste possible si vous souhaitez partager, et elle n'impose aucune obligation supplémentaire (art. 30, paragraphe 4).
Panne du fournisseur cloud, votre propre service ralenti
Si votre propre service devient nettement plus lent ou s'arrête, le critère A est rempli. Vérifiez aussi le critère B : des clients ou des opérateurs en aval subissent-ils un préjudice ? (art. 23, paragraphe 3, de NIS 2)
Une attaque DDoS met le portail client hors ligne pendant quatre heures
Interruption importante pour les clients. Les deux critères de l'art. 23, paragraphe 3, de NIS 2 sont potentiellement remplis. Pour les fournisseurs DNS, cloud ou de services de confiance, vérifiez également les art. 5 à 14 du CIR.
Une mauvaise configuration expose des données de clients
Article 33 du GDPR : 72 h à l'autorité de contrôle. Si un seuil de NIS 2 est également franchi (art. 23, paragraphe 3, de NIS 2 ou art. 3 du CIR), en outre article 23 de NIS 2 : alerte précoce de 24 h au CSIRT. Les deux horloges démarrent au moment de la prise de connaissance.
Fournisseur compromis, votre propre service affecté
Vérifiez d'abord le dommage à votre propre entité ou à vos clients. Tout incident d'un fournisseur ne déclenche pas votre propre obligation de notification. En parallèle : documentez la surveillance des fournisseurs au titre de l'art. 21, paragraphe 2, point d), de NIS 2.
Incertain quant au franchissement du seuil ? Déposez l'alerte précoce et complétez plus tard. L'art. 23, paragraphe 4, point a), de NIS 2 est conçu exactement pour cela. L'autorité compétente préfère un « nous ne sommes pas encore sûrs » précoce à un « nous avons trop attendu » tardif.
L'article 30, paragraphe 1, de NIS 2 permet la notification volontaire d'incidents, de cybermenaces et d'incidents évités de justesse au CSIRT. Cela s'applique aux entités relevant du champ d'application de la directive ainsi qu'aux entités qui en sont exclues et qui souhaitent notifier un événement important.
L'article 30, paragraphe 4, de NIS 2 constitue la protection essentielle : la notification volontaire n'entraîne aucune obligation supplémentaire pour l'entité notifiante. Notifier un cas limite ne fait courir aucun risque de devoirs supplémentaires. Cela supprime le prétexte évident de ne pas notifier un incident incertain.
L'article 23, paragraphe 2, de NIS 2 ajoute une obligation distincte. Les entités essentielles et importantes communiquent, sans retard injustifié, à leurs destinataires de services toutes les mesures ou réparations qu'ils peuvent prendre pour atténuer les risques d'une cybermenace importante. Ce n'est pas la notification au CSIRT ; c'est la communication externe aux clients.
En Allemagne, le §35 BSIG met cela en œuvre. Le §35, paragraphe 1, autorise le BSI à ordonner la notification. Le §35, paragraphe 2, oblige en outre certains secteurs (finance, sécurité sociale, infrastructure numérique, gestion des services TIC, services numériques) à notifier de leur propre initiative. La communication peut être faite par publication sur le site web de l'entité.
Orientations du BSI au titre du §32 BSIG
Le BSI reprend le libellé de l'art. 23, paragraphe 3, et vous renvoie à son formulaire de notification standard (MIRP). Il ne publie aucun chiffre pour les secteurs non numériques. Position du BSI : appréciez l'importance au regard des critères qualitatifs, consignez votre raisonnement par écrit, et notifiez en cas de doute.
Orientations techniques de mise en œuvre de l'ENISA
Les orientations techniques de mise en œuvre de l'ENISA (TIG, v1.2 d'août 2025) donnent des conseils pratiques sur l'évaluation de l'impact et renvoient aux seuils du CIR là où ils s'appliquent. Les TIG sont non contraignantes et renvoient explicitement les secteurs hors du champ du CIR aux autorités nationales.
Transpositions d'autres États membres
La Cyberbeveiligingswet néerlandaise, le projet autrichien NISG 2024 et le régime français OIV/REC reprennent tous mot pour mot le test de l'art. 23, paragraphe 3. Aucun d'eux n'a encore publié de chiffres pour les secteurs non numériques. Le schéma dans toute l'UE est le même : test qualitatif plus le CIR pour le groupe numérique.
Mythe 1 : Nous le saurons quand nous le verrons.
Réalité : l'art. 23, paragraphe 3, vous donne 24 heures pour décider, consigner le raisonnement par écrit et le défendre lors de l'audit. Si vous n'avez pas écrit vos critères avant l'incident, vous trancherez sous pression sans aucune trace sur laquelle vous appuyer. Construisez le cadre de décision maintenant, pas le jour venu.
Mythe 2 : Seules les violations de données comptent comme incidents importants.
Réalité : l'art. 23, paragraphe 3, point a), couvre la perturbation opérationnelle et la perte financière sans aucune mention de données à caractère personnel. Une ligne d'usine arrêtée par un rançongiciel sans exfiltration de données est un incident important. Une plateforme logistique hors ligne pendant trois heures est un incident important. NIS 2 n'est pas le GDPR.
Mythe 3 : Les petits incidents sous le seuil ne s'additionnent pas.
Réalité : l'art. 4 du CIR (et la même logique pour les critères qualitatifs) indique que des incidents répétés ayant la même cause profonde s'additionnent. Deux interruptions de 20 minutes dues au même composant défaillant en six mois peuvent franchir le seuil ensemble. Les compter isolément est une erreur.
Les annexes I et II de NIS 2 couvrent environ 18 secteurs. Seul le groupe numérique de l'art. 1er du CIR (environ 11 types d'entités) obtient des chiffres. C'est une petite part des entités concernées. Pour l'énergie, les transports, la banque, les infrastructures des marchés financiers, la santé, l'eau potable, les eaux usées, l'administration publique, l'espace, la poste, la gestion des déchets, la chimie, l'alimentation, la fabrication et la recherche, le test reste qualitatif.
C'est là que vous pouvez être utile autour de la table. La réponse honnête à la question du conseil d'administration (« qu'est-ce qui compte comme important pour nous ? ») est la suivante : l'UE l'a laissé à votre appréciation, voici les trois facteurs du considérant 101, voici le journal de décision que nous produirons le jour venu, voici qui le signe, voici le formulaire de notification du BSI que nous déposerons. La réponse défendable n'est pas un chiffre. C'est une décision écrite.
Le module d'incidents de nisd2.eu saisit votre raisonnement de classification sous forme d'un champ structuré rattaché à l'art. 23, paragraphe 3. Pour les entités d'infrastructure numérique, les chiffres des art. 3, 4 et 5 du CIR apparaissent comme garde-fous. Pour tous les autres, les trois facteurs du considérant 101 apparaissent sous forme de modèle guidé, le raisonnement est signé et horodaté, et l'enregistrement alimente les rapports à 24 heures et à 72 heures.
Le résultat est un enregistrement que vous pouvez défendre : la décision, le raisonnement, le signataire, l'horodatage. C'est ce que l'autorité compétente et le BSI demandent après un événement limite. C'est aussi ce qui protège l'organe de direction au titre de l'art. 20 de NIS 2 si quelqu'un conteste la décision par la suite.
- Directive (UE) 2022/2555 (NIS 2), art. 23 et considérant 101 — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Règlement d'exécution (UE) 2024/2690 de la Commission, articles 1, 3, 4, 5 à 14 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSIG §32 (Allemagne) — portail réglementaire bsi.bund.de
- Orientations techniques de mise en œuvre de l'ENISA sur la notification des incidents NIS 2 (TIG) — enisa.europa.eu
- Formulaire de notification MIRP du BSI et orientations sur les incidents — bsi.bund.de