Cartographie des éléments probants NIS2 avec ISO 27001:2022 pour 2026

Le problème NIS2 en 2026 n’est pas la sensibilisation, mais la preuve

Nous sommes lundi matin, 08 h 35. Maria, récemment nommée RSSI d’un fournisseur B2B de services cloud et de services gérés en forte croissance, rejoint la réunion trimestrielle du comité des risques du conseil d’administration avec une volumineuse analyse d’écarts NIS2 ouverte sur son ordinateur portable. La première diapositive est rassurante. Les politiques existent. Une appréciation des risques existe. La réponse aux incidents est documentée. Les fournisseurs sont répertoriés. Des analyses de vulnérabilités sont exécutées chaque mois.

Puis le président pose la question qui change le cours de la réunion :

« Pouvons-nous prouver que ces mesures ont fonctionné au dernier trimestre, et pouvons-nous montrer quels contrôles ISO 27001:2022, responsables et enregistrements appuient chaque obligation NIS2 ? »

La salle devient silencieuse.

Le service juridique sait que l’entreprise relève du champ de NIS2 parce qu’elle fournit des services TIC gérés et des services cloud à des clients de l’UE. La conformité sait que l’article 21 impose des mesures techniques, opérationnelles et organisationnelles de gestion des risques de cybersécurité. Les opérations savent que l’équipe applique des correctifs, réalise des revues de fournisseurs et surveille les journaux. Mais les éléments probants sont dispersés entre les systèmes de ticketing, les exports SIEM, les dossiers de politiques, les feuilles de calcul, les consoles cloud, les portails fournisseurs et les comptes rendus de réunion.

Personne ne peut montrer rapidement une chaîne défendable reliant l’article 21 de NIS2 au domaine d’application ISO 27001:2022, au risque, au contrôle, à la politique, au responsable, à la procédure, à l’enregistrement opérationnel et au constat d’audit.

Voilà le véritable défi de 2026.

De nombreuses organisations ne se demandent plus : « Sommes-nous dans le champ d’application de NIS2 ? » Elles posent une question plus exigeante : « Pouvons-nous prouver que nos mesures techniques NIS2 fonctionnent effectivement ? » La réponse ne peut pas être une feuille de calcul de cartographie ponctuelle. Elle doit prendre la forme d’un modèle opérationnel vivant au sein du système de management de la sécurité de l’information, dans lequel les obligations légales sont traduites en risques, politiques, contrôles, responsables, éléments probants et amélioration continue.

Le modèle de Clarysec utilise ISO/IEC 27001:2022 comme colonne vertébrale du système de management, l’article 21 de NIS2 comme corpus d’obligations réglementaires, les clauses de politique comme référentiel opérationnel, Zenith Blueprint : la feuille de route de l’auditeur en 30 étapes comme parcours de mise en œuvre, et Zenith Controls : le guide de conformité croisée comme cartographie de conformité croisée pour ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF et une assurance de type COBIT.

Commencer par le domaine d’application, car les éléments probants NIS2 commencent avant les contrôles

Une erreur fréquente dans les programmes NIS2 consiste à passer directement à l’authentification multifacteur, à la journalisation, à la réponse aux incidents et à la gestion des vulnérabilités avant d’avoir confirmé le périmètre au niveau de l’entité, des services et des juridictions.

NIS2 s’applique aux entités publiques et privées couvertes dans les secteurs réglementés qui remplissent les critères de taille et d’activité, certaines catégories d’entités étant couvertes quelle que soit leur taille. Les catégories numériques et TIC pertinentes incluent les fournisseurs de services d’informatique en nuage, les fournisseurs de services de centres de données, les fournisseurs de réseaux de diffusion de contenu, les prestataires de services de confiance, les fournisseurs de réseaux publics de communications électroniques, les prestataires de services gérés, les prestataires de services de sécurité gérés, les places de marché en ligne, les moteurs de recherche en ligne et les plateformes de réseaux sociaux.

Pour les fournisseurs cloud, les plateformes SaaS, les MSP, les MSSP et les fournisseurs d’infrastructures numériques, ce travail de cadrage n’est pas théorique. L’article 3 impose aux États membres de distinguer les entités essentielles et importantes. L’article 27 impose à ENISA de tenir un registre pour plusieurs fournisseurs numériques et TIC, notamment les fournisseurs de services DNS, les registres de noms de domaine de premier niveau, les prestataires de services d’enregistrement de noms de domaine, les fournisseurs de services d’informatique en nuage, les fournisseurs de services de centres de données, les fournisseurs de réseaux de diffusion de contenu, les prestataires de services gérés, les prestataires de services de sécurité gérés, les places de marché en ligne, les moteurs de recherche en ligne et les plateformes de réseaux sociaux.

ISO 27001:2022 fournit la bonne structure. Les clauses 4.1 à 4.4 exigent que l’organisation comprenne les enjeux externes et internes, les parties intéressées, les exigences, les interfaces et les dépendances, puis définisse le domaine d’application du SMSI. NIS2 doit être pris en compte à ce niveau, et non relégué dans une note juridique.

Un enregistrement pratique de cadrage NIS2 doit inclure :

• Analyse de l’entité juridique et de l’établissement dans l’UE
• Secteur NIS2 et catégorie de service
• Statut d’entité essentielle ou importante, lorsqu’il est confirmé par la législation nationale ou par une désignation de l’autorité compétente
• Pertinence du registre ENISA, le cas échéant
• Services critiques fournis aux clients
• Réseaux et systèmes d’information soutenant ces services
• Dépendances envers les fournisseurs cloud, centres de données, télécoms, surveillance de sécurité, identité et logiciels
• Liens avec DORA, GDPR, les contrats clients et les obligations sectorielles
• Référentiels d’éléments probants, propriétaires de systèmes et cadence de revue

C’est également à ce stade que DORA doit être correctement distingué. NIS2 reconnaît que lorsqu’un acte juridique sectoriel de l’UE impose des obligations équivalentes de gestion des risques de cybersécurité ou de notification des incidents, ce régime sectoriel s’applique à la place des dispositions NIS2 correspondantes. Pour les entités financières couvertes, DORA est généralement le régime opérationnel applicable à la cybersécurité et à la notification des incidents liés aux TIC. DORA s’applique depuis le 17 janvier 2025 et couvre la gestion des risques liés aux TIC, la notification des incidents, les tests de résilience opérationnelle numérique, le risque lié aux tiers TIC et la supervision des prestataires tiers critiques de services TIC.

Un groupe fintech peut donc avoir différents traitements de conformité au sein d’une même structure d’entreprise. L’entité de paiement peut relever principalement de DORA. La filiale MSP peut relever directement de NIS2. Une plateforme cloud partagée peut soutenir les deux. La réponse mature ne consiste pas à dupliquer les contrôles. Elle consiste à établir un modèle unique d’éléments probants du SMSI pouvant répondre à plusieurs lectures réglementaires.

ISO 27001:2022 comme système d’exploitation de la conformité NIS2

L’article 21 de NIS2 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées afin de gérer les risques pesant sur les réseaux et systèmes d’information et de prévenir ou réduire au minimum l’impact des incidents sur les destinataires des services et sur d’autres services.

ISO 27001:2022 se prête particulièrement bien à la mise en œuvre de cette exigence, car elle impose trois disciplines.

Premièrement, la gouvernance. Les clauses 5.1 à 5.3 exigent l’engagement de la direction, l’alignement sur l’orientation stratégique, l’allocation des ressources, la communication, l’attribution des responsabilités et une politique de sécurité de l’information documentée. Cela s’aligne directement sur l’article 20 de NIS2, qui impose aux organes de direction d’approuver les mesures de gestion des risques de cybersécurité, d’en superviser la mise en œuvre et de recevoir une formation.

Deuxièmement, le traitement des risques. Les clauses 6.1.1 à 6.1.3 exigent un processus d’appréciation des risques répétable, des propriétaires de risques, l’évaluation des risques, des options de traitement, la sélection des contrôles, une Déclaration d’applicabilité, un plan de traitement des risques et l’approbation du risque résiduel.

Troisièmement, la maîtrise opérationnelle. La clause 8.1 impose à l’organisation de planifier, mettre en œuvre et maîtriser les processus du SMSI, de conserver les informations documentées, de contrôler les changements et de maîtriser les processus, produits et services fournis par des tiers et pertinents pour le SMSI.

NIS2 cesse ainsi d’être une simple liste de vérification juridique pour devenir un modèle opérationnel de contrôle.

Chaque ligne doit avoir un responsable, une source d’enregistrement et une méthode d’échantillonnage. À défaut, l’organisation dispose d’une intention de contrôle, pas d’un contrôle.

La politique est le point où NIS2 devient un comportement opérationnel

Les politiques sont souvent traitées comme des modèles. Pour NIS2, cette approche est dangereuse. Une autorité de régulation ou un auditeur ne sera pas convaincu par un dossier de politiques si celles-ci n’attribuent pas la responsabilité, ne définissent pas les enregistrements, ne se rattachent pas aux risques et ne produisent pas d’éléments probants.

La Politique de conformité juridique et réglementaire d’entreprise établit le fondement à la clause 6.2.1 :

Toutes les obligations légales et réglementaires doivent être cartographiées avec des politiques, des contrôles et des responsables spécifiques au sein du système de management de la sécurité de l’information (SMSI).

Cette clause constitue le pont entre NIS2 et ISO 27001:2022. L’article 21 de NIS2 n’est pas simplement inscrit comme exigence externe. Il est décomposé en obligations liées aux politiques, cartographié avec les contrôles, attribué à des responsables et testé au moyen d’éléments probants.

Pour les organisations plus petites, la Politique de conformité juridique et réglementaire PME conserve le même principe sous une forme allégée. La clause 5.1.1 exige :

Le directeur général doit maintenir un registre de conformité simple et structuré répertoriant :

La formulation est volontairement pratique. Les PME n’ont pas besoin d’une mise en œuvre GRC complexe pour commencer. Elles ont besoin d’un registre de conformité qui capture l’obligation, l’applicabilité, le responsable, la politique, les éléments probants et la cadence de revue.

Le traitement des risques convertit ensuite l’obligation en action. La Politique de gestion des risques d’entreprise, clause 6.4.2, précise :

Le responsable des risques doit s’assurer que les traitements sont réalistes, limités dans le temps et cartographiés avec les contrôles de l’Annexe A d’ISO/IEC 27001.

Pour les PME, la Politique de gestion des risques - PME, clause 5.1.2, fournit l’enregistrement minimal viable du risque :

Chaque entrée de risque doit inclure : description, vraisemblance, impact, score, propriétaire et plan de traitement des risques.

Ces clauses sont importantes parce que NIS2 est explicitement fondée sur les risques et la proportionnalité. L’article 21 attend que les mesures reflètent l’état de l’art, les normes pertinentes, le coût de mise en œuvre, l’exposition au risque, la taille, la vraisemblance et la gravité des incidents, y compris leur impact sociétal et économique. Un registre des risques sans responsables ni plans de traitement ne peut pas démontrer la proportionnalité.

La Politique de sécurité de l’information d’entreprise complète le principe probatoire à la clause 6.6.1 :

Tous les contrôles mis en œuvre doivent être auditables, appuyés par des procédures documentées et par des éléments probants conservés attestant leur fonctionnement.

C’est ce qui distingue un programme NIS2 d’un programme NIS2 fondé sur les éléments probants.

Le parcours Clarysec de la cartographie à l’exploitation

Zenith Blueprint est précieux parce qu’il reflète la manière de raisonner des auditeurs. Ils ne demandent pas seulement si un contrôle existe. Ils demandent pourquoi il a été sélectionné, où il est documenté, comment il fonctionne, qui en est responsable, quels éléments probants l’attestent et comment l’organisation l’améliore.

Dans la phase de gestion des risques, l’étape 13 demande aux équipes d’ajouter la traçabilité entre les risques, les contrôles et les clauses :

✓ Cartographier les contrôles avec les risques : dans le plan de traitement des risques de votre registre des risques, vous avez indiqué certains contrôles pour chaque risque. Vous pouvez ajouter une colonne « Référence du contrôle de l’Annexe A » à chaque risque et y lister les numéros de contrôle.

Pour NIS2, cela signifie que le registre des risques et la Déclaration d’applicabilité doivent montrer pourquoi des contrôles tels que 8.8 Gestion des vulnérabilités techniques, 5.19 Sécurité de l’information dans les relations avec les fournisseurs et 5.24 Planification et préparation de la gestion des incidents sont applicables.

L’étape 14 de Zenith Blueprint rend la cartographie réglementaire explicite :

Pour chaque réglementation, le cas échéant, vous pouvez créer une table de cartographie simple (par exemple une annexe à un rapport) listant les principales exigences de sécurité de la réglementation et les contrôles/politiques correspondants dans votre SMSI.

Cela évite la fragmentation. La sécurité des données à caractère personnel au titre de GDPR, la notification des incidents NIS2, les tests de résilience TIC DORA et les engagements de sécurité envers les clients peuvent tous s’appuyer sur les mêmes éléments probants : revues d’accès, remédiation des vulnérabilités, enregistrements de journalisation, tests de sauvegarde, revues de fournisseurs et rapports d’incident.

L’étape 19 fait passer de la conception à l’exploitation :

Rattachez chacun de ces documents au contrôle approprié dans votre Déclaration d’applicabilité ou manuel SMSI. Ils serviront de preuve de mise en œuvre et de référence interne.

Le jeu documentaire de l’étape 19 comprend la sécurité des terminaux, la gestion des accès, l’authentification, les configurations de référence sécurisées, la journalisation et la surveillance, la gestion des correctifs, la gestion des vulnérabilités, la planification de capacité et les rapports d’exploitation informatique. Ce sont précisément les documents opérationnels nécessaires pour rendre les mesures techniques NIS2 auditables.

L’étape 26 explique comment les éléments probants d’audit doivent être collectés :

À mesure que vous collectez les éléments de preuve, consignez vos constats. Indiquez les points conformes à l’exigence (constats positifs) et ceux qui ne le sont pas (non-conformités potentielles ou observations).

Pour NIS2, cela signifie échantillonner les éléments probants avant qu’une autorité de régulation, un évaluateur client ou un auditeur de certification ne les demande.

Le rôle de conformité croisée de Zenith Controls

Zenith Controls n’est pas un cadre de contrôle distinct. Il s’agit du guide de conformité croisée de Clarysec pour cartographier les contrôles ISO/IEC 27001:2022 et ISO/IEC 27002:2022 avec des contrôles associés, les attentes d’audit et des cadres externes. Il aide les équipes à comprendre comment un même contrôle ISO 27001:2022 peut soutenir NIS2, DORA, GDPR, NIST CSF 2.0 et une assurance de type COBIT.

Trois contrôles ISO 27001:2022 sont particulièrement importants pour la cartographie des éléments probants NIS2.

Le contrôle 5.1 Politiques de sécurité de l’information est le point d’entrée, car l’article 21 de NIS2 inclut l’analyse des risques et les politiques de sécurité des systèmes d’information. Si une mesure technique NIS2 n’est pas reflétée dans une politique, elle est difficile à gouverner et difficile à auditer de manière cohérente.

Le contrôle 5.36 Conformité aux politiques, règles et normes de sécurité de l’information est le test de réalité. Il relie les exigences de politique à la conformité effective avec les règles internes, les normes et les obligations externes. En termes NIS2, c’est à ce niveau que l’organisation vérifie si elle fait réellement ce que sa cartographie de l’article 21 indique.

Le contrôle 8.8 Gestion des vulnérabilités techniques est l’un des domaines de test les plus exigeants pour 2026. La gestion des vulnérabilités est directement pertinente pour l’acquisition, le développement, la maintenance, le traitement des vulnérabilités et la divulgation sécurisés. Elle soutient également les tests et la remédiation DORA, la responsabilité en matière de sécurité GDPR, les résultats Identify et Protect du NIST CSF, ainsi que l’échantillonnage d’audit ISO 27001.

Les normes d’appui peuvent affiner la conception sans imposer de certifications supplémentaires. ISO/IEC 27002:2022 fournit des lignes directrices de mise en œuvre pour les contrôles de l’Annexe A. ISO/IEC 27005 soutient la gestion des risques de sécurité de l’information. ISO/IEC 27017 soutient la sécurité cloud. ISO/IEC 27018 soutient la protection des informations personnellement identifiables (PII) dans les scénarios de sous-traitance en cloud public. ISO 22301 soutient la continuité d’activité. ISO/IEC 27035 soutient la gestion des incidents. ISO/IEC 27036 soutient la sécurité des relations fournisseurs.

L’objectif n’est pas d’empiler les normes pour elles-mêmes. L’objectif est d’améliorer la conception des éléments probants.

Exemple pratique : constituer un dossier d’éléments probants NIS2 sur les vulnérabilités

Prenons la plateforme SaaS de Maria. Elle dessert des clients industriels dans l’UE et dépend de services cloud, de composants open source, de pipelines CI/CD et d’une surveillance gérée. Son rapport d’écarts indique « Gestion des vulnérabilités mise en œuvre », mais les éléments probants sont dispersés entre les outils d’analyse, Jira, GitHub, les outils de configuration cloud et les tickets de changement.

Un dossier d’éléments probants prêt pour NIS2 peut être constitué lors d’un sprint ciblé.

Étape 1 : définir le scénario de risque

Risque : une vulnérabilité exploitable dans une application exposée à Internet, une dépendance ou un composant cloud entraîne une interruption de service, un accès non autorisé ou une exposition des données clients.

Le registre des risques doit inclure la description, la vraisemblance, l’impact, le score, le propriétaire et le plan de traitement des risques. Le plan de traitement doit référencer le contrôle ISO 27001:2022 8.8 Gestion des vulnérabilités techniques, ainsi que les contrôles associés relatifs à l’inventaire des actifs, au développement sécurisé, à la journalisation, au contrôle d’accès, à la gestion des fournisseurs et à la réponse aux incidents.

Étape 2 : cartographier le risque avec l’article 21 de NIS2

Le risque soutient les exigences de l’article 21 relatives à l’acquisition, au développement et à la maintenance sécurisés, au traitement et à la divulgation des vulnérabilités, à l’analyse des risques, à la gestion des incidents, à la sécurité de la chaîne d’approvisionnement et à l’évaluation de l’efficacité des contrôles.

Étape 3 : ancrer les règles opérationnelles dans les politiques

Utilisez une procédure de gestion des vulnérabilités, une norme de développement sécurisé, des exigences de gestion des correctifs, une politique de tests de sécurité et des règles relatives aux éléments probants d’audit.

La Politique de tests de sécurité et de red teaming d’entreprise, clause 6.1, précise :

Types de tests : le programme de tests de sécurité doit inclure, au minimum : (a) des analyses de vulnérabilités, consistant en des analyses automatisées hebdomadaires ou mensuelles des réseaux et des applications afin d’identifier les vulnérabilités connues ; (b) des tests d’intrusion, consistant en des tests manuels approfondis de systèmes ou d’applications spécifiques par des testeurs qualifiés afin d’identifier des faiblesses complexes ; et (c) des exercices de red teaming, consistant en des simulations fondées sur des scénarios d’attaques réelles, incluant l’ingénierie sociale et d’autres tactiques, afin de tester les capacités de détection et de réponse de l’organisation dans son ensemble.

Cette clause crée une base de tests défendable. Elle s’aligne également sur les attentes de DORA en matière de tests récurrents et fondés sur les risques de la résilience opérationnelle numérique pour les entités financières couvertes.

Étape 4 : définir les métadonnées des éléments probants

La Politique d’audit et de surveillance de la conformité - PME, clause 6.2.3, précise :

Les métadonnées (par exemple, qui les a collectées, quand et depuis quel système) doivent être documentées.

Pour les éléments probants relatifs aux vulnérabilités, le dossier doit capturer :

• Nom et configuration de l’outil d’analyse
• Date et heure de l’analyse
• Périmètre des actifs et exclusions
• Constats critiques et élevés
• Numéro de ticket et responsable
• Décision de correctif ou d’atténuation
• Décision d’acceptation du risque, le cas échéant
• Date de remédiation
• Analyse de validation
• Lien vers l’enregistrement de changement
• Responsable de l’exception et date d’expiration

Étape 5 : ajouter les éléments probants de journalisation

La Politique de journalisation et de surveillance - PME, clause 5.4.4, inclut des journaux système tels que :

Journaux système : changements de configuration, actions administratives, installations logicielles, activité d’application des correctifs

Un ticket de correctif seul peut ne pas prouver que le changement a eu lieu. Les journaux de configuration, les actions administratives et les enregistrements d’installation logicielle renforcent la chaîne d’éléments probants.

Étape 6 : réaliser un échantillon d’audit

Sélectionnez cinq vulnérabilités critiques ou élevées du trimestre précédent. Pour chaque élément, vérifiez que l’actif figurait dans l’inventaire, que l’outil d’analyse a détecté le constat, qu’un ticket a été ouvert dans le délai de service convenu, qu’un responsable a été attribué, que la remédiation correspondait à la gravité et à l’exploitabilité, que les journaux montrent le changement, que la validation confirme la clôture et que toute exception dispose de l’approbation du propriétaire du risque avec une date d’expiration.

Ce sprint produit un dossier d’éléments probants sur les vulnérabilités prêt pour NIS2 et un échantillon d’audit interne ISO 27001:2022.

La sécurité des fournisseurs est une gouvernance d’écosystème

L’article 21 de NIS2 exige la sécurité de la chaîne d’approvisionnement, y compris les aspects de sécurité concernant les relations avec les fournisseurs directs et les prestataires de services. Il attend également des organisations qu’elles prennent en compte les vulnérabilités des fournisseurs, la qualité des produits, les pratiques de cybersécurité des fournisseurs et les pratiques de développement sécurisé.

C’est là que la première version du rapport d’écarts de Maria était la plus faible. Elle listait les fournisseurs, mais ne démontrait ni les diligences préalables, ni les clauses contractuelles de sécurité, ni la surveillance, ni la préparation à la sortie.

La Politique de sécurité des tiers et des fournisseurs fournit l’ancrage politique. La mise en œuvre associée peut être soutenue par la Politique de développement sécurisé, la Politique de sensibilisation et de formation à la sécurité de l’information, la Politique de gestion des vulnérabilités et des correctifs, la Politique sur les contrôles cryptographiques, la Politique de contrôle d’accès et la Politique de télétravail.

Un registre unique d’éléments probants fournisseurs peut soutenir NIS2, DORA et ISO 27001:2022.

Ce tableau évite les questionnaires dupliqués, les registres dupliqués et les responsabilités de contrôle contradictoires.

Un processus unique de gestion des incidents pour NIS2, DORA et GDPR

L’article 23 de NIS2 exige que les incidents significatifs soient notifiés sans retard injustifié. Il établit une chronologie par étapes : alerte précoce dans les 24 heures suivant la prise de connaissance, notification de l’incident dans les 72 heures avec une première évaluation de la gravité ou de l’impact et les indicateurs de compromission disponibles, mises à jour intermédiaires si elles sont demandées, et rapport final au plus tard un mois après la notification de l’incident.

DORA prévoit un cycle de vie similaire pour les entités financières : détection, classification, journalisation, évaluation de la gravité, escalade, communication client, notification à l’autorité, analyse de la cause racine et remédiation. GDPR ajoute l’analyse de la violation de données à caractère personnel, y compris les rôles de responsable du traitement et de sous-traitant, l’impact sur les personnes concernées et le délai de notification de 72 heures, le cas échéant.

La bonne conception ne consiste pas à créer trois processus d’incident. Elle consiste à établir un processus unique de gestion des incidents avec des branches de décision réglementaires.

La Politique de réponse aux incidents - PME, clause 5.4.1, précise :

Toutes les investigations d’incidents, tous les constats et toutes les actions correctives doivent être enregistrés dans un registre des incidents tenu par le directeur général.

Un registre des incidents robuste doit inclure :

Le lien avec GDPR ne doit pas être sous-estimé. Les autorités compétentes NIS2 peuvent informer les autorités de contrôle GDPR lorsque des défaillances de gestion des risques de cybersécurité ou de notification peuvent entraîner une violation de données à caractère personnel. Le SMSI doit donc intégrer l’évaluation de la protection des données au triage des incidents, et non la traiter après coup.

Comment les auditeurs et les régulateurs testeront vos éléments probants NIS2

Une organisation prête pour 2026 doit s’attendre à ce qu’un même contrôle soit testé sous différents angles.

Un auditeur ISO 27001:2022 commencera par le SMSI. Il demandera si les obligations NIS2 sont identifiées comme exigences des parties intéressées, si le domaine d’application du SMSI couvre les services et dépendances pertinents, si les risques sont appréciés et traités, si la Déclaration d’applicabilité justifie les contrôles applicables et si les enregistrements démontrent le fonctionnement.

Une autorité compétente NIS2 se concentrera sur les résultats juridiques. Elle peut demander si toutes les mesures de l’article 21 sont traitées, si les contrôles sont appropriés et proportionnés, si la direction a approuvé les mesures et en assure la supervision, et si la notification des incidents peut respecter les délais requis.

Un superviseur DORA, pour les entités financières couvertes, testera la gestion des risques liés aux TIC, la classification des incidents, les tests de résilience, le risque lié aux tiers, les dispositifs contractuels, le risque de concentration et les stratégies de sortie.

Un examinateur GDPR vérifiera si les mesures techniques et organisationnelles protègent les données à caractère personnel, si l’évaluation des violations est intégrée à la gestion des incidents, si les rôles de responsable du traitement et de sous-traitant sont clairs, et si les enregistrements de responsabilité existent.

Un évaluateur de type NIST CSF 2.0 ou COBIT 2019 se concentrera sur la gouvernance, la propriété du risque, les indicateurs de performance, les résultats actuels et cibles, la capacité des processus et l’alignement sur l’appétence au risque de l’entreprise.

La Politique d’audit et de surveillance de la conformité d’entreprise, clause 3.4, capture l’objectif probatoire :

Produire des éléments probants défendables et une piste d’audit à l’appui des demandes réglementaires, des procédures judiciaires ou des demandes d’assurance de clients.

C’est la norme opérationnelle vers laquelle les équipes NIS2 doivent tendre.

Responsabilité de la direction : le conseil d’administration ne peut pas déléguer NIS2

L’article 20 de NIS2 impose aux organes de direction des entités essentielles et importantes d’approuver les mesures de gestion des risques de cybersécurité, d’en superviser la mise en œuvre et de recevoir une formation. Les membres des organes de direction peuvent être tenus responsables des manquements, sous réserve des règles nationales de responsabilité.

Cela s’aligne sur les exigences de leadership d’ISO 27001:2022. La direction doit s’assurer que la politique de sécurité de l’information et les objectifs sont alignés sur l’orientation stratégique, intégrer les exigences du SMSI dans les processus métier, fournir les ressources, communiquer l’importance de ces exigences, attribuer les responsabilités et promouvoir l’amélioration continue.

Un conseil d’administration n’a pas besoin d’exports bruts d’outils d’analyse ni de journaux SIEM complets. Il a besoin d’une assurance exploitable pour la prise de décision.

Un dossier trimestriel d’éléments probants NIS2 destiné au conseil d’administration doit inclure :

1. Changements de domaine d’application et de statut réglementaire
2. Principaux risques NIS2 et statut du traitement
3. Tableau de bord de l’efficacité des contrôles de l’article 21
4. Incidents significatifs, quasi-incidents et décisions de notification
5. Exceptions relatives aux risques fournisseurs et cloud
6. Constats d’audit interne, actions correctives et éléments probants en retard

Ce dossier donne à la direction les informations nécessaires pour approuver les mesures, challenger les exceptions et accepter le risque résiduel.

Le modèle opérationnel Clarysec pour 2026

La mise en œuvre des mesures techniques NIS2 avec ISO 27001:2022 nécessite un modèle simple mais discipliné :

• Intégrer NIS2, DORA, GDPR et les obligations contractuelles dans le SMSI
• Cartographier les obligations avec les risques, politiques, contrôles, responsables et éléments probants
• Utiliser la Déclaration d’applicabilité comme source de vérité des contrôles
• Constituer des dossiers d’éléments probants pour les domaines à haut risque de l’article 21
• Intégrer la notification des incidents dans un processus réglementaire unique
• Traiter la sécurité des fournisseurs comme un cycle de vie, et non comme un questionnaire
• Réaliser des audits internes à partir d’échantillons réels
• Rapporter l’efficacité des contrôles aux organes de direction
• Améliorer sur la base des incidents, des constats d’audit, des tests et des évolutions réglementaires

Pour Maria, le point de bascule a été de comprendre qu’elle n’avait pas besoin d’un projet NIS2 séparé. Elle avait besoin d’un moteur d’éléments probants SMSI plus robuste.

Les politiques Clarysec, Zenith Blueprint et Zenith Controls sont conçus pour fonctionner ensemble. Les politiques définissent le comportement attendu et les enregistrements. Zenith Blueprint fournit le parcours de mise en œuvre et d’audit en 30 étapes. Zenith Controls fournit la cartographie de conformité croisée afin que NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF et une assurance de type COBIT puissent être gérés comme un programme cohérent unique.

Prochaine étape : construire votre cartographie d’éléments probants NIS2 vers ISO 27001:2022

Si votre travail NIS2 existe encore dans une feuille de calcul d’écarts, 2026 est l’année pour le rendre opérationnel.

Commencez par une mesure technique à haut risque, comme la gestion des vulnérabilités, la gestion des incidents ou la sécurité des fournisseurs. Cartographiez-la avec les risques ISO 27001:2022, les politiques, les contrôles de l’Annexe A, les responsables, les procédures et les éléments probants. Puis échantillonnez les enregistrements du dernier trimestre et posez une question exigeante : cela satisferait-il une autorité de régulation, un évaluateur client et un auditeur ISO 27001:2022 ?

Clarysec peut vous aider à construire cette réponse à l’aide de la bibliothèque de politiques, de Zenith Blueprint et de Zenith Controls.

L’objectif n’est pas d’ajouter de la documentation. L’objectif est de disposer d’éléments probants défendables et répétables démontrant que vos mesures techniques NIS2 fonctionnent réellement.