NIS2: la directive pour la cyber-résilience de l’UE.

Ce qu’est NIS2

NIS2, la directive (UE) 2022/2555, est le cadre juridique de l’UE pour la sécurité des réseaux et de l’information dans les secteurs critiques et importants. Publiée le 27 décembre 2022 et entrée en vigueur le 16 janvier 2023, elle a remplacé la directive NIS de 2016 (directive (UE) 2016/1148) avec un périmètre nettement élargi, des obligations de sécurité renforcées, une déclaration d’incidents harmonisée et une responsabilité personnelle de la direction.

NIS2 est une directive, non un règlement. Cette distinction compte : un règlement s’applique directement dans toute l’UE sans mesures nationales de mise en œuvre, tandis qu’une directive doit être transposée dans le droit national de chaque État membre. La date limite de transposition était le 17 octobre 2024. En pratique, tous les États membres n’ont pas respecté ce délai, ce qui signifie que les obligations exactes, l’organe de supervision et l’approche d’application diffèrent selon l’UE. Lorsque votre équipe juridique évalue l’exposition à NIS2, elle doit évaluer la loi nationale de transposition des États membres où vous opérez, et non seulement le texte de la directive.

Ce que signifie NIS2 : sécurité des réseaux et de l’information. NIS2 est l’abréviation de la directive de cybersécurité de deuxième génération, qui succède à NIS1.

Ce qui a changé entre la directive NIS et NIS2

NIS2 n’est pas une mise à jour mineure. La version 2022 a refondu la directive de 2016 sur le périmètre, les obligations, la responsabilité et l’application.

À qui s’applique NIS2

Le périmètre est la question pratique la plus difficile. La plupart des équipes conformité sous-estiment sa portée. NIS2 s’applique aux entités qui : (1) sont d’un type listé à l’Annexe I ou à l’Annexe II, (2) fournissent des services ou opèrent dans l’UE, et (3) atteignent ou dépassent le seuil de taille (moyenne : 50 employés ou plus, ou 10 millions d’EUR ou plus de chiffre d’affaires ou de bilan annuel). Certaines entités sont dans le périmètre quelle que soit leur taille.

NIS2 distingue deux types d’entités. Les entités essentielles font l’objet d’une supervision plus stricte : une surveillance proactive, ex ante, par l’autorité nationale compétente, qui peut auditer sans déclencheur d’incident. Les entités importantes font l’objet d’une supervision réactive : l’autorité agit après un incident, une plainte ou des éléments de non-conformité. Les deux doivent mettre en œuvre les mêmes dix mesures de sécurité de l’article 21. La distinction affecte l’intensité de la supervision et certains plafonds de sanction, non l’ensemble des obligations.

NIS2 étant une directive, « dans le périmètre » signifie dans le périmètre au titre de la loi nationale de transposition de l’État membre concerné. Les lois nationales peuvent étendre le périmètre au-delà du minimum de la directive, et plusieurs États membres l’ont fait.

Secteurs de l’Annexe I et de l’Annexe II

NIS2 couvre 18 secteurs répartis entre deux annexes. Les secteurs de l’Annexe I sont traités comme d’une criticité plus élevée : les grandes entités de ces secteurs sont des entités essentielles, les entités moyennes sont des entités importantes. Les secteurs de l’Annexe II produisent des entités importantes, que l’entité soit grande ou moyenne.

La catégorisation sectorielle compte pour l’auto-évaluation, mais le test définitif est toujours la loi nationale de transposition. Certains États membres ont ajouté des secteurs ou ajusté les définitions.

Le seuil de taille, et pourquoi la chaîne d’approvisionnement compte

Le seuil de taille de référence pour le périmètre NIS2 est la définition européenne de l’entreprise de taille moyenne : 50 employés ou plus, ou 10 millions d’EUR ou plus de chiffre d’affaires ou de bilan annuel. Les entités sous ce seuil dans les secteurs de l’Annexe I ou II sont généralement hors périmètre, sauf exceptions ci-dessous.

Inclusions indépendantes de la taille : les prestataires de services de confiance qualifiés et les registres de noms de domaine de premier niveau (TLD) sont des entités essentielles quelle que soit leur taille. Les fournisseurs de services DNS et les fournisseurs de réseaux ou services de communications électroniques publics de taille au moins moyenne sont essentiels. Les entités de l’administration publique sont essentielles quelle que soit leur taille. Les États membres peuvent désigner des entités supplémentaires.

L’angle chaîne d’approvisionnement : l’article 21(d) de NIS2 exige des entités couvertes qu’elles gèrent la sécurité de la chaîne d’approvisionnement, y compris les pratiques de sécurité des fournisseurs et prestataires directs. Cela signifie qu’une entité suisse ou hors UE qui fournit un logiciel, une infrastructure cloud ou des services gérés à une entité couverte de l’UE fera face à des exigences de sécurité NIS2 contractuelles dans le cadre de cette relation client, même si le fournisseur n’est pas lui-même directement soumis à la directive. C’est le mécanisme par lequel NIS2 dépasse les frontières de l’UE.

Pour les entités suisses en particulier : la Suisse n’est pas un État membre de l’UE et NIS2 ne s’applique pas directement. Le droit suisse prévoit des exigences de sécurité de l’information au titre de la LSI (loi sur la sécurité de l’information) et de la législation connexe pour les organes fédéraux et les infrastructures critiques. Toutefois, les entreprises suisses qui exploitent des filiales dans l’UE, fournissent des services numériques à des utilisateurs de l’UE ou approvisionnent des entités couvertes de l’UE rencontreront des obligations NIS2 via leurs activités dans l’UE ou leurs contrats clients.

Calendrier de NIS2 et transposition nationale

NIS2 a été publiée au Journal officiel de l’UE le 27 décembre 2022 et est entrée en vigueur le 16 janvier 2023. Les États membres avaient jusqu’au 17 octobre 2024 pour la transposer en droit national et le notifier à la Commission. Tous les États membres n’ont pas respecté ce délai. À la mi-2025, plusieurs avaient transposé tardivement, et certaines transpositions étaient encore en attente.

NIS2 étant une directive plutôt qu’un règlement, les obligations applicables dans un État membre proviennent de la loi nationale de cet État, non directement du texte de la directive. Cela a des conséquences pratiques : les définitions utilisées, l’autorité compétente désignée, les fourchettes de sanction exactes (dans les plafonds de la directive) et les obligations d’enregistrement varient toutes selon l’État membre. Les entités opérant dans plusieurs pays de l’UE doivent évaluer leur conformité par rapport à chaque loi nationale pertinente.

Article 21 : les dix mesures de sécurité requises

L’article 21 est l’article central des obligations. Il exige des entités essentielles et importantes qu’elles prennent des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour gérer les risques de cybersécurité et prévenir ou minimiser l’impact des incidents. Les mesures doivent reposer sur une approche tous risques et être proportionnées au niveau de risque, à la taille de l’entité et à l’impact qu’aurait un incident potentiel.

Les dix catégories de mesures sont spécifiées à l’article 21(2). Les États membres ne peuvent pas imposer d’exigences de cybersécurité supplémentaires au-delà de celles-ci, sauf autorisation spécifique du droit national.

Le calendrier de déclaration d’incident de NIS2

L’article 23 fixe les obligations de déclaration pour les incidents importants. Un incident important est un incident qui cause ou est susceptible de causer une perturbation opérationnelle grave, une perte financière ou un préjudice à autrui. L’horloge de déclaration court à partir du moment où l’entité a connaissance de l’incident, non du moment où il s’est produit.

Les entités déclarent à leur CSIRT national (ou à l’autorité compétente lorsqu’aucun CSIRT n’est désigné). Les entités également soumises à la déclaration d’incident de DORA utilisent le régime DORA pour les incidents liés aux TIC ; voir la section NIS2 et DORA ci-dessous.

Le défi pratique : l’horloge de 24 heures est très serrée. De nombreuses organisations constatent que détecter un incident, le classer comme important, escalader vers l’équipe habilitée à notifier, et déposer effectivement l’alerte précoce dans les 24 heures nécessite des flux préétablis, des messages pré-approuvés et un arbre de décision clair, tout cela avant tout incident. Construire ce flux après le début d’un incident, c’est trop tard.

Responsabilité du conseil et de la direction au titre de NIS2

L’article 20 est l’une des dispositions les plus lourdes de conséquences opérationnelles dans NIS2, et celle qui surprend le plus souvent les conseils qui la découvrent. Il exige des organes de direction qu’ils approuvent les mesures de gestion des risques de cybersécurité et supervisent leur mise en œuvre. Les membres de l’organe de direction sont personnellement responsables des infractions.

La disposition de responsabilité personnelle signifie que le dirigeant de l’organe de direction ou, lorsque le droit national le prévoit, chaque membre de l’organe de direction peut être tenu directement responsable des violations des obligations NIS2. Les conséquences précises (amendes, interdictions temporaires de fonctions de direction) dépendent des transpositions nationales, mais la directive elle-même crée explicitement cette responsabilité.

L’article 20 exige aussi des États membres qu’ils veillent à ce que les organes de direction des entités essentielles et importantes suivent une formation à la cybersécurité, et qu’ils offrent une formation similaire à leurs employés régulièrement. Ce n’est pas optionnel : c’est une obligation de conformité, non une bonne pratique.

Là où les entités peinent réellement : traduire l’article 20 en pratique de conseil. La supervision requise n’est pas une approbation unique d’une politique de sécurité. Elle implique un reporting régulier au niveau du conseil sur les mesures de sécurité, une conscience des risques significatifs, et des preuves documentées que le conseil a revu et approuvé les mesures. Lors d’une inspection de l’autorité compétente, le conseil ne peut pas simplement désigner une équipe de sécurité et dire « c’est elle qui s’en occupe ».

Le cadre de sanctions de NIS2

Les articles 36 et 37 fixent les plafonds de sanction maximaux. La directive spécifie des minimums de ce que les États membres doivent rendre disponible ; les transpositions nationales peuvent fixer des structures de sanction précises dans ces plafonds. Certains États membres ont introduit des amendes administratives ; d’autres recourent à la responsabilité pénale de la direction ou à des mécanismes d’application civile.

Les plafonds de sanction sont exprimés comme le plus élevé d’un maximum fixe ou d’un pourcentage du chiffre d’affaires annuel mondial, s’appliquant au chiffre d’affaires mondial de l’entité et de son groupe le cas échéant. Cela reflète la structure du RGPD et est conçu de façon similaire pour être proportionné à la taille des grandes organisations mondiales.

Des mesures non financières sont aussi disponibles : les autorités compétentes peuvent émettre des instructions contraignantes, exiger la mise en œuvre de mesures de sécurité spécifiques, divulguer publiquement la non-conformité, et interdire temporairement à des membres de l’organe de direction d’exercer des fonctions de direction.

NIS2 et DORA : le recoupement pour les entités financières

Pour les entités soumises à DORA (règlement (UE) 2022/2554), la relation entre les deux cadres est régie par une règle lex specialis. DORA est le texte sectoriel de l’UE pour le risque TIC dans les services financiers. Au titre de l’article 4(2) de NIS2, lorsqu’un acte juridique sectoriel de l’Union exige des entités essentielles ou importantes qu’elles adoptent des mesures de gestion des risques de cybersécurité ou notifient les incidents aux autorités compétentes, et lorsque ces exigences sont au moins équivalentes à NIS2, les dispositions sectorielles s’appliquent.

En pratique : les entités financières soumises à DORA suivent DORA pour la gestion des risques TIC (chapitre II), la classification et la déclaration des incidents TIC majeurs (chapitre III), les tests de résilience opérationnelle numérique (chapitre IV), la gestion du risque TIC lié aux tiers (chapitre V) et le partage d’informations (chapitre VI). Elles ne mènent pas de programme de conformité NIS2 distinct pour ces domaines. Là où DORA n’offre pas de couverture équivalente (ce qui est limité), NIS2 s’applique comme socle.

Le canal de supervision diffère aussi. Les entités financières DORA déclarent les incidents TIC majeurs à leur superviseur financier national (banque centrale, autorité des marchés financiers, superviseur des assurances) plutôt qu’à l’autorité nationale compétente NIS2. Pour les entités relevant des deux, cela suppose de garder au clair quel canal de déclaration s’applique à quel type d’incident.

L’implication pratique : une banque ou une entreprise d’investissement déjà conforme à DORA est en grande partie conforme aux exigences NIS2 équivalentes. Les cadres de gestion des risques, les flux d’incidents, le programme de risque lié aux tiers et les tests de résilience couverts par DORA recoupent étroitement l’article 21 de NIS2. Mener les deux dans Acuna avec une bibliothèque de mesures partagée signifie que le recoupement est cartographié une fois, non maintenu deux fois.

Comment NIS2 se cartographie vers ISO 27001 et DORA

NIS2 et ISO 27001 se recoupent étroitement au niveau des mesures. Une organisation menant ISO 27001 dispose déjà d’une grande partie du socle de l’article 21 : appréciation des risques, contrôle d’accès, gestion des incidents, continuité d’activité, sécurité des fournisseurs, cryptographie et formation se cartographient toutes vers les mesures de l’Annexe A d’ISO 27001. NIS2 n’exige pas la certification ISO 27001, mais les organisations dotées d’un SMSI mature verront leur effort de conformité nettement réduit.

Le tableau cartographie des mesures sélectionnées de l’article 21 de NIS2 vers leurs équivalents ISO 27001 et, lorsque DORA s’applique, vers les chapitres DORA. Mener les trois dans Acuna signifie que la bibliothèque de mesures est construite une fois et réutilisée entre référentiels, et que la cartographie inter-référentiels est maintenue automatiquement.

Exécuter NIS2 dans Acuna

Acuna est conçue pour la façon dont NIS2 arrive réellement sur les équipes conformité : aux côtés d’ISO 27001, de DORA et du RGPD, partageant mesures, preuves et données de risque entre référentiels plutôt que de mener chacun comme un projet isolé.

Pour NIS2 en particulier : le volet Comply guide le cadrage essentielle vs importante, cartographie les dix mesures de l’article 21 sur votre périmètre organisationnel, et documente le cadre de gestion des risques de cybersécurité. Supplier Shield gère les obligations de chaîne d’approvisionnement de l’article 21(d) : évaluations des risques liés aux tiers, exigences de sécurité contractuelles et surveillance continue. Le flux d’incidents applique les horloges de notification de 24 et 72 heures avec des chemins de remontée préétablis et des modèles de notification en brouillon. Le volet Assure tient la piste de preuves pour le contrôle de l’autorité compétente, y compris l’approbation au niveau du conseil et les registres de formation exigés par l’article 20.

Pour les entités soumises à la fois à NIS2 et à DORA : le moteur de cartographie inter-référentiels d’Acuna identifie quelles mesures satisfont les deux ensembles d’exigences, de sorte qu’une seule mise en œuvre de mesure produit des preuves pour les deux référentiels. Les équipes menant déjà DORA dans Acuna étendent leur programme vers NIS2 sans reconstruire la bibliothèque de mesures.

Voyez comment Acuna soutient la conformité NIS2.