Domaine d’application du SMSI ISO 27001 pour NIS2, DORA et GDPR
Maria, RSSI d’une fintech européenne en forte croissance, pensait que l’audit de surveillance ISO 27001 était maîtrisé.
Le certificat était récent. La Déclaration d’applicabilité (SoA) semblait mature. La déclaration du domaine d’application couvrait « le système de management de la sécurité de l’information de l’entreprise soutenant les opérations de la plateforme SaaS ». L’environnement de production cloud était documenté. La procédure de réponse aux incidents existait. Le registre des risques comportait des propriétaires, des échéances et des cotations de risque résiduel.
Puis l’auditeur a posé une question simple :
« Quelles parties de cette plateforme SaaS relèvent également du périmètre d’enregistrement NIS2, quels services externalisés soutiennent des fonctions critiques ou importantes DORA pour vos clients financiers, et où exactement les données à caractère personnel relevant de GDPR sont-elles traitées ? »
La salle est devenue silencieuse.
Le service juridique a ouvert un tableur des obligations réglementaires. L’équipe produit a ouvert un schéma d’architecture. Le délégué à la protection des données (DPO) a ouvert les registres des activités de traitement. Les achats ont ouvert la liste des fournisseurs approuvés. Les opérations ont ouvert le plan de reprise après sinistre. Aucun de ces documents ne concordait.
Le domaine d’application du SMSI indiquait « plateforme SaaS ». L’évaluation NIS2 identifiait des services d’infrastructure numérique dans plusieurs États membres. Les contrats clients décrivaient la plateforme comme soutenant des opérations financières réglementées. Les registres GDPR incluaient des données d’identité, de la télémétrie, des adresses IP, des métadonnées de paiement, des tickets de support et des analyses sous-traitées. Le plan de reprise après sinistre couvrait la production, mais pas la plateforme de support client utilisée pour les communications relatives aux violations. Les diligences préalables fournisseurs couvraient le prestataire d’hébergement, mais pas le service managé de détection connecté aux journaux de production.
C’est le problème de cadrage du SMSI en 2026. La certification ISO 27001 conserve sa valeur, mais un « domaine d’application minimal viable » trop étroit peut devenir un passif lorsque les autorités de supervision, les clients et les auditeurs attendent du même système de management qu’il explique les services essentiels NIS2, les fonctions critiques ou importantes DORA et les limites des traitements GDPR.
Pour ISO/IEC 27001:2022, NIS2, DORA et GDPR, un domaine d’application faible n’est pas une anomalie administrative. C’est le premier domino. Si le domaine d’application est erroné, l’appréciation des risques est incomplète, la SoA est trompeuse, les contrôles fournisseurs omettent des prestataires critiques, les délais de notification des incidents deviennent incertains et la responsabilité en matière de protection des données se fragmente entre les équipes.
Pourquoi le domaine d’application du SMSI ISO 27001 est désormais une limite réglementaire
La clause 4.3 d’ISO/IEC 27001:2022 exige qu’une organisation détermine les limites et l’applicabilité du SMSI, en tenant compte des enjeux internes et externes, des exigences des parties intéressées, ainsi que des interfaces et dépendances avec d’autres organisations ISO/IEC 27001:2022.
Cette formulation compte davantage en 2026 que lors des cycles de certification précédents. NIS2, DORA, GDPR, l’externalisation cloud, les contrats clients, les services technologiques de groupe et les prestataires de services managés ne sont pas des notes de bas de page. Ce sont des données d’entrée pour définir les limites du SMSI.
NIS2 renforce les enjeux de gouvernance pour les entités essentielles et importantes. Elle exige que les organes de direction approuvent les mesures de gestion des risques de cybersécurité, en supervisent la mise en œuvre et reçoivent une formation. NIS2 Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment l’analyse des risques, 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é, l’hygiène cyber, la cryptographie, la sécurité des ressources humaines, le contrôle d’accès, la gestion des actifs et l’authentification multifacteur lorsque cela est approprié.
DORA modifie la discussion sur le domaine d’application pour les entités financières. Il s’applique depuis le 17 janvier 2025 et établit des exigences uniformes en matière de gestion des risques liés aux TIC, de notification des incidents liés aux TIC, de tests de résilience opérationnelle numérique, de partage d’informations et de gestion des risques liés aux prestataires tiers de services TIC. DORA Article 6 exige un cadre documenté de gestion des risques liés aux TIC. DORA Article 8 exige l’identification, la classification et la documentation des fonctions métier soutenues par les TIC, des actifs informationnels et des actifs TIC, y compris leurs dépendances. DORA Article 28 exige la gestion des risques liés aux prestataires tiers de services TIC.
GDPR ajoute l’axe des données à caractère personnel. Il s’applique aux traitements automatisés ou structurés de données à caractère personnel, y compris les traitements effectués par des établissements de l’UE et certains responsables du traitement ou sous-traitants non établis dans l’UE qui proposent des biens ou services à des personnes dans l’Union ou surveillent leur comportement. GDPR Article 30 exige des registres des activités de traitement, Article 32 exige la sécurité du traitement, et Article 33 fixe les attentes relatives à la notification des violations.
Un domaine d’application du SMSI défendable n’est donc pas construit autour des départements. Il est construit autour des services réglementés, des fonctions critiques ou importantes, des traitements de données à caractère personnel, des actifs de soutien et des dépendances vis-à-vis de tiers.
L’erreur : traiter ISO 27001, NIS2, DORA et GDPR comme des programmes séparés
Un schéma fréquent apparaît dans de nombreuses organisations :
- La sécurité rédige le domaine d’application ISO 27001.
- Le juridique évalue l’applicabilité de NIS2.
- Les risques ou la conformité gèrent les obligations DORA.
- La fonction protection des données tient à jour les registres des activités de traitement GDPR.
- Les achats détiennent la liste des fournisseurs approuvés.
- Les opérations détiennent la continuité d’activité et la reprise après sinistre.
Chaque équipe peut produire un travail raisonnable. Le problème est que la réalité réglementée traverse tous ces périmètres.
Un service d’identité client hébergé dans le cloud peut soutenir simultanément la fourniture de services NIS2, les opérations client réglementées par DORA et le traitement de données à caractère personnel soumis à GDPR. Un prestataire de détection managée peut être à la fois un fournisseur de sécurité, une dépendance de réponse aux incidents, un sous-traitant ou sous-traitant ultérieur de données de journalisation, et une source clé pour les décisions de notification réglementaire. Une plateforme de support peut être considérée comme « hors production », tout en traitant des communications relatives à des violations de données à caractère personnel et des demandes clients d’éléments probants.
Le SMSI est le meilleur endroit pour intégrer ces obligations, car ISO 27001 impose une question structurante : qu’est-ce qui est à l’intérieur de la limite, qu’est-ce qui est à l’extérieur, et pourquoi ?
Le Zenith Blueprint : feuille de route en 30 étapes pour auditeur de Clarysec Zenith Blueprint traite ce sujet dans la phase Fondations et leadership du SMSI, étape 2 : besoins des parties intéressées et domaine d’application du SMSI :
« Une fois le contexte compris et les exigences des parties intéressées identifiées, la clause 4.3 vous demande de déterminer les limites et l’applicabilité du SMSI afin d’en établir le domaine d’application. Le domaine d’application du SMSI est une définition essentielle qui fixe ce qui est inclus dans votre programme de management de la sécurité (et ce qui ne l’est pas). »
Le Zenith Blueprint met également en évidence un point que de nombreuses déclarations de domaine d’application omettent encore :
« Si vous externalisez votre infrastructure informatique auprès d’un fournisseur cloud, cela ne l’exclut pas du domaine d’application ; au contraire, vous incluez la gestion de cette relation et les actifs cloud dans le domaine d’application. »
L’externalisation déplace l’exécution. Elle n’efface pas la responsabilité.
Le modèle à quatre limites pour le domaine d’application ISO 27001 en 2026
Pour les organisations concernées par NIS2, DORA et GDPR, Clarysec recommande de définir le domaine d’application du SMSI ISO 27001 au moyen de quatre limites articulées.
| Limite | Question clé de cadrage | Éléments probants typiques | Pertinence réglementaire |
|---|---|---|---|
| Limite des services | Quels services sont fournis aux clients, citoyens, patients, entités financières ou autres parties prenantes réglementées ? | Catalogue de services, évaluation d’applicabilité NIS2, contrats clients, schémas d’architecture | Classification en entité essentielle ou importante NIS2 et analyse d’impact sur les services |
| Limite des fonctions | Quels processus métier ou services TIC soutiennent des fonctions critiques ou importantes ? | BIA, cartographie des fonctions critiques DORA, stratégie de résilience, enregistrements RTO et RPO | Gestion des risques liés aux TIC DORA, tests de résilience opérationnelle et risque lié aux tiers |
| Limite des traitements | Où les données à caractère personnel sont-elles collectées, stockées, utilisées, transférées, journalisées, prises en charge ou supprimées ? | RoPA, cartographies des flux de données, DPIA, liste des sous-traitants de traitement de données, calendrier de conservation | Responsabilité GDPR, sécurité du traitement et réponse aux violations |
| Limite des dépendances | Quels fournisseurs, services cloud, sous-traitants et services internes partagés soutiennent les éléments ci-dessus ? | Registre des fournisseurs, contrats, inventaire cloud, plans de sortie, enregistrements de surveillance | Sécurité de la chaîne d’approvisionnement NIS2, risque lié aux prestataires tiers de services TIC DORA et contrôles fournisseurs ISO 27001 |
Une déclaration de domaine d’application faible se limite à « la plateforme SaaS ». Une déclaration plus robuste précise quels services métier, systèmes, environnements, sites, activités de traitement de données, groupes de personnel, relations fournisseurs et processus de management sont inclus.
Une version plus défendable pourrait être formulée ainsi :
« Le SMSI couvre la gouvernance, la gestion des risques, l’exploitation et l’amélioration continue de la sécurité de l’information pour la plateforme SaaS européenne d’analyse des paiements de l’entreprise, y compris les environnements cloud de production et hors production, les services d’identité client, les interfaces d’administration, les opérations de support, les plateformes de journalisation et de surveillance, la réponse aux incidents, la continuité d’activité, la gestion des fournisseurs et toutes les activités de traitement de données à caractère personnel soutenant le service. Le SMSI inclut la gestion de l’hébergement cloud externalisé, de la détection managée et des outils de support client utilisés pour la fourniture du service, la résilience, la surveillance de sécurité ou les communications liées à GDPR. »
Ce domaine d’application n’est pas seulement plus long. Il est plus auditable parce qu’il relie les services, les actifs, les traitements et les dépendances.
Comment les politiques Clarysec transforment le domaine d’application en langage de gouvernance
Le domaine d’application ne doit pas rester dans un document isolé. Il doit s’aligner sur la politique de sécurité de l’information, la conformité juridique et réglementaire, la gestion des risques, la protection des données, la gouvernance des fournisseurs, les critères d’audit et la planification de la continuité.
La Politique de sécurité de l’information Enterprise Politique de sécurité de l’information évite toute ambiguïté autour des exclusions :
« Toute exclusion ou limitation de ce domaine d’application doit être documentée dans la Déclaration du domaine d’application du SMSI et justifiée par une approbation formelle de la direction générale. »
Cette clause est importante lorsqu’une unité métier soutient que le support client est hors de la plateforme, alors même que les agents de support accèdent aux identifiants clients et traitent des communications relatives aux violations. L’exclusion n’est possible que si elle est documentée, justifiée et approuvée.
La Politique de conformité juridique et réglementaire Enterprise Politique de conformité juridique et réglementaire rend la cartographie juridique opérationnelle :
« 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). »
C’est le pont entre l’applicabilité juridique et la Déclaration d’applicabilité. NIS2 Article 21 ne doit pas rester dans une note juridique. Les obligations DORA relatives aux prestataires tiers de services TIC ne doivent pas rester uniquement dans des lignes directrices achats. Les obligations GDPR Article 30 et Article 32 ne doivent pas rester uniquement dans le registre de la protection des données. Elles nécessitent des responsables, des contrôles et des éléments probants cartographiés.
La Politique de gestion des risques Enterprise Politique de gestion des risques étend le domaine d’application aux tiers :
« La présente politique s’applique à toutes les unités organisationnelles, tous les processus métier, systèmes, personnels et engagements avec des tiers impliqués dans le traitement, le développement, le stockage ou la gestion des actifs informationnels. »
Cette formulation s’aligne sur la sécurité de la chaîne d’approvisionnement NIS2, le risque lié aux prestataires tiers de services TIC DORA et la responsabilité du responsable du traitement ou du sous-traitant au titre de GDPR.
La Politique de protection des données et de la vie privée Enterprise Politique de protection des données et de la vie privée ancre le domaine de la protection des données dans les traitements :
« La présente politique s’applique à toutes les unités organisationnelles, tous les personnels et systèmes impliqués dans le traitement d’informations personnellement identifiables (PII), notamment : »
Le principe est déterminant. Si un système traite des PII, il ne peut pas être invisible pour le SMSI au motif qu’il serait « uniquement support », « hors production » ou « détenu par le marketing ».
La Politique de continuité d’activité et de reprise après sinistre Enterprise Politique de continuité d’activité et de reprise après sinistre rattache le domaine d’application aux résultats de la BIA :
« La présente politique s’applique à toutes les unités organisationnelles, tous les systèmes d’information, processus métier, personnels et services fournis par des tiers classés comme critiques ou essentiels sur la base des résultats de l’analyse d’impact sur l’activité (BIA). »
Cette clause s’aligne naturellement sur les fonctions critiques ou importantes DORA et la continuité de service NIS2.
Pour les organisations plus petites, les politiques PME de Clarysec conservent une formulation concise tout en préservant la même logique. La Politique d’audit et de surveillance de la conformité PME Politique d’audit et de surveillance de la conformité PME définit la couverture d’audit comme :
« Tous les contrôles et systèmes relevant du domaine d’application du système de management de la sécurité de l’information (SMSI) »
La Politique de protection des données et de la vie privée PME Politique de protection des données et de la vie privée PME définit le périmètre de protection des données comme :
« Tout système, application ou lieu dans lequel des données à caractère personnel sont stockées ou transmises »
La Politique de gestion des risques PME Politique de gestion des risques PME maintient les services externalisés visibles :
« Toutes les informations, tous les services et actifs gérés en interne ou par l’intermédiaire de tiers »
Des clauses courtes comme celles-ci sont puissantes parce qu’elles empêchent une limite de certification d’exclure des données réglementées, des services cloud ou des actifs gérés par des fournisseurs.
L’inventaire des actifs est l’endroit où le domaine d’application devient réel
Une déclaration de domaine d’application n’est crédible que si elle peut être reliée aux actifs, aux propriétaires, aux fournisseurs, aux flux de données et aux éléments probants.
Le Zenith Blueprint, dans la phase de gestion des risques, étape 9 : identification des actifs, des menaces et des vulnérabilités, demande aux organisations de lister les actifs inclus dans le domaine d’application du SMSI et de saisir leur propriétaire, leur emplacement et leur classification. Il donne un exemple pratique :
« Base de données clients – détenue par le département informatique – hébergée sur AWS – contient des données à caractère personnel et financières (sensibilité élevée). »
La même étape ajoute un rappel de cadrage directement pertinent pour NIS2 et GDPR :
« Veillez à ce que les actifs contenant des données à caractère personnel soient signalés (pour leur pertinence GDPR) et que les actifs de services critiques soient notés (pour une applicabilité NIS2 potentielle si vous opérez dans un secteur réglementé). »
Le Zenith Controls : guide de conformité transversale de Clarysec Zenith Controls traite le contrôle 5.9 d’ISO/IEC 27002:2022, Inventaire des informations et autres actifs associés, comme un contrôle fondateur de conformité transversale. Ses attributs classent le contrôle comme préventif, soutenant la confidentialité, l’intégrité et la disponibilité, aligné sur le concept de cybersécurité Identifier, la capacité opérationnelle de gestion des actifs, ainsi que les domaines de gouvernance, d’écosystème et de protection.
Zenith Controls explique clairement la pertinence pour GDPR et NIS2 :
« Sans inventaire des actifs exact et à jour, les organisations ne peuvent ni évaluer ni mettre en œuvre les protections appropriées. »
Pour NIS2, l’inventaire des actifs soutient l’identification des systèmes et composants critiques qui sous-tendent les services essentiels ou importants. Pour DORA, DORA Article 8 place l’identification des actifs TIC et des actifs informationnels au cœur de la résilience opérationnelle. Pour GDPR, l’inventaire des actifs soutient la cartographie des flux de données, la qualité du RoPA et la réponse aux violations.
Les normes ISO connexes renforcent la même logique. ISO/IEC 27005:2024 renforce l’identification des actifs dans l’appréciation des risques de sécurité de l’information. ISO 22301:2019 soutient l’identification des ressources nécessaires à la continuité d’activité. ISO/IEC 19770-1:2017 soutient la maturité de la gestion des actifs informatiques. ISO/IEC 27017:2015 et ISO/IEC 27018:2019 soutiennent les contrôles propres au cloud et la protection des PII dans les clouds publics. ISO/IEC 27701:2019 étend le management des informations relatives à la vie privée. ISO/IEC 29100:2011 contribue aux principes de protection de la vie privée tels que la transparence, la minimisation et les mesures de sécurité.
Un exercice pratique de cadrage pour les équipes SaaS et fintech
Commencez par un service réglementé, et non par l’ensemble de l’entreprise. Par exemple : « SaaS européen d’analyse des paiements pour institutions financières ».
Construisez ensuite une cartographie service-actifs-traitements.
| Élément du domaine d’application | Exemple d’entrée | Pourquoi il appartient au domaine d’application |
|---|---|---|
| Service réglementé | SaaS européen d’analyse des paiements | Peut soutenir une classification NIS2 en service numérique et les obligations réglementaires des clients |
| Fonction critique ou importante | Tableau de bord de surveillance des transactions pour clients financiers réglementés | Peut être traité par les clients comme soutenant des fonctions critiques ou importantes DORA |
| Traitement de données à caractère personnel | Identité utilisateur, coordonnées clients, adresses IP, tickets de support, journaux d’audit | GDPR s’applique aux traitements automatisés ou structurés de données à caractère personnel |
| Actifs principaux | Tenant cloud de production, cluster de bases de données, passerelle API, IAM, pipeline CI/CD, pile de surveillance | Nécessaire pour l’appréciation des risques ISO 27001, la gestion des actifs NIS2 et la visibilité TIC DORA |
| Fournisseurs clés | Fournisseur cloud, prestataire de détection managée, SaaS de support client, service de messagerie, prestataire de sauvegarde | Nécessaire pour la sécurité de la chaîne d’approvisionnement NIS2 et le risque lié aux prestataires tiers de services TIC DORA |
| Dépendances de continuité | Coffre de sauvegarde, région de reprise après sinistre, communications de support, pont d’incident | Nécessaire pour la résilience DORA et la continuité d’activité NIS2 |
| Propriétaires des éléments probants | RSSI, DPO, responsable Ingénierie, responsable Achats, responsable de service | Nécessaire pour la responsabilité en audit et la revue de direction |
Un échantillon d’actifs plus détaillé pourrait ressembler à ceci.
| Nom ou description de l’actif | Propriétaire | Service métier soutenu | Pertinence réglementaire | Dans le domaine d’application du SMSI ? | Justification |
|---|---|---|---|---|---|
| Service d’authentification client | Responsable Plateforme | Connexion utilisateur et MFA | DORA, GDPR, NIS2 | Oui | Critique pour l’accès à la plateforme et traite des données à caractère personnel |
| Base de données de préproduction | Équipe DevOps | Tests de préproduction | GDPR | Oui | Traite des données à caractère personnel pseudonymisées et peut affecter la sécurité de la production |
| API de paiement tierce | Responsable Produit | Traitement principal des paiements | DORA, GDPR | Oui, gestion du fournisseur | Soutient la fourniture d’un service critique et traite des données à caractère personnel ou financières |
| Wiki interne | Responsable informatique | Documentation interne | ISO 27001 | Oui | Contient des détails de configuration, des procédures et de la documentation de sécurité |
| Réseau R&D isolé | Responsable R&D | Recherche future | Non applicable actuellement | Non | Isolé du réseau, aucune donnée de production, aucune PII, aucune fonction critique, exclusion formellement approuvée |
Ensuite, utilisez l’étape 13 du Zenith Blueprint : planification du traitement des risques et Déclaration d’applicabilité. Le guide demande aux utilisateurs de construire la SoA à partir du modèle listant tous les contrôles de l’Annexe A et de décider de leur applicabilité sur la base du traitement des risques, des exigences légales ou contractuelles, de la pertinence par rapport au domaine d’application et du contexte organisationnel. Il indique :
« Pour chaque contrôle (ligne) dans la feuille SoA, décidez s’il est Applicable à votre SMSI. »
Pour l’exemple ci-dessus, la SoA doit prendre en compte les contrôles relatifs à la sécurité des fournisseurs, aux services cloud, à la gestion des incidents, à la continuité, aux exigences légales et réglementaires, à la protection des données, à la gestion des vulnérabilités, aux sauvegardes, à la journalisation, à la surveillance, à la cryptographie, au développement sécurisé, aux tests de sécurité et à la gestion des changements.
Un workflow pratique est le suivant :
- Créer un onglet « Cartographie du domaine d’application du SMSI » dans le registre des risques et le générateur de SoA.
- Ajouter une ligne par service réglementé ou ligne de produits.
- Relier chaque service aux actifs, types de données, fournisseurs, sites et propriétaires métier.
- Marquer la pertinence NIS2, la pertinence DORA et la pertinence du traitement GDPR.
- Ajouter des scénarios de risque portant sur l’indisponibilité du service, la violation de données à caractère personnel, la défaillance fournisseur, la mauvaise configuration cloud, la vulnérabilité critique et l’échec de notification des incidents.
- Sélectionner les contrôles de la SoA sur la base de ces risques et obligations.
- Documenter les exclusions, les contrôles compensatoires et l’acceptation du risque.
- Obtenir l’approbation de la direction générale pour les limites et exclusions finales.
- Intégrer la limite finale dans l’audit interne, la revue de direction et la surveillance des fournisseurs.
Le résultat n’est pas seulement une meilleure déclaration du domaine d’application. C’est une chaîne défendable reliant service réglementé, actif, fournisseur, donnée, contrôle, propriétaire et élément probant.
Cartographie de conformité transversale : un domaine d’application, plusieurs obligations
Un SMSI ISO 27001 correctement cadré devient la couche opérationnelle où les attentes NIS2, DORA, GDPR, NIST CSF et COBIT peuvent être réconciliées.
| Contrôle ISO/IEC 27002:2022 | Valeur principale pour le cadrage | Pertinence NIS2 | Pertinence DORA | Pertinence GDPR | Pertinence NIST CSF et COBIT |
|---|---|---|---|---|---|
| 5.9 Inventaire des informations et autres actifs associés | Identifie les actifs, propriétaires, emplacements, classifications et dépendances de service | Soutient la gestion des actifs au titre de Article 21 et l’identification des systèmes soutenant les services | Soutient l’identification des actifs TIC, des actifs informationnels et des fonctions au titre de Article 8 | Soutient l’exactitude du RoPA, la sécurité du traitement et l’investigation des violations | Se rattache à NIST CSF ID.AM et COBIT 2019 BAI09 Manage Assets |
| 5.31 Exigences légales, statutaires, réglementaires et contractuelles | Relie les obligations aux politiques, contrôles, responsables et éléments probants | Soutient la gouvernance des obligations NIS2 et la conformité de la chaîne d’approvisionnement | Soutient la gestion des risques liés aux TIC, la notification et les obligations relatives aux tiers | Soutient la responsabilité et la conformité juridique | Se rattache à NIST CSF GOVERN et COBIT 2019 MEA03 Managed Compliance with External Requirements |
| 5.34 Vie privée et protection des PII | Garantit que les traitements de données à caractère personnel sont visibles et protégés | Soutient la protection des données des destinataires du service lorsque cela est pertinent | Soutient l’intégrité, la sécurité et la confidentialité des données dans les services TIC | Soutient GDPR Article 32 et les attentes de protection des données dès la conception | Soutient la gouvernance de la protection des données et la gestion opérationnelle de la vie privée |
Pour le contrôle 5.31 d’ISO/IEC 27002:2022, Exigences légales, statutaires, réglementaires et contractuelles, Zenith Controls relie les obligations de conformité à la vie privée, à la protection des PII, à la conservation des enregistrements, à la revue indépendante et au respect des politiques internes. Il se rattache naturellement à la responsabilité GDPR, à la conformité de la chaîne d’approvisionnement NIS2, à la gestion des risques liés aux TIC et à la conformité DORA, à la gouvernance NIST CSF et à la surveillance de la conformité externe COBIT 2019.
Pour le contrôle 5.34 d’ISO/IEC 27002:2022, Vie privée et protection des PII, Zenith Controls relie la vie privée à l’inventaire des actifs, aux services cloud, à la classification, au transfert d’informations, au contrôle d’accès, à la gestion des identités et aux revues de changement projet. Sa cartographie GDPR couvre la sécurité du traitement et la protection des données dès la conception. Sa cartographie DORA soutient l’intégrité, la sécurité et la confidentialité des données, y compris les données à caractère personnel traitées dans les services TIC.
Le principe est simple : ne créez pas quatre programmes de conformité déconnectés. Créez un SMSI cadré capable d’expliquer comment les obligations sont satisfaites, documentées par des éléments probants et auditées.
Périmètre de notification des incidents : lorsque les limites affectent les délais réglementaires
Un domaine d’application incorrect devient douloureusement visible pendant les incidents.
NIS2 Article 23 exige une notification échelonnée des incidents significatifs, comprenant une alerte précoce dans les 24 heures, une notification d’incident dans les 72 heures, des rapports intermédiaires sur demande et un rapport final dans un délai d’un mois. Une communication aux destinataires affectés peut également être requise.
DORA exige que les entités financières détectent, gèrent, classifient et déclarent les incidents majeurs liés aux TIC à l’aide de critères tels que les clients ou contreparties affectés, la durée, l’indisponibilité, l’étendue géographique, les pertes de données, la criticité des services affectés et l’impact économique. Les clients doivent être informés sans retard indu lorsqu’un incident majeur lié aux TIC affecte leurs intérêts financiers.
La notification d’une violation de données à caractère personnel au titre de GDPR dépend de la question de savoir si une violation entraîne la destruction, la perte, l’altération, la divulgation non autorisée de données à caractère personnel ou l’accès non autorisé à celles-ci, de manière accidentelle ou illicite.
Si la plateforme de support, l’environnement de journaux, le service d’identité, le canal de notification client ou le prestataire de détection managée se trouve hors du domaine d’application du SMSI, les équipes de gestion des incidents peuvent ne pas savoir si un événement déclenche NIS2, DORA, GDPR, les obligations contractuelles de notification client, ou l’ensemble de ces régimes. Cette incertitude consomme le délai de notification.
Un domaine d’application mature inclut les dépendances pertinentes pour les incidents : outils de détection, magasins de journaux, référentiels forensiques, canaux de communication client, outils de support, environnements de sauvegarde, ponts d’incident et fournisseurs impliqués dans le triage ou le rétablissement.
Comment les auditeurs et superviseurs testeront votre domaine d’application du SMSI
Un domaine d’application solide résiste à l’échantillonnage. Un domaine d’application faible s’effondre lorsque les auditeurs comparent les documents à la réalité.
| Angle d’audit | Ce que l’auditeur testera | Éléments probants typiquement demandés |
|---|---|---|
| Auditeur ISO 27001 | Vérifier si le domaine d’application tient compte du contexte, des exigences des parties intéressées, des interfaces, des dépendances et des exclusions documentées | Déclaration du domaine d’application du SMSI, registre des parties intéressées, registre juridique, inventaire des actifs, SoA, approbation de la direction |
| Évaluateur orienté NIST | Vérifier si les actifs, fournisseurs, réponses aux risques, la surveillance et les critères d’incident s’alignent sur la limite déclarée | Profils actuel et cible, inventaire des actifs, registre des risques, plan d’action, couverture de surveillance, plans de réponse aux incidents |
| Auditeur COBIT 2019 | Vérifier si la gouvernance couvre les obligations externes, les services critiques, la surveillance de la conformité et la responsabilité | Rapports au conseil d’administration, cartographies de conformité, propriété des services, tableaux de bord des risques, surveillance de type MEA03 |
| Auditeur ISACA ITAF | Vérifier si les éléments probants sont suffisants, appropriés et traçables depuis les obligations jusqu’aux contrôles et résultats | Actifs échantillonnés, contrats fournisseurs, journaux, registre juridique, pistes d’audit, entretiens avec les propriétaires |
| Évaluateur DORA | Vérifier si les actifs TIC et les services fournis par des tiers soutenant des fonctions critiques ou importantes sont identifiés et testés | Registre TIC, cartographie des fonctions critiques, contrats, plans de sortie, résultats des tests, enregistrements d’incidents |
| Auditeur protection des données | Vérifier si les traitements de données à caractère personnel sont inventoriés, protégés et reliés aux contrôles | RoPA, DPIA, accords de traitement des données, journaux d’accès, éléments probants de conservation, procédures de gestion des violations |
Zenith Controls fournit des attentes d’audit utiles pour le contrôle 5.9 d’ISO/IEC 27002:2022. Les auditeurs de type ISO/IEC 19011 demandent l’inventaire tôt afin de cadrer les autres évaluations et de réaliser des contrôles ponctuels sur les actifs physiques, logiciels et cloud. Les auditeurs de type ISO/IEC 27007 demandent comment et quand l’inventaire est mis à jour, en recherchant des liens avec les achats, la gestion des changements et la mise hors service. Les auditeurs de type NIST SP 800-53A vérifient que les détails de l’inventaire incluent le type d’actif, le propriétaire, l’emplacement, l’adresse réseau le cas échéant et le statut, et que les actifs cloud, virtuels et mobiles sont inclus.
Pour le contrôle 5.31, Zenith Controls note que les auditeurs de certification attendent un registre de conformité ou une liste des lois et contrats, référencés dans la SoA et les plans de traitement des risques. Les auditeurs COBIT recherchent des responsables de conformité, des évaluations et des rapports à la direction générale. Les auditeurs ISACA ITAF échantillonnent les éléments probants pour confirmer que l’organisation ne se contente pas de connaître ses obligations, mais veille activement à leur respect.
Pour le contrôle 5.34, les auditeurs examinent les politiques de protection des données, les inventaires de données, les DPIA, les journaux de formation, les éléments probants de chiffrement, les contrôles d’accès, des échantillons de demandes des personnes concernées, les éléments probants de protection de la vie privée dès la conception et les enregistrements d’incidents impliquant des PII. Une déclaration de domaine d’application qui exclut un système traitant des données à caractère personnel sera rapidement contestée.
La question du conseil d’administration : qu’est-ce qui ne peut pas être exclu ?
La direction générale demande souvent si une unité métier, un site, un fournisseur ou un système peut rester hors du domaine d’application du SMSI. Parfois, la réponse est oui. Mais pas si l’exclusion empêche l’organisation de satisfaire ses obligations légales, réglementaires, contractuelles ou de sécurité du service.
Utilisez ce test d’exclusion avant d’approuver toute limitation de périmètre :
- L’unité, le système ou le fournisseur soutient-il un service réglementé par NIS2 ?
- Soutient-il une fonction critique ou importante DORA pour l’organisation ou ses clients réglementés ?
- Collecte-t-il, stocke-t-il, transmet-il, journalise-t-il, soutient-il ou supprime-t-il des données à caractère personnel ?
- Fournit-il la surveillance de sécurité, l’identité, la sauvegarde, la réponse aux incidents ou le rétablissement pour un service inclus dans le domaine d’application ?
- Fournit-il les éléments probants nécessaires à la classification des incidents ou à la notification réglementaire ?
- Un contrat client exige-t-il qu’il soit couvert par le SMSI ?
- Sa compromission affecterait-elle la confidentialité, l’intégrité, la disponibilité, la conformité juridique ou la continuité de service dans le domaine d’application déclaré ?
Si la réponse est oui, l’exclusion nécessite des éléments probants solides, une gouvernance compensatoire, une acceptation du risque et une approbation formelle de la direction générale. Dans de nombreux cas, elle ne doit pas être exclue.
Un domaine d’application du SMSI ISO 27001 moderne doit inclure :
- Les services métier et lignes de produits couverts.
- Les entités juridiques, unités organisationnelles et sites couverts.
- Les segments clients et juridictions qui déterminent les obligations.
- Les fonctions critiques ou importantes et les services essentiels fondés sur la BIA.
- Les actifs informationnels, actifs TIC et environnements cloud.
- Les activités de traitement de données à caractère personnel et référentiels de PII.
- Les processus de développement, de test, de support, de surveillance et de gestion des incidents.
- Les fournisseurs et services externalisés soutenant les services inclus dans le domaine d’application.
- Les interfaces et dépendances avec les sociétés du groupe ou les prestataires externes.
- Les exclusions explicites, avec justification, acceptation du risque et approbation de la direction générale.
C’est ainsi que le domaine d’application ISO 27001 devient une position de gouvernance au niveau du conseil d’administration, et non un raccourci de certification.
Rendez votre domaine d’application du SMSI prêt pour audit avant que l’auditeur ne le définisse pour vous
Le pire moment pour découvrir un problème de domaine d’application est pendant une certification, une revue de supervision, une diligence raisonnable client ou un incident en cours.
Un certificat étroit peut satisfaire une case à cocher d’achat, mais il ne résistera pas à un examen sérieux s’il exclut les services, fonctions TIC, fournisseurs et traitements de données à caractère personnel qui créent l’exposition réglementaire. En 2026, les organisations qui réussiront les audits avec confiance seront celles qui pourront présenter une cartographie cohérente reliant service réglementé, actif, fournisseur, données à caractère personnel, contrôle, propriétaire et élément probant.
Commencez par trois actions concrètes :
- Utilisez la phase Fondations et leadership du SMSI, étape 2, du Zenith Blueprint Zenith Blueprint pour réécrire le domaine d’application de votre SMSI autour des services, fonctions, traitements et dépendances.
- Utilisez Zenith Controls Zenith Controls pour cartographier l’inventaire des actifs, les obligations légales et la protection des PII au regard des attentes d’audit ISO 27001, NIS2, DORA, GDPR, NIST et COBIT 2019.
- Alignez le domaine d’application des politiques à l’aide de la Politique de sécurité de l’information de Clarysec Politique de sécurité de l’information, de la Politique de conformité juridique et réglementaire Politique de conformité juridique et réglementaire, de la Politique de gestion des risques Politique de gestion des risques, de la Politique de protection des données et de la vie privée Politique de protection des données et de la vie privée et de la Politique de continuité d’activité et de reprise après sinistre Politique de continuité d’activité et de reprise après sinistre.
Si le domaine d’application actuel de votre SMSI ressemble encore à une étiquette de département, reconstruisez-le comme une limite de conformité. Téléchargez les toolkits Clarysec, cartographiez un service réglementé de bout en bout et transformez votre domaine d’application ISO 27001 en éléments probants prêts pour audit pour NIS2, DORA et GDPR.
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
