NIS2 et ransomware : ce que vous devez déclarer, si vous pouvez payer et ce qu'attend l'article 21

Au sens de NIS2, un rançongiciel (ransomware) qui a causé ou pourrait causer une perturbation grave ou des pertes financières est un incident important. Cela signifie une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification d’incident dans les 72 heures et un rapport final dans un délai d’un mois après celle-ci. NIS2 ne contient aucune règle sur le paiement des rançons : elle n’interdit pas de payer et n’impose pas de déclarer un paiement.

Ce guide couvre les cas où un rançongiciel est un incident important, ce qu’il faut notifier et quand, la question du paiement, ce que changerait la proposition COM(2026) 13, les mesures de l’article 21 qui comptent le plus, le RGPD, une liste de contrôle pour les 24 premières heures et ce que le droit laisse ouvert.

Question	Réponse courte	Source
Un rançongiciel est-il un incident important ?	Oui, s’il a causé ou peut causer une perturbation grave ou des pertes financières pour vous, ou des dommages considérables à d’autres	NIS2, art. 23, par. 3
Quand notifier ?	Alerte précoce dans les 24 heures suivant la prise de connaissance, notification dans les 72 heures, rapport final dans un délai d’un mois après la notification	Art. 23, par. 4
Faut-il dire qu’il s’agit d’une attaque ?	L’alerte précoce indique, le cas échéant, si l’on soupçonne des actes illicites ou malveillants	Art. 23, par. 4, point a)
Pouvez-vous payer ?	NIS2 ne dit rien. Le droit des sanctions et le droit national restent applicables	Règl. (UE) 2019/796
Faut-il déclarer un paiement ?	Pas en l’état actuel de NIS2. Une proposition de 2026 permettrait aux autorités de le demander	COM(2026) 13, proposition
Données personnelles touchées ?	Notification RGPD dans les 72 heures si possible, sauf si la violation n’est pas susceptible d’engendrer un risque	RGPD, art. 33
Quelles mesures comptent le plus ?	Sauvegardes et restauration, gestion des incidents, correctifs, contrôle d’accès, MFA, formation	Art. 21, par. 2

Une attaque par ransomware est-elle un incident important au sens de NIS2 ?

Le plus souvent, oui. Selon l’article 23, paragraphe 3, 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é concernée », ou s’il a affecté ou est susceptible d’affecter d’autres personnes en causant des dommages matériels, corporels ou moraux considérables.

Un rançongiciel qui chiffre les systèmes de production, bloque le traitement des commandes ou met hors service un service dont vos clients dépendent remplit le premier volet sans grand débat. Notez les mots « est susceptible de causer » : vous n’attendez pas de voir jusqu’où cela ira. Un rançongiciel détecté sur un seul ordinateur portable et supprimé avant de se propager peut ne pas être important. Dans les deux cas, consignez les raisons de votre décision.

Pour les fournisseurs de services d’informatique en nuage, de centres de données, de services gérés et les autres fournisseurs numériques couverts par le règlement d’exécution (UE) 2024/2690, le critère est plus concret. Son article 3, paragraphe 1, point e), considère comme important « un accès non autorisé effectif au réseau et aux systèmes d’information d’une entité concernée, qui est suspecté d’être malveillant » et susceptible de causer une perturbation opérationnelle grave. La plupart des incidents de rançongiciel commencent exactement ainsi. Une perte financière directe supérieure à 500 000 EUR ou à 5 % du chiffre d’affaires annuel, le montant le plus faible étant retenu, est un déclencheur distinct. Le critère complet est expliqué dans ce qui rend un incident important au sens de NIS2.

Que faut-il déclarer après une attaque par ransomware, et quand ?

Le délai commence lorsque vous avez connaissance d’un incident important, et non lorsque l’attaquant s’est introduit. L’article 23, paragraphe 4, fixe ensuite la séquence :

1. Alerte précoce, dans les 24 heures. Le cas échéant, elle indique si l’on soupçonne que l’incident a été causé par des actes illicites ou malveillants, ou s’il pourrait avoir un impact transfrontière. Pour un rançongiciel, la réponse à la première question est presque toujours oui.
2. Notification d’incident, dans les 72 heures. Une mise à jour de l’alerte précoce, une évaluation initiale de la gravité et de l’impact, et des indicateurs de compromission lorsqu’ils sont disponibles. Pour un rançongiciel, il s’agit généralement d’empreintes (hashes) de fichiers, d’adresses IP et de domaines de l’attaquant, de la note de rançon et de l’extension ajoutée aux fichiers chiffrés.
3. Rapport final, dans un délai d’un mois après la notification. Une description détaillée, le type de menace ou la cause profonde, les mesures d’atténuation appliquées et en cours, et l’éventuel impact transfrontière. Pour un rançongiciel, la cause profonde est l’accès initial : un compte victime d’hameçonnage, un boîtier VPN non corrigé, l’accès à distance d’un fournisseur.

Le CSIRT ou l’autorité peut demander des rapports intermédiaires, et un incident toujours en cours à l’échéance d’un mois donne d’abord lieu à un rapport d’avancement. Les rapports sont adressés à votre CSIRT national ou, le cas échéant, à l’autorité compétente. Le CSIRT répond sans retard injustifié et, si possible, dans les 24 heures suivant l’alerte précoce. Lorsque l’incident est suspecté d’être de nature criminelle, il fournit aussi des orientations sur la manière de signaler l’incident important aux services répressifs (art. 23, par. 5). Une notification NIS2 n’est pas une plainte pénale. Déposer plainte est une démarche distincte, régie par le droit national.

Lorsque c’est approprié, vous informez aussi sans retard injustifié les destinataires de vos services des incidents importants susceptibles de nuire à la fourniture de ces services (art. 23, par. 1). Le même paragraphe précise que le simple fait de notifier n’expose pas l’entité qui notifie à une responsabilité accrue. Les détails figurent dans le calendrier de notification des incidents NIS2.

NIS2 autorise-t-elle le paiement d’une rançon ?

NIS2 ne réglemente pas le paiement des rançons. Aucun article n’interdit de payer, ne soumet le paiement à une autorisation ni ne vous oblige à déclarer que vous avez payé, ou combien. Les rançongiciels apparaissent dans les considérants, qui éclairent le texte mais ne créent pas d’obligations.

• Le considérant 54 relève « une augmentation exponentielle des attaques de rançongiciels » et se termine ainsi : « Les États membres devraient élaborer une politique s’attaquant à l’augmentation des attaques de rançongiciels dans le cadre de leur stratégie nationale en matière de cybersécurité. »
• Le considérant 56 indique que certaines PME sont confrontées à un niveau accru de menaces, « comme les rançongiciels, pour lesquels elles devraient recevoir des orientations et une assistance ».

Aucun des deux ne dit si une rançon peut être payée. L’article 7, paragraphe 2, qui énumère les politiques qu’une stratégie nationale doit comporter, ne mentionne pas les rançongiciels.

D’autres règles, en revanche, s’appliquent au paiement :

• Sanctions de l’UE. Le règlement (UE) 2019/796 du Conseil concernant des mesures restrictives contre les cyberattaques prévoit qu’aucun fonds n’est mis, directement ou indirectement, à la disposition des personnes énumérées à son annexe I (art. 3, par. 2). D’autres régimes disent la même chose, par exemple le règlement (UE) n° 269/2014 (art. 2, par. 2). Le problème pratique : vous savez rarement qui contrôle un portefeuille de cryptomonnaie.
• Droit national. Le droit pénal, l’application des sanctions et les règles d’assurance diffèrent d’un État membre à l’autre. Vérifiez les vôtres avant un incident, pas pendant.
• Organismes publics. Selon la Commission, l’Union a souscrit, dans le cadre de l’International Counter Ransomware Initiative, à une déclaration non contraignante selon laquelle les institutions concernées relevant de l’autorité des gouvernements nationaux participants ne devraient pas payer les demandes d’extorsion liées aux rançongiciels (considérant 10 de COM(2026) 13). Ce n’est pas du droit.

Payer ne met fin à aucune de vos obligations. Les rapports à 24 heures, à 72 heures et à un mois restent dus, et des données copiées vers l’extérieur restent une violation de données à caractère personnel. En pratique, réservez la décision à l’organe de direction, prenez un avis juridique et consignez la décision avec ses motifs.

Que changerait la proposition COM(2026) 13 ?

Le 20 janvier 2026, la Commission a proposé des modifications ciblées de NIS2 (COM(2026) 13). En septembre 2026, il s’agit d’une proposition, pas de droit en vigueur. Deux modifications concernent les rançongiciels :

• Nouvel article 23, paragraphe 12. Lorsque la Commission adopte des actes d’exécution sur le type d’informations, le format et la procédure des notifications, elle serait tenue d’exiger des informations indiquant si l’entité a détecté une attaque par rançongiciel, quel a été le vecteur d’attaque et si des mesures d’atténuation ont été mises en œuvre.
• Nouvel article 23, paragraphe 13. En cas d’incident important causé par un rançongiciel, les entités devraient répondre, à la demande du CSIRT ou de l’autorité compétente et par un canal mis à disposition par celui-ci ou celle-ci, aux questions suivantes. L’entité a-t-elle reçu une demande de rançon et, le cas échéant, de qui ? Une rançon a-t-elle été payée ? Si oui, le montant, le moyen de paiement et le destinataire, y compris, le cas échéant, le crypto-actif et le prestataire de services sur crypto-actifs.

Les informations sur le paiement étant sensibles, elles ne seraient communiquées que sur demande, et les entités sont encouragées à désigner un point de contact pour ces échanges (considérant 10). La proposition n’interdirait toujours pas le paiement. Dans tous les cas, conservez une trace de la demande, de la décision et de tout paiement : le rapport final, votre assureur et les services répressifs vous les demanderont.

Quelles mesures de l’article 21 comptent le plus contre les rançongiciels ?

L’article 21, paragraphe 2, ne mentionne pas les rançongiciels, mais six de ses dix mesures minimales déterminent l’issue d’une attaque par rançongiciel. Le considérant 49 décrit un socle de cyberhygiène qui se lit comme une liste anti-rançongiciel : mises à jour logicielles et matérielles, changements de mot de passe, « la restriction des comptes d’accès de niveau administrateur et la sauvegarde de données ».

Mesure de l’article 21, paragraphe 2	Pourquoi elle compte face à un rançongiciel	À quoi ressemble une bonne pratique
(c) Continuité des activités : gestion des sauvegardes, reprise des activités, gestion des crises	Détermine si vous pouvez restaurer sans payer	Une copie hors ligne ou immuable, des restaurations testées, des délais de reprise connus
(b) Gestion des incidents	Détermine la rapidité de détection et de confinement	Alertes sur les modifications massives de fichiers et l’usage abusif des droits d’administration, pouvoir d’isoler
(e) Traitement des vulnérabilités	Les systèmes exposés sur internet et non corrigés sont un point d’entrée fréquent	Services exposés inventoriés et corrigés dans un délai fixé
(j) MFA, selon les besoins	Les mots de passe volés sont un point d’entrée fréquent	MFA sur l’accès à distance, la messagerie et chaque compte d’administration
(i) Contrôle d’accès et gestion des actifs	Limite la propagation de l’attaquant	Peu d’administrateurs de domaine, comptes d’administration séparés, actifs connus
(g) Cyberhygiène et formation	L’hameçonnage est à l’origine de nombreuses attaques	Une formation courte et régulière, et un moyen simple de signaler un e-mail suspect

Une observation tirée de la pratique : une sauvegarde accessible à l’administrateur du domaine de production est généralement chiffrée lors de la même attaque. « Nous avons des sauvegardes » et « nous pouvons restaurer » sont deux affirmations différentes.

L’article 20 impose à l’organe de direction d’approuver ces mesures et d’en superviser la mise en œuvre, et ses membres doivent suivre une formation. Un exercice sur table fondé sur un scénario de rançongiciel, question du paiement comprise, répond aux deux exigences. Voir la formation NIS2 des dirigeants et des salariés et les dix mesures dans les mesures de l’article 21 de NIS2 expliquées.

Que se passe-t-il si le rançongiciel a atteint des données personnelles ?

Le RGPD s’applique alors en parallèle. Chiffrer des données à caractère personnel est une violation de la disponibilité ; les copier vers l’extérieur est une violation de la confidentialité. En vertu de l’article 33 du RGPD, le responsable du traitement notifie la violation à l’autorité de contrôle « dans les meilleurs délais et, si possible, 72 heures au plus tard » après en avoir pris connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les personnes. Si elle est susceptible d’engendrer un risque élevé, les personnes concernées sont également informées (art. 34).

Les lignes directrices 01/2021 du CEPD examinent quatre cas de rançongiciel. Dans le premier, une sauvegarde adéquate a permis une restauration rapide et aucune donnée n’a été exfiltrée : la notification n’était donc pas requise. Toute violation doit néanmoins être documentée en vertu de l’article 33, paragraphe 5. Dans les trois autres, la notification était requise : absence de sauvegarde adéquate, exfiltration, ou un hôpital où même une restauration en deux jours a retardé les soins.

Le délai RGPD commence lorsque vous avez connaissance d’une violation de données à caractère personnel, ce qui peut intervenir plusieurs heures après le début du délai NIS2. Deux autorités, deux délais, un seul ensemble de faits : NIS2 et RGPD propose une procédure commune.

Ransomware et NIS2 : les 24 premières heures

Une séquence raisonnable pour le premier jour, pas une exigence légale. Adaptez-la à votre portail national de notification et à votre propre plan.

RANÇONGICIEL : LES 24 PREMIÈRES HEURES (NIS2)

HEURE 0  DÉTECTER ET CONSIGNER
  [ ] Ouvrir un seul dossier d'incident : ID, heure 1re alerte (UTC)
  [ ] Consigner qui a eu connaissance de quoi, et quand
  [ ] Conserver la note de rançon, des fichiers chiffrés, les journaux

HEURE 0-2  CONTENIR
  [ ] Isoler les hôtes et segments touchés ; éviter de les éteindre
  [ ] Désactiver les comptes compromis ; réinitialiser les accès admin
  [ ] Sauvegardes : accessibles à l'attaquant ? dernière copie saine ?

HEURE 1-4  DÉCIDER
  [ ] Incident important ? Perturbation grave, pertes financières,
      dommages à d'autres (NIS2 art. 23, par. 3). Consigner décision,
      heure
  [ ] Données personnelles chiffrées ou copiées ? Lancer l'analyse RGPD
  [ ] Réunir la cellule de crise ; informer l'organe de direction

HEURE 4-24  NOTIFIER
  [ ] Alerte précoce au CSIRT ou à l'autorité compétente,
      art. 23, par. 4, point a)
      acte illicite ou malveillant suspecté : oui
      impact transfrontière possible : oui / non / inconnu
  [ ] Informer les destinataires des services si approprié,
      art. 23, par. 1
  [ ] Services répressifs : suivre les orientations du CSIRT
      et les règles nationales
  [ ] Demande de rançon : aucun contact sans avis juridique ;
      contrôle des sanctions avant toute décision de paiement

PROCHAINES ÉCHÉANCES
  [ ] Notification d'incident NIS2 avec IoC : 72 h après connaissance
  [ ] Notification RGPD, si requise : 72 h après connaissance
      de la violation
  [ ] Rapport final NIS2 : 1 mois après la notification d'incident

Ce que NIS2 laisse ouvert, et comment combler l’écart

NIS2 parle de « gestion des sauvegardes ». Elle ne dit pas combien de copies conserver, si l’une doit être hors ligne, ni à quelle fréquence tester une restauration. Elle parle d’authentification à plusieurs facteurs « selon les besoins », sans préciser sur quels comptes. Elle parle de gestion des incidents, sans dire qui peut couper un site du réseau à trois heures du matin. Ces choix vous reviennent, et votre analyse des risques doit les justifier.

Après un incident, les questions de l’autorité portent sur les preuves, qu’elle peut exiger en vertu des articles 32 et 33. À quand remonte la dernière restauration réussie ? Le compte utilisé par l’attaquant était-il protégé par MFA ? Depuis combien de temps la vulnérabilité exploitée était-elle ouverte ? Une politique indiquant que les sauvegardes sont testées tous les mois n’y répond pas. Le journal des restaurations, si.

Ces preuves se trouvent dans votre système de sauvegarde, votre fournisseur d’identité, vos outils de protection des postes et votre gestion des correctifs. Collectées à la main avant un audit, elles décrivent un état passé. Collectées en continu, avec une personne qui examine les exceptions, elles révèlent le compte administrateur sans MFA ou la tâche de sauvegarde arrêtée depuis trois semaines avant qu’un attaquant ne les trouve. C’est ainsi que fonctionne la plateforme CloudSoul : une collecte automatisée, avec une expertise humaine dans la boucle. Un audit de sécurité mené sur un scénario de rançongiciel montre où vous en êtes, et le programme dans son ensemble est présenté sur la page conformité NIS2.

Liste de contrôle NIS2 contre les rançongiciels

• Définissez ce qui constitue un incident important pour vos services, avec des exemples, avant d’en avoir besoin.
• Conservez au moins une copie de sauvegarde inaccessible aux comptes d’administration de production, et testez une restauration.
• Imposez la MFA sur l’accès à distance, la messagerie et tous les comptes d’administration, et mesurez la couverture.
• Corrigez les systèmes exposés sur internet dans un délai que vous fixez et suivez.
• Exercez-vous à l’alerte précoce à 24 heures : qui décide, qui l’envoie, par quel canal.
• Décidez à l’avance qui peut approuver ou refuser le paiement d’une rançon, avec un avis juridique sur les sanctions.
• Organisez avec l’organe de direction un exercice sur table consacré à un rançongiciel, y compris les décisions NIS2 et RGPD.

Sources

• Directive (UE) 2022/2555 (NIS2), articles 7, 20, 21, 23, 32 et 33 et considérants 49, 54 et 56, EUR-Lex.
• Règlement d’exécution (UE) 2024/2690 de la Commission, article 3, EUR-Lex.
• Règlement (UE) 2016/679 (RGPD), articles 33 et 34, EUR-Lex.
• Lignes directrices 01/2021 du CEPD sur des exemples de notification de violations de données à caractère personnel, CEPD.
• Règlement (UE) 2019/796 du Conseil concernant des mesures restrictives contre les cyberattaques qui menacent l’Union ou ses États membres, article 3, EUR-Lex.
• Règlement (UE) n° 269/2014 du Conseil, article 2, EUR-Lex.
• Proposition de directive modifiant la directive (UE) 2022/2555, COM(2026) 13, 20 janvier 2026, EUR-Lex.

Questions fréquentes