Surveillance continue de la conformité pour NIS2 et DORA

La question du vendredi après-midi à laquelle chaque RSSI doit désormais répondre

À 16 h 40 un vendredi, le RSSI d’une plateforme de paiement hébergée dans le cloud reçoit trois messages en moins de dix minutes.

Le premier vient du directeur financier : « Notre partenaire bancaire demande des éléments probants à jour démontrant que nous répondons aux attentes de DORA en matière de risque lié aux tiers TIC et de notification des incidents. »

Le deuxième vient du service juridique : « Notre service de sécurité managé pourrait nous placer dans le champ d’application de la transposition nationale de NIS2. Pouvons-nous démontrer la supervision par la direction et l’efficacité des contrôles ? »

Le troisième vient du responsable de l’ingénierie : « Nous avons appliqué le correctif sur la vulnérabilité critique, mais le carnet de traitement indique 38 constats moyens en retard. Devons-nous remonter le sujet ? »

C’est à ce moment précis que la conformité annuelle s’effondre.

Une politique au format PDF, un registre des risques mis à jour pour la dernière fois avant l’audit précédent et un dossier de captures d’écran ne suffisent pas pour NIS2 et DORA. Ces régimes attendent une gouvernance vivante, une supervision par la direction, des processus de gestion des incidents, une visibilité sur les fournisseurs, des tests de résilience, des actions correctives et une efficacité des contrôles démontrable.

Pour de nombreux RSSI, la pression n’est pas théorique. La transposition de NIS2 dans les États membres de l’UE a fait passer la cybersécurité d’un programme technique à un sujet de responsabilité de la direction. DORA s’applique depuis le 17 janvier 2025 et fournit aux entités financières un cadre sectoriel de résilience opérationnelle pour le risque lié aux TIC, la notification des incidents, les tests et le risque lié aux tiers. Les fournisseurs de cloud, de SaaS, de services managés, de sécurité managée, de centres de données, de diffusion de contenu, de services de confiance et de communications électroniques publiques peuvent également être soumis à des obligations directes ou indirectes selon le champ d’application, la taille, le secteur, la classification nationale et les contrats clients.

La question pratique n’est plus : « Avons-nous un contrôle ? »

Elle devient : « Qui est responsable du contrôle, quel indicateur prouve qu’il fonctionne, à quelle fréquence collectons-nous les éléments probants, et que se passe-t-il si l’indicateur échoue ? »

C’est le cœur de la surveillance continue de la conformité pour NIS2 et DORA. Dans les mises en œuvre Clarysec, nous utilisons ISO/IEC 27001:2022 comme colonne vertébrale du système de management, ISO/IEC 27002:2022 comme langage de contrôle, Zenith Blueprint : feuille de route en 30 étapes pour auditeurs comme séquence de mise en œuvre, et Zenith Controls : guide de conformité croisée comme boussole de conformité croisée reliant les éléments probants ISO/IEC 27001:2022 à NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 et aux attentes d’audit.

Pourquoi NIS2 et DORA rendent la conformité périodique insuffisante

NIS2 et DORA diffèrent par leur structure juridique, leur modèle de supervision et leur champ d’application, mais ils créent la même pression opérationnelle. La cybersécurité et la résilience des TIC doivent être gouvernées en continu.

NIS2 exige des entités essentielles et importantes qu’elles appliquent des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées selon une approche « tous risques ». Ces mesures comprennent l’analyse des risques, les politiques de sécurité des systèmes d’information, la gestion des incidents, la continuité d’activité, la gestion de crise, la sécurité de la chaîne d’approvisionnement, l’acquisition et le développement sécurisés, le traitement des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la formation, 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é. Les organes de direction doivent approuver les mesures de gestion des risques de cybersécurité, en superviser la mise en œuvre et recevoir une formation.

DORA rend cette exigence encore plus explicite pour les entités financières. Il impose des dispositifs internes de gouvernance et de contrôle du risque lié aux TIC, un cadre documenté de gestion des risques liés aux TIC, la responsabilité de l’organe de direction, la gestion et la notification des incidents liés aux TIC, les tests de résilience opérationnelle numérique, la gestion des risques liés aux prestataires tiers TIC, le suivi des audits, la formation et les modalités de communication. DORA précise également que les entités financières restent responsables de leur conformité lorsqu’elles utilisent des prestataires tiers de services TIC.

Cela crée une nouvelle réalité de conformité. Un RSSI ne peut pas attendre le mois de l’audit pour découvrir que :

• les revues des accès à privilèges ont été manquées pendant deux trimestres ;
• les plans de sortie fournisseur ont été documentés mais jamais testés ;
• les critères de gravité des incidents ne correspondent pas aux seuils de notification réglementaire ;
• les sauvegardes sont configurées, mais les éléments probants de restauration manquent ;
• la direction n’a jamais revu les traitements des risques en retard ;
• les contrats cloud ne prévoient pas de droits d’audit, de visibilité sur les sous-traitants ni de clauses de notification des incidents.

L’ancien modèle en mode projet crée des cycles de panique. Les équipes se mobilisent avant un audit, collectent des captures d’écran, mettent à jour les dates des politiques et espèrent que les éléments probants racontent une histoire cohérente. NIS2 et DORA sont conçus pour faire échouer cette approche. Ils mettent l’accent sur la responsabilité, la proportionnalité, la résilience et la preuve du fonctionnement effectif.

ISO/IEC 27001:2022 fournit le cadre opératoire pour répondre à ce problème. Ses clauses exigent que les organisations comprennent le contexte, les parties intéressées, les exigences légales et contractuelles, le domaine d’application, le leadership, les rôles, l’appréciation des risques, le traitement des risques, la Déclaration d’applicabilité, la planification opérationnelle, l’évaluation de la performance, l’audit interne, la revue de direction, le traitement des non-conformités et l’amélioration continue. Cette structure est idéale pour combiner NIS2, DORA, GDPR, les programmes d’assurance demandés par les clients et le risque interne dans un modèle unique de surveillance continue.

La conformité continue ne consiste pas à multiplier les tableaux de bord. Elle consiste à gouverner la cadence de collecte des éléments probants.

Construire le moteur de conformité sur ISO/IEC 27001:2022

De nombreuses organisations réduisent à tort ISO/IEC 27001:2022 à un simple référentiel de certification. En pratique, il s’agit d’un système de gestion des risques permettant de rendre la gouvernance de la sécurité répétable, mesurable et vérifiable en audit.

C’est essentiel, car NIS2 et DORA ne sont pas des listes de contrôle isolées. Ils exigent un modèle opérationnel capable d’absorber les exigences légales, de les traduire en contrôles, d’attribuer les responsabilités, de surveiller la performance et d’améliorer le dispositif lorsque des lacunes sont constatées.

Les clauses fondatrices d’ISO/IEC 27001:2022 fournissent ce modèle :

Pour une FinTech, un fournisseur SaaS, un service de sécurité managé ou un prestataire TIC d’entités financières, cette structure évite les projets de conformité redondants. Un seul SMSI peut cartographier les obligations vers les contrôles une fois, puis réutiliser les éléments probants pour NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019, la certification ISO/IEC 27001:2022 et les revues d’assurance demandées par les clients.

Commencer par la responsabilité des contrôles, pas par les outils

Le premier schéma d’échec de la conformité continue est une mise en œuvre centrée sur l’outil. Une entreprise achète une plateforme GRC, importe des centaines d’exigences, attribue tout à « Sécurité » et appelle cela une surveillance continue. Six mois plus tard, le tableau de bord est rouge, l’ingénierie conteste les éléments probants relatifs aux vulnérabilités, le juridique indique que les documents fournisseurs sont incomplets et la direction ne voit pas clairement le risque résiduel.

ISO/IEC 27001:2022 évite cela en exigeant que les responsabilités et les autorités soient attribuées et communiquées. NIS2 et DORA renforcent la même attente par la responsabilité de la direction, la définition des rôles et la supervision.

La Politique relative aux rôles et responsabilités de gouvernance - PME de Clarysec dispose :

Chaque rôle comportant une responsabilité de sécurité doit être enregistré dans un journal central et faire l’objet d’un accusé de réception écrit.

Cette clause est plus importante que la plupart des tableaux de bord. Si les tests de sauvegarde, la remédiation des vulnérabilités, les diligences raisonnables relatives aux fournisseurs, la classification des incidents et la revue des accès à privilèges n’ont pas de responsables nommés, aucune cadence fiable de collecte des éléments probants n’existe.

La Politique de sécurité de l’information rend cela opérationnel pour les environnements d’entreprise :

Collecter et conserver les éléments probants d’audit pour les audits et les revues de contrôle.

Elle exige également des responsables de contrôle qu’ils :

Signalent la performance des contrôles ainsi que toute lacune ou tout problème au responsable du SMSI.

Dans Zenith Controls, ce thème correspond directement aux contrôles ISO/IEC 27002:2022 5.2 Rôles et responsabilités en sécurité de l’information, 5.35 Revue indépendante de la sécurité de l’information, et 5.36 Conformité aux politiques, règles et normes de sécurité de l’information.

Le Zenith Blueprint fournit un point de départ pratique dans la phase Fondations et leadership du SMSI, étape 4 : rôles et responsabilités dans le SMSI. Il recommande une nomination formelle, la mise à jour des fiches de poste, l’alignement avec les KPI, la communication à l’échelle de l’organisation et la responsabilité au niveau des services.

Un enregistrement de nomination type peut indiquer :

« Avec effet immédiat, vous êtes nommé responsable de la sécurité de l’information, chargé de superviser et de coordonner le SMSI, y compris la gestion des risques, la mise en œuvre des contrôles et la surveillance de la conformité. »

Cette nomination n’est pas de la bureaucratie. Elle constitue un élément probant d’audit pour le leadership et l’attribution des rôles ISO/IEC 27001:2022. Elle soutient également la supervision par la direction au titre de NIS2 et la gouvernance DORA. Les autorités de régulation, les auditeurs de certification et les clients bancaires veulent constater que la responsabilité n’est pas implicite. Elle est attribuée, reconnue, dotée de ressources et surveillée.

Un registre pratique de responsabilité des contrôles doit inclure les champs suivants :

Ce registre devient le pont entre la politique et la preuve.

Définir des KPI et des KRI qui prouvent l’efficacité des contrôles

Une fois les responsables désignés, ils doivent savoir à quoi ressemble un fonctionnement satisfaisant. La surveillance continue de la conformité repose sur des indicateurs pertinents, non sur des intentions générales.

« Améliorer l’application des correctifs » n’est pas un KPI. « Revoir régulièrement les fournisseurs » n’est pas un élément probant. « Maintenir la résilience » n’est pas un contrôle mesurable.

Clarysec distingue clairement les deux types d’indicateurs :

• un KPI, indicateur clé de performance, mesure si le processus fonctionne comme prévu ;
• un KRI, indicateur clé de risque, signale une augmentation du risque ou le franchissement d’un seuil nécessitant une remontée.

La Politique de gestion des risques pour les entreprises dispose :

Les KRI (indicateurs clés de risque) et les métriques de sécurité doivent être définis pour les risques critiques et surveillés mensuellement.

Elle exige également une logique de remontée :

Les déclencheurs d’escalade doivent être intégrés à la logique de surveillance (par exemple lorsque le risque résiduel augmente de plus d’un niveau ou lorsque les échéances de traitement sont manquées).

Pour les organisations plus petites, la Politique de gestion des risques - PME de Clarysec adopte une approche proportionnée :

Les progrès réalisés dans l’atténuation des risques doivent être revus trimestriellement.

Elle autorise également des métriques légères :

Des métriques informelles peuvent être suivies (par exemple nombre de risques ouverts, actions en retard, nouveaux incidents).

Cette proportionnalité est essentielle. Une banque multinationale et un fournisseur FinTech de 60 personnes n’ont pas besoin de la même télémétrie, mais tous deux ont besoin d’une responsabilité attribuée, d’une mesure répétable, de seuils de remontée et d’éléments probants d’action corrective.

Un modèle pratique de KPI et de KRI pour NIS2 et DORA peut se présenter ainsi :

Ces métriques soutiennent davantage que la certification ISO/IEC 27001:2022. Elles soutiennent aussi les mesures de gestion des risques de cybersécurité NIS2, la préparation à la notification des incidents NIS2, la gestion des risques liés aux TIC DORA, le risque lié aux tiers DORA, la responsabilité au titre du GDPR, les résultats de gouvernance NIST CSF 2.0 et la gestion de la performance de type COBIT.

Établir une cadence des éléments probants avant que l’audit ne la demande

De nombreuses organisations collectent les éléments probants de manière aléatoire. Une capture d’écran apparaît dans un canal Teams. Un ticket Jira est lié dans un courriel. Un questionnaire fournisseur est stocké par les achats. Un test de sauvegarde est décrit oralement. Pendant la semaine d’audit, le responsable du SMSI devient enquêteur forensique.

La conformité continue exige une cadence planifiée et une hygiène rigoureuse des éléments probants.

La Politique d’audit et de surveillance de la conformité - PME de Clarysec dispose :

Chaque audit doit inclure un périmètre défini, des objectifs, le personnel responsable et les éléments de preuve requis.

Elle précise également :

Les éléments de preuve doivent être conservés pendant au moins deux ans, ou plus longtemps lorsque la certification ou les accords clients l’exigent.

Pour les organisations d’entreprise, la Politique d’audit et de surveillance de la conformité ajoute des attentes d’automatisation :

Des outils automatisés doivent être déployés pour surveiller la conformité des configurations, la gestion des vulnérabilités, le statut d’application des correctifs et les accès à privilèges.

L’automatisation doit être ciblée. Les contrôles à haut risque et à forte fréquence ne doivent pas dépendre de captures d’écran manuelles. Le meilleur modèle d’éléments probants combine télémétrie automatisée, attestations des responsables, registres des exceptions, enregistrements de tickets, résultats de tests et comptes rendus de revue de direction.

Une convention de nommage est également importante. Les éléments probants doivent être faciles à retrouver sans effort héroïque. Par exemple :

• rapport hebdomadaire de vulnérabilités : YYYY-MM-DD_Vulnerability-SLA_ControlOwner
• revue mensuelle des accès à privilèges : YYYY-MM_IAM-Privileged-Review_Attestation
• revue trimestrielle des fournisseurs : YYYY-QX_Critical-Supplier-Review
• dossier d’incident : INC-YYYY-###_Timeline-Classification-RCA-CAPA

C’est ici que la politique devient opérationnelle. La conservation des éléments probants n’est pas une tâche d’archivage. Elle fait partie du contrôle.

Cartographier un élément probant vers plusieurs obligations

La conformité continue devient puissante lorsqu’un même élément probant satisfait plusieurs référentiels. C’est pourquoi Zenith Controls est central dans l’approche de conformité croisée de Clarysec.

Prenons la gestion des incidents. Au titre de NIS2, les incidents significatifs nécessitent des notifications échelonnées, incluant une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification dans les 72 heures et un rapport final dans le mois, sous réserve de la transposition nationale et des faits de l’incident. DORA exige des entités financières qu’elles gèrent, classent, remontent et notifient les incidents majeurs liés aux TIC au moyen de processus et de modèles requis. GDPR exige des responsables de traitement qu’ils évaluent et gèrent les violations de données à caractère personnel lorsque la confidentialité, l’intégrité ou la disponibilité de données à caractère personnel est affectée.

Un seul dossier d’éléments probants d’incident peut soutenir les trois s’il comprend :

• la chronologie de l’incident et l’heure de prise de connaissance ;
• la justification de la classification ;
• les services et juridictions affectés ;
• l’impact client, transactionnel ou utilisateur ;
• l’évaluation de l’impact sur les données à caractère personnel ;
• l’analyse de la cause racine ;
• les actions d’atténuation et de rétablissement ;
• les communications et notifications ;
• l’enregistrement de la remontée vers la direction ;
• l’entrée d’action corrective.

La même logique de conformité croisée s’applique au risque fournisseur. NIS2 exige la sécurité de la chaîne d’approvisionnement et l’attention portée aux relations avec les fournisseurs directs et les prestataires de services. DORA exige une stratégie de risque lié aux tiers TIC, des registres, des diligences précontractuelles, des clauses contractuelles, des droits d’audit, des niveaux de service, des stratégies de sortie et le suivi du risque de concentration. NIST CSF 2.0 traite le risque lié à la chaîne d’approvisionnement comme une discipline de gouvernance du cycle de vie. ISO/IEC 27001:2022 relie ces exigences au domaine d’application, aux exigences des parties intéressées, au traitement des risques et au contrôle opérationnel des processus fournis par des tiers.

Une matrice pratique des éléments probants aide les responsables de contrôle à comprendre pourquoi les éléments probants sont importants :

Cette approche évite le travail de conformité redondant. L’organisation collecte un ensemble solide d’éléments probants, puis le cartographie vers plusieurs obligations.

Le modèle de surveillance Clarysec, de l’obligation au responsable puis à la preuve

Un modèle de surveillance robuste suit une séquence simple.

Premièrement, définir l’obligation. Par exemple, DORA exige que le risque lié aux tiers TIC soit géré dans le cadre de la gestion des risques liés aux TIC, avec des registres, des diligences raisonnables, des exigences contractuelles, des droits d’audit et des stratégies de sortie pour les fonctions critiques ou importantes. NIS2 exige la sécurité de la chaîne d’approvisionnement et des actions correctives appropriées.

Deuxièmement, traduire l’obligation en exigences du SMSI ISO/IEC 27001:2022. Cela comprend les exigences des parties intéressées, le domaine d’application, l’appréciation des risques, le traitement des risques, la Déclaration d’applicabilité, le contrôle opérationnel, la surveillance, l’audit interne, la revue de direction et l’amélioration.

Troisièmement, sélectionner les contrôles opérationnels. Dans Zenith Controls, les contrôles de gouvernance centraux pour la conformité continue incluent les contrôles ISO/IEC 27002:2022 5.2, 5.35 et 5.36. Les contrôles de soutien incluent souvent 5.19 Sécurité de l’information dans les relations avec les fournisseurs, 5.21 Gestion de la sécurité de l’information dans la chaîne d’approvisionnement des TIC, 5.22 Surveillance, revue et gestion des changements des services fournisseurs, 5.23 Sécurité de l’information pour l’utilisation des services cloud, 5.24 Planification et préparation de la gestion des incidents de sécurité de l’information, 5.26 Réponse aux incidents de sécurité de l’information, 5.30 Préparation des TIC pour la continuité d’activité, 5.31 Exigences légales, statutaires, réglementaires et contractuelles, 8.8 Gestion des vulnérabilités techniques, 8.13 Sauvegarde de l’information, 8.15 Journalisation, 8.16 Activités de surveillance et 8.9 Gestion des configurations.

Quatrièmement, attribuer le responsable et la cadence. Le risque fournisseur peut impliquer les achats, le juridique, la sécurité et le responsable de service métier, mais un responsable redevable doit tenir le registre et signaler les exceptions.

Cinquièmement, définir les KPI, les KRI et les éléments probants. Les KPI fournisseurs peuvent inclure le pourcentage de fournisseurs TIC critiques ayant fait l’objet de diligences raisonnables complètes, le pourcentage disposant de clauses contractuelles approuvées, le nombre sans plans de sortie testés et le nombre de revues fournisseurs en retard. Les KRI peuvent inclure des constats fournisseurs à haut risque non résolus, un risque de concentration au-dessus de la tolérance ou l’absence de droits d’audit pour un service soutenant une fonction critique ou importante.

Sixièmement, reporter et remonter. Les tableaux de bord SMSI mensuels ne doivent pas simplement afficher un statut vert. Ils doivent identifier les éléments probants en retard, l’évolution des risques, les échéances de traitement manquées et les décisions requises de la direction.

Septièmement, auditer et améliorer. Les lacunes d’éléments probants deviennent des actions correctives, non des excuses.

Cela s’aligne avec la phase Audit, revue et amélioration du Zenith Blueprint. L’étape 25, programme d’audit interne, recommande de couvrir les processus et contrôles SMSI pertinents sur le cycle d’audit, avec un audit annuel complet du périmètre et de plus petits contrôles ponctuels trimestriels pour les domaines à haut risque lorsque cela est approprié. L’étape 28, revue de direction, prévoit des entrées telles que les changements d’exigences, les résultats de surveillance et de mesure, les résultats d’audit, les incidents, les non-conformités, les opportunités d’amélioration et les besoins en ressources. L’étape 29, amélioration continue, utilise le registre CAPA pour consigner la description du problème, l’analyse de la cause racine, l’action corrective, le responsable, la date cible et le statut.

C’est cela, la conformité continue en pratique.

Scénario pratique : vulnérabilité critique sur une API publique

À 02 h 15, une alerte SIEM se déclenche. Une analyse de vulnérabilités a identifié une vulnérabilité critique d’exécution de code à distance sur une passerelle API exposée au public qui soutient un service de paiement réglementé.

Le modèle de surveillance continue doit répondre sans attendre une réunion.

Premièrement, l’inventaire des actifs classe la passerelle comme critique. Le chronomètre KPI de gestion des vulnérabilités démarre. Le KRI relatif aux vulnérabilités critiques non corrigées augmente. Si l’actif est exposé à Internet et que le code d’exploitation est actif, le seuil de remontée est déclenché immédiatement.

Deuxièmement, le ticket est routé vers l’équipe DevOps d’astreinte. Le responsable DevOps, en tant que responsable de contrôle de la gestion des vulnérabilités, reçoit une notification automatisée. Le responsable du SOC vérifie si des indicateurs d’exploitation existent. Le responsable du SMSI surveille si les critères d’incident sont atteints.

Troisièmement, les éléments probants sont collectés comme sous-produit du processus. L’alerte SIEM, l’analyse de vulnérabilités, la classification de l’actif, les horodatages du ticket, le fil de discussion de réponse, l’enregistrement du correctif, l’analyse de validation et l’approbation de clôture sont joints au dossier d’éléments probants.

Quatrièmement, l’équipe évalue si l’événement est seulement une vulnérabilité, un événement de sécurité ou un incident. Si un impact sur le service, des indicateurs de compromission, un impact client ou une exposition de données à caractère personnel existent, le processus d’incident déclenche les évaluations de notification NIS2, DORA, GDPR et contractuelles.

Cinquièmement, la direction reçoit un rapport concis. Si la vulnérabilité a été corrigée en moins de quatre heures, les éléments probants soutiennent l’efficacité du contrôle. Si le SLA a été manqué, le registre CAPA enregistre l’analyse de la cause racine, l’action corrective, le responsable, la date cible et le statut.

Cet événement unique génère des éléments probants utiles pour la gestion des vulnérabilités, la préparation aux incidents, la surveillance, l’accès aux actifs critiques, la revue de direction et l’amélioration continue.

Comment les auditeurs et les autorités de régulation testeront le même modèle de surveillance

Un programme mature de conformité continue doit résister à différents angles d’audit. Les éléments probants ne changent pas, mais les questions changent.

Pour le contrôle ISO/IEC 27002:2022 5.35 Revue indépendante de la sécurité de l’information, un auditeur ISO/IEC 27001:2022 se concentrera sur le plan d’audit interne, le périmètre, la compétence, les constats et les actions correctives. Une autorité NIS2 ou DORA se concentrera sur la question de savoir si la direction a compris les constats, financé la remédiation et réduit le risque systémique. Un évaluateur NIST CSF 2.0 peut rattacher la revue à la fonction GOVERN, y compris la supervision et l’ajustement de la performance.

Le même ensemble d’éléments probants les sert tous s’il est complet, à jour et relié à la responsabilité des contrôles.

Pièges fréquents qui affaiblissent la conformité continue

Le premier piège consiste à traiter NIS2 et DORA comme des projets distincts. Cela crée des registres redondants, des métriques contradictoires et des responsables de contrôle épuisés. Utilisez ISO/IEC 27001:2022 comme colonne vertébrale du SMSI et cartographiez les obligations via une bibliothèque de contrôles unique.

Le deuxième piège consiste à attribuer les contrôles à des équipes plutôt qu’à des personnes. « L’IT est responsable des sauvegardes » ne suffit pas. Un responsable nommé doit attester, signaler les exceptions et remonter le risque.

Le troisième piège consiste à collecter des éléments probants sans évaluer l’efficacité. Une capture d’écran de sauvegarde réussie ne prouve pas la capacité de récupération. Un test de restauration, oui. Un questionnaire fournisseur ne prouve pas la résilience d’un tiers. Les clauses contractuelles, les droits d’audit, les conditions de notification des incidents, les rapports de performance et la planification de sortie constituent des éléments probants plus solides.

Le quatrième piège consiste à mesurer l’activité plutôt que le risque. Compter les vulnérabilités est utile. Suivre les vulnérabilités critiques en retard sur les systèmes exposés à Internet est préférable. Compter les fournisseurs est utile. Suivre les fournisseurs critiques sans plans de sortie est préférable.

Le cinquième piège est une discipline insuffisante des actions correctives. L’étape 29 du Zenith Blueprint est claire : les constats nécessitent une description du problème, une analyse de la cause racine, une action corrective, un responsable, une date cible et un statut. Si le registre CAPA n’est pas revu, la conformité continue devient une accumulation continue de faiblesses connues.

Ce que la direction doit voir chaque mois

Les organes de direction soumis à NIS2 et DORA n’ont pas besoin de rapports bruts issus des scanners. Ils ont besoin d’une vision du risque cyber et TIC adaptée à la prise de décision.

Un tableau de bord mensuel destiné au conseil ou à la direction doit inclure :

• les principaux risques cyber et TIC avec l’évolution du risque résiduel ;
• les traitements des risques en retard et les échéances manquées ;
• les incidents significatifs, les candidats incidents majeurs liés aux TIC et les enseignements tirés ;
• les exceptions de risque fournisseur critique ;
• la performance SLA des vulnérabilités pour les actifs critiques ;
• le statut des tests de sauvegarde et de rétablissement ;
• les exceptions de revue des accès à privilèges ;
• le taux d’achèvement des éléments probants de conformité ;
• les constats d’audit et le statut CAPA ;
• les décisions de ressources requises.

Cela soutient directement la revue de direction ISO/IEC 27001:2022 et les attentes de gouvernance de NIS2 et DORA. Cela s’aligne également sur NIST CSF 2.0, où les dirigeants fixent les priorités, la responsabilité, les ressources et l’appétence au risque, tandis que les managers traduisent ces priorités en profils cibles et plans d’action.

Construire votre rythme de collecte des éléments probants NIS2 et DORA cette semaine

Vous n’avez pas besoin de faire bouillir l’océan pour commencer. Une première semaine utile peut rester simple.

Jour 1, créez un registre des responsables de contrôle pour cinq domaines : gouvernance et gestion des risques, gestion et notification des incidents, gestion des vulnérabilités et des correctifs, risque fournisseur et cloud, et continuité d’activité et rétablissement.

Jour 2, définissez un KPI et un KRI pour chaque domaine. Gardez-les spécifiques, mesurables et liés à l’appétence au risque.

Jour 3, cartographiez chaque élément probant vers sa valeur pour NIS2, DORA, ISO/IEC 27001:2022, GDPR et les programmes d’assurance demandés par les clients.

Jour 4, définissez la cadence de collecte des éléments probants, l’emplacement de stockage, la convention de nommage, la règle de conservation et le réviseur.

Jour 5, organisez un exercice sur table avec remontée. Utilisez un scénario d’interruption cloud ou de vulnérabilité critique. Confirmez la classification, l’évaluation de notification réglementaire, la communication client, le stockage des éléments probants et la création CAPA.

Si votre organisation gère encore NIS2 et DORA avec des tableurs, des ateliers annuels et des dossiers d’éléments probants dispersés, le moment est venu de passer à un rythme opérationnel surveillé.

Commencez par trois actions :

1. Construisez un registre des responsables de contrôle pour vos domaines les plus risqués.
2. Définissez un KPI, un KRI, un élément probant et une cadence par contrôle.
3. Réalisez une revue des éléments probants de 30 minutes et ouvrez des éléments CAPA pour tout élément manquant.

Clarysec peut vous aider à accélérer cette transition avec Zenith Blueprint pour la séquence de mise en œuvre, Zenith Controls pour la cartographie de conformité croisée, et la bibliothèque de politiques Clarysec, notamment la Politique de sécurité de l’information, la Politique de gestion des risques, la Politique d’audit et de surveillance de la conformité, la Politique relative aux rôles et responsabilités de gouvernance - PME, la Politique de gestion des risques - PME et la Politique d’audit et de surveillance de la conformité - PME.

L’objectif n’est pas d’ajouter de la paperasse de conformité. L’objectif est de répondre avec confiance à la question du vendredi après-midi :

« Oui, nous savons qui est responsable du contrôle, nous connaissons le KPI, nous disposons des éléments probants, nous connaissons les exceptions et la direction a revu le risque. »

Contacter Clarysec pour construire un modèle de surveillance continue de la conformité prêt pour l’audit, prêt pour le conseil d’administration et suffisamment résilient pour NIS2, DORA et la prochaine réglementation à venir.