Guide 2026 du registre des obligations de conformité en cybersécurité

Maria, RSSI d’une plateforme fintech en forte croissance, disposait de vingt minutes avant le gel du dossier trimestriel destiné au conseil d’administration. Le message du directeur général était bref et inconfortable :

« Maria, j’ai besoin d’une seule diapositive montrant que nous maîtrisons nos obligations légales de cybersécurité pour 2026. Pas seulement ISO 27001. Je parle de tout : NIS2, DORA, GDPR, nos contrats clients. Sommes-nous conformes ? Où sont les éléments de preuve ? Qui en est responsable ? »

À 08:15, trois autres demandes sont arrivées. Le service juridique voulait savoir si l’entreprise était une entité importante au titre des textes nationaux de transposition de NIS2 dans un État membre. Le DPO voulait déterminer si une exportation suspecte de base de données devait être traitée comme une violation de données à caractère personnel au sens du GDPR, comme un incident majeur lié aux TIC au sens de DORA, comme les deux, ou comme aucun des deux. Les achats demandaient l’approbation d’un fournisseur d’analyse antifraude qui traiterait des données à caractère personnel de l’UE, soutiendrait un service critique et ferait appel à un sous-traitant ultérieur cloud situé hors de l’UE.

Aucune de ces questions n’est inhabituelle en 2026. Le risque apparaît lorsque l’organisation ne peut pas y répondre à partir d’une source de vérité unique et tenue à jour.

La plupart des entreprises disposent de politiques. Beaucoup ont des registres des risques, des dossiers fournisseurs, des registres relatifs à la protection des données, des playbooks de gestion des incidents et une Déclaration d’applicabilité. Mais la lacune se révèle lorsqu’un membre du conseil d’administration, un auditeur, une autorité de régulation ou un grand client pose une question simple :

« Montrez-moi chaque obligation légale, réglementaire et contractuelle de cybersécurité applicable, qui en est responsable, à quelle fréquence elle est revue, quel contrôle la met en œuvre, quels éléments de preuve l’attestent et comment les exceptions sont remontées à la direction. »

C’est précisément le rôle du registre des obligations de conformité en cybersécurité.

Pour les RSSI, les responsables conformité, les auditeurs et les responsables métier, ce registre n’est plus une simple feuille de calcul administrative. C’est le mécanisme opérationnel qui relie les obligations nationales issues de NIS2, les attentes de supervision DORA, la responsabilité prévue par le GDPR, les exigences ISO/IEC 27001:2022, les contrats clients et les politiques internes dans un système de gouvernance efficace.

Clarysec considère ce registre comme un livrable justificatif vivant du SMSI, et non comme une annexe juridique. Dans la Politique de conformité juridique et réglementaire, la fonction Conformité :

« Tient à jour le registre des obligations de conformité, qui recense l’ensemble des lois, normes, certifications et clauses contractuelles applicables. »
Extrait de la Politique de conformité juridique et réglementaire, Rôles et responsabilités, clause 4.2.1.

Le mot essentiel est « tient à jour ». Un registre créé pour la certification puis ignoré jusqu’au prochain audit n’est pas un mécanisme de conformité. C’est un élément de preuve d’un optimisme passé.

Ce qu’un registre des obligations de conformité en cybersécurité doit faire en 2026

Un registre des obligations utile remplit cinq fonctions.

Premièrement, il identifie les obligations. Celles-ci comprennent les lois, réglementations, normes, certifications et clauses contractuelles. En 2026, les sources courantes incluent NIS2 pour les entités essentielles et importantes, DORA pour les entités financières couvertes et les prestataires tiers de services TIC, GDPR pour les responsables du traitement et les sous-traitants traitant des données à caractère personnel de l’UE, les exigences ISO/IEC 27001:2022 relatives au SMSI, les engagements de sécurité cloud, les clauses contractuelles de notification des violations aux clients, les règles d’externalisation et les exigences de sécurité des fournisseurs.

Deuxièmement, il qualifie l’applicabilité. NIS2 peut s’appliquer parce que l’organisation relève d’un secteur de l’Annexe I ou de l’Annexe II, fournit une infrastructure numérique, agit comme prestataire de services managés, fournit des services d’informatique en nuage ou relève d’une catégorie indépendante de la taille, telle que DNS, TLD ou les services de confiance. DORA peut s’appliquer parce que l’organisation est une entité financière ou un prestataire tiers de services TIC soutenant des entités financières. GDPR peut s’appliquer parce que l’organisation traite des données à caractère personnel de l’UE, offre des services à des personnes situées dans l’UE ou surveille des comportements dans l’UE.

Troisièmement, il relie les obligations aux contrôles internes, aux politiques, aux processus et aux systèmes. C’est à ce stade que le registre devient opérationnel. Les mesures de gestion des risques de NIS2 Article 21 se rattachent à l’appréciation des risques, à la gestion des incidents, à la continuité d’activité, à la sécurité de la chaîne d’approvisionnement, au développement sécurisé, aux revues de l’efficacité des contrôles, à la formation, à la cryptographie, au contrôle d’accès, à la gestion des actifs et à l’authentification multifacteur lorsque cela est approprié. DORA se rattache à la responsabilité de l’organe de direction, à la gestion des risques liés aux TIC, à la classification des incidents, aux tests de résilience, aux registres des tiers et aux stratégies de sortie. GDPR se rattache aux registres des activités de traitement, à la base légale, à la minimisation des données, à la conservation, à la sécurité du traitement, à l’évaluation des violations de données à caractère personnel et aux éléments de preuve de responsabilité.

Quatrièmement, il attribue des responsables et une périodicité de revue. Sans responsabilité attribuée, la conformité reste un sujet de réunion. Avec des responsables désignés, elle devient un processus piloté.

Cinquièmement, il définit les éléments de preuve. Le registre doit répondre à la question suivante : quel livrable justificatif prouve aujourd’hui que cette obligation est satisfaite ? Les éléments de preuve peuvent inclure les comptes rendus du conseil d’administration, les enregistrements d’appréciation des risques, les tickets d’incident, les diligences préalables relatives aux fournisseurs, les clauses contractuelles, les configurations de chiffrement, les rapports de vulnérabilités, les revues d’accès, les enregistrements de tests de sauvegarde, les mentions d’information, les DPIA, les évaluations de violation de données à caractère personnel et les constats d’audit interne.

La politique de Clarysec rend cette traçabilité explicite :

« Toutes les obligations légales et réglementaires doivent être reliées à des politiques, contrôles et propriétaires précis au sein du système de management de la sécurité de l’information (SMSI). »
Extrait de la Politique de conformité juridique et réglementaire, Exigences de mise en œuvre de la politique, clause 6.2.1.

Elle définit également les éléments de preuve dans le même mécanisme :

« Livrables justificatifs ou enregistrements requis pour démontrer la conformité, par exemple journaux d’audit, paramètres de chiffrement, documentation du consentement. »
Extrait de la Politique de conformité juridique et réglementaire, Exigences de mise en œuvre de la politique, clause 6.2.2.3.

C’est ce qui distingue la sensibilisation à la conformité de l’assurance de la conformité.

Pourquoi ISO/IEC 27001:2022 constitue l’ossature

ISO/IEC 27001:2022 est souvent abordée comme un objectif de certification, mais sa valeur est plus forte pour la gestion des obligations. Elle donne au registre un ancrage dans un système de management.

Les clauses 4.1 à 4.4 exigent que l’organisation comprenne les enjeux internes et externes, identifie les parties intéressées et détermine les exigences légales, réglementaires et contractuelles pertinentes pour le SMSI. Les clauses 5.1 à 5.3 exigent l’engagement de la direction, l’alignement des politiques, les ressources et les responsabilités attribuées. Les clauses 6.1 à 6.2 exigent l’appréciation des risques, le traitement des risques, la Déclaration d’applicabilité et des objectifs mesurables éclairés par les exigences applicables. Les clauses 8, 9 et 10 créent le cycle opérationnel : mettre en œuvre les contrôles, réévaluer les risques, surveiller la performance, conduire des audits internes, réaliser la revue de direction et corriger les non-conformités.

Dans Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur, Clarysec place ce travail tôt dans la phase de fondation et de leadership du SMSI, à l’étape 2 : besoins des parties prenantes et domaine d’application du SMSI. Le Blueprint recommande aux équipes d’identifier les exigences des parties prenantes en examinant les exigences légales et réglementaires, en extrayant les clauses contractuelles de sécurité, en interrogeant les parties prenantes et en prenant en compte les normes sectorielles attendues par les partenaires.

« La clause 4.2 n’impose pas de document spécifique, mais en pratique il est utile de créer un tableau d’analyse des parties prenantes. Il peut s’agir d’un tableau simple avec les colonnes suivantes : partie intéressée, besoins/attentes, manière dont nous y répondons. »
Extrait de Zenith Blueprint, phase de fondation et de leadership du SMSI, étape 2.

Cette analyse des parties prenantes devient l’entrée amont du registre des obligations. Le registre devient ensuite le pont vers le traitement des risques.

Dans la phase de gestion des risques, à l’étape 13, Zenith Blueprint demande aux équipes de relier les contrôles aux risques, clauses et réglementations externes :

« Effectuez des références croisées avec les réglementations : si certains contrôles sont mis en œuvre spécifiquement pour se conformer au GDPR, à NIS2 ou à DORA, vous pouvez le noter soit dans le registre des risques, dans la justification de l’impact du risque, soit dans les notes de la SoA. »
Extrait de Zenith Blueprint, phase de gestion des risques, étape 13 : planification du traitement des risques et Déclaration d’applicabilité.

C’est cette traçabilité que les auditeurs attendent. Si le GDPR justifie les contrôles de chiffrement, de conservation et d’évaluation des violations de données à caractère personnel, indiquez-le. Si NIS2 justifie l’escalade du signalement des incidents et les mesures de sécurité des fournisseurs, indiquez-le. Si DORA justifie les registres de risques liés aux prestataires tiers TIC et les tests de sortie, indiquez-le.

Les trois points d’ancrage ISO/IEC 27002:2022

Le contrôle central d’ISO/IEC 27002:2022 pour la gestion des obligations est 5.31, Exigences légales, statutaires, réglementaires et contractuelles. Le Zenith Controls : guide de conformité croisée de Clarysec classe 5.31 comme un contrôle préventif lié à la confidentialité, à l’intégrité et à la disponibilité, aligné sur le concept de cybersécurité Identifier et opérant dans la capacité Juridique et conformité à travers les domaines de gouvernance, d’écosystème et de protection.

Le récit de Zenith Controls est direct :

« La sécurité n’existe pas dans le vide. Elle s’inscrit dans un maillage d’obligations, certaines définies par la loi, d’autres par contrat, et d’autres encore par des réglementations sectorielles. »
Extrait de Zenith Controls, traitement du contrôle ISO/IEC 27002:2022 5.31.

Le contrôle 5.31 ne fonctionne pas seul. Deux contrôles de soutien sont essentiels.

Le contrôle 5.2, Rôles et responsabilités en sécurité de l’information, garantit que les obligations ne sont pas attribuées de façon abstraite à « l’activité » ou à « l’informatique ». La mise en correspondance de Zenith Controls relie 5.2 à la responsabilité des politiques, à la surveillance de la conformité, à la gestion des incidents, à la sensibilisation, à la revue indépendante, au traitement des éléments de preuve et à la gouvernance des accès à privilèges.

Le contrôle 5.36, Conformité aux politiques, règles et normes de sécurité de l’information, boucle le cycle. Il garantit que les exigences documentées sont respectées, surveillées, rapportées et corrigées. La mise en correspondance de Zenith Controls relie 5.36 aux politiques de sécurité de l’information, au processus disciplinaire, à la revue indépendante, aux rôles et responsabilités, à l’évaluation des événements, à la journalisation, à la surveillance et aux enregistrements protégés.

Ensemble, ces contrôles répondent aux questions clés de l’auditeur.

Pour les organisations plus petites, la même structure peut être allégée. La Politique de conformité juridique et réglementaire - PME de Clarysec indique :

« Le DG doit tenir à jour un registre de conformité simple et structuré recensant : »
Extrait de la Politique de conformité juridique et réglementaire - PME, Exigences de gouvernance, clause 5.1.1.

Elle impose également une revue régulière :

« Le registre de conformité doit être revu trimestriellement et mis à jour lorsque : »
Extrait de la Politique de conformité juridique et réglementaire - PME, Exigences de gouvernance, clause 5.1.2.

Pour les PME, le registre peut commencer simplement. Il doit néanmoins comporter une responsabilité attribuée, une périodicité et des éléments de preuve.

Construire le registre autour des obligations, pas des référentiels

L’erreur la plus fréquente consiste à créer un suivi pour NIS2, un autre pour DORA, un autre pour GDPR, un autre pour ISO/IEC 27001:2022 et un autre pour les contrats clients. Cela crée des demandes d’éléments de preuve redondantes, des responsabilités contradictoires et des équipes épuisées.

Une meilleure approche consiste à associer les obligations aux contrôles. Une même capacité de sécurité peut satisfaire plusieurs fondements juridiques si le registre préserve les différences de déclencheur, de périmètre, de délai et d’autorité compétente.

Par exemple, la réponse aux incidents soutient le signalement des incidents significatifs au titre de NIS2, le signalement des incidents majeurs liés aux TIC au titre de DORA et l’évaluation des violations de données à caractère personnel au titre du GDPR. Les diligences préalables relatives aux fournisseurs soutiennent la sécurité de la chaîne d’approvisionnement NIS2, le risque lié aux prestataires tiers TIC DORA et la gouvernance des sous-traitants au titre du GDPR. La journalisation et la surveillance soutiennent la détection des incidents, l’efficacité des contrôles et la responsabilité. Les inventaires des actifs et des données soutiennent l’appréciation des risques NIS2, DORA, GDPR et ISO/IEC 27001:2022.

L’objectif n’est pas de masquer les différences juridiques. Il est d’éviter de mettre en œuvre trois fois la même capacité.

Un modèle pratique de registre à mettre en œuvre cette semaine

Un registre des obligations au format Clarysec doit être suffisamment simple à maintenir et suffisamment détaillé pour résister à un échantillonnage d’audit. Les champs minimaux sont les suivants :

1. Identifiant de l’obligation.
2. Source, par exemple NIS2, DORA, GDPR, ISO/IEC 27001:2022, contrat client ou politique interne.
3. Référence précise à l’article, à la clause ou au contrat.
4. Résumé de l’exigence.
5. Justification de l’applicabilité.
6. Processus métier ou service concerné.
7. Scénario de risque en cas de non-respect.
8. Mise en correspondance des contrôles, incluant les contrôles ISO/IEC 27002:2022 et les références aux politiques internes.
9. Responsable du contrôle.
10. Responsable des éléments de preuve.
11. Périodicité de revue.
12. Emplacement des éléments de preuve.
13. Exceptions ou lacunes ouvertes.
14. Indicateur d’escalade en revue de direction.
15. Date de dernière revue et prochaine date de revue.
16. Statut.

Voici un exemple pratique pour un fournisseur SaaS fintech opérant dans l’UE.

Notez que chaque ligne est exploitable. Elle ne se contente pas d’indiquer « se conformer à DORA ». Elle identifie l’exigence, la mise en correspondance interne, le responsable, le rythme de revue et les éléments de preuve.

La Politique relative aux rôles et responsabilités de gouvernance - PME de Clarysec renforce cette discipline d’attribution des responsabilités :

« Les responsabilités de gouvernance, par exemple la revue des politiques, l’approbation des exceptions et la supervision des prestataires, doivent être attribuées à des personnes ou à des rôles précis. »
Extrait de la Politique relative aux rôles et responsabilités de gouvernance - PME, Exigences de gouvernance, clause 5.3.

Dans les environnements d’entreprise, le même concept doit se refléter dans une matrice RACI, un registre des responsables de contrôle et un dossier de reporting de direction.

Exemple de signalement des incidents : un playbook, plusieurs obligations

Un fournisseur SaaS détermine qu’il peut relever du périmètre NIS2 parce qu’il fournit des activités cloud ou de services managés dans l’UE et satisfait aux critères pertinents de taille ou de secteur. L’organisation dispose déjà d’un plan de réponse aux incidents, mais elle n’a pas intégré le signalement NIS2 dans ses procédures d’escalade.

L’entrée du registre doit décrire l’obligation avec précision :

• Source : NIS2 Article 23.
• Exigence : notifier sans retard injustifié le CSIRT ou l’autorité compétente pour les incidents significatifs, avec une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final sous un mois.
• Applicabilité : potentiellement applicable en raison de la catégorie de service et des opérations dans les États membres.
• Risque en cas de non-respect : manquement réglementaire, notification tardive des parties prenantes, perte de confiance des clients.

Il faut ensuite la relier aux contrôles. Les contrôles ISO/IEC 27002:2022 5.24 à 5.28 couvrent la planification de la gestion des incidents, l’évaluation, la réponse, le retour d’expérience et la collecte des éléments de preuve. Le contrôle 5.31 couvre le suivi des obligations légales. Le contrôle 5.2 couvre l’attribution des rôles. Le contrôle 5.36 couvre la surveillance du respect du processus.

La responsabilité doit être explicite. Le responsable des incidents est responsable de la classification et de l’escalade. Le Juridique ou la Conformité est responsable de l’interprétation réglementaire et de l’autorisation de notification. La Communication est responsable de la communication client. Le responsable des éléments de preuve tient à jour le dossier d’incident.

Les éléments de preuve doivent inclure l’enregistrement de classification de l’incident, la chronologie, l’heure de prise de connaissance, l’heure de triage, l’heure d’escalade, la décision de notification, le dépôt auprès de l’autorité de régulation le cas échéant, la décision de communication client, les enseignements tirés et les actions correctives.

Un exercice sur table rend ensuite le registre concret. Utilisez un scénario dans lequel une mauvaise configuration cloud entraîne une exposition potentielle de données clients et une interruption de service. Testez la capacité de l’équipe à identifier le délai NIS2 de 24 heures, à déterminer si une évaluation de violation au titre du GDPR est requise, à qualifier l’impact potentiel DORA si des services financiers sont affectés et à produire un dossier d’éléments de preuve complet.

C’est ainsi que le registre des obligations devient un contrôle. Il modifie les comportements opérationnels.

La gestion des éléments de preuve est souvent le point de défaillance des audits

De nombreuses organisations peuvent présenter un registre. Moins nombreuses sont celles qui peuvent montrer que les éléments de preuve sont complets, à jour, protégés et liés.

La Politique d’audit et de surveillance de la conformité - PME de Clarysec énonce l’exigence de base :

« Tous les éléments de preuve doivent être stockés dans un dossier d’audit centralisé. »
Extrait de la Politique d’audit et de surveillance de la conformité - PME, Exigences de mise en œuvre de la politique, clause 6.2.1.

Cette phrase résout une défaillance d’audit fréquente. Des éléments de preuve dispersés dans des courriels, des tickets Jira, des dossiers SharePoint, des portails fournisseurs et des lecteurs personnels ne sont pas compatibles avec les exigences d’audit. Le dossier centralisé n’a pas nécessairement à être un dossier littéral unique pour chaque fichier, mais il doit exister un référentiel ou un index d’éléments de preuve contrôlé qui indique à l’auditeur où se trouve le livrable justificatif faisant autorité.

Pour chaque obligation, les éléments de preuve doivent être nommés de façon cohérente, reliés à l’identifiant de l’obligation et à l’identifiant du contrôle, détenus par une personne ou un rôle nommé, protégés contre toute modification non autorisée, conservés conformément aux exigences légales et contractuelles, revus selon une périodicité définie et liés aux exceptions et aux actions correctives.

Le traitement du contrôle 5.31 par Zenith Controls relie les exigences légales à la conservation des enregistrements via le contrôle 5.33, à la vie privée et à la protection des informations à caractère personnel via le contrôle 5.34, à la revue indépendante via le contrôle 5.35 et à la conformité interne via le contrôle 5.36. C’est important, car les éléments de preuve eux-mêmes peuvent contenir des informations réglementées, telles que des données à caractère personnel, des indicateurs forensiques, des journaux d’accès à privilèges ou des données confidentielles de clients.

Le regard de l’audit : comment les différents examinateurs testeront le registre

Un registre robuste résiste à plusieurs perspectives d’audit.

Un auditeur ISO/IEC 27001:2022 commencera par le contexte, les parties intéressées, le domaine d’application, le traitement des risques, la Déclaration d’applicabilité, la surveillance, l’audit interne et la revue de direction. Pour le contrôle 5.31, l’auditeur s’attendra à constater que les exigences légales et contractuelles applicables sont identifiées, tenues à jour et reflétées dans les contrôles. Pour le contrôle 5.2, il testera si les responsabilités sont attribuées et comprises. Pour le contrôle 5.36, il recherchera la surveillance, les non-conformités et les actions correctives.

Un évaluateur aligné sur NIST se concentrera sur les résultats de gouvernance. Le NIST Cybersecurity Framework 2.0 GOVERN inclut GV.OC-03, qui attend que les exigences légales, réglementaires et contractuelles relatives à la cybersécurité, y compris les obligations liées à la vie privée et aux libertés civiles, soient comprises et gérées. L’évaluateur peut demander un profil organisationnel, une analyse des écarts et un plan d’action priorisé, puis échantillonner la manière dont les obligations se traduisent en gestion des actifs, contrôle d’accès, protection des données, journalisation, réponse et rétablissement.

Un auditeur COBIT 2019 ou ISACA examinera la situation au prisme des objectifs de gouvernance et de management. MEA03, Managed Compliance With External Requirements, est particulièrement pertinent. L’auditeur peut tester si les exigences externes sont identifiées via MEA03.01, si les réponses sont optimisées via MEA03.02, si la conformité est confirmée via MEA03.03 et si l’assurance est obtenue via MEA03.04.

Un auditeur fondé sur ISACA ITAF insistera sur des éléments de preuve suffisants et appropriés. Il peut sélectionner une exigence de notification de violation au titre du GDPR, une exigence de registre fournisseur DORA et une exigence de signalement d’incident NIS2, puis demander la piste d’éléments de preuve de bout en bout.

Un évaluateur technique peut valider le contrôle 5.36 au moyen d’éléments de configuration. Si le registre indique que NIS2 et les contrats clients exigent l’authentification multifacteur pour l’accès à privilèges, il peut vérifier les paramètres du fournisseur d’identité. S’il indique que le GDPR et les contrats exigent le chiffrement, il peut inspecter le chiffrement de la base de données, les enregistrements de gestion des clés et les diagrammes de flux de données. Si DORA exige la surveillance des services de prestataires tiers TIC, il peut examiner les revues de service, les rapports SLA et les enregistrements de tests de sortie.

Le registre nécessite à la fois des éléments de preuve de gouvernance et des éléments de preuve techniques.

La revue de direction boucle la responsabilité

Un registre des obligations de conformité ne doit pas être détenu silencieusement par la conformité. Il doit alimenter la revue de direction, car NIS2, DORA, GDPR et ISO/IEC 27001:2022 reposent tous sur la responsabilité.

NIS2 exige que les organes de direction approuvent les mesures de gestion des risques de cybersécurité et supervisent leur mise en œuvre. DORA place la responsabilité ultime de la gestion des risques liés aux TIC sur l’organe de direction. GDPR exige des responsables du traitement qu’ils démontrent leur conformité. ISO/IEC 27001:2022 exige que la revue de direction prenne en compte les changements de contexte, les besoins des parties intéressées, les résultats d’audit, les résultats de surveillance, les résultats d’appréciation des risques, l’état du traitement et les opportunités d’amélioration.

La Politique de sécurité de l’information de Clarysec s’aligne sur cette attente :

« Les activités de revue de direction, conformément à la clause 9.3 d’ISO/IEC 27001, doivent être menées au moins une fois par an et inclure : »
Extrait de la Politique de sécurité de l’information, Exigences de gouvernance, clause 5.3.

La politique d’audit PME ajoute le lien opérationnel :

« Les constats d’audit et les mises à jour de statut doivent être inclus dans le processus de revue de direction du SMSI. »
Extrait de la Politique d’audit et de surveillance de la conformité - PME, Exigences de gouvernance, clause 5.4.3.

La revue de direction n’a pas besoin de chaque ligne. Elle a besoin des tendances, des décisions de risque, des exceptions, des ressources et de la responsabilité.

Cela transforme le registre d’un dossier de conformité en outil de direction.

Schémas de défaillance courants et moyens de les éviter

Le premier schéma de défaillance est le suivant : le Juridique possède la loi, la Sécurité possède les contrôles, et personne ne possède la mise en correspondance. Clarysec l’évite en exigeant que les obligations soient reliées aux politiques, aux contrôles et aux responsables dans le SMSI.

Le deuxième consiste à suivre des référentiels plutôt que des obligations. Une entrée de registre indiquant simplement « DORA » n’est pas exploitable. Une entrée indiquant « DORA Article 28, la gestion du risque lié aux prestataires tiers TIC exige des diligences préalables, des dispositions contractuelles, une surveillance et des stratégies de sortie » est exploitable.

Le troisième est l’absence de périodicité. Une revue trimestrielle constitue une base pratique pour de nombreuses organisations, avec des mises à jour événementielles pour les nouveaux services, les nouveaux pays, les nouveaux fournisseurs, les incidents, les audits et les changements contractuels.

Le quatrième concerne les éléments de preuve qui existent mais sont introuvables. Le principe du dossier d’audit centralisé répond directement à ce problème.

Le cinquième concerne les exceptions informelles. Si un contrôle ne peut satisfaire temporairement une obligation, l’exception doit être documentée, faire l’objet d’une appréciation des risques, être approuvée, limitée dans le temps et revue.

Le sixième est la revue de direction cérémonielle. Le registre doit orienter les décisions relatives au budget, aux effectifs, à la remédiation fournisseur, à la négociation contractuelle, à l’acceptation du risque et aux actions correctives.

Comment Clarysec transforme le registre en mécanisme opérationnel

L’approche en 30 étapes de Clarysec rend la gestion des obligations praticable.

Dans Zenith Blueprint, l’étape 2 identifie les besoins des parties prenantes et les exigences applicables. L’étape 13 relie les contrôles aux risques, aux clauses et à la Déclaration d’applicabilité. L’étape 23 traite des contrôles organisationnels, y compris l’exigence de construire et de tenir à jour un registre des exigences légales et réglementaires.

Le Blueprint indique :

« Travaillez avec le Juridique, la Conformité ou un conseil juridique externe pour construire un registre des lois, réglementations et obligations contractuelles applicables liées à la sécurité de l’information (5.31). Celui-ci doit inclure les lois relatives à la protection des données, par exemple GDPR, les exigences sectorielles et les obligations de certification. Assurez-vous que l’équipe SMSI sait où le consulter et que les changements sont revus au moins trimestriellement. »
Extrait de Zenith Blueprint, phase des contrôles en action, étape 23.

Les politiques Clarysec fournissent les règles de gouvernance : tenir à jour le registre, attribuer les responsabilités, centraliser les éléments de preuve, revoir les constats et inclure le statut dans la revue de direction.

Zenith Controls fournit la boussole de conformité croisée. Pour le contrôle 5.31, il relie la gestion des obligations à la responsabilité GDPR, aux obligations de cybersécurité NIS2, à la gestion des risques liés aux TIC DORA, à la gouvernance NIST CSF, au management de programme et à la surveillance continue NIST SP 800-53, ainsi qu’à la surveillance de la conformité externe COBIT 2019. Pour le contrôle 5.2, il relie la responsabilité des rôles au GDPR, à NIS2, à DORA, à NIST et à COBIT. Pour le contrôle 5.36, il relie la surveillance du respect des politiques à la responsabilité GDPR, aux attentes NIS2 en matière d’hygiène cyber et de contrôle d’accès, à la résilience opérationnelle DORA, à la surveillance continue NIST et à la surveillance de la conformité COBIT.

La valeur est simple : un registre, une architecture de contrôles, de nombreux résultats de conformité.

Prochaines étapes : rendre votre registre des obligations prêt pour l’audit

Les organisations qui géreront correctement la conformité 2026 ne seront pas celles qui possèdent le plus de feuilles de calcul. Ce seront celles qui disposent de traçabilité : de l’obligation au responsable, du responsable au contrôle, du contrôle aux éléments de preuve, des éléments de preuve à la revue, de la revue à l’amélioration.

Commencez par ces actions :

1. Créez ou actualisez votre registre des obligations de conformité en cybersécurité.
2. Ajoutez NIS2, DORA, GDPR, ISO/IEC 27001:2022 et les principales obligations contractuelles clients.
3. Reliez chaque obligation aux politiques, aux contrôles ISO/IEC 27002:2022, aux responsables, à la périodicité de revue et aux éléments de preuve.
4. Identifiez les lacunes, les exceptions et les éléments de preuve expirés.
5. Ajoutez le statut du registre à la prochaine revue de direction du SMSI.
6. Utilisez Zenith Blueprint de Clarysec pour intégrer le registre dans la feuille de route SMSI en 30 étapes.
7. Utilisez Zenith Controls pour mettre en correspondance les obligations avec les attentes ISO, NIST, COBIT, GDPR, NIS2 et DORA.
8. Utilisez la Politique de conformité juridique et réglementaire, la Politique de conformité juridique et réglementaire - PME, la Politique relative aux rôles et responsabilités de gouvernance - PME, la Politique d’audit et de surveillance de la conformité - PME et la Politique de sécurité de l’information de Clarysec pour formaliser la responsabilité, la revue, le stockage des éléments de preuve et la responsabilité de la direction.

Clarysec peut vous aider à intégrer cette traçabilité dans votre SMSI avant que l’auditeur, l’autorité de régulation, un membre du conseil d’administration ou un client ne la demande. Téléchargez les modèles de politiques Clarysec pertinents, mettez en correspondance vos dix premières obligations cette semaine et transformez la conformité d’une course d’urgence en système opérationnel.