Preuves d’enregistrement NIS2 dans ISO 27001:2022

Le courriel arriva dans la boîte de réception d’Anna avec un bruit discret qui ressemblait pourtant à une sirène. En tant que RSSI de CloudFlow, fournisseur SaaS B2B en forte croissance au service de clients dans toute l’UE, elle avait l’habitude des questionnaires de sécurité, des audits d’approvisionnement et des audits de surveillance ISO 27001. Ce message était différent.

L’objet indiquait : « Demande d’informations concernant la transposition nationale de la directive (UE) 2022/2555 (NIS2). » L’autorité nationale de cybersécurité demandait à CloudFlow de confirmer sa classification, de préparer les informations d’enregistrement de l’entité, d’identifier les services dans le champ d’application et d’être en mesure de démontrer les mesures de gestion des risques de cybersécurité.

Anna avait un certificat ISO 27001:2022 encadré au mur. Les équipes commerciales l’utilisaient dans les contrats grands comptes. L’organe de direction avait approuvé la politique de sécurité de l’information. L’audit interne venait de clôturer deux constats. Mais la question posée était plus précise que le simple statut de certification.

CloudFlow pouvait-il démontrer, rapidement et de manière défendable, que son système de management de la sécurité de l’information (SMSI) ISO 27001:2022 couvrait les obligations NIS2 ?

C’est ici que de nombreuses organisations prennent la mauvaise direction. Elles traitent l’enregistrement d’une entité NIS2 comme une formalité administrative, comparable à la mise à jour d’un registre des entreprises ou d’un portail fiscal. Ce n’est pas le cas. L’enregistrement ouvre la porte à la supervision. Une fois cette porte franchie, l’autorité compétente peut demander la justification du champ d’application, les enregistrements d’approbation par l’organe de direction, les procédures de notification des incidents, les preuves relatives aux risques fournisseurs, les points de contact, les indicateurs d’efficacité des contrôles et la preuve que l’organisation sait quels services sont critiques.

Pour les fournisseurs SaaS, cloud, de services managés, de sécurité managée, de centres de données, d’infrastructure numérique et certains fournisseurs du secteur financier, la vraie question n’est plus : « Avons-nous une politique de sécurité ? » Elle devient : « Pouvons-nous présenter une chaîne probatoire allant de l’obligation légale au domaine d’application du SMSI, au traitement des risques, au fonctionnement des contrôles et à la supervision par la direction ? »

Le meilleur programme de préparation à l’application de NIS2 n’est pas un tableur parallèle. C’est un modèle de preuves traçable au sein d’ISO 27001:2022.

L’enregistrement NIS2 est avant tout un problème de preuve

NIS2 s’applique largement aux entités publiques ou privées des secteurs énumérés à l’annexe I et à l’annexe II qui atteignent ou dépassent le seuil applicable aux entreprises de taille moyenne. Elle couvre également certaines entités indépendamment de leur taille, notamment les fournisseurs de réseaux ou de services de communications électroniques publics, les prestataires de services de confiance, les registres TLD, les fournisseurs de services DNS, les fournisseurs uniques de services essentiels et les entités dont la perturbation pourrait affecter la sécurité publique, la santé, le risque systémique ou la criticité nationale ou régionale.

Pour les entreprises technologiques, les catégories numériques sont particulièrement importantes. L’annexe I inclut l’infrastructure numérique, notamment 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 services DNS et les fournisseurs de réseaux ou de services de communications électroniques publics. L’annexe I inclut également la gestion des services TIC pour les services interentreprises, y compris les prestataires de services managés et les prestataires de services de sécurité managés. L’annexe II inclut les fournisseurs numériques tels que les places de marché en ligne, les moteurs de recherche en ligne et les plateformes de services de réseaux sociaux.

Une organisation peut donc entrer dans le champ d’application de NIS2 sans se considérer elle-même comme une « infrastructure critique ». Une entreprise SaaS B2B dotée de fonctionnalités de sécurité managée, une plateforme cloud soutenant des clients réglementés ou un fournisseur adjacent à la fintech peut soudainement avoir besoin d’un dossier d’enregistrement, d’un modèle de contact avec l’autorité compétente et d’un récit de contrôle défendable.

NIS2 distingue également les entités essentielles et les entités importantes. Les entités essentielles sont généralement soumises à un modèle de supervision plus proactif, tandis que les entités importantes sont en principe supervisées après des éléments de preuve de non-conformité ou des incidents. Cette distinction importe, mais elle ne supprime pas la nécessité de se préparer. Les deux catégories ont besoin de gouvernance, de gestion des risques, de notification des incidents, de sécurité des fournisseurs et de preuves.

Les entités financières doivent aussi prendre en compte DORA. NIS2 Article 4 reconnaît que lorsqu’un acte juridique sectoriel de l’Union impose des obligations au moins équivalentes en matière de gestion des risques de cybersécurité et de notification des incidents, ces règles sectorielles s’appliquent aux domaines correspondants. DORA s’applique à compter du 17 janvier 2025 et établit la gestion des risques liés aux TIC, la notification des incidents majeurs liés aux TIC, les tests de résilience opérationnelle numérique, le partage d’informations, la gestion des risques liés aux tiers TIC, les contrôles contractuels et la supervision des prestataires tiers critiques de services TIC. Pour les entités financières couvertes, DORA constitue le cadre principal de cyberrésilience pour les exigences qui se recoupent, mais les interfaces NIS2 et la coordination avec les autorités nationales peuvent toujours être importantes.

La leçon est simple. N’attendez pas le champ du portail ou le courriel du régulateur pour constituer les preuves. Chaque réponse d’enregistrement implique une future question d’audit.

Commencer par le domaine d’application du SMSI, pas par le formulaire du portail

ISO 27001:2022 est utile parce qu’elle oblige l’organisation à définir le contexte, les parties intéressées, les obligations réglementaires, le domaine d’application, les risques, les plans de traitement des risques, le fonctionnement des contrôles, la surveillance, l’audit interne, la revue de direction et l’amélioration.

Les clauses 4.1 à 4.4 exigent que l’organisation détermine les enjeux internes et externes, identifie les parties intéressées et leurs exigences, décide quelles exigences sont traitées par le SMSI, définisse le domaine d’application du SMSI en tenant compte des interfaces et dépendances, documente ce domaine d’application et exploite les processus du SMSI.

Pour NIS2, ce domaine d’application doit répondre à des questions pratiques :

• Quels services dans l’UE, entités juridiques, filiales, plateformes, composants d’infrastructure et unités métier sont concernés ?
• Quelle catégorie de l’annexe I ou de l’annexe II peut s’appliquer ?
• L’organisation est-elle essentielle, importante, couverte par DORA, hors champ, ou en attente de classification nationale ?
• Quels services sont critiques pour les clients, la sécurité publique, la stabilité financière, les soins de santé, l’infrastructure numérique ou d’autres secteurs réglementés ?
• Quels fournisseurs cloud, MSP, MSSP, centres de données, sous-traitants et autres fournisseurs soutiennent ces services ?
• Quels États membres, autorités compétentes, CSIRT, autorités de contrôle de la protection des données et superviseurs financiers peuvent être concernés ?

Le Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint place ce travail très tôt, à l’étape 2, besoins des parties prenantes et domaine d’application du SMSI. Il demande aux organisations d’identifier les autorités de régulation et autorités compétentes, d’examiner les exigences légales et réglementaires, de revoir les contrats et accords, de mener des entretiens avec les parties prenantes et de prendre en compte les normes sectorielles attendues.

Action Item 4.2 : Dressez la liste de toutes les parties intéressées significatives et notez leurs exigences relatives à la sécurité de l’information. Soyez exhaustif : pensez à toute personne susceptible de se plaindre ou de subir des conséquences si votre sécurité échouait ou si un contrôle donné faisait défaut. Cette liste guidera ce à quoi vous devez vous conformer ou satisfaire au moyen de votre SMSI et alimentera l’appréciation des risques ainsi que la sélection des contrôles.

C’est le bon point de départ pour l’enregistrement NIS2. Avant tout dépôt, établissez une courte note de champ d’application NIS2 qui relie le modèle économique aux catégories de l’annexe I ou de l’annexe II, documente les hypothèses de taille et de services, consigne l’interprétation du droit national, identifie les autorités compétentes et précise si DORA, GDPR, les contrats clients ou des règles sectorielles s’appliquent également.

La politique Clarysec SME Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy - SME définit clairement l’objet :

« Cette politique définit l’approche de l’organisation pour identifier, respecter et démontrer la conformité aux obligations légales, réglementaires et contractuelles. »

Pour les programmes de plus grande ampleur, la Legal and Regulatory Compliance Policy de Clarysec Legal and Regulatory Compliance Policy est encore plus explicite :

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

Cette phrase constitue le socle de la préparation à l’application de NIS2. Si une autorité compétente demande comment les obligations NIS2 ont été identifiées, la réponse ne doit pas être : « le juridique nous l’a indiqué ». Elle doit être un registre documenté, relié au domaine d’application, aux risques, aux responsables de contrôle, aux procédures, aux preuves conservées et à la revue de direction.

Construire la chaîne probatoire NIS2 dans ISO 27001:2022

NIS2 Article 21 impose aux entités essentielles et importantes de mettre en œuvre 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 utilisés pour les activités ou la fourniture de services. Les mesures doivent tenir compte de l’état de l’art, des normes européennes et internationales pertinentes le cas échéant, du coût, de l’exposition au risque, de la taille, de la vraisemblance et de la gravité des incidents, ainsi que de leur impact sociétal et économique.

Article 21(2) énumère des domaines minimaux, notamment l’analyse des risques et les politiques de sécurité des systèmes d’information, la gestion des incidents, la continuité d’activité, les sauvegardes, la reprise après sinistre, la gestion de crise, la sécurité de la chaîne d’approvisionnement, l’acquisition et le développement sécurisés, la gestion des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la formation, la cryptographie, la sécurité liée aux ressources humaines, le contrôle d’accès, la gestion des actifs, l’authentification multifacteur ou continue et, le cas échéant, les communications sécurisées.

ISO 27001:2022 se rattache naturellement à cette structure. Les clauses 6.1.1 à 6.1.3 exigent l’appréciation des risques et le traitement des risques, y compris les critères d’acceptation du risque, les propriétaires du risque, l’analyse de la vraisemblance et des conséquences, un plan de traitement des risques, la comparaison avec les contrôles de l’annexe A et une Déclaration d’applicabilité. La clause 8 exige la planification et la maîtrise opérationnelles, les preuves que les processus ont fonctionné comme prévu, la maîtrise des changements, la maîtrise des processus fournis par des tiers, les appréciations des risques récurrentes et les résultats documentés du traitement. La clause 9.1 exige la surveillance, la mesure, l’analyse et l’évaluation. La clause 9.2 exige l’audit interne. La clause 10.2 exige des actions face aux non-conformités et des actions correctives.

La Risk Management Policy de Clarysec Risk Management Policy - SME transforme cela en règle opérationnelle :

« Tous les risques identifiés doivent être consignés dans le registre des risques. »

La Risk Management Policy pour l’entreprise Risk Management Policy relie le traitement des risques à la sélection des contrôles ISO 27001:2022 :

« Les décisions de contrôle issues du processus de traitement des risques doivent être reflétées dans la SoA. »

C’est essentiel, car les preuves NIS2 doivent être traçables. Si une autorité demande pourquoi un contrôle existe, il faut pouvoir renvoyer à l’obligation, au risque, à la décision de traitement, au responsable de contrôle, à l’entrée de la SoA, à la procédure et aux preuves. Si l’autorité demande pourquoi un contrôle n’a pas été sélectionné, il faut renvoyer à la justification dans la SoA, à l’acceptation du risque approuvée et à la revue de direction.

La meilleure chaîne probatoire est volontairement simple. Chaque obligation a un responsable. Chaque responsable a un contrôle. Chaque contrôle a des preuves. Chaque exception a une approbation. Chaque constat d’audit a une action corrective.

Intégrer la gouvernance de l’Article 20 dans les preuves destinées à l’organe de direction

NIS2 Article 20 fait entrer la cybersécurité dans la salle du conseil. Les organes de direction doivent approuver les mesures de gestion des risques de cybersécurité adoptées pour l’Article 21, superviser leur mise en œuvre et peuvent être tenus responsables des manquements. Les membres des organes de direction doivent suivre une formation, et les entités sont encouragées à dispenser régulièrement une formation à la cybersécurité à leurs employés.

Un organe de direction ne peut pas simplement déléguer NIS2 à l’informatique. Les preuves doivent montrer que la direction a compris l’analyse du champ d’application NIS2, approuvé l’approche de gestion des risques, examiné les risques significatifs, alloué les ressources, suivi la mise en œuvre, revu les incidents et exercices, et reçu une formation.

Les clauses 5.1 à 5.3 d’ISO 27001:2022 soutiennent ce modèle de gouvernance en exigeant l’engagement de la direction, l’alignement des objectifs de sécurité de l’information sur la stratégie de l’organisation, l’intégration des exigences du SMSI dans les processus métier, les ressources, la communication, la responsabilité et le reporting de la performance du SMSI à la direction.

La Governance Roles and Responsibilities Policy de Clarysec Governance Roles and Responsibilities Policy définit le rôle de correspondant sécurité comme une fonction qui :

« Sert d’interlocuteur principal auprès des auditeurs, des autorités de régulation et de la haute direction pour les questions de sécurité de l’information. »

Ce rôle doit être nommé dans le dossier de preuves d’enregistrement NIS2. Il ne doit pas être implicite. Les autorités, les auditeurs et les clients veulent savoir qui coordonne le contact réglementaire, qui est responsable de la notification des incidents, qui tient à jour le registre des obligations légales et réglementaires, qui actualise les contacts des autorités et qui rend compte à l’organe de direction.

Un ensemble pratique de preuves de gouvernance comprend :

• L’approbation par l’organe de direction du cadre de gestion des risques de cybersécurité.
• Les comptes rendus de revue de direction couvrant le champ d’application NIS2, les risques, les incidents, les fournisseurs et la préparation.
• Les enregistrements de formation des membres des organes de direction et des employés.
• Une matrice RACI pour les obligations NIS2, les contrôles ISO 27001:2022, la notification des incidents, l’assurance fournisseurs et la communication réglementaire.
• Des preuves montrant que les obligations NIS2 sont intégrées à l’audit interne et à la surveillance de la conformité.
• Le suivi des actions correctives relatives aux lacunes, aux risques en retard, aux exceptions et aux tests échoués.

Les Articles 32 et 33 rendent également la qualité des preuves déterminante en identifiant des facteurs de manquement grave tels que les violations répétées, l’absence de notification ou de remédiation des incidents significatifs, l’absence de correction des défaillances après instructions contraignantes, l’entrave aux audits ou à la surveillance, et les informations fausses ou manifestement inexactes. Des preuves faibles peuvent devenir un problème d’application même lorsque des contrôles techniques existent.

Préparer les preuves de contact avec les autorités et de notification des incidents avant 02:00

Les échecs les plus douloureux en matière de notification des incidents commencent souvent par une question élémentaire : « Qui devons-nous notifier ? » Lors d’un rançongiciel, d’une défaillance DNS, d’une compromission cloud ou d’une exposition de données, les équipes perdent du temps à rechercher le CSIRT, l’autorité compétente, l’autorité de contrôle de la protection des données, le superviseur financier, le canal des autorités répressives compétentes, le modèle client et l’approbateur interne appropriés.

NIS2 Article 23 exige la notification sans retard injustifié des incidents significatifs affectant la fourniture des services. Un incident significatif est un incident qui a causé ou pourrait causer une perturbation opérationnelle grave ou une perte financière, ou qui a affecté ou pourrait affecter d’autres personnes en causant un dommage matériel ou immatériel considérable. Le calendrier est progressif : alerte précoce dans les 24 heures suivant la prise de connaissance, notification de l’incident dans les 72 heures, mises à jour intermédiaires sur demande et rapport final dans le mois suivant la notification à 72 heures ou après le traitement de l’incident pour les incidents en cours. Le cas échéant, les destinataires du service doivent également être informés des incidents significatifs ou des cybermenaces significatives et des mesures de protection.

Zenith Blueprint, dans la phase Controls in Action, étape 22, traite le contact avec les autorités comme une préparation, non comme une réaction de panique :

Le principe est simple : si votre organisation était ciblée par une cyberattaque, impliquée dans une violation de données ou sous enquête, qui appellerait les autorités ? Comment saurait-il quoi dire ? Dans quelles conditions un tel contact serait-il déclenché ? Ces questions doivent recevoir une réponse à l’avance, et non après coup.

Le Zenith Controls: The Cross-Compliance Guide de Clarysec Zenith Controls couvre le contrôle ISO/IEC 27002:2022 5.5, Contact avec les autorités. Il classe le contrôle comme préventif et correctif, lié à la confidentialité, à l’intégrité et à la disponibilité, et connecté aux concepts Identifier, Protéger, Répondre et Rétablir. Il relie également le contrôle 5.5 aux contrôles ISO/IEC 27002:2022 5.24 Planification et préparation de la gestion des incidents de sécurité de l’information, 6.8 Signalement des événements de sécurité de l’information, 5.7 Renseignement sur les menaces, 5.6 Contact avec les groupes d’intérêt spécialisés et 5.26 Réponse aux incidents de sécurité de l’information.

Dans une perspective de conformité croisée, Zenith Controls mappe le contact avec les autorités à NIS2 Article 23, à la notification des violations au titre du GDPR, à la notification des incidents DORA, à NIST SP 800-53 IR-6 Incident Reporting et aux pratiques d’escalade externe de COBIT 2019. Un seul registre des contacts des autorités peut répondre à plusieurs obligations s’il est correctement conçu.

La Incident Response Policy de Clarysec Incident Response Policy - SME rend explicite le triage juridique :

« Lorsque des données client sont concernées, le Directeur général doit évaluer les obligations légales de notification en fonction de l’applicabilité du GDPR, de NIS2 ou de DORA. »

Un dossier probatoire solide relatif aux contacts avec les autorités doit comprendre :

• Les coordonnées de l’autorité compétente et du CSIRT par État membre et par service.
• Les contacts des autorités de contrôle pour la notification des violations de données à caractère personnel au titre du GDPR.
• Les contacts des superviseurs financiers si DORA s’applique.
• Les voies de contact avec les autorités répressives compétentes et les services cybercriminalité.
• Les communicants internes autorisés et leurs suppléants.
• Les seuils d’incident pour NIS2, GDPR, DORA, les contrats clients et l’assurance cyber.
• Les modèles d’alerte à 24 heures, de notification à 72 heures, de mise à jour intermédiaire et de rapport à un mois.
• Les enregistrements d’exercices sur table testant la notification externe.
• Les enregistrements de notifications antérieures, de décisions de non-notification et de justification juridique.

Mapper NIS2 Article 21 aux contrôles ISO 27001 et aux preuves de politique

Un certificat seul ne répond pas à la question d’un régulateur. Une cartographie des contrôles, si. Le tableau suivant fournit aux équipes sécurité et conformité une passerelle pratique entre les domaines de NIS2 Article 21, les contrôles ISO/IEC 27002:2022, les politiques Clarysec et les preuves.

Le Zenith Controls de Clarysec couvre également le contrôle ISO/IEC 27002:2022 5.31, Exigences légales, statutaires, réglementaires et contractuelles, comme contrôle préventif ayant un impact sur la confidentialité, l’intégrité et la disponibilité. Il relie le contrôle 5.31 à la Protection de la vie privée et des informations personnellement identifiables (PII), à la conservation des enregistrements, à la revue indépendante et à la conformité aux politiques internes. Il mappe également 5.31 à la responsabilité GDPR, à la conformité de la chaîne d’approvisionnement NIS2, à la gestion des risques liés aux TIC DORA, à la gouvernance NIST CSF, aux contrôles de programme NIST SP 800-53 et à la supervision de la conformité externe COBIT 2019.

« Le contrôle 5.31 garantit que toutes les exigences légales, réglementaires, statutaires et contractuelles pertinentes relatives à la sécurité de l’information sont identifiées, documentées et gérées en continu. »

C’est exactement ce qu’une autorité nationale veut voir après l’enregistrement : non seulement que NIS2 est répertoriée, mais que l’organisation dispose d’un mécanisme vivant pour identifier, cartographier, mettre en œuvre, surveiller et mettre à jour les obligations.

Ne pas dissocier NIS2 de DORA, GDPR, des fournisseurs et du cloud

Les preuves NIS2 existent rarement isolément.

NIS2 Article 21(2)(d) impose la sécurité de la chaîne d’approvisionnement, y compris les aspects liés à la sécurité des relations avec les fournisseurs et prestataires de services. Article 21(3) exige que les décisions relatives aux risques fournisseurs prennent en compte les vulnérabilités, la qualité globale des produits, les pratiques de cybersécurité, les procédures de développement sécurisé et les évaluations coordonnées pertinentes des risques de la chaîne d’approvisionnement de l’UE.

L’annexe A d’ISO 27001:2022 fournit la passerelle opérationnelle par les contrôles A.5.19 à A.5.23. Pour les organisations SaaS et cloud, ces contrôles déterminent souvent si les preuves d’enregistrement sont superficielles ou défendables.

DORA précise davantage les attentes fournisseurs pour les entités financières. Les Articles 28 à 30 exigent la gestion des risques liés aux tiers TIC, un registre des contrats de services TIC, la distinction des services soutenant des fonctions critiques ou importantes, l’appréciation des risques précontractuelle, les diligences raisonnables, les exigences contractuelles de sécurité, les droits d’audit et d’inspection, les droits de résiliation, les stratégies de sortie testées, l’évaluation de la sous-traitance, la transparence sur la localisation des données, l’assistance en cas d’incident, la coopération avec les autorités et les dispositions de transition. Si un fournisseur SaaS sert des clients réglementés par DORA, ses contrats et son dossier d’assurance peuvent être examinés même s’il n’est pas lui-même l’entité financière.

La Third-party and supplier security policy - SME de Clarysec Third-party and supplier security policy - SME doit donc être intégrée au dossier de preuve NIS2. La préparation fournisseurs doit inclure :

• L’inventaire des fournisseurs et la classification de criticité.
• Les diligences raisonnables fournisseurs et les appréciations des risques.
• Les clauses contractuelles relatives à la sécurité, à l’assistance en cas d’incident, aux droits d’audit, à la localisation des données, à la sous-traitance et à la sortie.
• Les matrices de responsabilité partagée cloud.
• Les enregistrements de surveillance des fournisseurs critiques.
• Les tests de sortie et de reprise pour les services critiques.
• Les procédures de notification et d’escalade des incidents fournisseurs.

Le GDPR doit également être intégré. Un incident significatif NIS2 peut aussi constituer une violation de données à caractère personnel si des données clients, employés ou utilisateurs sont compromises. Le GDPR exige des responsables du traitement qu’ils démontrent leur responsabilité et, lorsque les seuils de notification sont atteints, qu’ils notifient l’autorité de contrôle dans les 72 heures suivant la prise de connaissance d’une violation de données à caractère personnel. Votre processus de réponse aux incidents doit évaluer en parallèle les obligations NIS2, GDPR, DORA, contractuelles et clients.

Constituer un dossier de preuve NIS2 en une semaine

Un fournisseur SaaS, MSP, MSSP, cloud ou une entreprise d’infrastructure numérique peut réaliser des progrès substantiels en une semaine ciblée.

Jour 1, classer l’entité et les services. Utilisez la Déclaration du domaine d’application du SMSI et le registre des parties intéressées. Ajoutez une note de champ d’application NIS2 qui identifie les catégories de l’annexe I ou de l’annexe II, les services dans l’UE, les États membres, les clients, les dépendances, les hypothèses de taille et l’applicabilité éventuelle de DORA ou de règles sectorielles. Consignez l’incertitude de classification comme un risque si l’interprétation juridique n’est pas finalisée.

Jour 2, mettre à jour le registre des obligations légales et réglementaires. Ajoutez NIS2 Articles 20, 21 et 23, les exigences d’enregistrement en droit national, les obligations de notification des violations au titre du GDPR, les obligations DORA le cas échéant et les principales exigences contractuelles de notification. Mappez chaque obligation à une politique, un propriétaire, un contrôle, une source de preuves et une fréquence de revue.

Jour 3, mettre à jour l’appréciation et le traitement des risques. Intégrez l’impact légal, réglementaire, opérationnel, fournisseur, financier, réputationnel et sociétal dans les critères de risque. Ajoutez des risques tels que le défaut d’enregistrement, une classification d’entité incorrecte, une alerte précoce à 24 heures manquée, l’indisponibilité des contacts des autorités, une interruption fournisseur affectant des services critiques, une supervision insuffisante par l’organe de direction et l’incapacité à prouver l’efficacité des contrôles.

Jour 4, actualiser la SoA. Confirmez les contrôles pertinents pour NIS2, notamment A.5.5 contact avec les autorités, A.5.19 à A.5.23 contrôles fournisseurs et cloud, A.5.24 à A.5.28 contrôles d’incidents, A.5.29 sécurité pendant une perturbation, A.5.30 préparation des TIC à la continuité d’activité, A.5.31 exigences légales, A.5.34 vie privée, A.8.8 gestion des vulnérabilités, A.8.13 sauvegardes, A.8.15 journalisation, A.8.16 activités de surveillance, A.8.24 cryptographie et contrôles de développement sécurisé A.8.25 à A.8.32.

Jour 5, tester la notification des incidents. Menez un exercice sur table : une mauvaise configuration cloud expose des données clients et perturbe le service dans deux États membres. Lancez le chronomètre. L’équipe peut-elle classifier l’événement, évaluer les seuils GDPR, NIS2, DORA, contractuels et clients, préparer une alerte précoce à 24 heures, rédiger une notification à 72 heures, préserver les preuves et attribuer l’analyse de la cause racine ?

Jour 6, rassembler les preuves. Créez un dossier prêt pour l’autorité compétente avec la note de champ d’application, le registre des obligations légales et réglementaires, le registre des risques, la SoA, la liste de contacts des autorités, la procédure opérationnelle d’incident, le registre des fournisseurs, les comptes rendus de l’organe de direction, les enregistrements de formation, les journaux, les rapports de surveillance, les tests de sauvegarde, les rapports de vulnérabilités, le champ de l’audit interne et le journal des actions correctives.

Jour 7, revue de direction. Présentez le dossier de préparation à la direction. Consignez les approbations, les risques résiduels, les actions ouvertes, les échéances, les ressources et la responsabilité des propriétaires. Si l’enregistrement est dû, joignez l’index des preuves à l’enregistrement de la décision d’enregistrement.

La politique Audit and Compliance Monitoring Policy for SMEs de Clarysec Audit and Compliance Monitoring Policy-sme - SME anticipe ce besoin :

« Les éléments de preuve doivent être alignés sur les obligations NIS2 lorsque l’organisation est désignée comme entité importante ou relève autrement du champ d’application du droit national »

La politique Audit and Compliance Monitoring Policy pour l’entreprise Audit and Compliance Monitoring Policy énonce l’objectif :

« Générer des éléments de preuve 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 l’objectif : disposer de preuves défendables avant l’arrivée de la demande.

Se préparer à différentes lectures d’audit

Un auditeur de certification, une autorité nationale, un auditeur client, un auditeur vie privée et une équipe d’assurance fournisseurs ne poseront pas exactement les mêmes questions. Un dossier de preuve NIS2 solide fonctionne pour chacun d’eux.

Pour le contrôle ISO/IEC 27002:2022 5.5, les auditeurs attendent généralement des contacts d’autorités documentés, des responsabilités attribuées, la maintenance des contacts, des procédures de réponse aux incidents et une clarté fondée sur des scénarios. Une simple question d’audit peut révéler la maturité : « En cas de rançongiciel, qui contacte les autorités répressives compétentes ou le CSIRT national ? » Si la réponse dépend de la mémoire d’une personne, le contrôle n’est pas prêt.

La Logging and Monitoring Policy de Clarysec Logging and Monitoring Policy - SME renforce l’attente probatoire :

« Les journaux doivent être disponibles et intelligibles pour les auditeurs externes ou les autorités de régulation sur demande »

La Information Security Policy de Clarysec Information Security Policy fixe le standard global de l’entreprise :

« Tous les contrôles mis en œuvre doivent être auditables, soutenus par des procédures documentées et des éléments de preuve conservés de leur fonctionnement. »

C’est le test d’audit en une phrase. Si un contrôle ne peut pas être étayé par des preuves, il aura peu de poids lorsqu’une autorité compétente demandera des justificatifs.

Liste de contrôle finale des preuves d’enregistrement NIS2

Utilisez cette liste de contrôle avant l’enregistrement ou avant de répondre à une demande d’une autorité nationale.

• Documenter l’analyse du champ d’application NIS2, y compris la justification annexe I ou annexe II, les descriptions de services, les hypothèses de taille, l’empreinte par État membre et la classification de l’entité.
• Identifier si DORA s’applique directement, ou indirectement via des clients du secteur financier et des contrats de services TIC.
• Mettre à jour le domaine d’application du SMSI afin d’inclure les services pertinents, les dépendances, les processus externalisés et les interfaces réglementaires.
• Ajouter NIS2, GDPR, DORA, les règles sectorielles et les exigences contractuelles au registre des obligations légales et réglementaires.
• Mapper chaque obligation aux politiques, contrôles, responsables, preuves, fréquence de revue et reporting de direction.
• Confirmer l’approbation et la supervision par l’organe de direction des mesures de gestion des risques de cybersécurité.
• Maintenir les enregistrements de formation à la cybersécurité de la direction et des employés.
• Mettre à jour les critères de risque pour inclure l’impact réglementaire, l’interruption de service, le préjudice client, l’impact transfrontalier et la dépendance fournisseur.
• Consigner les risques liés à NIS2 dans le registre des risques et les relier aux plans de traitement des risques.
• Mettre à jour la SoA avec les contrôles de l’annexe A pertinents pour NIS2 et leur statut de mise en œuvre.
• Maintenir les listes de contacts des autorités et les procédures de notification pour les CSIRT, les autorités compétentes, les autorités de contrôle de la protection des données, les superviseurs financiers et les autorités répressives compétentes.
• Tester le processus d’alerte précoce à 24 heures, de notification à 72 heures, de mise à jour intermédiaire et de rapport final à un mois.
• Maintenir les preuves fournisseurs et cloud, notamment les diligences raisonnables, les contrats, les droits d’audit, la surveillance, la sous-traitance et les plans de sortie.
• Étayer l’efficacité des contrôles au moyen de journaux, indicateurs, audits, tableaux de bord, résultats de tests et actions correctives.
• Préparer un index des preuves afin que toute demande d’un régulateur, d’un client ou d’un auditeur puisse recevoir une réponse rapide.

La prochaine étape avec Clarysec

L’enregistrement d’une entité NIS2 n’est pas la ligne d’arrivée. C’est le moment où votre organisation devient visible pour la supervision nationale de la cybersécurité. La bonne question n’est pas : « Pouvons-nous nous enregistrer ? » La bonne question est : « Si l’autorité demande des preuves après l’enregistrement, pouvons-nous produire un récit ISO 27001:2022 cohérent en quelques heures, et non en quelques semaines ? »

Clarysec aide les organisations à construire ce récit au moyen du Zenith Blueprint Zenith Blueprint, de Zenith Controls Zenith Controls et d’ensembles pratiques de politiques ISO 27001:2022 qui relient les obligations légales, le traitement des risques, la notification des incidents, la sécurité des fournisseurs, la journalisation, la surveillance, les preuves d’audit et la responsabilité de la direction.

Menez une revue des écarts de preuve NIS2 par rapport à votre SMSI actuel. Commencez par la note de champ d’application, le registre des obligations légales et réglementaires, le registre des risques, la SoA, la liste de contacts des autorités, le processus de notification des incidents, le registre des fournisseurs et le dossier de preuves d’audit. Si ces livrables justificatifs sont incomplets ou déconnectés, Clarysec peut vous aider à les transformer en un dossier de preuve prêt pour l’autorité compétente avant que votre autorité nationale ne le demande.