CVD pour NIS2 et DORA : cartographie des éléments probants ISO 27001

À 08 h 17, un mardi, la boîte aux lettres de sécurité reçoit un message d’un chercheur indépendant. L’objet est calme, presque courtois : « Prise de contrôle potentielle de compte dans votre portail client ». Le corps du message est moins rassurant. Le chercheur affirme qu’une chaîne de vulnérabilités dans votre application SaaS permet à un locataire d’accéder aux enregistrements de factures d’un autre locataire. Une preuve de concept est jointe, chiffrée avec votre clé PGP publique.

Pour Maria, nouvelle RSSI de FinanTechSaaS, le moment ne pouvait pas être plus mal choisi. Son entreprise vient de signer un contrat majeur avec une banque européenne de premier rang. L’équipe de diligence raisonnable du client a déjà demandé une « politique de divulgation coordonnée des vulnérabilités » et des éléments probants attestant de sa mise en œuvre, en faisant explicitement référence à NIS2 et DORA. L’entreprise dispose bien d’une adresse électronique security@, mais elle est surveillée par un seul développeur. Il n’existe pas de registre formel de réception, pas de SLA de validation défini, pas de circuit d’escalade vers la direction et pas de piste d’audit.

Trois horloges démarrent simultanément.

La première est opérationnelle. La vulnérabilité est-elle réelle ? Est-elle exploitable en production ? Quelqu’un est-il déjà en train de l’exploiter ?

La deuxième est réglementaire. Si des données client sont exposées, l’évaluation de violation au titre du GDPR commence. Si la fourniture du service est affectée pour une entité essentielle ou importante au sens de NIS2, les seuils de notification des incidents peuvent être déclenchés. Si l’entreprise est une entité financière ou un prestataire de services TIC soutenant des services financiers, les règles DORA relatives à la gestion des incidents, à la classification, à l’escalade et à la communication aux clients peuvent devenir pertinentes.

La troisième concerne les éléments probants. Six mois plus tard, un auditeur ISO/IEC 27001:2022, un superviseur du secteur financier, une équipe d’assurance client ou un comité d’audit interne peut demander : « Montrez-nous comment cette vulnérabilité a été traitée. »

C’est souvent à ce moment que de nombreuses organisations découvrent que la divulgation coordonnée des vulnérabilités n’est pas une simple boîte aux lettres de sécurité. C’est un dispositif de gouvernance. Il lui faut un responsable de politique, un canal public de signalement, un flux de triage, des SLA de remédiation, une escalade fournisseur, une logique de décision d’incident, une revue Protection des données, des rapports à la direction et des éléments probants défendables.

Clarysec considère la CVD comme un modèle de contrôle intégré, et non comme une boîte de réception autonome. Dans Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, la gestion des vulnérabilités apparaît dans la phase Controls in Action, Step 19: Technological Controls I, où la recommandation est claire : les organisations ne doivent pas archiver passivement les constats de vulnérabilité, mais les trier, les affecter et les suivre jusqu’à leur clôture. Le même niveau d’exigence s’applique aux divulgations externes. Si quelqu’un vous indique comment votre service peut échouer, la vraie question devient : pouvez-vous prouver que vous avez reçu, évalué, priorisé, corrigé, communiqué et tiré des enseignements ?

Pourquoi la CVD est désormais un sujet relevant du conseil d’administration au titre de NIS2 et DORA

Pendant des années, les organisations attentives à la sécurité ont invité les hackers éthiques à signaler les vulnérabilités parce qu’il s’agissait d’une bonne pratique. Avec NIS2 et DORA, cette pratique fait désormais partie de la résilience numérique réglementée.

NIS2 s’applique à de nombreuses entités moyennes et grandes relevant de secteurs hautement critiques ou d’autres secteurs critiques, notamment les fournisseurs d’infrastructures numériques, les fournisseurs de services d’informatique en nuage, les fournisseurs de services de centres de données, les prestataires de services managés, les prestataires de services de sécurité managés, ainsi que certains fournisseurs numériques tels que les places de marché en ligne, les moteurs de recherche et les plateformes de réseaux sociaux. Elle peut également s’appliquer indépendamment de la taille à des catégories telles que les prestataires de services de confiance, les fournisseurs de services DNS, les registres de noms de domaine de premier niveau et les fournisseurs de réseaux ou services de communications électroniques publics.

NIS2 Article 21 exige des entités essentielles et importantes qu’elles mettent en œuvre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées de gestion des risques de cybersécurité, selon une approche tous risques. L’un des domaines minimaux porte sur la sécurité lors de l’acquisition, du développement et de la maintenance des réseaux et des systèmes d’information, y compris la gestion et la divulgation des vulnérabilités. Le même socle couvre également la gestion des incidents, la sécurité de la chaîne d’approvisionnement, la continuité d’activité, le contrôle d’accès, la gestion des actifs, la formation, la cryptographie et les procédures d’évaluation de l’efficacité des contrôles.

NIS2 Article 20 rend également explicite la responsabilité de la direction. Les organes de direction doivent approuver les mesures de gestion des risques de cybersécurité, en superviser la mise en œuvre et suivre une formation. Pour un programme CVD, cela signifie que le conseil d’administration ou la direction générale doit comprendre le canal de signalement, l’équipe de réponse aux vulnérabilités, les délais de validation, les attentes de remédiation, les dépendances fournisseurs et les déclencheurs de notification des incidents.

DORA crée, à compter du 17 janvier 2025, un régime sectoriel spécifique pour les entités financières. Il couvre la gestion des risques liés aux TIC, la notification des incidents liés aux TIC, les tests de résilience opérationnelle numérique, le partage d’informations, le risque lié aux prestataires tiers de services TIC, les exigences contractuelles, la supervision des prestataires tiers critiques de services TIC et la coopération avec les autorités de supervision. Pour les entités financières couvertes par DORA, DORA prévaut généralement sur NIS2 pour la gestion des risques liés aux TIC et la notification des incidents, car il s’agit de l’acte juridique de l’Union spécifique au secteur. Mais l’exigence pratique reste la même : les entités financières et les prestataires de services TIC qui les servent doivent exploiter un processus structuré, documenté et testable pour identifier, analyser, classer, escalader, remédier et tirer des enseignements des faiblesses liées aux TIC.

Un signalement de vulnérabilité peut commencer comme un constat technique, devenir un événement de sécurité, être escaladé en incident, déclencher une évaluation de violation de données à caractère personnel au titre du GDPR, exiger une action fournisseur et apparaître ensuite dans la Déclaration d’applicabilité ISO/IEC 27001:2022. C’est pourquoi la CVD doit être conçue comme un modèle opérationnel unique couvrant sécurité, conformité, ingénierie, juridique, protection des données, achats et direction.

Le socle ISO 27001 : de la divulgation aux éléments probants du SMSI

ISO/IEC 27001:2022 fournit aux RSSI et aux responsables conformité le système de management qui rend la CVD auditable.

Les clauses 4.1 à 4.4 exigent que l’organisation comprenne les enjeux internes et externes, les exigences des parties intéressées, les limites du SMSI et les dépendances avec d’autres organisations. C’est à ce niveau que NIS2, DORA, GDPR, les contrats clients, les obligations fournisseurs et les engagements de divulgation des vulnérabilités entrent dans le SMSI.

Les clauses 5.1 à 5.3 instaurent la responsabilité de la direction. La direction doit aligner la sécurité de l’information sur l’orientation stratégique, fournir les ressources, attribuer les responsabilités et veiller à ce que le SMSI atteigne les résultats attendus. Pour la CVD, cela signifie désigner une équipe de réponse aux vulnérabilités, définir l’autorité permettant d’accepter le risque résiduel et escalader à la direction les vulnérabilités à fort impact.

Les clauses 6.1.1 à 6.1.3 fournissent le moteur de gestion des risques. L’organisation doit définir les critères de risque, apprécier les risques de sécurité de l’information, attribuer des propriétaires de risque, sélectionner les options de traitement des risques, comparer les contrôles avec l’Annexe A, produire une Déclaration d’applicabilité et obtenir l’approbation du risque résiduel. Les clauses 8.1 à 8.3 exigent ensuite le contrôle opérationnel, les changements planifiés, le contrôle des processus fournis par des tiers, les appréciations des risques à intervalles planifiés ou après changements significatifs, ainsi que les éléments probants des résultats du traitement.

Dans Zenith Blueprint, phase Risk Management, Step 13, la Déclaration d’applicabilité est décrite comme bien plus qu’une feuille de calcul de conformité :

« La SoA est effectivement un document passerelle : elle relie votre appréciation/traitement des risques aux contrôles réels dont vous disposez. »
Source : Zenith Blueprint: An Auditor’s 30-Step Roadmap, phase Risk Management, Step 13: Risk Treatment Planning and Statement of Applicability (SoA) Zenith Blueprint

Pour la divulgation coordonnée des vulnérabilités, la SoA doit relier les obligations réglementaires, le risque métier, les contrôles de l’Annexe A, les clauses de politique et les éléments probants opérationnels.

L’objectif n’est pas de créer des silos parallèles de conformité. La politique CVD doit être un processus maîtrisé du SMSI qui soutient simultanément la certification ISO/IEC 27001:2022, la conformité NIS2, la préparation à DORA, l’assurance client et les opérations de sécurité.

Le socle de politique : ce que votre politique CVD doit énoncer

Le premier contrôle visible est le canal public de divulgation. Les chercheurs, clients, fournisseurs et partenaires doivent savoir où signaler les vulnérabilités et comment protéger les éléments probants sensibles.

La Politique de divulgation coordonnée des vulnérabilités de Clarysec Politique de divulgation coordonnée des vulnérabilités fournit le socle applicable à l’entreprise :

« Canaux publics de divulgation : l’organisation doit maintenir un canal clair pour le signalement des vulnérabilités, tel qu’une adresse électronique dédiée de contact sécurité (par exemple, security@company.com) ou un formulaire web. Cette information doit être publiée sur la page sécurité du site web de l’entreprise, avec la clé publique PGP de l’organisation afin de permettre les soumissions chiffrées. »
Source : Politique de divulgation coordonnée des vulnérabilités, exigences de mise en œuvre, clause 6.1

Cette clause répond à une défaillance d’audit fréquente. De nombreuses organisations affirment accepter les signalements, mais le canal de signalement est caché, non chiffré ou placé sous la responsabilité de la mauvaise équipe. Un canal mature est public, sécurisé, surveillé et attribué à une fonction responsable.

Le contrôle suivant porte sur la discipline de réponse. Un signalement critique suivi de silence crée un risque de divulgation, un risque réputationnel et un risque d’exploitation. La Politique de divulgation coordonnée des vulnérabilités fixe une exigence concrète en matière d’accusé de réception et de validation :

« Triage et accusé de réception : à la réception d’un signalement, la VRT doit l’enregistrer et adresser un accusé de réception au déclarant dans un délai de 2 jours ouvrés, en attribuant une référence de suivi. La VRT doit réaliser une évaluation préliminaire de la gravité, par exemple à l’aide d’une notation CVSS, et valider le problème, y compris avec l’appui des équipes informatiques et de développement lorsque nécessaire, dans un délai cible de 5 jours ouvrés. Les vulnérabilités critiques, telles que celles permettant l’exécution de code à distance ou une violation de données majeure, doivent être traitées en priorité accélérée. »
Source : Politique de divulgation coordonnée des vulnérabilités, exigences de mise en œuvre, clause 6.4

Cette formulation crée des points de preuve immédiats : heure de réception, heure d’accusé de réception, référence de suivi, gravité préliminaire, résultat de validation et décision de traitement accéléré.

Pour les PME, Clarysec applique la même logique avec une mise en œuvre proportionnée. La Application Security Requirements Policy-sme Application Security Requirements Policy - SME exige des organisations qu’elles :

« précisent les obligations relatives à la divulgation des vulnérabilités, aux délais de réponse et à l’application des correctifs. »
Source : Application Security Requirements Policy-sme, exigences de gouvernance, clause 5.3.2

Il n’est pas nécessaire de disposer d’une grande équipe de sécurité produit pour être responsable. Il faut des obligations explicites, des délais réalistes, des propriétaires nommés et des éléments probants démontrant que le processus fonctionne.

Le flux de réception CVD : de l’e-mail du chercheur à l’enregistrement de décision

Un bon flux de réception doit être suffisamment simple pour fonctionner sous pression et suffisamment complet pour satisfaire un auditeur. Il doit commencer par un canal dédié tel que security@[company], un formulaire web ou un fichier security.txt publié. Le canal de soumission doit permettre de transmettre des éléments probants chiffrés, le produit ou le point de terminaison affecté, les étapes de reproduction, les coordonnées du déclarant, le calendrier de divulgation souhaité et toute indication d’exposition de données ou d’exploitation active.

Une fois le signalement reçu, l’équipe de réponse aux vulnérabilités doit créer un enregistrement dans un outil GRC, une plateforme de ticketing, un système de gestion des vulnérabilités ou un registre contrôlé. L’outil importe moins que la cohérence et la qualité des éléments probants.

Le flux doit ensuite suivre sept étapes opérationnelles.

1. Réception : le signalement est reçu via le canal public et journalisé automatiquement ou manuellement.
2. Accusé de réception : la VRT répond dans un délai de 2 jours ouvrés et attribue une référence de suivi.
3. Validation : l’équipe technique reproduit le problème, confirme les systèmes affectés et réalise une notation préliminaire de la gravité.
4. Évaluation de l’événement : la VRT détermine si la vulnérabilité est uniquement une faiblesse, un événement de sécurité de l’information ou un incident.
5. Escalade : les problèmes élevés ou critiques sont transmis aux propriétaires de systèmes, au RSSI, aux équipes Protection des données, juridique, fournisseurs et direction selon les besoins.
6. Remédiation : l’équipe responsable applique un correctif, une mesure d’atténuation, un contrôle compensatoire ou une restriction temporaire.
7. Clôture : la VRT vérifie le correctif, communique avec le déclarant, met à jour le dossier d’éléments probants et enregistre les enseignements tirés.

Clarysec associe cette étape opérationnelle à la mesure ISO/IEC 27002:2022 A.5.25, Évaluation et décision relatives aux événements de sécurité de l’information, et à la mesure A.8.8, Gestion des vulnérabilités techniques, au moyen de Zenith Controls: The Cross-Compliance Guide Zenith Controls. Pour A.5.25, Zenith Controls explique que l’évaluation des événements constitue la fonction de triage entre les alertes brutes de surveillance et la gestion formelle des incidents, en utilisant les journaux, les seuils et les critères de décision pour déterminer l’escalade. Pour A.8.8, Zenith Controls relie la gestion des vulnérabilités techniques à la protection contre les logiciels malveillants, à la gestion des configurations, à la gestion des changements, à la sécurité des terminaux, au renseignement sur les menaces, à la surveillance, au développement sécurisé, à l’évaluation des événements et à la réponse aux incidents.

Un passage de Zenith Controls est particulièrement utile lorsqu’une exploitation active est suspectée :

« Le renseignement sur les menaces indique quelles vulnérabilités sont activement exploitées, ce qui oriente la priorisation de l’application des correctifs. »
Source : Zenith Controls: The Cross-Compliance Guide, mesure ISO/IEC 27002:2022 8.8, lien avec la mesure 5.7 Threat Intelligence Zenith Controls

C’est un point de gouvernance important. La gravité ne se limite pas au CVSS. Une vulnérabilité notée moyenne mais activement exploitée contre votre secteur peut passer devant un problème théoriquement critique sur un système de test non exposé.

Quand une vulnérabilité devient un incident

Tous les signalements de vulnérabilité ne sont pas des incidents. Un en-tête de sécurité manquant sur un environnement de préproduction n’est pas comparable à un contournement d’autorisation exploité exposant des factures clients. Mais tout signalement crédible de vulnérabilité doit passer par un point de décision incident.

NIS2 Article 23 exige des entités essentielles et importantes qu’elles notifient sans retard injustifié à leur CSIRT ou à l’autorité compétente les incidents ayant un impact significatif sur la fourniture de services. Un incident significatif est un incident ayant causé ou susceptible de causer une perturbation opérationnelle grave ou une perte financière, ou ayant affecté ou susceptible d’affecter d’autres personnes en causant des dommages matériels ou immatériels considérables. La séquence de notification comprend une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification d’incident dans les 72 heures, des rapports intermédiaires sur demande et un rapport final dans le mois suivant la notification à 72 heures.

DORA Articles 17 to 20 exigent des entités financières qu’elles détectent, gèrent, enregistrent, classent, escaladent, notifient et communiquent les incidents liés aux TIC et les cybermenaces significatives. Les incidents majeurs liés aux TIC doivent être escaladés à la haute direction et à l’organe de direction. Une communication client peut être requise lorsque les intérêts financiers sont affectés.

Pour les PME, la culture de signalement doit être tout aussi claire. La Incident Response Policy-sme de Clarysec Incident Response Policy - SME indique :

« Le personnel doit signaler toute activité suspecte ou tout incident confirmé à incident@[company] ou verbalement au directeur général ou au prestataire informatique. »
Source : Incident Response Policy-sme, exigences de mise en œuvre de la politique, clause 6.2.1

Dans Zenith Blueprint, phase Controls in Action, Step 16: People Controls II, le principe est encore plus simple :

« En cas de doute, signalez. »
Source : Zenith Blueprint: An Auditor’s 30-Step Roadmap, phase Controls in Action, Step 16: People Controls II (A.6.5 to A.6.8)

Cette phrase doit s’appliquer aux développeurs, aux équipes support, aux responsables fournisseurs, aux référents Protection des données, aux dirigeants et aux prestataires externalisés. Une vulnérabilité susceptible d’affecter la confidentialité, l’intégrité, la disponibilité, la confiance client, la notification réglementaire ou les opérations financières doit être enregistrée et évaluée, et non traitée informellement dans un chat.

Remédiation, application des correctifs et contrôles compensatoires

Une fois une vulnérabilité validée, elle doit être traitée. Le traitement doit être fondé sur les risques, étayé par des éléments probants et assorti de délais.

La Politique de divulgation coordonnée des vulnérabilités fixe l’exigence applicable à l’entreprise :

« Plan de remédiation : un plan de remédiation ou d’atténuation doit être élaboré pour toutes les vulnérabilités confirmées. La mise en œuvre du correctif doit être priorisée selon la gravité. Par exemple, les vulnérabilités critiques doivent être corrigées ou atténuées dans un délai de 14 jours lorsque cela est faisable, ou plus rapidement lorsqu’une exploitation active est détectée, tandis que les problèmes de moindre gravité doivent être traités dans un délai raisonnable. Lorsqu’un correctif complet est différé, des contrôles compensatoires ou des mesures temporaires d’atténuation, tels que la désactivation d’une fonctionnalité vulnérable ou le renforcement de la surveillance, doivent être mis en œuvre. »
Source : Politique de divulgation coordonnée des vulnérabilités, exigences de mise en œuvre, clause 6.6

Pour la discipline d’application des correctifs en PME, la Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy - SME indique :

« Les correctifs critiques doivent être appliqués dans les 3 jours suivant leur publication, en particulier pour les systèmes exposés à Internet »
Source : Vulnerability and Patch Management Policy-sme, exigences de mise en œuvre de la politique, clause 6.1.1

Ces délais ne sont pas contradictoires. Un correctif fournisseur pour un système exposé à Internet peut nécessiter un déploiement très rapide. Une vulnérabilité produit nécessitant des modifications de code, des tests de non-régression, une coordination client et une mise en production progressive peut exiger un plan de remédiation assorti de mesures d’atténuation intermédiaires. Le point essentiel est que la décision soit documentée, attribuée à un propriétaire du risque et approuvée lorsqu’un risque résiduel demeure.

Un déroulé de cas pratique ressemble à ceci :

1. Un chercheur signale un contournement d’autorisation dans l’API de facturation client.
2. La VRT journalise CVD-2026-014 avec un horodatage et adresse un accusé de réception dans un délai de 2 jours ouvrés.
3. La sécurité produit valide le défaut en 24 heures et attribue une gravité élevée en raison d’un accès inter-locataires aux données.
4. La fonction Protection des données réalise une évaluation de violation GDPR parce que les enregistrements de factures peuvent contenir des données à caractère personnel.
5. Le responsable des incidents ouvre une évaluation d’événement au titre de la mesure ISO/IEC 27002:2022 A.5.25.
6. Le propriétaire du système désactive le point de terminaison vulnérable au moyen d’un indicateur de fonctionnalité temporaire.
7. L’ingénierie crée un correctif d’urgence au titre de la mesure ISO/IEC 27002:2022 A.8.32, Gestion des changements.
8. Des règles de surveillance sont ajoutées pour les indicateurs d’exploitation, liées à A.8.15, Journalisation, et A.8.16, Activités de surveillance.
9. Le RSSI informe la haute direction, car le problème présente un risque élevé.
10. La VRT coordonne avec le chercheur le retest et le calendrier de divulgation.
11. Le propriétaire du risque approuve la clôture uniquement après les tests de vérification et la revue d’impact client.
12. La SoA, le registre des risques, le ticket, les journaux, la notification à la direction et les enseignements tirés sont mis à jour.

C’est la différence entre « nous l’avons corrigé » et « nous pouvons prouver que nous l’avons gouverné ».

Dépendances fournisseurs et cloud : le point de défaillance caché

De nombreux échecs de CVD sont en réalité des échecs fournisseurs. La vulnérabilité peut affecter un composant SaaS, un service cloud, un prestataire de sécurité managé, une passerelle de paiement, un courtier d’authentification, une bibliothèque open source, une équipe de développement externalisé ou un sous-traitant.

NIS2 Article 21 exige la sécurité de la chaîne d’approvisionnement, y compris les relations avec les fournisseurs directs et les prestataires de services. Les mesures relatives à la chaîne d’approvisionnement doivent prendre en compte les vulnérabilités des fournisseurs, la qualité des produits, les pratiques de cybersécurité et les procédures de développement sécurisé.

DORA Articles 28 to 30 vont plus loin pour les entités financières. Ils exigent que le risque lié aux prestataires tiers de services TIC soit géré dans le cadre du dispositif de gestion des risques liés aux TIC, avec des registres des contrats de services TIC, la distinction entre fonctions critiques ou importantes, des diligences précontractuelles, des exigences contractuelles de sécurité, une assistance en cas d’incident, la coopération avec les autorités, des droits d’audit, des droits de résiliation et des stratégies de sortie. Les entités financières restent pleinement responsables de la conformité à DORA même lorsqu’elles recourent à des prestataires tiers de services TIC.

La Third-Party and Supplier Security Policy-sme de Clarysec Third-Party and Supplier Security Policy - SME inclut une règle d’escalade simple :

« Doit notifier immédiatement le directeur général de toute violation de sécurité, changement ou incident »
Source : Third-Party and Supplier Security Policy-sme, rôles et responsabilités, clause 4.4.3

Pour les contrats fournisseurs d’entreprise, Zenith Blueprint, phase Controls in Action, Step 23, recommande d’inclure les obligations de confidentialité, les responsabilités de contrôle d’accès, les mesures techniques et organisationnelles, les délais de notification des incidents, le droit d’audit, les contrôles des sous-traitants et les dispositions de fin de contrat. Il précise :

« Ce qui compte, c’est qu’elles existent et qu’elles soient comprises et acceptées par les deux parties. »
Source : Zenith Blueprint: An Auditor’s 30-Step Roadmap, phase Controls in Action, Step 23: Organizational controls (5.19 to 5.37)

La préparation CVD des fournisseurs doit répondre aux questions suivantes :

• Le fournisseur publie-t-il un canal de signalement des vulnérabilités ?
• Les délais de notification des vulnérabilités sont-ils définis dans le contrat ?
• Les vulnérabilités critiques du fournisseur sont-elles signalées sans retard injustifié ?
• Les faiblesses ayant un impact client sont-elles reliées aux obligations d’assistance en cas d’incident ?
• Le fournisseur peut-il fournir des éléments probants de remédiation ou des avis de sécurité ?
• Les obligations relatives aux vulnérabilités sont-elles répercutées aux sous-traitants ?
• Existe-t-il une stratégie de sortie si la remédiation est insuffisante ?

C’est ici que NIS2, DORA et ISO/IEC 27001:2022 convergent. La gestion des vulnérabilités fournisseurs n’est pas une case à cocher des achats. Elle fait partie de la résilience opérationnelle.

Cartographie des éléments probants pour ISO 27001, NIS2, DORA, GDPR et COBIT

Les programmes CVD les plus robustes sont conçus d’abord autour des éléments probants. Ils partent du principe que tout signalement significatif pourra ensuite être revu par l’audit interne, des auditeurs de certification, des autorités de régulation, des clients, des assureurs ou un comité des risques du conseil d’administration.

La Politique d’audit et de surveillance de la conformité-sme de Clarysec Audit and Compliance Monitoring Policy - SME capture un détail que de nombreuses équipes négligent :

« Les métadonnées (par exemple, qui les a collectées, quand et à partir de quel système) doivent être documentées. »
Source : Audit and Compliance Monitoring Policy-sme, exigences de mise en œuvre de la politique, clause 6.2.3

Une capture d’écran d’un serveur corrigé est faible si personne ne sait qui l’a capturée, quand, depuis quel système et comment elle correspond à la vulnérabilité. Un ticket avec horodatages, sortie de scanner, pull request, approbation de changement, journaux de déploiement, requête de surveillance, confirmation de retest et métadonnées est beaucoup plus solide.

Une matrice de traçabilité plus détaillée facilite la diligence raisonnable client et l’audit interne.

Les différents auditeurs testeront le même processus sous des angles différents.

Un auditeur ISO/IEC 27001:2022 commencera par le SMSI. Il vérifiera si les obligations de divulgation des vulnérabilités sont incluses dans les exigences des parties intéressées, si les risques sont appréciés de manière cohérente, si les contrôles apparaissent dans la SoA, si des éléments probants opérationnels existent et si la direction revoit les tendances et les éléments en retard.

Un réviseur DORA ou services financiers se concentrera sur la résilience opérationnelle. Il examinera l’intégration du risque lié aux TIC, la classification des incidents, l’escalade à la haute direction, la communication client, les dépendances vis-à-vis de tiers, les tests et les enseignements tirés. Si la vulnérabilité affecte une fonction critique ou importante, il attendra un lien étroit entre le ticket technique, l’impact métier, les implications de continuité et les obligations fournisseur.

Un réviseur GDPR se concentrera sur les données à caractère personnel. Des données à caractère personnel étaient-elles impliquées ? Y a-t-il eu accès, perte, altération ou divulgation non autorisés ? Les rôles de responsable du traitement et de sous-traitant étaient-ils clairs ? Le seuil de violation a-t-il été évalué ? Des mesures de protection telles que le chiffrement, le contrôle d’accès, la journalisation et la minimisation étaient-elles pertinentes ?

Un auditeur COBIT 2019 ou ISACA se concentrera sur la gouvernance, la responsabilité, la performance et l’assurance. Il recherchera une propriété définie, des indicateurs, l’escalade, des objectifs de contrôle, une supervision par la direction et le suivi des exceptions. Une vulnérabilité critique en retard n’est pas seulement un problème technique. C’est un problème de gouvernance, sauf si elle a été formellement escaladée et acceptée en risque.

Un évaluateur orienté NIST raisonnera en termes d’Identify, Protect, Detect, Respond et Recover. Il attendra la propriété des actifs, l’identification des vulnérabilités, la priorisation, le changement protecteur, la détection de l’exploitation, la coordination de la réponse et la validation de la récupération.

L’avantage d’un modèle CVD intégré est que la même colonne vertébrale d’éléments probants peut soutenir toutes ces revues.

La boucle mensuelle de contrôle : les indicateurs utiles à la direction

La CVD ne s’arrête pas à la clôture du ticket. La Politique de divulgation coordonnée des vulnérabilités exige une revue continue du journal :

« La VRT doit maintenir un journal de divulgation des vulnérabilités retraçant chaque signalement de la réception à la clôture. Le journal doit être revu mensuellement afin de garantir l’avancement en temps voulu des éléments ouverts. Les éléments en retard doivent être escaladés. »
Source : Politique de divulgation coordonnée des vulnérabilités, surveillance et audit, clause 9.1

Cette revue mensuelle transforme la divulgation des vulnérabilités en gouvernance exploitable par le conseil d’administration. La direction n’a pas besoin de tous les détails techniques. Elle a besoin des tendances, de l’exposition, de la responsabilité et du risque en retard.

Dans une mise en œuvre Clarysec mature, cette revue mensuelle du journal alimente le registre des risques, la Déclaration d’applicabilité, le backlog de développement sécurisé, les revues fournisseurs, les enseignements tirés des incidents, le plan d’audit interne et le dossier de reporting à la direction.

Construire le processus avant l’arrivée d’un signalement grave

Le pire moment pour concevoir la divulgation coordonnée des vulnérabilités est après la publication publique de votre faiblesse par un chercheur ou après le gel de l’intégration par un client bancaire critique. NIS2, DORA, GDPR, ISO/IEC 27001:2022, les attentes de résilience de type NIST et la gouvernance COBIT 2019 convergent toutes dans la même direction : la divulgation des vulnérabilités doit être planifiée, attribuée, testée, étayée par des éléments probants et améliorée.

Commencez par ces cinq actions :

1. Adoptez ou adaptez la Politique de divulgation coordonnée des vulnérabilités.
2. Construisez le flux de réception et de triage à l’aide de Zenith Blueprint, notamment Step 13 pour la traçabilité SoA, Step 16 pour la culture de signalement, Step 19 pour la gestion des vulnérabilités techniques et Step 23 pour les accords fournisseurs.
3. Cartographiez le flux au moyen de Zenith Controls, en vous concentrant sur les mesures ISO/IEC 27002:2022 A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 et A.8.32.
4. Ajoutez les clauses prêtes pour les PME issues de Incident Response Policy-sme, Vulnerability and Patch Management Policy-sme, Third-Party and Supplier Security Policy-sme, Application Security Requirements Policy-sme et Audit and Compliance Monitoring Policy-sme lorsque la proportionnalité compte.
5. Réalisez un exercice sur table simulant un signalement de chercheur affectant des données à caractère personnel et un composant hébergé chez un fournisseur, puis testez l’accusé de réception, le triage, la classification de l’incident, l’application des correctifs, la communication client, la collecte des éléments probants et l’escalade à la direction.

Clarysec peut vous aider à transformer cela en une politique CVD opérationnelle, un registre de réception, une cartographie des éléments probants ISO/IEC 27001:2022, un arbre de décision NIS2 et DORA, un modèle d’escalade fournisseur et un dossier de contrôles compatible avec les exigences d’audit. L’objectif est simple : lorsque le prochain signalement de vulnérabilité arrive, votre équipe ne doit pas improviser. Elle doit exécuter avec confiance, éléments probants et maîtrise.