Selon l’article 23, paragraphe 3, de NIS2, un incident est important s’il a causé ou peut causer une perturbation opérationnelle grave ou des pertes financières pour l’entité, ou des dommages matériels, corporels ou moraux considérables à d’autres personnes. La directive ne fixe aucun chiffre. Les fournisseurs de services d’informatique en nuage, de centres de données, de services gérés et d’autres fournisseurs numériques disposent de seuils concrets dans le règlement d’exécution (UE) 2024/2690.
Ce guide couvre le critère légal, la personne qui décide, les seuils des fournisseurs numériques, les critères nationaux, un arbre de décision, la différence avec une violation de données à caractère personnel au sens du RGPD, ce que le critère laisse ouvert et une liste de contrôle.
| Niveau | S’applique à | Important si | Source |
|---|---|---|---|
| Critère général | Toutes les entités essentielles et importantes | Perturbation opérationnelle grave ou pertes financières pour l’entité, ou dommages considérables à d’autres, causés ou possibles | NIS2, art. 23, par. 3 |
| Critères des fournisseurs numériques | DNS, TLD, informatique en nuage, centres de données, CDN, MSP, MSSP, plateformes en ligne, services de confiance | Perte directe supérieure à 500 000 EUR ou à 5 % du chiffre d’affaires, le montant le plus faible étant retenu ; autres critères généraux ; incidents récurrents ; seuils par service | Règl. 2024/2690, art. 3 à 14 |
| Critères nationaux | Selon le pays | Facteurs ou seuils ajoutés par certaines autorités | Droit national et lignes directrices |
Qu’est-ce qu’un incident important selon NIS2 ?
Selon l’article 6, point 6), un incident est tout événement compromettant la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données ou des services qu’offrent vos systèmes. La plupart des incidents ne sont pas importants.
L’article 23, paragraphe 3, fixe le critère. Un incident est considéré comme important si :
- « 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 » ; ou
- « il a affecté ou est susceptible d’affecter d’autres personnes physiques ou morales en causant des dommages matériels, corporels ou moraux considérables ».
Le premier volet regarde vers l’intérieur : vos services et votre argent. Le second regarde vers l’extérieur : les clients, les utilisateurs et toute autre personne que votre incident atteint. L’un ou l’autre suffit.
Que signifie « susceptible de causer » ?
Vous n’attendez pas le dommage. Une intrusion contenue à la troisième heure, qui aurait pu arrêter votre service principal, peut être un incident important. Le considérant 101 vise la notification des incidents qui, sur la base d’une évaluation initiale effectuée par l’entité concernée, pourraient causer une perturbation grave, des pertes ou des dommages. Un rançongiciel découvert sur un système de production est le cas d’école, traité dans NIS2 et les rançongiciels.
Que doit prendre en compte l’évaluation ?
« Grave » et « considérables » ne sont pas définis. Selon le considérant 101, l’évaluation initiale devrait tenir compte des systèmes touchés, en particulier de leur importance pour la fourniture des services de l’entité, de la gravité et des caractéristiques techniques de la menace, des éventuelles vulnérabilités exploitées et de votre expérience d’incidents similaires. Il ajoute que la mesure dans laquelle le fonctionnement du service est affecté, la durée d’un incident ou le nombre de destinataires des services touchés peuvent montrer si une perturbation est grave. Votre logiciel de paie indisponible pendant une matinée et votre plateforme client indisponible pendant une matinée sont deux incidents différents.
Qui décide si un incident est important ?
Vous. L’article 23, paragraphe 1, fait peser l’obligation de notification sur l’entité, et le considérant 101 la fonde sur l’évaluation initiale de l’entité elle-même.
Pour les fournisseurs numériques couverts par le règlement 2024/2690, son considérant 31 précise à quel moment vous avez « eu connaissance » de l’incident : lorsque, après une évaluation initiale menée en temps opportun, l’entité « est raisonnablement certaine qu’un incident important s’est produit ». L’évaluation elle-même doit être menée en temps opportun : une évaluation lente ne fait donc pas gagner de temps.
L’avis de l’autorité vient ensuite. Elle peut vous ordonner de respecter les obligations de notification de l’article 23 selon des modalités précises et dans un délai déterminé (article 32, paragraphe 4, point d), et article 33, paragraphe 4, point d)). Pour les entités essentielles, un incident important peut justifier un audit ad hoc (article 32, paragraphe 2, point c)). Les manquements à l’article 23 sont passibles d’amendes au titre de l’article 34.
Deux conséquences en découlent, qui relèvent de la pratique et non du droit :
- Consignez chaque évaluation, y compris celles qui vous conduisent à ne pas notifier : heure, faits connus, critère examiné, résultat.
- Un cas limite notifié avec votre raisonnement est plus facile à défendre qu’un incident que vous avez gardé pour vous. En dessous du seuil, l’article 30 vous permet toujours de notifier volontairement des incidents, des cybermenaces et des incidents évités.
Une fois l’incident jugé important, les délais figurent dans le calendrier de notification des incidents NIS2.
Quels sont les seuils de notification NIS2 pour les fournisseurs numériques ?
L’article 23, paragraphe 11, imposait à la Commission de préciser quand un incident est important pour certains fournisseurs numériques. Elle l’a fait dans le règlement d’exécution (UE) 2024/2690, en vigueur depuis le 7 novembre 2024 et directement applicable dans tous les États membres. Il couvre les fournisseurs de services DNS, les registres des noms de domaine de premier niveau, les fournisseurs de services d’informatique en nuage, de centres de données et de réseaux de diffusion de contenu, les fournisseurs de services gérés et de services de sécurité gérés, les places de marché en ligne, les moteurs de recherche en ligne et les réseaux sociaux, ainsi que les prestataires de services de confiance, que l’article 23, paragraphe 11, ne mentionnait pas.
Les critères généraux, article 3
Un incident est important pour ces fournisseurs si un ou plusieurs des critères suivants sont remplis :
- une perte financière directe, causée ou possible, supérieure à 500 000 EUR ou à 5 % du chiffre d’affaires annuel total de l’exercice précédent, le montant le plus faible étant retenu ;
- l’exfiltration de secrets d’affaires, causée ou possible ;
- le décès d’une personne, ou des dommages considérables à sa santé, causés ou possibles ;
- un accès non autorisé effectif aux systèmes, suspecté d’être malveillant et susceptible de causer une perturbation opérationnelle grave ;
- le critère des incidents récurrents de l’article 4, ou un critère de service des articles 5 à 14.
La maintenance programmée ne compte pas. Selon le considérant 36, la perte financière directe comprend le remplacement du matériel et des logiciels, les frais de personnel et les heures supplémentaires, les pénalités contractuelles, l’indemnisation des clients, les recettes non perçues, ainsi que les coûts de communication, de conseil juridique, d’investigation numérique et de remédiation. Les amendes administratives et les coûts de fonctionnement courants n’en font pas partie.
Incidents récurrents, article 4
Des incidents qui ne sont pas importants pris isolément deviennent collectivement un incident important s’ils se sont produits au moins deux fois en six mois, ont la même cause originelle apparente et dépassent ensemble le seuil de perte financière. Vous ne le repérez que si votre registre des incidents consigne les causes profondes.
Critères propres à chaque service, articles 5 à 14
Un seul critère suffit. Les utilisateurs sont comptés dans l’Union ; selon l’article 3, paragraphe 3, ils comprennent les clients liés par un contrat et les personnes associées à vos clients professionnels. Lorsque deux chiffres sont indiqués, le plus petit s’applique.
| Article | Fournisseur | Important si, par exemple |
|---|---|---|
| 5 | Fournisseurs de services DNS | Totalement indisponible pendant plus de 30 minutes ; temps de réponse supérieur à 10 secondes pendant plus d’une heure ; données compromises (exception étroite en cas d’erreur de configuration) |
| 6 | Registres des noms de domaine de premier niveau | Résolution faisant autorité totalement indisponible, quelle qu’en soit la durée ; temps de réponse supérieur à 10 secondes pendant plus d’une heure ; données techniques compromises |
| 7, 9, 10 | Informatique en nuage, CDN, MSP, MSSP | Totalement indisponible pendant plus de 30 minutes ; disponibilité limitée pour plus de 5 % des utilisateurs ou 1 million pendant plus d’une heure ; données compromises par une action suspectée d’être malveillante, ou pour plus de 5 % des utilisateurs ou 1 million |
| 8 | Centres de données | Totalement indisponible ; disponibilité limitée pendant plus d’une heure ; données compromises par une action suspectée d’être malveillante ; accès physique compromis |
| 11 à 13 | Places de marché, moteurs de recherche, réseaux sociaux | Totalement indisponible, ou disponibilité limitée, pour plus de 5 % des utilisateurs ou 1 million ; données compromises par une action suspectée d’être malveillante, ou pour plus de 5 % des utilisateurs ou 1 million |
| 14 | Prestataires de services de confiance | Totalement indisponible pendant plus de 20 minutes ; indisponible plus d’une heure par semaine calendaire ; disponibilité limitée pour plus de 1 % ou 200 000 utilisateurs ou parties utilisatrices ; accès physique compromis ; données compromises pour plus de 0,1 % ou 100 utilisateurs |
Notez le critère de l’action suspectée d’être malveillante : aux articles 7 à 13, une compromission des données du service par une action suspectée d’être malveillante est importante sans aucune condition de taille. Pour un MSP, un attaquant présumé dans les outils servant à gérer les environnements des clients peut remplir ce critère avant qu’un client ne remarque quoi que ce soit. Plus de détails dans NIS2 pour les fournisseurs de services gérés.
Les règles nationales peuvent-elles ajouter des seuils ?
Oui. NIS2 fixe un minimum : l’article 5 permet aux États membres d’adopter ou de maintenir des dispositions assurant un niveau de cybersécurité plus élevé, ce qui laisse aux lois et aux autorités nationales la possibilité de préciser le critère général. L’article 23, paragraphe 11, permet aussi à la Commission d’adopter des règles sur le caractère important des incidents pour d’autres entités ; à ce jour, le règlement 2024/2690 ne couvre que les fournisseurs numériques mentionnés ci-dessus.
Le régulateur luxembourgeois, par exemple, demande aux entités quels facteurs s’appliquent : nombre et proportion d’utilisateurs touchés, durée, étendue géographique, perte financière directe, dommages matériels et immatériels, atteinte à la réputation ou couverture médiatique, exfiltration de secrets d’affaires ou d’autres informations sensibles, décès ou atteinte à la santé, et accès non autorisé. La procédure est décrite dans la notification des incidents NIS2 au Luxembourg. Consultez les lignes directrices de votre propre autorité avant de rédiger vos critères.
Comment trancher vite ? Un arbre de décision
INCIDENT IMPORTANT NIS2 : DÉCISION DANS LES PREMIÈRES HEURES
0. Incident ? Consigner l'heure et qui évalue. Aller à 1.
1. Êtes-vous un fournisseur numérique couvert par le règlement 2024/2690 ?
Oui -> aller à 2. Non -> aller à 4.
2. Article 3 : l'un de ces critères, avéré ou potentiel ?
[ ] perte directe > 500 000 EUR ou 5 % du CA (le plus faible)
[ ] exfiltration de secrets d'affaires
[ ] décès, ou dommages considérables à la santé
[ ] accès non autorisé effectif, suspecté d'être malveillant,
susceptible de causer une perturbation opérationnelle grave
Oui -> IMPORTANT. Non -> aller à 3.
3. Votre critère de service des articles 5 à 14 est-il rempli ?
Ou récurrence : au moins deux fois en 6 mois, même cause
originelle apparente, ensemble au-dessus du seuil de perte
(article 4) ?
Oui -> IMPORTANT.
Non -> non important selon les critères du règlement.
Consigner pourquoi. Réévaluer si les faits changent.
4. Article 23, paragraphe 3, pour toutes les autres entités :
a) perturbation opérationnelle grave de vos services, ou
pertes financières pour vous, causées ou possibles ?
b) dommages matériels, corporels ou moraux considérables
à d'autres, causés ou possibles ?
Évaluer : systèmes touchés, part du service affectée, durée,
destinataires touchés, menace. Appliquer les critères nationaux.
Oui à a) ou b) -> IMPORTANT.
Cas limite -> décider, consigner le raisonnement.
En pratique, notifier est plus facile à défendre.
5. IMPORTANT -> alerte précoce dans les 24 h après en avoir eu
connaissance. Données personnelles en cause ? Mener l'analyse
RGPD en parallèle.Un incident important est-il la même chose qu’une violation de données personnelles au sens du RGPD ?
Non. Les deux critères posent des questions différentes, et un même incident peut remplir l’un, l’autre, les deux ou aucun.
| Incident important NIS2 | Violation de données à caractère personnel (RGPD) | |
|---|---|---|
| Définition | Perturbation grave ou pertes financières pour vous, ou dommages considérables à d’autres, causés ou possibles | Une violation de la sécurité entraînant la destruction, la perte, l’altération ou la divulgation non autorisée de données à caractère personnel, ou l’accès non autorisé à de telles données |
| Qui notifie | L’entité essentielle ou importante | Le responsable du traitement |
| Seuil | Le critère de l’incident important | Notification, sauf si la violation n’est pas susceptible d’engendrer un risque pour les personnes |
| Destinataire | CSIRT ou autorité compétente | Autorité de protection des données |
Trois exemples, qui relèvent de la pratique :
- Un rançongiciel chiffre la plateforme de production et copie des données clients : probablement les deux.
- Une attaque par déni de service rend un portail client indisponible pendant des heures, sans toucher aux données personnelles : cela peut être un incident important au sens de NIS2, et ce n’est pas une violation de données à caractère personnel.
- Un e-mail contenant les données de santé d’un client part vers le mauvais destinataire : une violation de données à caractère personnel qui peut devoir être notifiée, et rarement un incident important.
Les autorités se parlent : lorsqu’une autorité NIS2 constate qu’un manquement à l’article 21 ou 23 peut entraîner une violation de données à caractère personnel devant être notifiée, elle en informe l’autorité de protection des données (article 35). Plus de détails dans NIS2 et RGPD.
Que laisse ouvert le critère de l’incident important en pratique ?
Le droit vous donne des critères, pas les données pour les appliquer. Chaque seuil du règlement 2024/2690 est une mesure : des minutes d’indisponibilité, une part des utilisateurs dans l’Union, des euros de perte directe. Même pour le critère général, le considérant 101 renvoie au nombre de destinataires touchés et à la durée. Si vous ne pouvez pas le mesurer à la deuxième heure, vous ne pouvez pas décider à la deuxième heure. Combler cet écart est un travail à faire avant l’incident :
- une cartographie qui relie systèmes, services et clients, avec le nombre d’utilisateurs, pour que « 5 % des utilisateurs » soit une simple recherche ;
- une supervision de la disponibilité qui enregistre quand chaque service est tombé et quand il est revenu ;
- une estimation des pertes par service et par heure d’interruption, pour que 500 000 EUR soit un calcul, pas un débat ;
- des journaux interrogeables, conservés assez longtemps pour montrer si l’accès était malveillant et ce qu’il a atteint ;
- un décideur désigné et son suppléant, et un dossier d’incident unique qui regroupe chaque évaluation.
L’essentiel de ces données se trouve déjà dans vos outils de supervision, de gestion des identités et de tickets, si quelque chose les collecte et les relie. La plateforme CloudSoul le fait en continu : une collecte automatisée des preuves, avec une expertise humaine dans la boucle pour les décisions qu’un outil ne devrait pas prendre seul, par exemple déterminer si un incident est important. Le programme dans son ensemble est présenté sur la page conformité NIS2.
Liste de contrôle : incident important NIS2
- Formulez le critère de l’article 23, paragraphe 3, dans les termes de vos propres services : ce que perturbation grave et dommage considérable signifient pour chacun.
- Si vous êtes un fournisseur numérique, listez les critères du règlement 2024/2690 qui s’appliquent à vous et la mesure qui sous-tend chacun.
- Tenez une cartographie des services avec le nombre d’utilisateurs et une estimation des pertes par heure d’interruption.
- Désignez la personne qui décide si un incident est important, ainsi qu’un suppléant, tous deux joignables en dehors des heures de bureau.
- Consignez chaque évaluation, y compris pour les incidents que vous décidez de ne pas notifier.
- Consignez les causes profondes, pour repérer un deuxième incident survenu dans les six mois.
- Menez l’analyse de violation RGPD en parallèle, à partir du même dossier d’incident.
Sources
- Directive (UE) 2022/2555 (NIS2), articles 5, 6, 23, 30, 32, 33, 34 et 35 et considérant 101, EUR-Lex.
- Règlement d’exécution (UE) 2024/2690 de la Commission, articles 1, 3 à 14 et 16 et considérants 31 et 36, EUR-Lex.
- Règlement (UE) 2016/679 (RGPD), article 4, point 12), et articles 33 et 34, EUR-Lex.
- ILR, Notification d’incident, mise à jour du 6 juillet 2026.
Questions fréquentes
Qu'est-ce qu'un incident important selon NIS2 ?
Selon l'article 23, paragraphe 3, de la directive (UE) 2022/2555, un incident est important 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, corporels ou moraux considérables.
Existe-t-il un seuil chiffré de notification dans NIS2 ?
Pas dans la directive elle-même. Pour les fournisseurs de services DNS, les registres des noms de domaine de premier niveau, les fournisseurs de services d'informatique en nuage, de centres de données et de réseaux de diffusion de contenu, les fournisseurs de services gérés et de services de sécurité gérés, les plateformes en ligne et les prestataires de services de confiance, le règlement d'exécution (UE) 2024/2690 fixe des critères concrets, par exemple une perte financière directe supérieure à 500 000 EUR ou à 5 % du chiffre d'affaires annuel, le montant le plus faible étant retenu.
Qui décide si un incident est important ?
L'entité, sur la base de sa propre évaluation initiale. L'autorité compétente peut revoir cette décision par la suite, ordonner à l'entité de respecter ses obligations de notification au titre de l'article 23 et sanctionner par des amendes les manquements à l'article 23.
Quand un incident chez un fournisseur de services gérés est-il important ?
Entre autres critères, lorsqu'un service géré ou un service de sécurité géré est totalement indisponible pendant plus de 30 minutes, ou lorsque des données liées au service sont compromises par une action suspectée d'être malveillante (article 10 du règlement d'exécution (UE) 2024/2690).
Un incident important NIS2 est-il la même chose qu'une violation de données à caractère personnel au sens du RGPD ?
Non. Une violation de données à caractère personnel concerne des données personnelles et se notifie à l'autorité de protection des données, sauf si elle n'est pas susceptible d'engendrer un risque pour les personnes. Un incident important concerne une perturbation, une perte ou un dommage et se notifie au CSIRT ou à l'autorité compétente. Un même incident peut relever des deux.
