Déclaration d’applicabilité ISO 27001 pour la préparation à NIS2 et DORA
Il est 08 h 30 un lundi matin. Elena, RSSI d’un fournisseur SaaS FinTech B2B en forte croissance, ouvre une demande urgente du conseil d’administration. L’entreprise vient d’obtenir la certification ISO/IEC 27001:2022, mais un prospect bancaire majeur dans l’UE pose des questions plus exigeantes que celles du questionnaire de sécurité habituel.
Il ne demande pas seulement si l’entreprise chiffre les données, utilise l’authentification multifacteur ou dispose d’un rapport de tests d’intrusion. Il veut savoir si la plateforme SaaS l’aide à satisfaire ses obligations DORA, si le fournisseur pourrait entrer dans le champ de NIS2 en tant que service TIC ou dépendance d’infrastructure numérique, et si la Déclaration d’applicabilité ISO 27001 peut justifier chaque contrôle inclus, chaque contrôle exclu et chaque élément de preuve.
Le conseil pose la question que tout RSSI, responsable de la conformité et fondateur SaaS entend de plus en plus souvent :
Notre SoA ISO 27001 peut-elle prouver notre préparation à NIS2 et DORA ?
Elena sait que la mauvaise réponse serait de lancer trois programmes de conformité séparés : un pour ISO 27001, un pour NIS2 et un pour DORA. Cela créerait des éléments de preuve dupliqués, des responsables de contrôle en conflit et une mobilisation permanente avant chaque évaluation client. La meilleure réponse consiste à utiliser le SMSI existant comme système d’exploitation de la conformité, avec la Déclaration d’applicabilité, ou SoA, comme document maître de traçabilité.
La SoA n’est pas seulement une feuille de calcul destinée à la certification ISO. Dans un environnement européen de cybersécurité et de résilience opérationnelle, elle permet à une organisation de démontrer pourquoi les contrôles existent, pourquoi les exclusions sont défendables, qui est responsable de chaque contrôle, quels éléments de preuve soutiennent la mise en œuvre et comment l’ensemble de contrôles couvre NIS2, DORA, GDPR, les contrats clients et le traitement interne des risques.
La Politique de sécurité de l’information Enterprise de Clarysec Politique de sécurité de l’information prévoit :
Le SMSI doit inclure des limites de domaine d’application définies, une méthodologie d’appréciation des risques, des objectifs mesurables et des contrôles documentés justifiés dans la Déclaration d’applicabilité (SoA).
Cette exigence, issue de la clause 6.1.2 de la Politique de sécurité de l’information, constitue le socle d’une approche prête à l’audit. La SoA doit devenir la passerelle entre obligations, risques, contrôles, éléments de preuve et décisions de direction.
Pourquoi NIS2 et DORA ont changé le sens d’« applicable »
Une SoA ISO/IEC 27001:2022 traditionnelle commence souvent par une question simple : « Quels contrôles de l’Annexe A s’appliquent à notre plan de traitement des risques ? » Cette question reste correcte, mais elle ne suffit plus pour les fournisseurs SaaS, cloud, de services managés, fintech, de technologies financières et de chaînes d’approvisionnement critiques.
NIS2 relève le niveau de référence de la gestion des risques de cybersécurité pour les entités essentielles et importantes dans l’UE. Elle couvre des secteurs tels que l’infrastructure numérique, les fournisseurs de services cloud, les fournisseurs de services de centres de données, les réseaux de diffusion de contenu, les prestataires de services managés, les prestataires de services de sécurité managés, la banque et les infrastructures de marchés financiers. Les États membres doivent identifier les entités essentielles et importantes ainsi que les fournisseurs de services d’enregistrement de noms de domaine. De nombreux prestataires technologiques qui considéraient auparavant la réglementation cybersécurité comme un sujet client sont désormais soit directement dans le champ, soit exposés par des exigences contractuelles répercutées.
NIS2 Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées couvrant l’analyse des risques, les politiques de sécurité, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition et le développement sécurisés, l’évaluation de l’efficacité des contrôles, l’hygiène cyber, la formation, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs et l’authentification lorsque cela est approprié. NIS2 Article 23 ajoute des attentes de notification des incidents par étapes, notamment l’alerte précoce, la notification, les mises à jour et le rapport final pour les incidents significatifs.
DORA, le règlement sur la résilience opérationnelle numérique, s’applique depuis le 17 janvier 2025 et se concentre sur les entités financières et leur écosystème de risque TIC. Il couvre la gestion des risques liés aux TIC, la notification des incidents liés aux TIC, la notification des incidents opérationnels ou de sécurité liés aux paiements pour certaines entités, les tests de résilience opérationnelle numérique, le partage d’informations sur les cybermenaces, la gestion des risques liés aux prestataires tiers de services TIC, les accords contractuels et la supervision des prestataires tiers critiques de services TIC.
Pour les entités financières qui sont également des entités essentielles ou importantes au titre de NIS2, DORA fonctionne comme le régime sectoriel applicable aux obligations équivalentes de gestion des risques liés aux TIC et de notification des incidents. Mais pour les fournisseurs SaaS, les prestataires cloud, les MSP et les fournisseurs MDR servant des clients financiers, la réalité opérationnelle est que les attentes DORA arrivent par les achats, les contrats, les droits d’audit, les obligations de support en cas d’incident, la planification de sortie, la transparence sur les sous-traitants et les éléments de preuve de résilience.
Cela change la conversation autour de la SoA. La question n’est plus : « L’Annexe A contient-elle ce contrôle ? » La meilleure question est :
Pouvons-nous prouver que la sélection des contrôles est fondée sur les risques, tient compte des obligations, est proportionnée, attribuée, mise en œuvre, surveillée, étayée par des éléments de preuve et approuvée ?
ISO 27001 comme traducteur universel de NIS2 et DORA
ISO/IEC 27001:2022 est précieuse parce qu’il s’agit d’une norme de système de management, et non d’une simple liste de contrôle. Elle exige que le SMSI soit intégré aux processus de l’organisation et dimensionné selon ses besoins. Cela en fait un traducteur universel efficace pour des exigences de conformité qui se recoupent.
Les clauses 4.1 à 4.4 exigent que l’organisation comprenne son contexte, identifie les parties intéressées, détermine les exigences pertinentes et définisse le domaine d’application du SMSI. Pour un fournisseur SaaS FinTech comme l’entreprise d’Elena, ces exigences des parties intéressées peuvent inclure les clients de l’UE, les clients financiers concernés par DORA, l’exposition sectorielle à NIS2, les obligations de responsable du traitement et de sous-traitant au titre du GDPR, les dépendances cloud externalisées, les interfaces fournisseurs et les attentes du conseil d’administration.
Les clauses 6.1.1 à 6.1.3 exigent la planification face aux risques et opportunités, un processus reproductible d’appréciation des risques de sécurité de l’information, un processus de traitement des risques, une comparaison avec l’Annexe A et une Déclaration d’applicabilité qui identifie les contrôles inclus, l’état de mise en œuvre et les justifications d’exclusion.
C’est ici que la SoA devient un enregistrement des décisions de contrôle. Un contrôle peut être inclus parce qu’il traite un risque, satisfait une exigence légale, exécute un contrat client, soutient un objectif métier ou représente une hygiène de sécurité de référence. Un contrôle ne peut être exclu qu’après que l’organisation l’a évalué de manière délibérée, l’a jugé non pertinent pour le domaine d’application du SMSI, a documenté la justification et a obtenu l’approbation appropriée.
La Politique de gestion des risques Enterprise de Clarysec Politique de gestion des risques prévoit :
Une Déclaration d’applicabilité (SoA) doit refléter toutes les décisions de traitement et être mise à jour chaque fois que la couverture des contrôles est modifiée.
Cette exigence, issue de la clause 5.4 de la Politique de gestion des risques, est critique pour la préparation à NIS2 et DORA. Un nouveau client réglementé, une nouvelle dépendance cloud, une nouvelle obligation de notification des incidents ou un nouveau risque de concentration fournisseur peuvent tous modifier l’applicabilité des contrôles.
Commencer par le registre de conformité, pas par la liste des contrôles
Une SoA faible part de l’Annexe A et demande : « Quels contrôles avons-nous déjà ? » Une SoA solide part de la réalité opérationnelle de l’organisation et demande : « Quelles obligations, quels services, quels risques, quelles données, quels fournisseurs et quels clients le SMSI doit-il couvrir ? »
ISO/IEC 27005:2022 soutient cette approche en mettant l’accent sur les exigences des parties intéressées, les critères de risque et la nécessité de prendre en compte les normes, règles internes, lois, règlements, contrats et contrôles existants. Elle souligne également que la non-applicabilité ou la non-conformité doit être expliquée et justifiée.
La Politique de conformité juridique et réglementaire PME de Clarysec Politique de conformité juridique et réglementaire PME reprend le même principe opérationnel :
Le DG doit tenir à jour un registre de conformité simple et structuré listant :
Cette exigence provient de la clause 5.1.1 de la Politique de conformité juridique et réglementaire PME. Pour une petite organisation, le registre peut rester simple. Pour une grande entreprise, il doit être plus détaillé. La logique est identique : les obligations doivent être visibles avant de pouvoir être cartographiées.
La Politique de conformité juridique et réglementaire Enterprise de Clarysec Politique de conformité juridique et réglementaire est explicite :
Toutes les obligations légales et réglementaires doivent être cartographiées avec des politiques, contrôles et responsables spécifiques dans le système de management de la sécurité de l’information (SMSI).
Il s’agit de la clause 6.2.1 de la Politique de conformité juridique et réglementaire. C’est l’ossature de gouvernance qui permet d’utiliser une Déclaration d’applicabilité ISO 27001 pour la préparation à la conformité NIS2 et DORA.
| Champ du registre | Exemple d’entrée | Pourquoi c’est important pour la SoA |
|---|---|---|
| Source de l’obligation | NIS2 Article 21 | Déclenche l’inclusion des contrôles d’analyse des risques, de gestion des incidents, de continuité, de sécurité des fournisseurs, de cryptographie, de contrôle d’accès, de gestion des actifs et de formation |
| Justification d’applicabilité | Fournisseur SaaS soutenant des clients financiers et de secteurs essentiels dans l’UE | Montre pourquoi NIS2 est prise en compte, même si le statut juridique final dépend de la désignation par un État membre |
| Responsable de contrôle | Responsable des opérations de sécurité | Soutient la redevabilité et la propriété des éléments de preuve |
| Contrôle ISO/IEC 27001:2022 cartographié | Contrôles de gestion des incidents A.5.24 à A.5.28 | Relie l’obligation légale à la sélection des contrôles de l’Annexe A |
| Source des éléments de preuve | Plan de réponse aux incidents, échantillons de tickets, revue post-incident, exercice de notification | Facilite l’échantillonnage d’audit |
| Décision SoA | Applicable | Crée la traçabilité entre obligation, risque, contrôle et éléments de preuve |
Construire des critères de risque qui couvrent la résilience, la vie privée, les fournisseurs et la réglementation
De nombreuses justifications de SoA échouent parce que le modèle de cotation des risques est trop étroit. Il mesure la vraisemblance et l’impact techniques, mais ne couvre pas l’exposition réglementaire, la criticité du service, le préjudice client, la dépendance fournisseur, l’impact sur la vie privée ou la perturbation opérationnelle systémique.
NIS2 ne porte pas seulement sur la confidentialité. Elle vise à prévenir et à réduire au minimum l’impact des incidents sur les services et leurs bénéficiaires. DORA définit les fonctions critiques ou importantes selon qu’une perturbation compromettrait de manière significative la performance financière, la continuité de service ou la conformité réglementaire. Le GDPR ajoute la responsabilité, l’intégrité, la confidentialité, la préparation aux violations et le préjudice pour les personnes concernées.
La Politique de gestion des risques PME de Clarysec Politique de gestion des risques PME fournit un minimum pratique :
Chaque entrée de risque doit inclure : description, vraisemblance, impact, score, propriétaire et plan de traitement des risques.
Il s’agit de la clause 5.1.2 de la Politique de gestion des risques PME. Pour la préparation à NIS2 et DORA, Clarysec étend ce minimum à des champs tels que source de l’obligation, service affecté, catégorie de données, dépendance fournisseur, propriétaire métier, impact réglementaire, risque résiduel, état de traitement et source des éléments de preuve.
| ID du risque | Scénario de risque | Facteur d’obligation | Contrôles de traitement | Justification SoA |
|---|---|---|---|---|
| R-021 | Une panne de plateforme cloud empêche les clients d’accéder à des tableaux de bord réglementés d’analyse de fraude | NIS2 Article 21, dépendance client DORA, SLA contractuel | A.5.29, A.5.30, A.8.13, A.8.15, A.8.16 | Applicable parce que la continuité de service, les sauvegardes, la journalisation, la surveillance et la préparation TIC réduisent la perturbation opérationnelle et soutiennent les obligations de résilience des clients |
| R-034 | Un incident de sécurité impliquant des données à caractère personnel de l’UE n’est pas détecté, escaladé ou notifié dans les délais requis | Responsabilité GDPR, NIS2 Article 23, obligations de support en cas d’incident DORA | A.5.24 à A.5.28, A.8.15, A.8.16 | Applicable parce que la gestion des incidents par étapes, la collecte des éléments de preuve, le retour d’expérience, la journalisation et la surveillance soutiennent les flux de notification réglementaires et clients |
| R-047 | Une faiblesse chez un sous-traitant critique affecte la fourniture sécurisée de services à des clients financiers | Sécurité de la chaîne d’approvisionnement NIS2 Article 21, risque lié aux prestataires tiers TIC DORA | A.5.19 à A.5.23, A.5.31, A.5.36 | Applicable parce que le risque fournisseur, les exigences contractuelles, la gouvernance cloud, les obligations de conformité et la conformité aux politiques sont nécessaires pour donner de l’assurance sur les dépendances TIC |
Notez la formulation. Une justification solide ne se limite pas à « mis en œuvre ». Elle explique pourquoi le contrôle est applicable dans le contexte métier, réglementaire et de risque de l’organisation.
Cartographier les domaines NIS2 et DORA avec les contrôles ISO 27001:2022
Une fois le registre de conformité et les critères de risque établis, le travail opérationnel consiste à cartographier les domaines réglementaires avec les contrôles de l’Annexe A. Cette cartographie ne prouve pas la conformité à elle seule, mais elle fournit aux auditeurs et aux clients un index clair pour tester les éléments de preuve.
| Domaine d’exigence réglementaire | Référence NIS2 | Référence DORA | Exemples de contrôles ISO/IEC 27001:2022 |
|---|---|---|---|
| Gouvernance et responsabilité de la direction | Article 20 | Article 5 | A.5.1, A.5.2, A.5.31, A.5.35, A.5.36 |
| Cadre de gestion des risques | Article 21(1) | Article 6 | Clauses ISO 27001 6.1.1 à 6.1.3, A.5.7, A.5.31, A.5.36 |
| Gestion et notification des incidents | Article 23 | Articles 17 à 19 | A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16 |
| Continuité d’activité et résilience | Article 21(2)(c) | Articles 11 et 12 | A.5.29, A.5.30, A.8.13, A.8.14, A.8.15, A.8.16 |
| Chaîne d’approvisionnement et risque tiers | Article 21(2)(d), Article 21(3) | Articles 28 à 30 | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 |
| Acquisition et développement sécurisés | Article 21(2)(e) | Article 9 | A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.32 |
| Tests et efficacité des contrôles | Article 21(2)(f) | Articles 24 à 27 | A.5.35, A.5.36, A.8.8, A.8.29, A.8.34 |
| Contrôle d’accès et gestion des actifs | Article 21(2)(i) | Article 9(4)(d) | A.5.9, A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.3 |
| Cryptographie et chiffrement | Article 21(2)(h) | Article 9(4)(d) | A.8.24 |
Pour Elena, cette cartographie a changé la conversation avec le conseil. Au lieu de présenter NIS2 et DORA comme des projets séparés, elle a pu montrer les recoupements : gouvernance, gestion des risques, incidents, continuité, fournisseurs, tests, contrôle d’accès et cryptographie.
Les trois contrôles ISO dont dépend toute SoA NIS2 et DORA
Dans Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec considère trois contrôles ISO/IEC 27002:2022 comme centraux pour une gouvernance SoA prête à l’audit dans le cadre de NIS2 et DORA. Il s’agit de contrôles ISO, enrichis d’attributs de conformité croisée dans le guide Zenith Controls.
| Contrôle ISO/IEC 27002:2022 | Nom du contrôle | Attributs Zenith Controls | Pourquoi c’est important pour la gouvernance SoA |
|---|---|---|---|
| 5.31 | Exigences légales, statutaires, réglementaires et contractuelles | Préventif, CIA, Identifier, Juridique et conformité, Gouvernance, Écosystème, Protection | Établit le socle des obligations qui détermine l’inclusion des contrôles et l’attribution des responsables |
| 5.35 | Revue indépendante de la sécurité de l’information | Préventif et correctif, CIA, Identifier et protéger, Assurance de la sécurité de l’information, Gouvernance, Écosystème | Fournit l’assurance que les décisions SoA et les éléments de preuve de mise en œuvre peuvent résister à une revue indépendante |
| 5.36 | Conformité aux politiques, règles et normes de sécurité de l’information | Préventif, CIA, Identifier et protéger, Juridique et conformité, Assurance de la sécurité de l’information, Gouvernance, Écosystème | Relie la SoA à la conformité opérationnelle, au respect des politiques et à la surveillance |
Ces contrôles ne sont pas isolés. Ils se rattachent directement aux contrôles de relations fournisseurs A.5.19 à A.5.23, aux contrôles de gestion des incidents A.5.24 à A.5.28, aux contrôles de continuité A.5.29 et A.5.30, au contrôle relatif à la protection de la vie privée A.5.34, à la gestion des vulnérabilités A.8.8, à la gestion des configurations A.8.9, aux sauvegardes d’information A.8.13, à la journalisation A.8.15, aux activités de surveillance A.8.16, à la cryptographie A.8.24, aux contrôles de développement sécurisé A.8.25 à A.8.29 et à la gestion des changements A.8.32.
La valeur de Zenith Controls est d’aider les équipes à éviter de traiter la SoA comme un livrable justificatif limité à une seule norme. Le contrôle 5.31 soutient la cartographie légale et contractuelle. Le contrôle 5.35 soutient l’audit interne, la revue indépendante et l’assurance de la direction. Le contrôle 5.36 soutient la conformité opérationnelle aux politiques, procédures, normes et exigences de contrôle.
Utiliser le Zenith Blueprint pour construire, tester et défendre la SoA
Dans Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Clarysec place la construction de la SoA dans la phase de gestion des risques, étape 13 : planification du traitement des risques et Déclaration d’applicabilité. Le Blueprint demande aux organisations d’utiliser la feuille SoA du modèle « Risk Register and SoA Builder.xlsx », de décider si chacun des 93 contrôles de l’Annexe A est applicable et de fonder la décision sur le traitement des risques, les exigences légales et contractuelles, la pertinence du périmètre et le contexte organisationnel.
Le Blueprint indique :
La SoA est effectivement un document passerelle : elle relie votre appréciation et votre traitement des risques aux contrôles réellement en place.
Cette phrase résume le modèle opérationnel. La SoA relie obligations, risques, politiques, contrôles, éléments de preuve et conclusions d’audit.
Le Zenith Blueprint demande également aux équipes de référencer les réglementations dans les notes de la SoA lorsque cela est approprié. Si un contrôle est mis en œuvre pour GDPR, NIS2 ou DORA, cela doit apparaître dans le registre des risques ou dans les notes SoA. Plus tard, à l’étape 24, le Blueprint demande aux organisations de mettre à jour la SoA après la mise en œuvre et de la vérifier par recoupement avec le plan de traitement des risques. À l’étape 30, Préparation à la certification, revue finale et audit à blanc, le Blueprint demande aux équipes de confirmer que chaque contrôle applicable de l’Annexe A dispose d’éléments de preuve tels qu’une politique, une procédure, un rapport, un plan ou un enregistrement de mise en œuvre.
Cette séquence fait de la SoA un instrument vivant de conformité :
- L’étape 13 la construit à partir du traitement des risques et des obligations.
- L’étape 24 la teste au regard de la réalité de la mise en œuvre.
- L’étape 30 la défend au moyen d’une revue finale des éléments de preuve et d’un audit à blanc.
Rédiger des justifications d’inclusion compréhensibles par les auditeurs
Un contrôle doit être inclus dès lors qu’au moins un facteur défendable existe : traitement des risques, exigence légale, exigence contractuelle, pertinence du périmètre, hygiène de sécurité de référence, attente d’assurance client ou objectif de résilience approuvé par la direction.
Une formule utile est :
Applicable parce que [risque ou obligation] affecte [service, actif, données ou processus], et que ce contrôle fournit [résultat préventif, détectif, correctif ou de résilience], étayé par [politique, enregistrement, test, rapport ou sortie système].
| Domaine de contrôle | Justification faible | Justification prête à l’audit |
|---|---|---|
| Gestion des incidents | Mis en œuvre | Applicable parce que NIS2 Article 23 et les attentes DORA relatives au cycle de vie des incidents exigent la détection, la classification, l’escalade, le support à la notification, les communications, l’analyse de la cause racine, la collecte des éléments de preuve et le retour d’expérience pour les incidents affectant des clients réglementés |
| Sécurité des fournisseurs | Requis | Applicable parce que l’hébergement cloud, les prestataires de support et les services MDR affectent la disponibilité des services et la confidentialité des données, et que NIS2 Article 21 ainsi que les attentes DORA relatives au risque lié aux prestataires tiers TIC exigent des diligences préalables, des garanties contractuelles, une surveillance, une revue des sous-traitants et une planification de sortie |
| Cryptographie | En usage | Applicable parce que les données clients, les secrets d’authentification, les sauvegardes et les données financières réglementées nécessitent des mesures de protection de confidentialité et d’intégrité au titre de NIS2, DORA, GDPR, des contrats clients et du traitement interne des risques |
| Revue indépendante | Oui | Applicable parce que la direction, les clients et les auditeurs exigent l’assurance que les contrôles du SMSI, les décisions SoA, les éléments de preuve et les cartographies réglementaires font l’objet d’une revue indépendante périodique |
Pour un fournisseur SaaS fintech, une ligne SoA pourrait ressembler à ceci :
| Champ SoA | Exemple d’entrée |
|---|---|
| Contrôle | A.5.19 Gestion de la sécurité de l’information dans les relations fournisseurs |
| Applicabilité | Oui |
| Justification | Applicable parce que l’hébergement cloud, les outils de support et les services MDR affectent la confidentialité, la disponibilité, la détection des incidents et l’assurance des clients réglementés. Soutient les attentes NIS2 relatives à la chaîne d’approvisionnement, les attentes DORA relatives au risque lié aux prestataires tiers TIC pour les clients financiers, la responsabilité des sous-traitants au titre du GDPR et les exigences contractuelles d’audit. |
| État de mise en œuvre | Mis en œuvre et surveillé |
| Responsable | Responsable de la gestion des fournisseurs |
| Éléments de preuve | Registre des fournisseurs, liste de contrôle de diligence raisonnable, clauses de sécurité contractuelles, enregistrements de revue annuelle, rapports SOC ou d’assurance, revue des sous-traitants, plan de sortie pour les prestataires critiques |
| Risques liés | R-047, R-021, R-034 |
| Politiques liées | Politique de sécurité des tiers et des fournisseurs, Politique de conformité juridique et réglementaire, Politique de gestion des risques |
| Fréquence de revue | Annuelle, et lors d’un changement de fournisseur, d’un incident majeur, d’un nouveau client réglementé ou d’une extension de service |
Cette formulation est prête à l’audit parce qu’elle relie le contrôle au contexte, au risque, à l’obligation, à la mise en œuvre, à la responsabilité et aux éléments de preuve.
Justifier les exclusions sans créer d’exposition en audit
Les exclusions ne sont pas des échecs. Les exclusions mal justifiées en sont.
ISO/IEC 27001:2022 exige que la SoA justifie les contrôles de l’Annexe A exclus. ISO/IEC 27005:2022 renforce l’exigence selon laquelle la non-applicabilité doit être expliquée et justifiée. La Politique de sécurité de l’information Enterprise de Clarysec prévoit :
Le référentiel minimal peut être adapté ; toutefois, les exclusions doivent être documentées avec approbation formelle et justification dans la SoA.
Il s’agit de la clause 7.2.2 de la Politique de sécurité de l’information.
La Politique de sécurité de l’information PME de Clarysec Politique de sécurité de l’information PME prévoit :
Tout écart par rapport à cette politique doit être documenté, en expliquant clairement pourquoi l’écart est nécessaire, quelles mesures de protection alternatives sont en place et la date définie pour la réévaluation.
Cette exigence provient de la clause 7.2.1 de la Politique de sécurité de l’information PME.
| Domaine de contrôle | Justification d’exclusion | Mesures de protection requises |
|---|---|---|
| Contrôles de développement sécurisé pour du code interne | Non applicable parce que le domaine d’application du SMSI couvre uniquement un service de revente sans développement logiciel interne, sans modification de code et sans pipeline CI/CD | Assurance fournisseur, approbation des changements, réception des vulnérabilités, communication client et réévaluation annuelle |
| Surveillance de la sécurité physique pour les installations détenues | Non applicable parce que l’organisation ne possède aucun centre de données, salle serveur ou site de bureaux dans le domaine d’application du SMSI, et que toute l’infrastructure de production est exploitée par des fournisseurs cloud audités | Diligence raisonnable des fournisseurs cloud, contrôles contractuels, revues d’accès, revue du modèle de responsabilité partagée et éléments de preuve issus des rapports d’assurance des prestataires |
| Certaines activités de gestion des supports sur site | Non applicable parce qu’aucun support amovible ni stockage sur site n’est utilisé dans le service inclus dans le périmètre | Restrictions des terminaux, surveillance DLP lorsque cela est approprié, inventaire des actifs et validation périodique |
Pour NIS2 et DORA, les exclusions exigent une vigilance accrue. Une entreprise SaaS devrait rarement exclure la journalisation, la surveillance, les sauvegardes, la gestion des incidents, le contrôle d’accès, la sécurité des fournisseurs ou la gestion des vulnérabilités. Même lorsqu’un contrôle n’est pas lié à un risque spécifique, il peut rester nécessaire comme mesure de sécurité de référence, assurance client, attente contractuelle ou obligation légale.
La Politique de gestion des risques PME de Clarysec rappelle également comment le risque accepté doit être traité :
Accepter : justifier pourquoi aucune action supplémentaire n’est requise et enregistrer le risque résiduel.
Cette clause 6.1.1 de la Politique de gestion des risques PME correspond exactement à l’état d’esprit nécessaire pour les exclusions et les décisions relatives au risque résiduel.
Notification des incidents : prouver le flux de travail, pas l’existence d’une politique
NIS2 Article 23 exige une notification par étapes des incidents significatifs, comprenant une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification dans les 72 heures, des mises à jour lorsqu’elles sont demandées et un rapport final dans un délai d’un mois à compter de la notification de 72 heures. DORA exige que les entités financières détectent, gèrent, classent, escaladent, communiquent et signalent les incidents majeurs liés aux TIC, informent les clients affectés lorsque cela est requis, réalisent une analyse de la cause racine et améliorent les contrôles.
Un fournisseur SaaS ne signale pas toujours directement à une autorité DORA, mais il peut devoir soutenir les délais de notification de ses clients financiers. Cela rend les contrôles d’incident très pertinents dans la SoA.
Une SoA faible indique : « La politique de réponse aux incidents existe. »
Une SoA solide indique : « Applicable parce que l’organisation doit détecter, évaluer, classer, escalader, communiquer, préserver les éléments de preuve, soutenir les délais de notification réglementaire, notifier les clients affectés lorsque le contrat l’exige et tirer les enseignements des incidents affectant les services, les données ou les clients réglementés. »
Les éléments de preuve doivent inclure :
- Plan de réponse aux incidents et matrice d’escalade.
- Critères de classification de gravité.
- Flux de notification client.
- Arbre de décision de notification réglementaire lorsque applicable.
- Tickets d’incident et chronologies.
- Journaux et alertes de surveillance.
- Enregistrements d’exercices sur table.
- Revue post-incident et actions correctives.
- Procédures de préservation des éléments de preuve.
La Politique d’audit et de surveillance de la conformité Enterprise de Clarysec Politique d’audit et de surveillance de la conformité explique pourquoi cela compte :
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.
Cet objectif provient de la clause 3.4 de la Politique d’audit et de surveillance de la conformité.
Pour les organisations plus petites, la conservation des éléments de preuve doit également être explicite. La Politique d’audit et de surveillance de la conformité PME de Clarysec Politique d’audit et de surveillance de la conformité PME prévoit :
Les éléments de preuve doivent être conservés pendant au moins deux ans, ou plus longtemps lorsque la certification ou les accords clients l’exigent.
Il s’agit de la clause 6.2.4 de la Politique d’audit et de surveillance de la conformité PME.
Une SoA, plusieurs conversations d’audit
La meilleure SoA ne duplique pas les référentiels. Elle crée une narration traçable des contrôles que différents auditeurs peuvent comprendre.
| Référentiel ou angle d’analyse | Ce que l’auditeur ou l’évaluateur demandera | Comment la SoA aide |
|---|---|---|
| ISO/IEC 27001:2022 | Pourquoi ce contrôle de l’Annexe A est-il inclus ou exclu, quel est son état de mise en œuvre et où se trouvent les éléments de preuve ? | Relie les décisions de contrôle aux risques, obligations, états de mise en œuvre, responsables et éléments de preuve |
| NIS2 | Comment la gouvernance, l’analyse des risques, la gestion des incidents, la continuité d’activité, la chaîne d’approvisionnement, le chiffrement, le contrôle d’accès, la gestion des actifs et la formation fonctionnent-ils en pratique ? | Cartographie les attentes de l’Article 21 et de l’Article 23 avec les contrôles de l’Annexe A et les enregistrements opérationnels |
| DORA | Comment le risque TIC, la gestion des incidents, les tests de résilience, le risque tiers, les contrats, les droits d’audit, les plans de sortie et la supervision de la direction sont-ils étayés par des éléments de preuve ? | Montre quels contrôles soutiennent les obligations des entités financières ou l’assurance fournisseur SaaS |
| GDPR | L’organisation peut-elle démontrer l’intégrité, la confidentialité, la responsabilité, la préparation aux violations, le support au traitement licite et les contrôles applicables aux sous-traitants ? | Relie les obligations de vie privée aux contrôles d’accès, à la cryptographie, à la journalisation, aux fournisseurs, aux incidents, à la conservation et aux éléments de preuve |
| NIST CSF 2.0 | Comment les résultats Govern, Identify, Protect, Detect, Respond et Recover sont-ils soutenus par les contrôles mis en œuvre ? | Utilise la même base d’éléments de preuve pour montrer la couverture fonctionnelle de cybersécurité |
| COBIT 2019 et audit ISACA | Les objectifs de gouvernance, la propriété des contrôles, les activités d’assurance, les indicateurs et la responsabilité de la direction sont-ils définis ? | Relie les décisions SoA aux responsables, à la revue de performance, à la revue indépendante et aux actions correctives |
Un auditeur ISO 27001 commence généralement par la logique des clauses : périmètre, parties intéressées, appréciation des risques, traitement des risques, SoA, objectifs, audit interne, revue de direction et amélioration. Un réviseur orienté NIS2 se concentre sur la proportionnalité, la responsabilité de la direction, la formation, la chaîne d’approvisionnement, les délais d’incident et l’impact sur les services. Un évaluateur client orienté DORA se concentre sur le risque TIC, les fonctions critiques ou importantes, les incidents majeurs liés aux TIC, les tests de résilience, les clauses contractuelles, les droits d’audit, les plans de sortie, la sous-traitance et le risque de concentration. Un réviseur vie privée se concentre sur la responsabilité GDPR et la préparation aux violations. Un auditeur de type COBIT 2019 ou ISACA teste la gouvernance, les indicateurs, la propriété, l’assurance et les actions correctives.
C’est pourquoi la SoA ne peut pas être maintenue uniquement par l’équipe de sécurité. Elle nécessite une responsabilité partagée avec les fonctions juridique, protection des données, achats, ingénierie, opérations, RH et direction générale.
Défaillances fréquentes des SoA dans les projets de préparation à NIS2 et DORA
Clarysec observe régulièrement les mêmes problèmes dans les projets de préparation :
- La SoA marque des contrôles comme applicables, mais aucun risque, obligation ou motif métier n’est enregistré.
- NIS2 et DORA sont mentionnés dans les politiques, mais ne sont pas cartographiés avec les contrôles, les responsables ou les éléments de preuve.
- Les contrôles fournisseurs sont marqués comme mis en œuvre, mais il n’existe pas de registre des fournisseurs, de cotation de criticité, de revue contractuelle ou de plan de sortie.
- Les contrôles d’incident existent, mais le processus ne soutient pas les flux de notification à 24 heures, 72 heures, client ou finale.
- L’approbation de la direction est implicite, mais il n’existe aucun enregistrement d’acceptation du risque, d’approbation de la SoA ou de décision relative au risque résiduel.
- Les exclusions sont copiées depuis un modèle et ne correspondent pas au modèle opérationnel réel cloud, télétravail, SaaS ou fintech.
- Des éléments de preuve existent dans plusieurs outils, mais aucune piste d’audit ne les relie à la SoA.
- Le traitement des données à caractère personnel au titre du GDPR n’est pas relié aux contrôles de sécurité, à la réponse aux violations, aux contrats fournisseurs ou à la conservation.
- L’audit interne contrôle les documents, mais ne teste pas si la SoA reflète la mise en œuvre réelle.
- La SoA n’est mise à jour qu’avant la certification, et non après l’arrivée de nouveaux clients, fournisseurs, incidents, constats d’audit ou changements réglementaires.
Ce ne sont pas des problèmes documentaires. Ce sont des problèmes de gouvernance.
Liste de contrôle pratique pour une SoA ISO 27001 prête à l’audit
Utilisez cette liste de contrôle avant un audit de certification ISO 27001, une revue de préparation NIS2, une évaluation client DORA, une réunion du conseil d’administration ou une diligence raisonnable investisseur.
| Point de contrôle | Bonne réponse |
|---|---|
| Domaine d’application | Le domaine d’application du SMSI reflète les services, clients, données, fournisseurs, interfaces externalisées et dépendances réglementées |
| Parties intéressées | NIS2, les clients DORA, les rôles GDPR, les autorités de régulation, les clients, les fournisseurs et les parties prenantes internes sont identifiés |
| Registre de conformité | Les obligations légales, réglementaires, contractuelles et clients sont cartographiées avec les politiques, contrôles et responsables |
| Critères de risque | Les impacts juridiques, opérationnels, vie privée, fournisseurs, résilience, financiers et réputationnels sont inclus |
| Registre des risques | Chaque risque inclut description, vraisemblance, impact, score, propriétaire, plan de traitement des risques et risque résiduel |
| Inclusion SoA | Chaque contrôle applicable dispose d’une justification liée au risque, à l’obligation, au périmètre, au contrat ou à la sécurité de référence |
| Exclusion SoA | Chaque contrôle exclu dispose d’une justification spécifique, approuvée, fondée sur des éléments de preuve et d’un déclencheur de revue |
| Éléments de preuve | Chaque contrôle applicable dispose d’éléments de preuve sous forme de politique, procédure, configuration, rapport, test, ticket, journal, revue ou enregistrement |
| Approbation de la direction | Les propriétaires de risques approuvent les plans de traitement des risques et les risques résiduels, et la direction examine la performance du SMSI |
| Revue indépendante | L’audit interne ou la revue indépendante teste l’exactitude de la SoA, la qualité des éléments de preuve et la réalité de la mise en œuvre |
| Déclencheurs de mise à jour | Les mises à jour de la SoA ont lieu après des changements de services, de fournisseurs, des incidents, de nouveaux clients, des évolutions réglementaires ou des constats d’audit |
Transformer la SoA en passerelle de conformité défendable
La présentation d’Elena au conseil a réussi parce qu’elle n’a pas présenté trois projets de conformité déconnectés. Elle a présenté un modèle opérationnel contrôlé et fondé sur les éléments de preuve, construit sur ISO/IEC 27001:2022, avec la SoA comme passerelle entre réglementation, risque, mise en œuvre des contrôles, éléments de preuve et supervision de la direction.
NIS2 et DORA ne rendent pas ISO 27001 obsolète. Ils rendent une Déclaration d’applicabilité ISO 27001 bien construite plus précieuse. La SoA peut devenir l’endroit unique où votre organisation explique pourquoi les contrôles existent, pourquoi les exclusions sont défendables, comment les éléments de preuve sont conservés, comment les fournisseurs sont gouvernés, comment les incidents sont escaladés et comment la direction sait que le SMSI fonctionne.
Votre action immédiate est simple :
- Ouvrez votre SoA actuelle.
- Sélectionnez cinq contrôles marqués comme applicables et demandez : « Quel risque, quelle obligation ou quel contrat le justifie ? »
- Sélectionnez cinq exclusions et demandez : « Cela aurait-il encore du sens pour un auditeur NIS2, DORA, GDPR ou ISO/IEC 27001:2022 ? »
- Vérifiez que chaque contrôle applicable dispose d’éléments de preuve à jour.
- Confirmez que la direction a approuvé les risques résiduels et les décisions SoA.
- Mettez à jour le registre de conformité, le registre des risques et la SoA chaque fois que les services, fournisseurs, clients, réglementations ou incidents changent.
Clarysec aide les organisations à le faire au moyen de Zenith Blueprint Zenith Blueprint, de Zenith Controls Zenith Controls, d’ensembles de politiques Enterprise et PME, d’outils de registre des risques, de modèles de SoA, de préparation à l’audit et de cartographie de conformité croisée pour NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 et l’assurance client.
Si votre SoA ne peut pas répondre à pourquoi, qui en est responsable, quels éléments de preuve le démontrent et quelle obligation elle soutient, elle n’est pas encore prête. Utilisez Clarysec pour la transformer en passerelle de conformité prête à l’audit avant qu’une autorité de régulation, un auditeur ou un client ne pose ces questions en premier.
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
