Exigences NIS2 en matière de test d'intrusion et d'évaluation des vulnérabilités : ce qui est obligatoire et ce qui relève de l'approche par les risques

Pas en le nommant. L'article 21 de la directive (UE) 2022/2555 énumère dix mesures minimales, et aucune d'entre elles n'est le « test d'intrusion ». Le terme n'apparaît que dans les considérants, dans une phrase sur les fournisseurs de services de sécurité gérés qui proposent des tests d'intrusion, et comme outil que les autorités de contrôle peuvent elles-mêmes utiliser.

Ce que la directive exige, en revanche, c'est un ensemble de résultats difficiles à prouver sans tests :

• Art. 21, paragraphe 2, point e) : la sécurité de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris le traitement et la divulgation des vulnérabilités.
• Art. 21, paragraphe 2, point f) : des politiques et des procédures pour évaluer l'efficacité des mesures de gestion des risques en matière de cybersécurité.
• Art. 21, paragraphe 1 : des mesures appropriées et proportionnées au risque, compte tenu de l'état de l'art, du degré d'exposition de l'entité, de sa taille, ainsi que de la probabilité et de la gravité des incidents.
• Art. 21, paragraphe 4 : une entité qui constate qu'elle n'est pas conforme doit prendre des mesures correctives sans retard injustifié.

La formulation explicite arrive un niveau plus bas. Le règlement d'exécution (UE) 2024/2690 transforme ces points en exigences de tests et de gestion des vulnérabilités pour les fournisseurs d'infrastructures numériques et de services TIC, et en Italie les mesures de base de l'ACN inscrivent « vulnerability assessment e/o penetration test » parmi les exigences applicables aux entités essentielles. Quiconque vous affirme que NIS2 impose un test d'intrusion annuel à toutes les entités exagère le texte ; quiconque vous affirme que les tests sont facultatifs sous-estime ce que les articles 21 et 32 vous obligent à prouver.

Les articles 32 et 33 donnent aux autorités compétentes le pouvoir de vous tester et de vous demander les résultats de vos propres tests. Pour les entités essentielles (art. 32, paragraphe 2), la supervision est ex ante : inspections sur place et contrôles à distance, y compris des contrôles aléatoires, audits de sécurité réguliers et ciblés réalisés par un organisme indépendant ou par l'autorité, audits ad hoc, scans de sécurité fondés sur des critères d'évaluation des risques objectifs, et demandes de preuves de la mise en œuvre des politiques de cybersécurité, telles que les résultats des audits de sécurité réalisés par un auditeur qualifié et les éléments de preuve sous-jacents correspondants.

Pour les entités importantes (art. 33), les mêmes outils, sans audits réguliers, sont utilisés ex post, lorsque l'autorité dispose de preuves, d'indications ou d'informations faisant état d'une non-conformité.

En Italie, l'ACN applique la même distinction. Sa FAQ sur la supervision (MVE.3) précise que les inspections des entités essentielles, y compris les contrôles aléatoires, peuvent être ordonnées ex ante, tandis que les entités importantes ne peuvent être inspectées que lorsque l'ACN dispose de preuves ou d'informations suggérant une violation possible (art. 36, comma 2, D.Lgs. 138/2024). C'est donc le plus souvent après un incident qu'une entité importante se verra demander ses registres de tests, soit le pire moment pour découvrir qu'ils n'existent pas.

La Commission a adopté le règlement d'exécution (UE) 2024/2690 le 17 octobre 2024 en vertu de l'art. 21, paragraphe 5, de NIS2. Il est directement applicable et couvre une liste définie d'entités concernées : fournisseurs de services DNS, registres des noms de domaine de premier niveau, fournisseurs de services d'informatique en nuage, fournisseurs de services de centres de données, fournisseurs de réseaux de diffusion de contenu, fournisseurs de services gérés, fournisseurs de services de sécurité gérés, places de marché en ligne, moteurs de recherche en ligne, plateformes de services de réseaux sociaux et prestataires de services de confiance. Pour les autres secteurs, il n'est pas contraignant, mais c'est la lecture la plus détaillée de l'art. 21, paragraphe 2, que l'UE ait publiée.

Les points de l'annexe qui comptent pour les tests :

• 6.5 Tests de sécurité : une politique et des procédures de tests de sécurité ; la nécessité, le périmètre, la fréquence et le type des tests établis sur la base de l'analyse des risques ; des tests réalisés selon une méthodologie documentée, couvrant les composants identifiés comme pertinents pour un fonctionnement sûr ; le type, le périmètre, la date et les résultats documentés, y compris l'évaluation de la criticité et les mesures d'atténuation pour chaque constat ; des mesures d'atténuation appliquées pour les constats critiques ; une politique réexaminée à intervalles planifiés.
• 6.10 Traitement et divulgation des vulnérabilités : surveiller les informations sur les vulnérabilités provenant des CSIRT, des autorités et des fournisseurs ; effectuer, lorsqu'il y a lieu, des scans de vulnérabilités et consigner la preuve de leurs résultats, à intervalles planifiés ; traiter sans retard injustifié les vulnérabilités critiques pour les opérations ; maintenir le traitement des vulnérabilités compatible avec la gestion des changements, des correctifs, des risques et des incidents ; établir une procédure de divulgation conforme à la politique nationale de divulgation coordonnée des vulnérabilités. Lorsqu'une vulnérabilité ne nécessite pas de remédiation, il faut documenter et justifier pourquoi (6.10.3).
• 7 Évaluation de l'efficacité : une politique et des procédures qui définissent ce qui est mesuré, les méthodes, quand, par qui, et quand et par qui les résultats sont évalués.
• 2.3 Examen indépendant : l'approche globale de la sécurité des réseaux et des systèmes d'information fait l'objet d'un examen indépendant, par des personnes disposant de compétences en audit et extérieures à la ligne hiérarchique du domaine examiné, à intervalles planifiés et après des incidents ou des changements importants.

Le considérant 15 cite les tests envisagés : tests automatisés ou manuels, tests d'intrusion, scans de vulnérabilités, tests statiques et dynamiques de sécurité des applications, tests de configuration et audits de sécurité, réalisés lors de la mise en place, après des mises à niveau ou des changements importants, ou après une maintenance. Il s'agit d'une liste d'options, pas d'une obligation. Une règle s'applique à toute l'annexe (art. 2, paragraphe 2) : lorsqu'une exigence s'applique « lorsqu'il y a lieu » et que vous décidez qu'elle ne l'est pas dans votre cas, vous devez documenter votre raisonnement de manière compréhensible.

L'article 24, comma 2, du D.Lgs. 138/2024 transpose l'art. 21, paragraphe 2, presque mot pour mot : la lettre e) couvre la gestion et la divulgation des vulnérabilités, la lettre f) les politiques et procédures d'évaluation de l'efficacité des mesures de gestion des risques. Le détail vient de l'ACN. La determinazione ACN 379907 du 19 décembre 2025, qui a remplacé la determinazione 164179 du 14 avril 2025 et s'applique depuis le 15 janvier 2026, fixe les mesures de sécurité de base dans deux annexes : Allegato 1 pour les entités importantes, Allegato 2 pour les entités essentielles. Les mesures suivent les codes du cadre national italien pour la cybersécurité et la protection des données (Framework nazionale per la Cybersecurity e la Data Protection, édition 2025), et chaque mesure comporte des exigences numérotées.

Les exigences relatives aux tests et aux vulnérabilités, telles qu'elles figurent dans les deux annexes :

• ID.RA-01, point 1 (les deux) : les informations sur les vulnérabilités recueillies au titre d'ID.RA-08 sont utilisées pour identifier les vulnérabilités des systèmes d'information et des réseaux.
• ID.RA-01, point 2 (entités essentielles uniquement) : pour au moins les systèmes d'information et réseaux pertinents, conformément au plan de gestion des vulnérabilités, et sauf raisons réglementaires ou techniques justifiées et documentées, des activités d'identification des vulnérabilités comprenant au moins une évaluation des vulnérabilités et/ou un test d'intrusion sont réalisées périodiquement et en tout état de cause avant la mise en production des systèmes.
• ID.RA-01, point 3 (entités essentielles uniquement) : ces activités sont documentées dans des rapports qui contiennent au moins une description générale des activités et de leurs résultats, ainsi qu'une description des vulnérabilités constatées avec leur niveau d'impact sur la sécurité.
• ID.RA-08 (les deux) : surveiller au moins les canaux du CSIRT Italia et des éventuels CERT et ISAC sectoriels ; corriger rapidement les vulnérabilités par des mises à jour de sécurité ou des mesures d'atténuation, ou accepter et documenter le risque dans le plan de traitement des risques ; tenir un plan de gestion des vulnérabilités, approuvé par les organes de direction, qui précise comment les vulnérabilités sont identifiées au titre d'ID.RA-01 et comment ces activités sont planifiées. Les entités essentielles surveillent également les canaux des fournisseurs de logiciels critiques.
• ID.IM-01, points 3 et 4 (entités essentielles uniquement) : un plan d'évaluation de l'efficacité des mesures de gestion des risques, indiquant quelles mesures sont évaluées et comment, avec des rapports périodiques aux organes de direction.
• PR.PS-02, point 4 (entités essentielles uniquement) : les mises à jour des logiciels critiques sont vérifiées dans un environnement de test avant la mise en production, conformément à l'analyse des risques.

Deux détails changent la manière de planifier. La formule « pour au moins les systèmes pertinents » vous permet de limiter le point 2 d'ID.RA-01 aux systèmes dont la compromission aurait un impact significatif sur les services pour lesquels vous êtes dans le périmètre (FAQ ACN MSB.7) : la liste des systèmes pertinents doit donc exister au préalable. Et le point 2 d'ID.RA-01 fait partie des exigences qui, si elles ne sont pas mises en œuvre pour des raisons réglementaires ou techniques documentées, doivent être couvertes par des mesures compensatoires décrites dans le plan de traitement des risques approuvé par les organes de direction (ID.RA-06, point 2, et tableau 2 de l'Allegato 2).

La determinazione 379907/2025 fixe deux délais, tous deux calculés à partir de la date à laquelle l'entité a reçu la communication de son inscription sur la liste des entités NIS (art. 3) :

• Mesures de sécurité de base (Allegati 1 et 2) : 18 mois. La presse italienne situe les premières communications d'inscription de l'ACN au 12 avril 2025 ; pour la cohorte 2025, l'échéance tombe donc au cours du mois d'octobre 2026 — comptez 18 mois à partir de votre propre communication, qui figure dans votre PEC ou dans la notification du portail, car la date n'est pas la même pour tout le monde.
• Notification des incidents significatifs de base (Allegati 3 et 4) : 9 mois, que l'ACN situe en janvier 2026 pour les entités inscrites en 2025.

La determinazione ACN 127434/2026, applicable depuis le 30 avril 2026, fixe des dates précises pour les entités inscrites pour la première fois au cours de 2026 : mesures de sécurité au plus tard le 31 juillet 2027, obligations de notification des incidents à partir du 1er janvier 2027. Les entités inscrites en 2025 qui restent sur la liste 2026 conservent les délais initiaux.

Entités essentielles et entités importantes partagent la même échéance ; ce qui diffère, c'est l'annexe qu'elles doivent mettre en œuvre. Pour une entité essentielle inscrite en 2025, le premier cycle périodique de VA/PT sur les systèmes pertinents, ses rapports et le plan de gestion des vulnérabilités approuvé par les organes de direction devraient donc déjà être en place, et les nouveaux systèmes mis en production doivent désormais faire l'objet de leur test avant mise en production.

Une fois le délai expiré, rien ne vous est notifié : l'obligation est simplement en vigueur, et la supervision suit la distinction décrite dans la section précédente — ex ante pour les entités essentielles, y compris par des contrôles aléatoires, ex post pour les entités importantes. Les annexes de la 379907/2025 comportent 87 exigences pour les entités importantes et 116 pour les entités essentielles ; la question pratique au 1er novembre n'est donc pas de savoir si chaque exigence est parfaite, mais si, pour chaque exigence relative aux tests, vous pouvez produire le document qui le prouve : le plan, la liste des systèmes pertinents, les rapports, le registre de remédiation. Lorsqu'une exigence n'est pas mise en œuvre pour des raisons réglementaires ou techniques documentées, la mesure compensatoire doit figurer dans le plan de traitement des risques approuvé par les organes de direction (ID.RA-06, point 2) — rédigée avant une inspection, pas pendant.

Avant de dimensionner un budget de tests, il est utile de distinguer le texte des idées reçues.

Écrit dans les règles :

• Toute entité NIS2 : le traitement et la divulgation des vulnérabilités, et des politiques et procédures d'évaluation de l'efficacité des mesures (art. 21, paragraphe 2, points e) et f)).
• Entités relevant du règlement 2024/2690 : une politique de tests de sécurité dont le périmètre, la fréquence et le type sont fixés par l'analyse des risques ; des résultats documentés avec la criticité et l'atténuation de chaque constat ; des scans de vulnérabilités à intervalles planifiés lorsqu'il y a lieu, avec des preuves consignées ; des examens indépendants.
• Entités essentielles italiennes : une évaluation des vulnérabilités et/ou un test d'intrusion au moins sur les systèmes pertinents, périodiquement et avant la mise en production, documentés dans des rapports ; un plan d'évaluation de l'efficacité.
• Entités importantes et essentielles italiennes : un plan de gestion des vulnérabilités approuvé par les organes de direction et une remédiation rapide ou une acceptation du risque documentée.

Écrit nulle part dans ces textes :

• Un test d'intrusion annuel en tant qu'obligation NIS2 universelle.
• Une fréquence fixe pour les scans ou les tests. « Périodiquement » et « à intervalles planifiés » désignent l'intervalle que vous fixez et justifiez.
• L'obligation de recourir à un testeur externe ou certifié. Le règlement 2024/2690 exige des compétences en audit et l'indépendance pour l'examen indépendant, pas pour chaque test.
• La red teaming fondé sur la menace ou le TLPT. C'est un instrument de DORA réservé aux entités financières désignées ; voir le TLPT dans DORA.

Les parties fondées sur les risques ne sont pas moins exigeantes. Lorsqu'un règlement vous laisse choisir la fréquence, un inspecteur vérifie que ce choix est écrit, qu'il découle de votre analyse des risques et qu'il a été effectivement appliqué.

Une évaluation des vulnérabilités recense les faiblesses connues sur de nombreux systèmes et les classe. Un test d'intrusion tente d'exploiter les faiblesses, les enchaîne et montre ce qu'un attaquant peut réellement atteindre. Le texte de l'ACN accepte l'un ou l'autre (« et/ou ») : le choix relève donc du plan de gestion des vulnérabilités, motifs à l'appui. Une structure facile à défendre :

1. Partez de la liste des systèmes pertinents. Sans elle, vous ne pouvez pas utiliser le périmètre « au moins les systèmes pertinents », et votre couverture n'est pas mesurable.
2. Évaluation des vulnérabilités sur tous les systèmes pertinents, à un intervalle fixé par votre analyse des risques, ainsi qu'après des changements importants et lorsque de nouvelles vulnérabilités touchant votre environnement sont publiées sur les canaux que vous surveillez.
3. Test d'intrusion là où l'exploitabilité est la question : services exposés sur Internet, accès distants, infrastructure d'identité et systèmes qui soutiennent les services pour lesquels vous êtes dans le périmètre. Testez depuis l'extérieur et depuis l'intérieur avec les accès d'un utilisateur standard ; voir tests en boîte noire et en boîte grise.
4. Tests avant mise en production pour les nouveaux systèmes pertinents et les versions majeures, comme l'exige le point 2 d'ID.RA-01 pour les entités essentielles.
5. Re-tests après remédiation, afin que chaque constat soit clôturé avec une preuve plutôt qu'avec un statut de ticket.

Si vous décidez qu'un système ne peut pas être testé, par exemple un composant OT fragile, consignez la raison réglementaire ou technique et les mesures compensatoires dans le plan de traitement des risques : c'est la voie que prévoient les annexes de l'ACN.

La FAQ MSB.11 de l'ACN énumère les types de documents qui étayent la mise en œuvre des mesures : listes, inventaires, plans, politiques, procédures et registres, tenus à jour et disponibles sur papier ou sous forme numérique. Pour les tests et la gestion des vulnérabilités, le dossier comprend généralement :

• Le plan de gestion des vulnérabilités (ID.RA-08, point 3) avec l'approbation des organes de direction, montrant comment les vulnérabilités sont identifiées et comment les tests sont planifiés.
• La liste des systèmes pertinents et le raisonnement qui la sous-tend.
• Les rapports de VA/PT comportant au minimum une description des activités, leurs résultats et chaque vulnérabilité avec son impact sur la sécurité (ID.RA-01, point 3, pour les entités essentielles).
• Les traces des tests avant mise en production pour les systèmes mis en service après l'échéance.
• Le registre de surveillance des canaux du CSIRT Italia, des CERT sectoriels et des ISAC, et, pour les entités essentielles, des fournisseurs de logiciels critiques.
• Les registres de remédiation : vulnérabilité, décision (corriger, atténuer ou accepter), responsable, dates, résultat du re-test, et chaque acceptation de risque dans le plan de traitement des risques approuvé par les organes de direction.
• Pour les entités essentielles, le plan d'évaluation de l'efficacité et les rapports périodiques aux organes de direction (ID.IM-01).
• Pour les entités relevant du règlement 2024/2690 : la politique de tests de sécurité, la méthodologie documentée, ainsi que la criticité et l'atténuation de chaque constat (point 6.5.2).

Les lacunes d'un tel dossier sont traitées dans le playbook sur les sanctions de l'art. 38 ; le décret dans son ensemble est expliqué dans Le D.Lgs. 138/2024 expliqué.

Une red team IA autonome pour les réseaux et les infrastructures ne décide pas de votre fréquence, n'approuve pas vos plans et ne constitue pas l'examen indépendant que décrit le règlement 2024/2690. Ce qu'il change, c'est la quantité de preuves de tests disponibles entre un rapport et le suivant.

• VA et PT dans une même campagne. Des campagnes en boîte noire depuis l'extérieur et en boîte grise avec les accès d'un utilisateur standard, exécutées selon un calendrier et après chaque changement, identifient les vulnérabilités et tentent de les exploiter : chaque constat indique ainsi s'il a été prouvé exploitable dans votre environnement.
• Re-test à la demande. Chaque correctif peut être vérifié avec la même preuve que celle qui a révélé la vulnérabilité, ce qui clôture le registre de remédiation exigé par ID.RA-08.
• Correspondance avec les référentiels. Le moteur associe les constats aux contrôles de l'art. 21, paragraphe 2, points e) et f), de NIS2, parmi les 34 référentiels de conformité qu'il prend en charge, et exporte des rapports de conformité. Il ne les associe pas aux codes des mesures ACN : le lien entre ses rapports et ID.RA-01, ID.RA-08 et ID.IM-01 reste à établir dans votre documentation.
• Approbation humaine des étapes à risque. Cinq niveaux d'autonomie définissent ce qui attend la validation d'une personne, de l'approbation de tout scan actif au niveau le plus bas à l'absence de toute étape d'approbation au niveau le plus élevé, qui se choisit délibérément. Les preuves de concept d'exploit peuvent être retenues pour revue par un opérateur. Voir human-in-the-loop.
• Des traces qui tiennent. Chaque tentative d'attaque est une entrée signée Ed25519 dans une chaîne de hachage SHA-256 propre à chaque campagne, vérifiable hors ligne : on peut ainsi démontrer que le registre de tests présenté à l'ACN n'a pas été altéré.
• Aucune donnée client ne quitte l'appliance. Les constats sur des systèmes exploitables sont précisément ce que recherche un attaquant. Les modèles s'exécutent sur l'appliance, sans aucun service d'IA externe ; en mode air-gap (réseau isolé), elle cesse également tout téléchargement depuis des sources publiques. Voir red team IA on-premise.

• Directive (UE) 2022/2555 (NIS2), art. 21, 32 et 33 (EUR-Lex)
• Règlement d'exécution (UE) 2024/2690 de la Commission, annexe, points 2.3, 6.5, 6.10 et 7 (EUR-Lex)
• D.Lgs. 4 settembre 2024, n. 138, art. 24 (Normattiva)
• ACN : modalità e specifiche di base, échéances et annexes (acn.gov.it)
• Determinazione ACN 379907/2025, spécifications de base (PDF, acn.gov.it)
• Allegato 1, mesures de base pour les entités importantes (PDF, acn.gov.it)
• Allegato 2, mesures de base pour les entités essentielles (PDF, acn.gov.it)
• Determinazione ACN 127434/2026, délais pour les entités inscrites en 2026 (PDF, acn.gov.it)
• FAQ ACN : mesures de sécurité et notification des incidents (acn.gov.it)
• FAQ ACN : surveillance, supervision et exécution (acn.gov.it)
• NIS2, a ottobre scadono le misure di base (Tom's Hardware Italia, octobre 2026) — indique le 12 avril 2025 comme date des premières communications d'inscription