ISO 27001 comme ossature des éléments probants pour NIS2 et DORA

La collision de conformité du lundi matin
À 08 h 12 un lundi matin, Maria, RSSI d’un prestataire européen de traitement des paiements, reçoit trois messages qui semblent sans rapport.
Le responsable de l’audit interne demande des éléments probants montrant que la Déclaration d’applicabilité ISO 27001:2022 est à jour. L’équipe juridique transmet le questionnaire d’un partenaire bancaire sur la supervision des risques liés aux prestataires tiers de services TIC au titre de DORA. Le directeur des opérations demande si la même procédure opérationnelle de gestion des incidents peut répondre aux attentes de notification NIS2 pour une entité opérationnelle européenne récemment acquise.
À 09 h 00, le tableau blanc du bureau de Maria est couvert d’acronymes : ISO 27001, NIS2, DORA, GDPR, NIST, COBIT 2019. Son organisation dispose de contrôles. Elle dispose d’une gestion des accès, de sauvegardes, de questionnaires fournisseurs, de chiffrement, d’une réponse aux incidents, d’approbations de politiques, de revues de direction et d’enregistrements de formation. Ce qui lui manque, c’est une ossature unique d’éléments probants prête pour l’audit, capable d’expliquer pourquoi ces contrôles existent, quels risques ils traitent, quelles réglementations ils soutiennent, qui en est responsable et où se trouvent les preuves.
Ce problème devient courant en Europe. NIS2 renforce la gestion des risques cybersécurité, la gouvernance, la gestion des incidents et la résilience de la chaîne d’approvisionnement. DORA ajoute des exigences détaillées relatives à la gestion des risques liés aux TIC, aux tests de résilience, au signalement des incidents et à la supervision des prestataires tiers de services TIC pour les entités financières. GDPR continue d’exiger la responsabilité, la sécurité du traitement, la gouvernance des sous-traitants de données et l’évaluation des violations de données à caractère personnel.
La mauvaise réponse consiste à construire trois programmes de conformité parallèles. Cela crée des contrôles dupliqués, des éléments probants incohérents et des équipes épuisées.
La réponse la plus solide consiste à utiliser ISO 27001:2022 comme ossature de contrôles. Non pas comme un certificat accroché au mur, mais comme le système opérationnel de la gestion des risques, des politiques, de la gouvernance des fournisseurs, de la réponse aux incidents, de la cartographie de la conformité et des éléments probants d’audit.
Le modèle pratique de Clarysec est simple : utiliser le SMSI ISO 27001:2022 comme système d’organisation, utiliser la Déclaration d’applicabilité comme passerelle, utiliser les politiques comme règles opérationnelles applicables, et utiliser Zenith Controls : le guide de la conformité croisée comme boussole de conformité croisée. Construire une fois, cartographier avec précision, démontrer en continu.
Pourquoi ISO 27001:2022 fonctionne comme ossature de conformité
NIS2 et DORA ont des périmètres, des mécanismes juridiques et des modèles de supervision différents. NIS2 s’applique aux entités essentielles et importantes dans plusieurs secteurs. DORA s’applique aux entités financières et crée des exigences détaillées de résilience opérationnelle numérique. GDPR se concentre sur le traitement des données à caractère personnel et la responsabilité.
Pourtant, les questions opérationnelles sous-jacentes à ces référentiels se recoupent :
- La cybersécurité est-elle encadrée par des politiques approuvées par la direction ?
- Les risques de sécurité de l’information et les risques liés aux TIC sont-ils identifiés, évalués et traités ?
- Les contrôles sont-ils sélectionnés en fonction des risques, du contexte métier et des obligations légales ?
- Les fournisseurs sont-ils gouvernés au moyen de diligences raisonnables, de contrats, d’une surveillance et de contrôles de réversibilité ?
- Le personnel peut-il reconnaître et signaler rapidement les événements de sécurité ?
- Les incidents peuvent-ils être triés, escaladés, investigués et évalués aux fins d’une notification réglementaire ?
- L’organisation peut-elle récupérer rapidement les éléments probants lors d’un audit, d’une revue client ou d’une demande d’une autorité de supervision ?
ISO 27001:2022 fournit à la direction un système de management permettant de répondre à ces questions de manière cohérente. ISO/IEC 27007:2022 considère la Déclaration d’applicabilité comme une liste auditable de contrôles de sécurité de l’information sélectionnés, incluant les contrôles de l’annexe A d’ISO 27001:2022, d’autres normes ou des mesures propres à l’organisation, avec une justification documentée de leur inclusion ou de leur exclusion. ISO/IEC 27006-1:2024 confirme que la SoA et la documentation associée du SMSI constituent un socle d’éléments probants pour montrer quels contrôles sont requis, comment les responsabilités sont attribuées et comment les politiques sont mises en œuvre et communiquées.
La SoA devient ainsi bien plus qu’un tableur. Elle devient le contrat de contrôle entre les risques, la conformité, les opérations, le juridique, les achats, l’audit et le conseil d’administration.
La [P01] Politique de sécurité de l’information de Clarysec ancre cette exigence de gouvernance :
L’organisation doit mettre en œuvre et maintenir un système de management de la sécurité de l’information (SMSI) conformément aux clauses 4 à 10 d’ISO/IEC 27001:2022.
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.
C’est important, car les demandes d’éléments probants NIS2 et DORA arrivent rarement dans le langage ISO. Une autorité de régulation, un client ou un comité du conseil peut demander une preuve de gestion des risques cybersécurité, de gouvernance des TIC, de supervision des dépendances vis-à-vis des tiers, d’escalade des incidents ou de tests de résilience opérationnelle. Le SMSI ISO 27001:2022 donne une structure à ces réponses.
La SoA est la passerelle, pas un exercice documentaire
Dans Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur, phase Gestion des risques, étape 13, Clarysec présente la SoA comme le mécanisme clé de traçabilité entre le traitement des risques et les contrôles mis en œuvre :
La SoA est effectivement un document de liaison : elle relie votre appréciation et votre traitement des risques aux contrôles réels dont vous disposez.
Cette phrase est au cœur de la conformité croisée. Un contrôle sans traçabilité devient un élément justificatif isolé. Un contrôle relié à un risque, une obligation légale, une politique, un responsable, un enregistrement d’élément probant et un résultat de test devient prêt pour l’audit.
L’étape 13 recommande également d’ajouter des références de contrôle aux scénarios de risque, par exemple en reliant un scénario de violation d’une base de données clients au contrôle d’accès, à la cryptographie, à la gestion des vulnérabilités, à la réponse aux incidents et aux contrôles fournisseurs. Elle recommande aussi d’indiquer quand des contrôles soutiennent des exigences externes telles que GDPR, NIS2 ou DORA.
La [P06] Politique de gestion des risques de Clarysec rend cette règle opérationnelle explicite :
Les décisions relatives aux contrôles issues du processus de traitement des risques doivent être reflétées dans la SoA.
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.5.1.
Pour les organisations de plus petite taille, la Politique de gestion des risques - PME applique la même logique :
Elle veille à ce que la gestion des risques soit une composante active de la planification, de l’exécution des projets, de la sélection des fournisseurs et de la réponse aux incidents, en alignement avec ISO 27001, ISO 31000 et les exigences réglementaires applicables.
Extrait de la section « Objet », clause de politique 1.2.
Si un traitement des risques liés aux tiers au titre de DORA, une mesure de gestion des incidents NIS2 ou une exigence de sécurité applicable aux sous-traitants au titre de GDPR n’est pas reflété dans la SoA ou dans le registre de conformité associé, l’organisation peut malgré tout réaliser le travail. Mais elle aura des difficultés à le démontrer de manière cohérente.
Une correspondance ISO 27001:2022 pratique pour NIS2 et DORA
La correspondance ci-dessous ne constitue pas un avis juridique. Il s’agit d’un modèle pratique d’éléments probants pour les RSSI, responsables conformité, auditeurs internes et responsables métier qui doivent aligner les éléments probants ISO 27001:2022 sur les attentes NIS2 et DORA.
L’ENISA, en collaboration avec la Commission européenne et le groupe de coopération NIS, a fourni des orientations consultatives de références croisées qui aident à aligner les exigences de cybersécurité de l’UE avec les normes internationales et nationales, dont ISO 27001. Ces orientations ne sont pas juridiquement contraignantes et doivent être complétées par les instructions des autorités nationales, les règles sectorielles et une revue juridique. Elles soutiennent toutefois une approche de cartographie défendable.
| Question de conformité | Éléments probants de l’ossature ISO 27001:2022 | Pertinence NIS2 | Pertinence DORA | Élément probant Clarysec |
|---|---|---|---|---|
| La cybersécurité est-elle encadrée par des politiques approuvées par la direction ? | Politique de sécurité de l’information, périmètre du SMSI, rôles, enregistrements de revue de direction, SoA | Attentes de gestion des risques cybersécurité et de gouvernance | Gouvernance des TIC et cadre de gestion des risques liés aux TIC | Politique de sécurité de l’information, SoA, dossier de revue de direction |
| Les risques sont-ils évalués et traités ? | Registre des risques, plan de traitement des risques, justifications de la SoA, approbations du risque résiduel | Mesures de cybersécurité fondées sur les risques au titre de l’Article 21 | Identification, protection, prévention, détection, réponse et rétablissement des risques liés aux TIC | Registre des risques, plan de traitement des risques, SoA_Builder.xlsx |
| Les fournisseurs sont-ils contrôlés ? | Politique fournisseurs, enregistrements de diligence raisonnable, contrats, droits d’audit, clauses de notification de violation | Cybersécurité de la chaîne d’approvisionnement au titre de l’Article 21(2)(d) | Gestion des risques liés aux prestataires tiers de services TIC au titre des Articles 28 à 30 | Politique de sécurité des tiers et des fournisseurs, registre des fournisseurs |
| Les incidents sont-ils détectés, escaladés et signalés ? | Plan de réponse aux incidents, canal de signalement, enregistrements de qualification, exercices sur table, retours d’expérience | Gestion et signalement des incidents significatifs au titre de l’Article 23 | Gestion et signalement des incidents liés aux TIC au titre des Articles 17 à 19 | Politique de réponse aux incidents, tickets d’incident, rapport d’exercice |
| Les éléments probants sont-ils centralisés et auditables ? | Programme d’audit interne, référentiel d’éléments probants, registre de conformité, actions correctives | Capacité à fournir les éléments attendus par la supervision | Préparation aux inspections réglementaires et de supervision | Politique d’audit et de surveillance de la conformité, dossier d’audit central |
Cette correspondance fonctionne parce qu’elle ne crée pas de contrôles dupliqués pour chaque réglementation. Elle utilise ISO 27001:2022 comme ossature de contrôles et y ajoute des balises réglementaires, des responsabilités et des attentes en matière d’éléments probants.
Trois contrôles ISO 27001:2022 qui activent l’ossature
Plusieurs contrôles sont importants pour NIS2 et DORA, mais trois contrôles ISO/IEC 27002:2022 deviennent fréquemment l’ossature du modèle d’éléments probants : 5.1, 5.19 et 5.24. Un quatrième contrôle, 6.8, détermine souvent si le signalement des incidents fonctionne réellement.
| Contrôle ISO/IEC 27002:2022 | Pourquoi il compte | Valeur de conformité croisée |
|---|---|---|
| 5.1 Politiques de sécurité de l’information | Établit l’orientation de sécurité approuvée par la direction et la responsabilité | Soutient la gouvernance NIS2, la gouvernance des TIC DORA, la responsabilité GDPR et les éléments probants de politique ISO 27001 |
| 5.19 Sécurité de l’information dans les relations avec les fournisseurs | Définit les exigences de sécurité fournisseur pour l’intégration, la surveillance et la gestion de la relation | Soutient la cybersécurité de la chaîne d’approvisionnement NIS2, les risques liés aux prestataires tiers de services TIC DORA et la supervision des sous-traitants GDPR |
| 5.24 Planification et préparation de la gestion des incidents de sécurité de l’information | Crée le cadre de gestion des incidents, les rôles, les circuits d’escalade et les activités de préparation | Soutient la gestion des incidents NIS2, le signalement des incidents liés aux TIC DORA et l’évaluation des violations GDPR |
| 6.8 Signalement des événements de sécurité de l’information | Garantit que le personnel peut signaler rapidement les événements suspects par des canaux clairs | Soutient la détection précoce, l’escalade, l’évaluation des notifications et la qualité des éléments probants d’incident |
Dans Zenith Controls, le contrôle ISO/IEC 27002:2022 5.1, Politiques de sécurité de l’information, est caractérisé comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, avec la gouvernance et la gestion des politiques comme capacités opérationnelles clés. La cartographie croisée explique que les Articles 5(2), 24 et 32 de GDPR exigent la responsabilité, l’attribution des responsabilités et la sécurité du traitement. Elle associe également le même contrôle aux attentes NIS2 de gestion des risques cybersécurité et de gouvernance, ainsi qu’aux exigences DORA relatives à la gouvernance des TIC et au cadre de gestion des risques.
C’est pourquoi la politique de sécurité de l’information n’est pas une politique parmi d’autres. Un évaluateur NIS2 peut la lire comme un élément probant de gouvernance. Un superviseur DORA peut la lire comme un élément probant du cadre de gestion des risques liés aux TIC. Un réviseur GDPR peut la lire comme un élément probant de responsabilité. Un auditeur ISO 27001:2022 peut la lire comme une partie de la structure documentaire du SMSI.
Le contrôle 5.19, Sécurité de l’information dans les relations avec les fournisseurs, est le point de rencontre des achats, du juridique, de la sécurité, de la protection des données et de la résilience. Zenith Controls le cartographie avec les obligations GDPR relatives aux sous-traitants, la cybersécurité de la chaîne d’approvisionnement NIS2 et la gestion des risques liés aux prestataires tiers de services TIC DORA. Pour DORA, ces éléments probants deviennent encore plus solides lorsqu’ils sont appuyés par les contrôles 5.20, Traitement de la sécurité de l’information dans les accords fournisseurs, 5.21, Gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC, et 5.23, Sécurité de l’information pour l’utilisation des services cloud.
Le contrôle 5.24, Planification et préparation de la gestion des incidents de sécurité de l’information, est le moteur opérationnel de la préparation aux incidents. Zenith Controls le cartographie avec la gestion et la notification des incidents NIS2, la notification des violations de données à caractère personnel GDPR, ainsi que la gestion et le signalement des incidents liés aux TIC DORA. Ses éléments probants ne se limitent pas à une politique de réponse aux incidents. Ils incluent les canaux de signalement, les critères de qualification, les enregistrements d’escalade, les évaluations juridiques de notification, les exercices sur table, les tickets d’incident et les retours d’expérience.
Le contrôle 6.8, Signalement des événements de sécurité de l’information, comble l’écart entre le plan écrit et le comportement humain. Si le personnel ne sait pas comment signaler un hameçonnage suspecté, une fuite de données, des interruptions de fournisseur ou une activité système suspecte, l’organisation peut perdre un temps critique avant même que les évaluations de notification juridiques ou réglementaires ne commencent.
Un incident fournisseur, une chaîne d’éléments probants coordonnée
Imaginez qu’un fournisseur d’analytique cloud utilisé par le prestataire de traitement des paiements de Maria détecte un accès non autorisé à un portail d’assistance. Le fournisseur héberge des données d’usage clients pseudonymisées et soutient un flux de reporting critique pour l’activité. L’incident peut affecter des données à caractère personnel, la résilience des TIC réglementée et la disponibilité du service.
Un programme de conformité fragmenté ouvre trois flux de travail distincts : une évaluation de violation GDPR, une revue d’incident lié aux TIC DORA et un ticket fournisseur ISO 27001. Chaque équipe demande des éléments probants similaires dans un format différent. Les achats recherchent le contrat. Le juridique demande si le fournisseur est un sous-traitant. La sécurité demande si l’incident atteint les seuils de notification. La conformité ouvre un nouveau tableur.
Une ossature ISO 27001:2022 mature ouvre une seule chaîne coordonnée d’éléments probants.
D’abord, l’événement est journalisé dans le processus de réponse aux incidents. Le déclarant utilise un canal défini, l’équipe sécurité qualifie l’événement et le juridique évalue les obligations de notification. La [P30] Politique de réponse aux incidents de Clarysec exige que les incidents impliquant des données réglementées soient évalués par le juridique et le DPO :
Si un incident entraîne une exposition confirmée ou probable de données à caractère personnel ou d’autres données réglementées, le juridique et le DPO doivent évaluer l’applicabilité de :
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.4.1.
Pour les organisations de plus petite taille, la Politique de réponse aux incidents - PME attribue le même point de décision pratique :
Lorsque des données clients sont concernées, le Directeur général doit évaluer les obligations légales de notification en fonction de l’applicabilité de GDPR, NIS2 ou DORA.
Extrait de la section « Traitement des risques et exceptions », clause de politique 7.4.1.
Ensuite, la relation fournisseur est revue. Le fournisseur était-il classé critique ? Le contrat incluait-il des obligations de notification de violation, des droits d’audit, des responsabilités en matière de protection des données, des exigences de continuité de service et des dispositions de réversibilité ? La Politique de sécurité des tiers et des fournisseurs de Clarysec définit cette attente :
Intégrer des exigences de sécurité standardisées dans tous les contrats fournisseurs, y compris les obligations de notification de violation, les droits d’audit et les responsabilités en matière de protection des données.
Extrait de la section « Objectifs », clause de politique 3.2.
Pour les PME, la Politique de sécurité des tiers et des fournisseurs - PME rend explicite l’objectif de conformité croisée :
Soutenir la conformité avec ISO/IEC 27001:2022, GDPR, NIS2 et DORA pour les obligations relatives à la gouvernance des fournisseurs.
Extrait de la section « Objectifs », clause de politique 3.6.
Enfin, le registre des risques, le plan de traitement et la SoA sont mis à jour si l’incident révèle une lacune. Le contrat fournisseur ne prévoit peut-être pas de délai de notification réglementaire spécifique. La fréquence de surveillance des fournisseurs est peut-être trop faible pour un prestataire de services TIC critique. Le plan de réponse aux incidents ne distingue peut-être pas clairement les critères de violation de données à caractère personnel des critères d’interruption de service TIC.
L’objectif n’est pas de créer un nouvel univers de conformité. L’objectif est de mettre à jour une chaîne d’éléments probants intégrée afin que les mêmes enregistrements puissent répondre à plusieurs questions d’audit.
Transformer la SoA en carte d’éléments probants NIS2 et DORA
Une SoA standard répond souvent bien aux questions ISO : quels contrôles sont applicables, pourquoi ils ont été sélectionnés et s’ils sont mis en œuvre. Pour en faire une carte pratique d’éléments probants NIS2 et DORA, enrichissez-la avec des champs réglementaires et opérationnels.
Ouvrez le fichier SoA_Builder.xlsx de l’Audit Ready Toolkit référencé dans Zenith Blueprint, phase Audit, revue et amélioration, étape 24. L’étape 24 explique que les auditeurs prélèvent souvent un contrôle dans la SoA et demandent pourquoi il a été mis en œuvre. La colonne de justification et le risque ou l’exigence lié doivent répondre à cette question.
Ajoutez ces colonnes :
| Nouvelle colonne SoA | Objet | Exemple d’entrée |
|---|---|---|
| Base réglementaire | Indique si le contrôle soutient NIS2, DORA, GDPR, des contrats clients ou la résilience | NIS2, DORA, GDPR |
| ID du risque cartographié | Relie le contrôle au registre des risques | R-017 Interruption fournisseur affectant le reporting réglementé |
| Responsable des éléments probants | Identifie la personne qui maintient les preuves | Responsable des opérations de sécurité |
| Élément probant principal | Définit l’élément justificatif que les auditeurs doivent examiner en premier | Plan de réponse aux incidents et journal des tickets d’incident |
| Élément probant opérationnel | Montre que le contrôle fonctionne dans la durée | Rapport d’exercice sur table, test de notification de violation fournisseur |
| Statut d’audit | Suit le niveau de préparation | Testé, lacune ouverte, action corrective à échéance |
Appliquez-la ensuite au jeu de contrôles principal.
| Contrôle ISO/IEC 27002:2022 | Base réglementaire | Élément probant principal | Élément probant opérationnel | Conclusion de l’auditeur |
|---|---|---|---|---|
| 5.1 Politiques de sécurité de l’information | NIS2, DORA, GDPR | Politique de sécurité de l’information approuvée, périmètre du SMSI, attribution des rôles | Enregistrement de revue de politique, attestation de formation, comptes rendus de revue de direction | La gouvernance existe, la direction a approuvé l’orientation et la responsabilité est documentée |
| 5.19 Sécurité de l’information dans les relations avec les fournisseurs | NIS2, DORA, GDPR | Politique fournisseurs, registre des fournisseurs, classification des fournisseurs | Revues de diligence raisonnable, évaluations de criticité, revues de contrats, éléments probants de droits d’audit | Le risque lié aux tiers est gouverné de l’intégration à la contractualisation, à la surveillance et à la sortie |
| 5.20 Traitement de la sécurité de l’information dans les accords fournisseurs | NIS2, DORA, GDPR | Clauses contractuelles standard, annexe de sécurité, conditions de traitement des données | Échantillonnage de contrats, approbations d’exceptions de clauses, enregistrements de revue juridique | Les exigences de sécurité sont intégrées dans les accords fournisseurs |
| 5.23 Sécurité de l’information pour l’utilisation des services cloud | DORA, NIS2, GDPR | Standard de sécurité cloud, appréciation des risques cloud, approbation d’architecture | Revue du fournisseur cloud, revue du risque de concentration, test d’incident cloud | Le risque lié aux services cloud est identifié, gouverné, surveillé et testé |
| 5.24 Planification et préparation de la gestion des incidents de sécurité de l’information | NIS2, DORA, GDPR | Politique de réponse aux incidents, matrice d’escalade, arbre de décision de notification | Tickets d’incident, rapports d’exercices sur table, retours d’expérience, évaluations de notification | Les incidents peuvent être détectés, qualifiés, escaladés et évalués aux fins de signalement réglementaire |
| 6.8 Signalement des événements de sécurité de l’information | NIS2, DORA, GDPR | Canal de signalement, supports de sensibilisation, procédure de signalement des événements | Signalements de hameçonnage, journaux de ligne d’assistance, enregistrements de simulation, entretiens avec le personnel | Le personnel sait comment signaler rapidement les événements de sécurité suspectés |
Réalisez ensuite une traçabilité par échantillon. Choisissez un incident fournisseur de l’année écoulée et suivez-le du ticket d’incident au contrat fournisseur, de la classification fournisseur au registre des risques, du traitement des risques à la SoA, puis de la SoA à la revue de direction.
Si la chaîne se rompt, ce n’est pas un échec. C’est une action corrective précise avant qu’un auditeur, un client, une autorité de régulation ou un comité du conseil d’administration ne constate la lacune.
La centralisation des éléments probants est l’accélérateur sous-estimé
De nombreuses organisations disposent de contrôles adéquats, mais d’une faible capacité de récupération des éléments probants. Les preuves sont dispersées entre les courriels, les systèmes de tickets, les dossiers SharePoint, les référentiels contractuels, les plateformes RH, les outils GRC et les portails fournisseurs. Pendant la période d’audit, l’équipe conformité passe des semaines à rechercher des captures d’écran.
Ce n’est pas de la préparation à l’audit. C’est de la récupération d’éléments pour l’audit.
La [P33S] Politique d’audit et de surveillance de la conformité - PME de Clarysec indique :
Tous les éléments de preuve doivent être stockés dans un dossier d’audit centralisé.
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.1.
Un dossier d’audit centralisé ne signifie pas un espace de dépôt non maîtrisé. Il signifie un référentiel structuré aligné sur le SMSI, la SoA, le registre des risques, le plan d’audit et le registre de conformité.
| Dossier | Contenu | Usage de conformité croisée |
|---|---|---|
| 01 Gouvernance | Périmètre du SMSI, politique de sécurité de l’information, attribution des rôles, comptes rendus de revue de direction | Gouvernance NIS2, gouvernance des TIC DORA, responsabilité GDPR |
| 02 Risques et SoA | Registre des risques, plan de traitement des risques, SoA, approbations du risque résiduel | Gestion des risques NIS2, gestion des risques liés aux TIC DORA |
| 03 Fournisseurs | Registre des fournisseurs, diligence raisonnable, contrats, notations de criticité, enregistrements de revue | Chaîne d’approvisionnement NIS2, risques liés aux prestataires tiers de services TIC DORA, sous-traitants GDPR |
| 04 Incidents | Tickets d’incident, évaluations de violation, décisions de notification, exercices sur table | Signalement NIS2, gestion des incidents DORA, notification de violation GDPR |
| 05 Audit et amélioration | Rapports d’audit interne, actions correctives, échantillonnage des éléments probants, suivi par la direction | Préparation à l’audit ISO 27001:2022, préparation à la supervision |
La Politique de conformité juridique et réglementaire - PME de Clarysec traite directement le problème de cartographie :
Lorsqu’une réglementation s’applique à plusieurs domaines (par exemple, GDPR s’applique à la conservation, à la sécurité et à la vie privée), cela doit être clairement cartographié dans le registre de conformité et les supports de formation.
Extrait de la section « Exigences de gouvernance », clause de politique 5.2.2.
C’est exactement ainsi qu’ISO 27001:2022 devient l’ossature de contrôles pour NIS2 et DORA. Vous ne vous appuyez pas sur un savoir informel. Vous cartographiez les réglementations avec les processus, les politiques, les contrôles, les éléments probants et les formations.
Le signalement des incidents commence par les personnes, pas par les portails
Une faiblesse d’audit fréquente apparaît lorsque le plan de réponse aux incidents semble solide, mais que les employés ne savent pas quand ni comment signaler. C’est dangereux pour NIS2, DORA et GDPR, car les délais d’évaluation réglementaire dépendent de la détection, de l’escalade et de la classification.
Dans Zenith Blueprint, phase Contrôles en action, étape 16, Clarysec met l’accent sur le signalement des incidents par le personnel au titre du contrôle ISO/IEC 27002:2022 6.8. Les recommandations indiquent que la réponse aux incidents commence par les personnes. Les organisations doivent créer un canal de signalement clair, simple et accessible, tel qu’une adresse de courriel surveillée, un portail interne, une ligne d’assistance ou une catégorie de ticket. Elles recommandent également une formation de sensibilisation, une culture de signalement sans blâme, la confidentialité, un seuil de signalement bas et des simulations périodiques.
L’impact sur la conformité croisée est direct. Zenith Blueprint relie cette capacité de signalement par le personnel à l’Article 33 de GDPR, à l’Article 23 de NIS2 et à l’Article 17 de DORA. Si les employés hésitent à signaler une activité suspecte, l’organisation peut perdre un temps critique avant que les équipes juridiques, sécurité ou réglementaires puissent évaluer les obligations de notification.
Un test de contrôle pratique est simple :
- Demander à cinq employés comment signaler un courriel de hameçonnage suspecté.
- Vérifier si le canal de signalement est surveillé.
- Confirmer si le système de tickets comporte une catégorie incident de sécurité.
- Revoir la dernière simulation ou le dernier exercice sur table.
- Vérifier que les retours d’expérience ont été examinés en revue de direction.
Si une réponse est incertaine, mettez à jour la fiche d’instructions relative aux incidents, le support de formation, le canal de signalement et la référence d’élément probant dans la SoA.
Comment différents auditeurs inspectent la même ossature
Les éléments probants de conformité croisée doivent résister à différents angles d’audit. Le même contrôle peut être testé différemment selon le mandat du réviseur.
| Angle d’audit | Question probable | Éléments probants attendus | Défaillance fréquente |
|---|---|---|---|
| Auditeur ISO 27001:2022 | Pourquoi ce contrôle est-il applicable et fonctionne-t-il comme décrit ? | Justification de la SoA, lien avec le traitement des risques, politique, enregistrements opérationnels, résultats d’audit interne | Le contrôle existe, mais la justification SoA est vague ou obsolète |
| Évaluateur orienté NIS2 | Pouvez-vous démontrer des mesures de cybersécurité fondées sur les risques et une coordination des incidents ? | Registre des risques, politique de gouvernance, plan d’incident, processus de signalement, éléments probants du risque fournisseur | La cartographie NIS2 existe dans un jeu de diapositives, mais pas dans les éléments probants opérationnels |
| Superviseur orienté DORA | Pouvez-vous prouver la gestion des risques liés aux TIC, la classification des incidents, les tests et la supervision des tiers ? | Registre des risques liés aux TIC, criticité des fournisseurs, classification des incidents, tests de résilience, clauses contractuelles | Les enregistrements fournisseurs ne distinguent pas les prestataires de services TIC critiques des fournisseurs ordinaires |
| Réviseur orienté GDPR | Pouvez-vous démontrer la responsabilité, la sécurité du traitement, les contrôles des sous-traitants et l’évaluation des violations ? | Cartographie de la protection des données, clauses de sous-traitance, enregistrements d’évaluation des violations, éléments probants d’accès et de chiffrement | Les contrôles de sécurité sont mis en œuvre, mais ne sont pas reliés aux risques sur les données à caractère personnel |
| Auditeur orienté NIST | Pouvez-vous montrer la gouvernance, l’identification des risques, la protection, la détection, la réponse et le rétablissement ? | Gouvernance des politiques, enregistrements d’actifs et de risques, journaux de détection, éléments probants d’incident et de rétablissement | Les éléments probants techniques existent, mais la responsabilité de gouvernance est faible |
| Auditeur COBIT 2019 ou de type ISACA | Les objectifs de gouvernance, les responsabilités, la surveillance de la performance et les activités d’assurance sont-ils définis ? | RACI, responsabilité des contrôles, reporting de direction, plan d’audit, indicateurs, actions correctives | Les contrôles sont techniques, mais ne sont pas gouvernés au moyen d’une responsabilité mesurable |
C’est ici que Zenith Controls apporte une valeur supérieure à une simple table de cartographie. Il aide à traduire les contrôles ISO/IEC 27002:2022 en perspectives pertinentes pour l’audit, incluant les attributs de contrôle, les relations réglementaires et les attentes en matière d’éléments probants. Pour le contrôle 5.1, les attributs soutiennent la gouvernance, la gestion des politiques, la responsabilité et les objectifs de sécurité. Pour le contrôle 5.24, les attributs soutiennent les concepts de réponse et de rétablissement, la préparation aux incidents et l’action corrective. Pour le contrôle 5.19, les attributs de relation fournisseur relient la gouvernance, le risque écosystémique, la protection et la supervision des tiers.
Ce que le conseil d’administration doit voir
Le conseil d’administration n’a pas besoin de chaque ligne de la SoA. Il a besoin de l’histoire que raconte la SoA.
Un dossier solide pour le conseil sur l’alignement ISO 27001:2022, NIS2 et DORA doit inclure :
- Le périmètre du SMSI et les services métier couverts.
- Les principaux risques de sécurité de l’information et risques liés aux TIC.
- Un résumé des contrôles applicables par domaine.
- Le statut de cartographie NIS2, DORA et GDPR.
- Les fournisseurs critiques et les risques de concentration.
- Les indicateurs de signalement des incidents et les résultats des exercices sur table.
- Les actions correctives ouvertes et les traitements des risques en retard.
- Les décisions nécessaires sur l’acceptation du risque, le budget, la responsabilité et les ressources.
Cela transforme la conformité en éléments probants de gouvernance. Cela s’aligne également sur l’objet du contrôle 5.1 dans Zenith Controls, où les politiques de sécurité de l’information soutiennent l’orientation au niveau de la direction, la responsabilité et les objectifs de sécurité.
Erreurs fréquentes à éviter
La première erreur consiste à supposer que la certification ISO 27001:2022 prouve automatiquement la conformité à NIS2 ou DORA. Ce n’est pas le cas. ISO 27001:2022 vous donne un système de management solide et une ossature de contrôles, mais vous devez encore définir le périmètre réglementaire, réaliser l’analyse juridique, interpréter les exigences sectorielles, mettre en place les circuits de notification et connaître les attentes des autorités nationales.
La deuxième erreur consiste à traiter la SoA comme un document statique. La SoA doit évoluer lorsque de nouveaux fournisseurs, systèmes, incidents, règlements, services ou risques apparaissent. Zenith Blueprint, étape 24, recommande de vérifier la cohérence de la SoA avec le registre des risques et le plan de traitement, en veillant à ce que chaque contrôle sélectionné dispose d’une justification fondée sur un risque cartographié, une exigence légale ou un besoin métier.
La troisième erreur consiste à cartographier à un niveau trop élevé. Une diapositive indiquant « ISO 27001 correspond à DORA » n’est pas un élément probant d’audit. Une entrée SoA spécifique qui relie la sécurité des relations fournisseurs à un risque de fournisseur de services TIC critique, une clause contractuelle, un enregistrement de revue fournisseur et une attente DORA de supervision des tiers est beaucoup plus solide.
La quatrième erreur consiste à ne pas centraliser les éléments probants. Si le responsable conformité passe deux semaines à collecter des captures d’écran avant chaque audit, l’organisation a un problème de récupération.
La cinquième erreur consiste à ignorer les contrôles relatifs aux personnes. Le signalement des incidents, l’intégration des fournisseurs, les revues d’accès, l’acceptation de la politique et l’escalade dépendent tous du comportement humain. Un processus soigné que personne ne suit s’effondrera lors de l’échantillonnage d’audit.
Le modèle opérationnel Clarysec pour la conformité croisée
La méthode Clarysec relie le récit de conformité de la stratégie aux éléments probants :
- Dans Zenith Blueprint, phase Gestion des risques, étape 13, vous cartographiez les contrôles avec les risques et construisez la SoA comme document de liaison.
- Dans Zenith Blueprint, phase Gestion des risques, étape 14, vous établissez des références croisées entre les exigences GDPR, NIS2 et DORA, les politiques et les contrôles.
- Dans Zenith Blueprint, phase Contrôles en action, étape 16, vous opérationnalisez le signalement des incidents par le personnel afin que l’escalade commence tôt.
- Dans Zenith Blueprint, phase Audit, revue et amélioration, étape 24, vous finalisez et testez la SoA, la vérifiez par rapport au plan de traitement des risques et la préparez comme l’un des premiers documents qu’un auditeur demandera.
Cette méthode est soutenue par les politiques Clarysec qui transforment les principes en règles opérationnelles : gouvernance de la sécurité de l’information, traitement des risques, sécurité des fournisseurs, réponse aux incidents, cartographie juridique et réglementaire, et stockage des éléments probants.
Le résultat n’est pas seulement une préparation ISO 27001:2022. C’est un système réutilisable d’éléments probants de conformité pour NIS2, DORA, GDPR, les programmes d’assurance demandés par les clients, l’audit interne et la supervision par le conseil d’administration.
Prochaines étapes : construire une fois, prouver plusieurs fois
Si votre organisation fait face à NIS2, DORA, GDPR, à des audits clients ou à une pression de certification ISO 27001:2022, commencez par l’ossature.
- Revoyez votre SoA et ajoutez des colonnes de base réglementaire pour NIS2, DORA et GDPR.
- Vérifiez la cohérence de la SoA avec votre registre des risques et votre plan de traitement des risques.
- Cartographiez les fournisseurs critiques avec les contrôles de sécurité fournisseur, les clauses contractuelles et les éléments probants de surveillance.
- Testez votre processus de signalement des incidents au moyen d’un exercice sur table.
- Centralisez les éléments probants d’audit par contrôle, réglementation, responsable et statut de test.
- Utilisez Zenith Controls pour traduire les contrôles ISO/IEC 27002:2022 en éléments probants de conformité croisée.
- Utilisez Zenith Blueprint pour passer du traitement des risques à une validation de la SoA prête pour l’audit.
- Déployez l’ensemble de politiques Clarysec, notamment la Politique de sécurité de l’information, la Politique de gestion des risques, la Politique de sécurité des tiers et des fournisseurs et la Politique de réponse aux incidents, afin d’accélérer la mise en œuvre.
La voie la plus rapide ne consiste pas à multiplier les listes de contrôle déconnectées. Elle consiste à mettre en place un SMSI intégré, une SoA traçable, un modèle centralisé d’éléments probants et un rythme opérationnel unique de conformité croisée.
Clarysec peut vous aider à transformer ISO 27001:2022 d’un projet de certification en une ossature pratique de contrôles pour NIS2 et DORA. Téléchargez Zenith Blueprint, explorez Zenith Controls, ou réservez une évaluation Clarysec pour construire un modèle d’éléments probants prêt pour l’audit avant que le prochain régulateur, client ou comité du conseil d’administration ne demande des preuves.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


