Registres des contacts réglementaires NIS2 et DORA pour ISO 27001

L’incident de 02:17 : quand la liste de contacts devient une mesure de sécurité

À 02:17 un mardi, l’analyste SOC observe le schéma que personne ne souhaite voir. Un compte de service à privilèges s’est authentifié depuis une zone géographique inhabituelle, des enregistrements clients ont été consultés en série et un prestataire de détection managée a ouvert un ticket de gravité élevée. En quelques minutes, le responsable de l’incident confirme le risque : des indicateurs de rançongiciel se propagent latéralement, un service de production critique est dégradé et des données clients peuvent être concernées.

La réponse technique démarre rapidement. Les terminaux sont isolés, les journaux d’identité sont extraits, les instantanés cloud sont préservés et le prestataire de sécurité managée rejoint la cellule de crise. Puis une inquiétude plus froide s’installe.

Le RSSI demande : « Qui devons-nous notifier ? »

Le service juridique indique que l’autorité de contrôle en matière de protection des données pourrait devoir être impliquée. Le délégué à la protection des données (DPO) demande s’il s’agit d’une violation de données à caractère personnel. Le directeur des opérations précise que le fournisseur cloud doit faire l’objet d’une escalade au titre de la clause de support entreprise. Le responsable conformité demande si l’entité est une entité importante au sens de NIS2, ou si DORA s’applique parce que le service soutient une entité financière réglementée. Le conseil d’administration veut savoir ce qui doit être fait dans les premières 24 heures.

Personne ne conteste la nécessité de communiquer. Le problème est que les coordonnées, le circuit d’approbation, les déclencheurs juridiques et les exigences en matière d’éléments probants sont dispersés entre un ancien tableur de continuité d’activité, des contrats fournisseurs, des fils de courriels, un wiki conformité obsolète et le téléphone d’une seule personne.

Ce n’est pas seulement une gêne opérationnelle. En 2026, c’est une lacune de conformité.

NIS2 a fait de la notification progressive des incidents une obligation de gouvernance, avec notamment une alerte précoce dans les 24 heures, une notification sous 72 heures et un rapport final dans un délai d’un mois pour les incidents significatifs. DORA a instauré un régime dédié de résilience opérationnelle numérique pour les entités financières, couvrant la gestion des incidents liés aux TIC, la classification, la déclaration aux autorités compétentes, le risque lié aux tiers TIC et la communication de crise. GDPR reste pertinent chaque fois que des données à caractère personnel sont en cause. ISO/IEC 27001:2022 transforme ces obligations en éléments probants auditables du système de management.

Un registre des contacts réglementaires peut sembler administratif. Il ne l’est pas. Il constitue le tissu de liaison entre réponse aux incidents, notification juridique, continuité d’activité, coordination des prestataires, responsabilité de la direction et éléments probants d’audit.

Clarysec traite ce sujet comme un problème d’éléments probants, et non comme un exercice documentaire. Dans Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, l’étape 22 de la phase Controls in Action explique pourquoi le contact avec les autorités doit être prédéfini :

La mesure 5.5 garantit que l’organisation est prête à interagir avec les autorités externes lorsque nécessaire, non pas de manière réactive ou dans la panique, mais au moyen de canaux prédéfinis, structurés et bien compris.

C’est la véritable leçon de l’incident de 02:17. Le moment de trouver le portail de notification du régulateur, le téléphone d’astreinte du CSIRT, le contact suppléant du DPO, le canal de notification du superviseur financier et le circuit d’escalade fournisseur se situe avant l’incident, et non lorsque le délai de notification a déjà commencé à courir.

Pourquoi les registres des contacts réglementaires sont devenus une priorité de conformité en 2026

De nombreuses organisations disposent déjà de listes de contacts d’urgence. Le problème est que NIS2 et DORA exigent davantage qu’une liste de noms et de numéros de téléphone. Ils exigent une gouvernance des contacts exacte, fondée sur les rôles et prête pour l’audit, reliée aux déclencheurs juridiques, à l’autorité d’escalade, aux délais de notification et aux dépendances fournisseurs.

NIS2 s’applique à un large ensemble d’entités essentielles et importantes dans des secteurs tels que l’énergie, les transports, la banque, les infrastructures des marchés financiers, la santé, l’eau potable, les eaux usées, l’infrastructure numérique, la gestion des services TIC, l’administration publique et l’espace. Elle couvre également de nombreux fournisseurs numériques, notamment les services cloud, les 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, les places de marché en ligne, les moteurs de recherche en ligne et les plateformes de réseaux sociaux. Les États membres devaient établir les listes des entités essentielles et importantes au 17 avril 2025 et les mettre à jour au moins tous les deux ans. Pour de nombreux fournisseurs cloud, SaaS, de services managés et de plateformes numériques, l’exposition réglementaire est passée du théorique à l’opérationnel.

DORA s’applique depuis le 17 janvier 2025 aux entités financières telles que les établissements de crédit, les établissements de paiement, les établissements de monnaie électronique, les entreprises d’investissement, les prestataires de services sur crypto-actifs, les plateformes de négociation, les dépositaires centraux de titres, les contreparties centrales, les entreprises d’assurance et de réassurance et d’autres organisations couvertes du secteur financier. DORA est également fortement pertinent pour l’écosystème des tiers TIC, car les entités financières doivent gérer les prestataires qui soutiennent des fonctions critiques ou importantes. DORA Article 17 exige un processus de gestion des incidents liés aux TIC, Article 18 définit les attentes de classification et Article 19 régit la notification des incidents majeurs liés aux TIC à l’autorité compétente.

GDPR ajoute la dimension de la protection de la vie privée. Un incident de cybersécurité peut devenir une violation de données à caractère personnel s’il implique la destruction, la perte, l’altération, la divulgation non autorisée ou l’accès non autorisé à des données à caractère personnel, de manière accidentelle ou illicite. Le responsable du traitement doit être en mesure de démontrer sa responsabilité, d’évaluer le risque pour les personnes et, lorsque cela est requis, de notifier l’autorité de contrôle et, le cas échéant, les personnes concernées.

Un registre des contacts réglementaires mature doit donc répondre à cinq questions sous pression :

• Quel CSIRT, quelle autorité compétente, quel superviseur financier, quelle autorité de protection des données et quel service répressif compétent s’appliquent à cette entité juridique, à cette juridiction et à ce service ?
• Quel rôle interne est autorisé à initier le contact, à approuver la formulation et à soumettre les notifications ?
• Quels prestataires doivent être contactés pour le confinement, les journaux, la restauration, la préservation des éléments probants ou les notifications contractuelles ?
• Quel canal de communication client, contrepartie ou public est déclenché à chaque niveau de gravité ?
• Comment prouver que le registre a été revu, testé et utilisé correctement ?

La réponse ne peut pas résider uniquement dans la boîte de réception du service juridique ou dans la mémoire du RSSI. Elle doit constituer un enregistrement maîtrisé du SMSI.

Ce que contient un registre des contacts NIS2 et DORA prêt pour les éléments probants

Un registre des contacts réglementaires doit être conçu pour être utilisé lors d’un incident réel. Si le responsable de l’incident doit prendre la première décision d’escalade en quelques minutes, le registre ne peut pas être une vague liste de sites web. Il doit être structuré, vérifié et relié au guide opérationnel de réponse.

Un registre complet doit inclure au moins six familles de contacts.

Premièrement, les autorités officielles de cybersécurité : CSIRT nationaux, autorités compétentes, points de contact uniques le cas échéant et agences sectorielles de cybersécurité.

Deuxièmement, les superviseurs financiers pour DORA : autorités compétentes et canaux de notification utilisés pour les rapports initiaux, intermédiaires et finaux relatifs aux incidents majeurs liés aux TIC.

Troisièmement, les autorités de protection de la vie privée : autorités de protection des données, logique d’autorité de contrôle chef de file pour les traitements transfrontaliers et circuits d’escalade du DPO.

Quatrièmement, les services répressifs compétents : unités de lutte contre la cybercriminalité, unités de lutte contre la fraude et contacts d’urgence en cas d’extorsion, de rançongiciel, d’accès non autorisé et de préservation des éléments probants.

Cinquièmement, les fournisseurs et tiers TIC : fournisseurs cloud, prestataires de sécurité managée, prestataires de services managés, plateformes d’identité, prestataires de services de paiement, prestataires d’investigation numérique et conseil juridique.

Sixièmement, les rôles d’escalade internes : responsable de l’incident, RSSI, DPO, directeur juridique, responsable des communications, responsable de la continuité d’activité, approbateur exécutif, liaison avec le conseil d’administration et responsable de service.

Le registre doit également inclure les groupes d’intérêt particulier lorsque cela est pertinent, tels que les ISAC ou les communautés sectorielles de partage d’information. Ce ne sont pas des régulateurs, mais ils peuvent devenir des canaux importants pour le renseignement sur les menaces et la réponse coordonnée.

Le Zenith Blueprint rend cela concret à l’étape 22 :

Créez ou mettez à jour les procédures d’échange avec les autorités lors d’événements de sécurité (5.5), y compris les coordonnées des CERT locaux, des régulateurs et des services répressifs compétents. Tenez à jour une liste de contacts similaire pour la participation aux forums de sécurité ou aux groupes sectoriels (5.6). Conservez ces informations dans un emplacement accessible mais soumis à contrôle d’accès, et intégrez-les à votre guide opératoire de réponse aux incidents.

Cette dernière phrase est essentielle. Si le registre n’est pas dans le guide opératoire de réponse aux incidents, il a peu de chances d’être utilisé lorsque la pression est réelle.

Exemple de structure de registre des contacts pour un fournisseur FinTech ou SaaS

Imaginez un fournisseur SaaS fintech qui prend en charge l’analytique des paiements pour des clients de l’UE. Il utilise un fournisseur cloud, un prestataire de détection managée, une plateforme d’identité, une plateforme de support client et un conseil juridique externe. Selon son rôle, il peut être une entité financière, un prestataire tiers de services TIC, un fournisseur numérique entrant dans le champ de NIS2 ou un sous-traitant de données à caractère personnel au sens de GDPR.

Un registre pratique pourrait commencer ainsi :

Les entrées ne doivent pas contenir de données à caractère personnel inutiles. Utilisez des contacts fondés sur les rôles chaque fois que possible, protégez les coordonnées sensibles et assurez une disponibilité hors ligne lors d’une panne majeure. Un registre accessible uniquement depuis les mêmes systèmes touchés par un incident de rançongiciel n’est pas résilient.

Cartographier le registre avec les éléments probants ISO/IEC 27001:2022

Les auditeurs ne constatent que rarement une défaillance parce qu’une organisation ne dispose pas d’un tableur. Ils la constatent parce que l’organisation ne peut pas prouver que ce tableur est complet, à jour, approuvé, protégé, testé et relié aux processus réels.

ISO/IEC 27001:2022 commence par le contexte de l’organisation. Les clauses 4.1 à 4.4 exigent que l’organisation comprenne les enjeux internes et externes, identifie les parties intéressées et leurs exigences, définisse le domaine d’application du SMSI et comprenne les interfaces et dépendances. Un registre des contacts réglementaires constitue un élément probant solide montrant que les exigences légales, réglementaires, contractuelles et des parties prenantes ont été traduites en relations opérationnelles.

Vient ensuite le leadership. Les clauses 5.1 à 5.3 exigent que la direction générale démontre son leadership, attribue les responsabilités, assure la communication et soutienne le SMSI. Si le registre identifie qui est autorisé à notifier un CSIRT, un superviseur ou une autorité de protection des données, qui approuve les communications externes et qui rend compte du statut de l’incident à la direction générale, il soutient les éléments probants relatifs au leadership.

La planification des risques transforme ensuite les obligations en actions. Les clauses 6.1.1 à 6.1.3 exigent un processus d’appréciation des risques et de traitement des risques, une comparaison avec l’Annexe A, une Déclaration d’applicabilité, un plan de traitement des risques et l’acceptation du risque résiduel. Le registre doit apparaître dans le plan de traitement des risques pour des risques tels que l’échec de notification légale, le retard d’escalade d’un incident, l’échec de réponse d’un fournisseur, l’erreur de notification transfrontalière et la rupture de communication de continuité d’activité.

Les points d’ancrage des mesures de l’Annexe A sont clairs :

Dans Zenith Controls: The Cross-Compliance Guide Zenith Controls, le contact avec les autorités est traité comme la mesure 5.5, avec des caractéristiques préventives et correctives. Elle soutient la confidentialité, l’intégrité et la disponibilité, et se relie aux concepts de cybersécurité Identifier, Protéger, Répondre et Rétablir. Zenith Controls la rattache à la planification des incidents, au signalement des événements, au renseignement sur les menaces, aux groupes d’intérêt particulier et à la réponse aux incidents. Il explique également pourquoi des contacts préétablis avec les régulateurs, les services répressifs compétents, les CERT nationaux ou les agences de protection des données permettent une escalade et des orientations plus rapides lors d’événements tels que des violations significatives ou des attaques par rançongiciel.

La mesure n’est pas isolée. Zenith Controls cartographie également la mesure 6.8, signalement des événements de sécurité de l’information, comme une mesure de détection liée à la planification des incidents, à l’appréciation des événements, à la réponse, aux enseignements tirés, à la sensibilisation, à la surveillance et au processus disciplinaire. La mesure 5.24, planification et préparation de la gestion des incidents de sécurité de l’information, est reliée à l’appréciation des événements, aux enseignements tirés, à la journalisation, à la surveillance, à la sécurité pendant une perturbation, à la continuité et au contact avec les autorités. Le récit d’audit devient plus solide lorsque les événements sont signalés, appréciés, escaladés, communiqués, étayés et améliorés.

NIS2, DORA et GDPR : un registre unique, des délais juridiques différents

Un même incident peut déclencher plusieurs flux juridiques. Un accès non autorisé chez un fournisseur SaaS peut constituer un incident significatif NIS2, une violation de données à caractère personnel GDPR et un événement de notification contractuelle aux clients. Une interruption de service dans une entité financière peut constituer un incident majeur lié aux TIC au sens de DORA, tout en nécessitant une analyse GDPR et une coordination fournisseur.

NIS2 exige que les entités essentielles et importantes notifient sans retard indu à leur CSIRT ou à leur autorité compétente les incidents significatifs affectant la fourniture de services. Le modèle de notification progressive comprend une alerte précoce sans retard indu et dans les 24 heures suivant la prise de connaissance, une notification d’incident sans retard indu et dans les 72 heures, des rapports d’état intermédiaires sur demande et un rapport final dans un délai d’un mois après la notification d’incident. Si l’incident est toujours en cours, des rapports d’avancement peuvent également être exigés.

DORA impose aux entités financières de maintenir un processus de gestion des incidents liés aux TIC qui détecte, gère et notifie les incidents, enregistre les incidents et les cybermenaces significatives, classe la gravité et la criticité, attribue les rôles, définit l’escalade et la communication, signale les incidents majeurs à la direction générale et soutient le rétablissement en temps utile. La notification des incidents majeurs liés aux TIC suit une logique de rapports initiaux, intermédiaires et finaux, avec une classification fondée sur des facteurs tels que les clients affectés, la durée, l’étendue géographique, la perte de données, la criticité des services et l’impact économique.

GDPR ajoute l’appréciation de la violation de données à caractère personnel. Un registre des contacts ne décide pas à lui seul du caractère juridiquement notifiable. Il garantit que les bonnes personnes peuvent décider rapidement, à partir de canaux à jour et de critères documentés.

La bibliothèque de politiques de Clarysec rend cela opérationnel. Dans la Politique de réponse aux incidents PME Politique de réponse aux incidents - PME, la clause 5.1.1 énonce :

Le Directeur général (DG) est responsable de l’autorisation de toutes les décisions d’escalade des incidents, des notifications réglementaires et des communications externes.

La même politique PME, clause 7.4.1, ajoute :

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

Pour les environnements d’entreprise, la Politique de réponse aux incidents Politique de réponse aux incidents, clause 5.5, établit le cadre de communication :

Toutes les communications relatives aux incidents doivent suivre la matrice de communication et d’escalade, en veillant à ce que :

La clause 6.4.2 ajoute l’exigence relative aux éléments probants :

Toutes les notifications de violation doivent être documentées et approuvées avant soumission, et des copies doivent être conservées dans le SMSI.

C’est ici que le registre devient un élément probant ISO. Il ne s’agit pas seulement de savoir qui appeler. Il s’agit de montrer qui était autorisé, ce qui a été apprécié, ce qui a été approuvé, ce qui a été soumis et où se trouve la copie conservée.

Le modèle probant Clarysec : quatre livrables justificatifs qui fonctionnent ensemble

Une capacité solide de gestion des contacts réglementaires nécessite quatre livrables justificatifs fonctionnant comme une chaîne probante unique.

Le registre des contacts réglementaires identifie les contacts, les canaux, les déclencheurs et les propriétaires. La matrice de communication et d’escalade définit qui fait quoi. Le journal de décision enregistre la classification, l’appréciation du caractère notifiable, la revue juridique et l’approbation. Le dossier d’éléments probants de notification conserve les notifications soumises, les accusés de réception de portails, les e-mails, les notes d’appel, les retours du régulateur, les réponses des prestataires et les rapports finaux.

La Politique de conformité juridique et réglementaire de Clarysec Politique de conformité juridique et réglementaire - PME rend explicite le concept de registre. La clause 5.5.2 énonce :

Les conditions clés de conformité, par exemple les délais de notification des violations et les clauses de traitement des données, doivent être extraites et suivies dans le registre de conformité.

Le registre de conformité doit alimenter le registre des contacts réglementaires. L’exigence légale peut indiquer « alerte précoce NIS2 dans les 24 heures », tandis que le registre des contacts identifie le portail du CSIRT national, le numéro d’astreinte de secours, le soumissionnaire autorisé, le réviseur juridique, les éléments probants requis et le chemin de conservation.

Les politiques de continuité d’activité renforcent la même attente. La Politique de continuité d’activité et de reprise après sinistre PME Politique de continuité d’activité et de reprise après sinistre - PME, clause 5.2.1.1, mentionne :

les listes de contacts et les plans de communication alternatifs

La Politique de continuité d’activité et de reprise après sinistre d’entreprise Politique de continuité d’activité et de reprise après sinistre, clause 5.3.3, exige que les dispositifs de continuité soient :

appuyés par des listes de contacts à jour et des flux d’escalade

La gouvernance des fournisseurs fait également partie du modèle. Dans la Politique de sécurité des tiers et des fournisseurs PME Politique de sécurité des tiers et des fournisseurs - PME, la clause 5.4.3 exige une :

personne de contact désignée

Pour NIS2 et DORA, ce contact ne peut pas être générique. Si un fournisseur cloud critique, un prestataire de services de sécurité managés, un fournisseur d’identité ou un prestataire de services de paiement soutient un service réglementé, le registre doit identifier le contact opérationnel, le contact pour incident de sécurité, le canal de notification contractuelle et le circuit d’escalade pour les demandes d’éléments probants.

Construire le registre en une seule séance de travail

Un registre utile peut être construit rapidement si les bonnes personnes sont présentes. Planifiez une session de deux heures avec le RSSI, le DPO, le conseil juridique, le responsable fournisseurs, le responsable de la continuité d’activité, le responsable de l’incident et le responsable conformité.

Commencez par le registre de conformité. Extrayez les obligations de notification NIS2, DORA, GDPR, contractuelles et sectorielles. Enregistrez les délais, les critères de caractère notifiable et les exigences en matière d’éléments probants.

Ouvrez le guide opératoire de réponse aux incidents. Pour chaque catégorie d’incident, telle que rançongiciel, accès non autorisé, interruption de service, exfiltration de données, incident fournisseur et défaillance d’une région cloud, identifiez les contacts externes nécessaires.

Renseignez le registre des contacts réglementaires avec l’autorité, la juridiction, le déclencheur, le canal principal, le canal de secours, le propriétaire, l’approbateur, les éléments probants requis, la date de dernière validation et l’emplacement de conservation.

Reliez les contacts fournisseurs. Pour chaque fonction critique ou importante, identifiez le contact incident de sécurité du prestataire, le canal de notification contractuelle, le contact d’audit et le circuit d’escalade d’urgence.

Procédez à une revue au regard des politiques. Confirmez que l’autorité d’escalade correspond à la Politique de réponse aux incidents, que les éléments probants de notification sont conservés dans le SMSI, que les listes de contacts de continuité d’activité sont alignées et que les contacts fournisseurs ont des propriétaires désignés.

Testez un scénario. Utilisez un exercice sur table ciblé : « Exposition de données clients détectée à 02:17 affectant des clients de l’UE et possiblement causée par des identifiants compromis d’un fournisseur d’identité. » Demandez à l’équipe de déterminer si des notifications au CSIRT, à l’autorité de protection des données, au superviseur financier, au fournisseur et aux clients peuvent être requises. L’objectif n’est pas de forcer une conclusion juridique finale pendant l’exercice. L’objectif est de prouver où les contacts sont trouvés, qui approuve le contact, quels éléments probants sont nécessaires et où les décisions sont consignées.

Créez le dossier d’éléments probants. Conservez la version du registre, les participants à la réunion, les approbations, les notes de scénario, le journal de décision, les actions à mener et la référence mise à jour du guide opératoire.

C’est ici que l’étape 23 du Zenith Blueprint devient pratique :

Assurez-vous de disposer d’un plan de réponse aux incidents à jour (5.24), couvrant la préparation, l’escalade, la réponse et la communication. Définissez ce qui constitue un événement de sécurité notifiable (5.25) et la manière dont le processus décisionnel est déclenché et documenté. Sélectionnez un événement récent ou réalisez un exercice sur table pour valider votre plan.

L’exercice n’a pas besoin d’être élaboré. Il doit prouver la préparation.

Cartographie de conformité croisée : un registre, plusieurs référentiels

La valeur d’un registre des contacts réglementaires réside dans sa capacité à réduire les efforts de conformité redondants. Un livrable justificatif prêt pour l’audit peut soutenir les attentes de gouvernance d’ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT 2019.

NIST CSF 2.0 est particulièrement utile comme couche d’intégration. Sa fonction GOVERN attend des organisations qu’elles comprennent les parties prenantes, les obligations légales et réglementaires, les services critiques, les dépendances, l’appétence au risque, les rôles, les politiques, la supervision et le risque fournisseur. Ses profils CSF aident les organisations à documenter un profil actuel, à définir un profil cible, à analyser les écarts et à créer un plan d’action priorisé. Un registre des contacts réglementaires peut constituer un élément probant concret qui comble l’écart entre la gouvernance actuelle et cible des incidents.

Pour la chaîne d’approvisionnement, NIST CSF 2.0 attend que les fournisseurs, clients et partenaires disposent de rôles et responsabilités définis en cybersécurité, que la criticité des fournisseurs soit connue, que les exigences de cybersécurité soient intégrées aux accords, que les risques fournisseurs soient appréciés et que les fournisseurs pertinents soient inclus dans la planification, la réponse et le rétablissement en cas d’incident. Cela correspond directement au risque lié aux tiers TIC DORA et aux attentes NIS2 relatives à la chaîne d’approvisionnement.

Comment auditeurs et superviseurs testeront le même registre

Un registre bien maintenu sera examiné différemment selon l’angle du réviseur.

Un auditeur ISO/IEC 27001:2022 commencera par le domaine d’application et les parties intéressées. Il demandera comment l’organisation a identifié les autorités applicables, les obligations légales, les obligations de notification contractuelle et les dépendances externalisées. Il tracera ensuite le registre jusqu’à la Déclaration d’applicabilité, au plan de réponse aux incidents, au plan de continuité d’activité et à la conservation des éléments probants. Il pourra échantillonner un contact et demander la preuve de sa dernière validation.

Un évaluateur NIS2 vérifiera en priorité si l’entité a identifié le bon CSIRT ou la bonne autorité compétente et si les seuils d’incident significatif ont été opérationnalisés. Il recherchera un processus capable de soutenir l’alerte précoce à 24 heures, la notification à 72 heures et le rapport final. Il examinera également la supervision par l’organe de direction, car NIS2 Article 20 fait de la gouvernance cybersécurité une responsabilité de leadership.

Un superviseur DORA ou une équipe d’audit interne testera si le registre soutient la gestion des incidents, la classification, la notification des incidents majeurs liés aux TIC, la communication de crise, la remontée d’information à la direction générale, la coordination fournisseur et le rétablissement opérationnel. Il pourra demander si des contacts existent pour les prestataires tiers de services TIC soutenant des fonctions critiques ou importantes et si les obligations de communication sont reflétées dans les contrats.

Un auditeur GDPR ou une revue DPO se concentrera sur l’appréciation des violations de données à caractère personnel. Il demandera si le DPO et les contacts juridiques protection des données sont impliqués tôt, si les rôles de responsable du traitement et de sous-traitant sont clairs, si la bonne autorité de contrôle est identifiée et si les décisions de communication aux personnes concernées sont enregistrées.

Un évaluateur NIST CSF traitera le registre comme un élément probant des résultats GOVERN : attentes des parties prenantes, obligations légales, rôles, politiques, supervision et risque lié à la chaîne d’approvisionnement. Un auditeur COBIT 2019 ou de type ISACA examinera si les besoins des parties prenantes sont traduits en pratiques de gouvernance et de management, si les responsabilités sont attribuées et si la performance des processus est surveillée.

Le même livrable doit résister à toutes ces questions. C’est pourquoi le registre doit être maîtrisé, placé sous responsabilité, revu, soumis à contrôle d’accès et testé.

Schémas de défaillance courants dans la gouvernance des contacts

Les organisations échouent rarement parce qu’elles n’ont aucun contact. Elles échouent parce que les contacts ne sont pas fiables lors d’un incident réel.

Chaque problème génère un constat d’audit prévisible. La remédiation est tout aussi prévisible : aligner le registre sur la politique, l’intégrer à la réponse aux incidents, valider les contacts, tester le flux et conserver les éléments probants.

Responsabilité du conseil d’administration et du management

NIS2 exige que les organes de direction approuvent les mesures de gestion des risques de cybersécurité, supervisent leur mise en œuvre et suivent une formation. DORA Article 5 rend l’organe de direction responsable de définir, approuver, superviser et assumer la responsabilité des dispositifs de gestion des risques liés aux TIC, y compris les politiques, rôles, plans de continuité d’activité TIC, plans de réponse et de rétablissement, politique relative aux tiers TIC, sensibilisation et formation. ISO/IEC 27001:2022 exige que la direction aligne le SMSI sur l’orientation stratégique, fournisse les ressources, attribue les responsabilités et soutienne l’amélioration continue.

Le conseil d’administration n’a pas besoin de mémoriser le numéro de téléphone du CSIRT. Il doit en revanche obtenir l’assurance que la préparation à la notification existe, qu’elle est placée sous responsabilité, testée et revue.

Un dossier trimestriel de revue de direction doit inclure :

• Statut de revue du registre des contacts réglementaires
• Changements concernant les autorités, superviseurs ou juridictions applicables
• Lacunes ouvertes dans les contacts incident fournisseurs
• Résultats des exercices sur table et enseignements tirés
• Éléments probants de test du flux d’approbation des notifications
• Indicateurs sur le délai entre la détection et la décision d’escalade
• Mises à jour des obligations de notification NIS2, DORA, GDPR et contractuelles
• Risques résiduels nécessitant une acceptation par la direction

Cela fait passer le registre d’un tableur opérationnel à une mesure de gouvernance.

Comment Clarysec vous aide à construire une gouvernance des contacts prête pour l’audit

Clarysec relie le texte des politiques, le séquencement de mise en œuvre et la cartographie de conformité croisée des mesures dans un même chemin probant.

La bibliothèque de politiques définit la responsabilité et les enregistrements requis. La Politique de réponse aux incidents fixe les attentes relatives à l’escalade, à l’approbation des notifications et à la conservation. La Politique de conformité juridique et réglementaire exige le suivi des conditions de conformité telles que les délais de notification des violations. La Politique de continuité d’activité et de reprise après sinistre exige des listes de contacts à jour et des plans de communication alternatifs. La Politique de sécurité des tiers et des fournisseurs exige des contacts fournisseurs désignés.

Le Zenith Blueprint fournit le séquencement de mise en œuvre. L’étape 5 de la phase ISMS Foundation & Leadership traite de la communication, de la sensibilisation et de la compétence, y compris les parties prenantes externes, le calendrier, les rôles des communicants et les plans de communication. L’étape 22 intègre les contacts des autorités et des groupes d’intérêt particulier dans les mesures organisationnelles. L’étape 23 valide la gestion des incidents, les décisions relatives aux événements notifiables, la préservation des éléments probants d’investigation numérique et les enseignements tirés.

Le guide Zenith Controls fournit la boussole de conformité croisée. Il montre comment le contact avec les autorités se relie à la planification des incidents, au signalement des événements, au renseignement sur les menaces, aux groupes d’intérêt particulier et à la réponse aux incidents. Il montre également pourquoi le signalement des événements de sécurité de l’information et la préparation aux incidents sont des compléments nécessaires. Un registre des contacts n’est efficace que si les événements sont signalés et appréciés suffisamment tôt pour le déclencher.

Pour les PME, cela signifie un registre allégé mais défendable, une responsabilité claire et des éléments probants adaptés au principe de proportionnalité. Pour les entreprises, cela signifie une intégration entre juridictions, entités juridiques, unités métier, fournisseurs, régulateurs, superviseurs, CSIRT et reporting au conseil d’administration.

Prochaines étapes : construire le registre avant le démarrage du délai

Si votre organisation se prépare à NIS2, DORA, à la préparation aux notifications de violation au titre de GDPR ou à la certification ISO/IEC 27001:2022, n’attendez pas un incident en production pour découvrir si votre gouvernance des contacts fonctionne.

Commencez par quatre actions cette semaine :

1. Créez ou actualisez votre registre des contacts réglementaires pour les CSIRT, autorités compétentes, superviseurs financiers, autorités de protection des données, services répressifs compétents, fournisseurs critiques et rôles d’escalade internes.
2. Cartographiez chaque contact avec un déclencheur, un propriétaire, un circuit d’approbation, une exigence en matière d’éléments probants et un emplacement de conservation.
3. Réalisez un exercice sur table centré sur les décisions de notification, le contact avec les autorités, la coordination fournisseur et la conservation des éléments probants.
4. Mettez à jour les enregistrements du SMSI, notamment le registre de conformité, le guide opératoire de réponse aux incidents, les listes de contacts de continuité d’activité et les enregistrements de contacts fournisseurs.

Clarysec peut vous aider à mettre cela en œuvre rapidement avec le Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls et nos bibliothèques de politiques PME et entreprise, notamment la Politique de réponse aux incidents Politique de réponse aux incidents, la Politique de conformité juridique et réglementaire Politique de conformité juridique et réglementaire - PME, la Politique de continuité d’activité et de reprise après sinistre Politique de continuité d’activité et de reprise après sinistre et la Politique de sécurité des tiers et des fournisseurs Politique de sécurité des tiers et des fournisseurs - PME.

Le délai de 24 heures ne s’interrompt pas pendant que votre équipe cherche le bon contact. Construisez le registre maintenant, testez-le et intégrez-le à vos éléments probants ISO avant que le prochain incident ne fixe le calendrier à votre place.