Qu'est-ce qu'un incident de cybersécurité ?

Un incident de cybersécurité est un événement qui compromet la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données, ou des services qui reposent sur des systèmes d’information. C’est la définition de la directive NIS2 (article 6). Un compte piraté, des fichiers chiffrés par un rançongiciel ou une fuite de données sont des incidents ; une simple alerte ne l’est pas encore.

Cet article fait partie de notre série sur la réponse à incident. Pour la vue d’ensemble, voir Qu’est-ce que la réponse à incident en cybersécurité ?.

La définition officielle, en clair

NIS2 définit l’incident comme un événement compromettant la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données stockées, transmises ou traitées, ou des services offerts par des réseaux et systèmes d’information ou accessibles par ceux-ci. Quatre propriétés sont donc en jeu :

• Disponibilité : le service ou la donnée est inaccessible (serveurs chiffrés, messagerie bloquée, saturation par déni de service).
• Intégrité : la donnée a été modifiée sans autorisation (RIB changé dans une facture, configuration altérée).
• Confidentialité : la donnée a été vue ou copiée par quelqu’un qui n’aurait pas dû (exfiltration, boîte mail consultée par un tiers).
• Authenticité : on ne peut plus se fier à l’origine d’une action ou d’un message (identité usurpée, compte utilisé par un attaquant).

Le NIST, dans son guide SP 800-61 (révision 3, avril 2025), retient une approche proche : un incident met en danger, réellement ou de façon imminente, la sécurité d’une information ou d’un système, ou viole une politique de sécurité.

Événement, alerte, incident : ne pas tout mélanger

Un système d’information produit en permanence des événements (connexions, modifications de fichiers, trafic réseau). Certains déclenchent une alerte parce qu’ils ressemblent à un comportement malveillant. L’alerte devient un incident seulement quand l’analyse confirme qu’une compromission a eu lieu ou est en cours.

Notion	Ce que c’est	Exemple
Événement	Toute trace d’activité observable	Une connexion à Microsoft 365
Alerte	Un événement jugé suspect par un outil ou une règle	Connexion depuis un pays inhabituel
Incident évité (NIS2)	Un événement qui aurait pu compromettre le système, mais a été empêché	Phishing bloqué avant le clic
Incident	Une compromission avérée	Compte utilisé par un attaquant pour envoyer des factures frauduleuses
Incident important (NIS2)	Un incident aux conséquences graves	Production à l’arrêt plusieurs jours
Violation de données (RGPD)	Un incident touchant des données personnelles	Fichier clients copié

C’est le travail de qualification d’un SOC : trier les alertes, écarter les faux positifs et confirmer les vrais incidents. Voir Que se passe-t-il quand un SOC managé détecte une attaque ?.

Quand un incident devient « important » au sens de NIS2

Pour les entités soumises à NIS2, la directive prévoit la notification des incidents importants. L’article 23, paragraphe 3, en donne deux critères. Un incident est important s’il :

1. a causé ou peut causer une perturbation opérationnelle grave des services ou des pertes financières pour l’entité ;
2. a affecté ou peut affecter d’autres personnes physiques ou morales en causant des dommages matériels ou non matériels considérables.

Dans ce cas, la directive prévoit une alerte précoce dans les 24 heures, une notification dans les 72 heures et un rapport final dans un délai d’un mois. Au 13 septembre 2026, la loi française de transposition n’est pas encore adoptée ; ces délais décrivent ce que prévoit la directive. Voir La réponse à incident est-elle obligatoire ?.

Le cas des données personnelles

Le RGPD a sa propre notion : la violation de données à caractère personnel (article 4, point 12), c’est-à-dire la destruction, la perte, l’altération, la divulgation ou l’accès non autorisé à des données personnelles. Lorsqu’elle présente un risque pour les personnes, l’article 33 prévoit sa notification à l’autorité de contrôle (la CNIL en France) dans les 72 heures après en avoir pris connaissance. Un même incident peut donc relever à la fois de NIS2 et du RGPD.

Quelques exemples concrets

• Un rançongiciel chiffre les serveurs de fichiers d’une PME.
• Un compte Microsoft 365 est compromis et sert à envoyer du phishing aux clients.
• Un attaquant exploite une faille d’un pare-feu exposé sur Internet.
• Un ancien prestataire se connecte encore avec un accès oublié.
• Une base de données clients se retrouve en vente sur un forum.

Pour une typologie complète, voir Quels types d’incidents de cybersécurité existe-t-il ?.

Pourquoi la bonne qualification compte

Les délais de notification courent à partir du moment où l’organisation a connaissance de l’incident. Une qualification rapide permet de mobiliser à temps les bonnes personnes : l’équipe de réponse, la direction et, si l’incident prend de l’ampleur, une cellule de crise. Voir Quelle différence entre réponse à incident et gestion de crise ?.

À l’inverse, traiter chaque alerte comme un incident épuise les équipes. D’où l’intérêt d’une surveillance continue qui fait ce tri en permanence, et d’un CERT capable de prendre le relais quand l’incident est confirmé. Voir CERT, CSIRT et SOC : quelles différences ?.

Faire le point avec un expert

Vous voulez savoir comment vos alertes sont qualifiées, ou celles de vos clients ? Si vous travaillez avec un infogérant partenaire de Cyna, il est votre premier interlocuteur. Sinon, contactez-nous.

Vous êtes attaqué ? Déclarez un incident : l’astreinte Cyna est joignable 24h/24 et 7j/7.

Questions fréquentes

Une tentative de phishing bloquée est-elle un incident ?

En général non : rien n'a été compromis. NIS2 parle alors d'incident évité. Il reste utile de l'enregistrer, car une série de tentatives ciblées peut annoncer une attaque plus construite.

Une panne matérielle est-elle un incident de cybersécurité ?

Elle peut l'être au sens large de NIS2, qui vise tout événement compromettant la disponibilité des services, quelle qu'en soit la cause. En pratique, c'est l'origine malveillante ou non qui détermine qui la traite : l'exploitation informatique ou l'équipe de réponse à incident.

Qui décide qu'un événement est un incident ?

Le premier tri est souvent fait par un SOC ou par l'infogérant. La qualification finale, et surtout la décision de notifier une autorité, revient en général à l'organisation touchée, avec l'appui de son conseil juridique si besoin. Voir Qui contacter en cas de cyberattaque ?.

Faut-il garder une trace des incidents mineurs ?

C'est recommandé. Le RGPD (article 33, paragraphe 5) prévoit que toute violation de données personnelles soit documentée, même lorsqu'elle n'est pas notifiée. Pour le reste, un registre d'incidents aide à repérer les tendances et à prouver que les incidents sont traités.