Des scans aux éléments probants : ISO 27001:2022, NIS2, DORA

Il est 08 h 16, un lundi. Une vulnérabilité critique d’exécution de code à distance vient d’apparaître sur le tableau de bord d’un serveur applicatif exposé à Internet. L’équipe infrastructure indique que le correctif éditeur est disponible. Le propriétaire de l’application avertit que le serveur prend en charge un processus client critique pour le chiffre d’affaires. Le service juridique demande si une exploitation pourrait déclencher des obligations de notification au titre de NIS2, DORA ou GDPR. Maria, RSSI, ouvre le calendrier d’audit et voit le véritable problème : l’audit de surveillance ISO 27001:2022 commence la semaine suivante, une revue de préparation à NIS2 est déjà en cours et un client fintech important a demandé des éléments probants DORA.

Le scanner affiche du rouge. Le tableau de tickets montre de l’activité. Le tableur montre l’effort fourni. Mais rien de tout cela ne prouve automatiquement que le contrôle est maîtrisé.

C’est l’écart que de nombreuses organisations découvrent trop tard. Le scan de vulnérabilités n’est pas équivalent à une gestion des vulnérabilités auditable. Un scan indique qu’un problème peut exister. Les éléments probants d’audit démontrent que l’organisation savait ce qu’elle possédait, a évalué le risque, a attribué la responsabilité, a agi conformément à la politique, a maîtrisé le changement, a documenté les exceptions, a vérifié les résultats et a revu l’issue.

Pour ISO/IEC 27001:2022, NIS2 et DORA, cette chaîne d’éléments probants compte autant que la correction technique. Le scanner ouvre le dossier. L’inventaire des actifs, le registre des vulnérabilités, le ticket, la décision de risque, l’enregistrement de changement, le journal de correctifs, les éléments probants de validation, l’approbation d’exception et la revue de direction le complètent.

L’approche de Clarysec est simple : ne pas traiter la gestion des vulnérabilités comme un rituel technique mensuel. La traiter comme un processus gouverné de production d’éléments probants.

Pourquoi les rapports de scan échouent comme éléments probants d’audit

Un scan de vulnérabilités est une observation technique à un instant donné. Il peut identifier une CVE, un correctif manquant, une bibliothèque non prise en charge, un service exposé ou une configuration faible. C’est utile, mais insuffisant.

Un auditeur posera d’autres questions :

• L’actif concerné était-il dans le périmètre ?
• Qui est propriétaire de l’actif et du service métier ?
• La vulnérabilité a-t-elle été évaluée selon l’exposition, l’exploitabilité, l’impact métier et la sensibilité des données ?
• La remédiation a-t-elle été achevée dans le délai défini ?
• Si la remédiation a été retardée, qui a accepté le risque résiduel ?
• Le correctif a-t-il été déployé au moyen d’une gestion des changements maîtrisée ?
• La correction a-t-elle été vérifiée par un nouveau scan ou par une validation technique ?
• Les éléments probants ont-ils été conservés et revus par la direction ?

Un dossier d’exports de scanner répond rarement à ces questions. Lors d’un audit ISO 27001:2022, l’auditeur vérifie si le SMSI fonctionne comme prévu. Au titre de NIS2, les organes de direction doivent approuver et superviser les mesures de gestion des risques de cybersécurité. Au titre de DORA, les entités financières doivent disposer d’un cadre documenté de gestion des risques liés aux TIC, d’un cycle de vie des incidents, de tests de résilience et de contrôles du risque lié aux tiers prestataires TIC. Au titre du GDPR, la question devient de savoir si des mesures techniques et organisationnelles appropriées ont protégé les données à caractère personnel et si la responsabilité peut être démontrée.

Les clauses 4.1 à 4.4 d’ISO/IEC 27001:2022 exigent que l’organisation comprenne son contexte, les parties intéressées, les exigences et le domaine d’application du SMSI. La gestion des vulnérabilités et des correctifs ne peut pas être conçue isolément. Elle doit refléter les contrats clients, les autorités de régulation, les dépendances cloud, les services TIC externalisés, les obligations de protection des données et les services critiques.

Les clauses 6.1.1 à 6.1.3 d’ISO/IEC 27001:2022 exigent une appréciation des risques, un traitement des risques, une sélection des mesures de sécurité, une Déclaration d’applicabilité (SoA) et l’approbation du propriétaire du risque pour le risque résiduel. Les éléments probants relatifs aux vulnérabilités doivent donc être reliés au registre des risques, au plan de traitement des risques et à la SoA.

ISO/IEC 27005:2022 renforce ce modèle en encourageant les organisations à consolider les exigences issues de l’Annexe A, des obligations sectorielles, des réglementations, des contrats, des règles internes et des contrôles existants dans le référentiel de l’appréciation des risques. Il met également l’accent sur les critères de vraisemblance, de conséquence, d’obligations légales, de relations fournisseurs, d’impact sur la vie privée et d’impact sur les tiers. En pratique, une vulnérabilité n’est pas seulement un score CVSS. C’est un événement de risque relié à des actifs, des obligations, des parties prenantes et des conséquences métier.

La pression réglementaire derrière les éléments probants relatifs aux correctifs

La réglementation moderne en cybersécurité tolère de moins en moins l’application informelle des correctifs.

NIS2 s’applique à de nombreuses entités moyennes et grandes dans des secteurs hautement critiques et critiques, et peut également viser certaines entités indépendamment de leur taille. Son périmètre inclut les fournisseurs d’infrastructures numériques tels que les services d’informatique en nuage, les services de centres de données, les réseaux de diffusion de contenu, les fournisseurs de réseaux publics de communications électroniques, les services de confiance, les services DNS et TLD, ainsi que les fournisseurs de gestion de services TIC tels que les prestataires de services managés et les prestataires de services de sécurité managés. Elle couvre également des fournisseurs numériques importants tels que les places de marché en ligne, les moteurs de recherche en ligne et les plateformes de réseaux sociaux.

Article 20 de NIS2 fait de la cybersécurité une responsabilité de l’organe de direction. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition sécurisée, le développement sécurisé, la maintenance sécurisée, le traitement et la divulgation des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, le contrôle d’accès, la gestion des actifs et l’authentification. Article 23 crée un processus échelonné de notification des incidents significatifs, incluant une alerte précoce dans les 24 heures, une notification dans les 72 heures et, le cas échéant, un rapport final dans un délai d’un mois.

DORA établit, à compter du 17 janvier 2025, un corpus directement applicable de règles de résilience opérationnelle numérique pour les entités financières. Il couvre la gestion des risques liés aux TIC, la notification des incidents majeurs liés aux TIC, les tests de résilience opérationnelle, le partage de renseignement sur les cybermenaces, la gestion du risque lié aux tiers prestataires TIC et la supervision des prestataires tiers de services TIC critiques. Articles 5 et 6 placent la gouvernance du risque TIC sous la responsabilité de l’organe de direction et exigent un cadre de gestion des risques liés aux TIC documenté, intégré et régulièrement revu. Article 8 renforce la nécessité d’identifier les fonctions opérationnelles prises en charge par les TIC, les actifs informationnels, les actifs TIC et les dépendances. Articles 17 à 20 exigent la détection, l’enregistrement, la classification, l’escalade, la notification, la communication, la remédiation et le retour d’expérience pour les incidents liés aux TIC. Articles 28 à 30 exigent que le risque lié aux tiers prestataires TIC soit maîtrisé au moyen de registres, de diligences raisonnables, de garanties contractuelles, de droits d’audit, de plans de sortie et d’une supervision.

Pour les entités financières couvertes par DORA, DORA remplace généralement les obligations équivalentes de NIS2 en matière de gestion des risques et de notification. Mais NIS2 reste importante pour la coordination de l’écosystème et pour les entités hors périmètre DORA. Pour les fournisseurs SaaS, MSP et MSSP servant des clients financiers, la réalité pratique est directe : les clients peuvent exiger vos éléments probants de gestion des vulnérabilités afin de satisfaire leurs obligations DORA.

GDPR ajoute une autre couche. Articles 2 et 3 peuvent s’appliquer aux organisations établies dans l’UE et aux organisations non établies dans l’UE qui proposent des biens ou services à des personnes dans l’UE ou surveillent leur comportement. Article 5 exige la protection des données à caractère personnel et la responsabilité en matière de conformité. Article 4 définit une violation de données à caractère personnel comme un incident de sécurité entraînant la perte, la destruction, l’altération, la divulgation non autorisée de données à caractère personnel ou l’accès non autorisé à celles-ci, de manière accidentelle ou illicite. Un correctif retardé sur une base de données, une plateforme d’identité ou un portail client peut devenir un sujet de responsabilité en matière de vie privée.

De la politique à la preuve

La première étape consiste à définir les règles. Une politique robuste de gestion des vulnérabilités et des correctifs n’est pas seulement un document d’audit. C’est la constitution opérationnelle du contrôle.

Pour les environnements d’entreprise, la Politique de gestion des vulnérabilités et des correctifs relie explicitement l’application technique des correctifs à la conformité croisée :

Cette politique soutient la conformité à ISO/IEC 27001 Annexe A Mesure 8.8 et aux recommandations ISO/IEC 27002, et couvre les exigences réglementaires au titre de DORA Article 8, NIS2 Article 21, GDPR Article 32, ainsi que des domaines DSS et APO de COBIT 2019.

Extrait de la section « Objet ».

La même politique fixe l’exigence de gouvernance applicable au principal livrable probant :

Un registre de gestion des vulnérabilités centralisé doit être tenu par l’équipe des opérations de sécurité et revu mensuellement par le RSSI ou une autorité déléguée.

Extrait de la section « Exigences de gouvernance », clause 5.1 de la politique.

Elle définit également la cadence de scan :

Tous les systèmes doivent être scannés au moins une fois par mois ; les actifs à haut risque ou exposés à l’extérieur doivent être scannés chaque semaine.

Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.1.1 de la politique.

Elle empêche également les correctifs urgents de devenir une activité technique non maîtrisée :

Toutes les activités de remédiation doivent être coordonnées dans le cadre du processus de gestion des changements (conformément à P5 - Politique de gestion des changements) afin d’assurer la stabilité et la préservation de la piste d’audit.

Extrait de la section « Exigences de gouvernance », clause 5.5 de la politique.

Pour les PME, les mêmes principes de preuve peuvent être mis en œuvre plus simplement. La Politique de gestion des vulnérabilités et des correctifs pour PME indique :

Tenir des enregistrements exacts des correctifs appliqués, des points en suspens et des exceptions afin de garantir la préparation à l’audit

Extrait de la section « Objectifs », clause 3.4 de la politique.

Elle définit ensuite le journal de correctifs comme élément probant d’audit :

Un journal de correctifs doit être tenu et revu lors des audits et des activités de réponse aux incidents

Extrait de la section « Exigences de gouvernance », clause 5.4.1 de la politique.

Et elle précise le contenu minimal :

Les journaux doivent inclure le nom de l’appareil, la mise à jour appliquée, la date d’application des correctifs et la raison de tout retard

Extrait de la section « Exigences de gouvernance », clause 5.4.2 de la politique.

Pour une exposition urgente sur des systèmes exposés à Internet, la politique PME fixe une exigence mesurable :

Les correctifs critiques doivent être appliqués dans les 3 jours suivant leur publication, en particulier pour les systèmes exposés à Internet

Extrait de Politique de gestion des vulnérabilités et des correctifs pour PME, section « Exigences de mise en œuvre de la politique », clause 6.1.1.

Ces clauses transforment le travail technique en éléments probants. La politique définit les attentes. Le registre consigne les constats. Le ticket attribue les travaux. L’enregistrement de changement maîtrise le déploiement. Le journal de correctifs prouve l’action. Le registre des risques consigne les exceptions. Les comptes rendus de revue démontrent la supervision.

Le modèle Clarysec orienté éléments probants

Le modèle Clarysec orienté éléments probants repose sur un principe : chaque constat de vulnérabilité doit être traçable de la découverte à la décision.

Dans Zenith Blueprint : feuille de route d’audit en 30 étapes, la phase Contrôles en action, Étape 19 : Contrôles technologiques I, traite la gestion des vulnérabilités comme un contrôle répétable plutôt que comme une exigence théorique :

La gestion des vulnérabilités est l’un des domaines les plus critiques de l’hygiène cyber moderne. Bien que les pare-feu et les outils antivirus fournissent une protection, ils peuvent être contournés si des systèmes non corrigés ou des services mal configurés restent exposés.

La même étape explique que les organisations doivent utiliser des calendriers réguliers d’application des correctifs, des scanners de vulnérabilités, le triage, l’attribution, le suivi de la remédiation, des contrôles compensatoires et l’acceptation du risque résiduel. Surtout, elle cadre correctement la posture d’audit :

Le contrôle ne vise pas la perfection ; il vise un processus organisé, transparent et assorti d’une responsabilité claire.

Pour les auditeurs, cette distinction est importante. Une organisation mature peut avoir des vulnérabilités ouvertes tout en démontrant la maîtrise du contrôle, dès lors qu’elle dispose d’une priorisation fondée sur les risques, d’une propriété documentée, d’exceptions approuvées, de contrôles compensatoires et d’une remédiation vérifiée.

Le Zenith Blueprint avertit également que les auditeurs examineront ce domaine de près :

Il s’agit d’un contrôle prioritaire pour les auditeurs, qui l’examineront généralement en profondeur. Attendez-vous à des questions sur la fréquence d’application des correctifs aux systèmes, le processus suivi lorsqu’une vulnérabilité zero-day est annoncée et les systèmes les plus difficiles à corriger.

C’est pourquoi un RSSI ne doit pas se présenter à un audit avec un simple tableau de bord de scanner. Le dossier probant doit montrer la gouvernance, le processus, l’exécution, la vérification et l’amélioration.

Cartographier les contrôles ISO 27002 aux éléments probants d’audit

Zenith Controls : guide de conformité croisée sert de boussole de conformité croisée en cartographiant les contrôles ISO/IEC 27002:2022 et en montrant leur lien avec les attentes d’audit. Pour la gestion des vulnérabilités et des correctifs, trois mesures ISO/IEC 27002:2022 forment le triangle opérationnel.

ISO/IEC 27002:2022 mesure 8.8, gestion des vulnérabilités techniques, est le contrôle central. Elle est préventive, soutient la confidentialité, l’intégrité et la disponibilité, s’aligne sur les concepts de cybersécurité Identifier et Protéger et se relie à la gestion des menaces et des vulnérabilités.

ISO/IEC 27002:2022 mesure 8.32, gestion des changements, est également préventive. Elle relie l’application des correctifs à un déploiement maîtrisé, aux tests, à l’approbation, au retour arrière et à l’auditabilité.

ISO/IEC 27002:2022 mesure 5.36, conformité aux politiques, règles et normes de sécurité de l’information, garantit que le processus n’est pas facultatif ni dépendant d’actes héroïques individuels. Elle relie la gestion des vulnérabilités au respect de la politique, à l’assurance et à la supervision.

Cette cartographie évite un échec d’audit courant. La sécurité dit : « Nous avons appliqué le correctif. » L’exploitation dit : « Nous l’avons déployé. » La conformité dit : « Nous ne pouvons pas prouver la séquence. » Une chaîne d’éléments probants cartographiée donne aux trois équipes le même récit.

La chaîne d’éléments probants attendue par les auditeurs

Une chaîne d’éléments probants défendable pour la gestion des vulnérabilités comporte sept étapes.

La différence pratique entre « nous réalisons des scans » et « nous sommes prêts pour l’audit » tient à la continuité. Si une vulnérabilité ne peut pas être tracée de la découverte à la clôture, le contrôle est faible. Si des exceptions existent mais que personne ne les a approuvées, le processus est faible. Si les correctifs contournent la gestion des changements, la piste d’audit est faible. Si des vulnérabilités critiques restent ouvertes sans contrôles compensatoires, la gouvernance est faible.

La Politique d’audit et de surveillance de la conformité soutient l’automatisation dans ce modèle :

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.

Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.4.1 de la politique.

Pour les PME, la Politique d’audit et de surveillance de la conformité pour PME définit la vérification des contrôles techniques en termes pratiques :

Vérification des contrôles techniques (par exemple, statut des sauvegardes, configuration du contrôle d’accès, enregistrements des correctifs)

Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.1.1.2 de la politique.

Les petites organisations n’ont pas besoin d’outillage de niveau entreprise pour être prêtes pour l’audit. Elles ont besoin d’éléments probants cohérents. Un registre léger, un tableau de tickets, un journal de correctifs et une revue mensuelle peuvent suffire s’ils sont complets, à jour et reliés au risque.

Exemple : un constat critique entièrement prêt pour l’audit

Le scan externe hebdomadaire de Maria identifie CVE-2026-12345 sur une passerelle API de paiement exposée à Internet. Le scanner la classe comme critique. Le service traite l’identité client et des métadonnées de transaction ; des implications GDPR et DORA sont donc possibles. La passerelle appartient à Platform Engineering, mais le correctif nécessite une courte interruption de service.

Voici le processus auditable.

1. Créer l’entrée dans le registre des vulnérabilités

L’équipe sécurité consigne le constat dans le registre central :

• Identifiant du constat : VULN-2026-0142
• Source : scan externe hebdomadaire
• Date et heure de découverte
• Actif : api-gw-prod-01
• Propriétaire : Platform Engineering
• Exposition : exposé à Internet
• Contexte des données : identité client et métadonnées de transaction
• Gravité : critique
• SLA : 72 heures ou plus strict selon la politique
• Ticket : SEC-4821
• Enregistrement de changement : CHG-10988
• Statut : remédiation planifiée

2. Triage selon le contexte métier et réglementaire

L’équipe vérifie la disponibilité d’un code d’exploitation, la surface d’attaque, les exigences d’authentification, l’impact métier et la sensibilité des données. Le système étant exposé à Internet et prenant en charge des processus clients, la vulnérabilité reste critique. Le propriétaire du risque est le responsable de Platform Engineering, et le RSSI est notifié en raison d’implications possibles au titre de NIS2, DORA et GDPR.

Les clauses 7.1 à 7.4 d’ISO/IEC 27005:2022 soutiennent l’identification des risques, la propriété, les conséquences, la vraisemblance et la priorisation. Les clauses 8.2 à 8.6 soutiennent la sélection du traitement, la détermination des contrôles, le lien avec la SoA, la planification du traitement et l’approbation du risque résiduel.

3. Ouvrir un changement d’urgence maîtrisé

Le correctif est planifié pour le soir même. L’enregistrement de changement comprend la référence éditeur, les services affectés, le plan de test, le plan de retour arrière, la fenêtre de maintenance, la décision de communication client, les approbations et l’exigence de validation post-déploiement.

Cela soutient directement ISO/IEC 27002:2022 mesure 8.32 et l’exigence de la politique d’entreprise selon laquelle la remédiation doit être coordonnée par la gestion des changements.

4. Appliquer le correctif et mettre à jour le journal de correctifs

Le journal de correctifs consigne le nom de l’appareil, la mise à jour appliquée, la date d’application des correctifs et, le cas échéant, la raison du retard. Si l’application du correctif avait été retardée, l’équipe aurait documenté des contrôles compensatoires tels que des règles WAF, des restrictions d’accès temporaires, une journalisation renforcée, un isolement ou une supervision renforcée.

5. Vérifier et clôturer

La sécurité relance un scan de la passerelle API. La vulnérabilité n’apparaît plus. Le ticket est mis à jour avec l’élément probant de scan propre, la version du correctif, l’horodatage de déploiement et le lien vers l’enregistrement de changement. Le statut du registre des vulnérabilités passe à « Clôturé, vérifié ».

6. Examiner l’impact sur les obligations de notification

En l’absence d’exploitation et d’interruption de service, la notification d’incident au titre de NIS2 ou DORA peut ne pas être déclenchée. Si des indicateurs de compromission sont détectés, le processus d’incident doit classifier l’impact et l’escalade. Au titre de NIS2, un incident significatif peut nécessiter une alerte précoce et une notification échelonnée. Au titre de DORA, un incident majeur lié aux TIC nécessite une classification et une notification via le processus applicable auprès de l’autorité compétente.

7. Intégrer les enseignements dans la revue de direction

En fin de mois, la revue du RSSI note que la vulnérabilité a été détectée par le scan externe hebdomadaire, remédiée dans le SLA, vérifiée par un nouveau scan et clôturée sans incident. Si des problèmes similaires se reproduisent, le plan de traitement des risques peut inclure des configurations de référence sécurisées, un déploiement automatisé des correctifs, une escalade éditeur ou une modernisation applicative.

Lorsqu’un auditeur interroge Maria sur CVE-2026-12345, elle peut présenter un dossier sélectionné plutôt que des courriels et des captures d’écran.

C’est prêt pour l’audit. Non parce que l’organisation n’avait aucune vulnérabilité, mais parce qu’elle en avait la maîtrise.

Un seul jeu d’éléments probants, plusieurs obligations

Un programme bien conçu de gestion des vulnérabilités et des correctifs peut satisfaire plusieurs référentiels sans dupliquer le travail.

Pour ISO 27001:2022, les éléments probants soutiennent le SMSI fondé sur les risques, la mise en œuvre des contrôles de l’Annexe A, la Déclaration d’applicabilité, les plans de traitement des risques, l’audit interne et l’amélioration continue. Si ISO/IEC 27002:2022 mesure 8.8 est applicable dans la SoA, l’organisation doit pouvoir démontrer la justification juridique, réglementaire, de risque ou métier. Cette justification inclut souvent NIS2 Article 21, les obligations de risque TIC de DORA, la responsabilité au titre du GDPR, les contrats clients et les besoins de résilience opérationnelle.

Pour NIS2, les mêmes éléments probants aident à démontrer les mesures Article 21, notamment l’analyse des risques, le traitement des vulnérabilités, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’hygiène cyber, le contrôle d’accès et l’évaluation de l’efficacité. Article 20 est démontré par la revue du RSSI, le reporting au conseil d’administration, l’approbation de la direction et la formation cybersécurité. Article 23 devient pertinent si une exploitation cause ou pourrait causer une perturbation opérationnelle grave, une perte financière ou un préjudice pour autrui.

Pour DORA, les éléments probants relatifs aux vulnérabilités et aux correctifs soutiennent le cadre de gestion des risques liés aux TIC, la supervision par l’organe de direction, la stratégie de résilience, la détection et la classification des incidents, les tests de résilience et la supervision des tiers prestataires TIC. Lorsqu’un fournisseur TIC héberge ou administre le système affecté, Articles 28 à 30 exigent des diligences raisonnables, des protections contractuelles, des droits d’audit, une assistance en cas d’incident et des considérations de sortie.

Pour GDPR, les mêmes éléments probants soutiennent la responsabilité exigée par Article 5 et le niveau de sécurité attendu au titre de Article 32. Si une vulnérabilité entraîne un accès non autorisé, une altération, une perte ou une divulgation de données à caractère personnel, la chronologie de la vulnérabilité, les enregistrements de correctifs, les journaux de surveillance et les notes d’évaluation de la violation deviennent essentiels.

Pour COBIT 2019 et l’assurance de type ISACA, la gestion des vulnérabilités est évaluée au regard de la sécurité opérationnelle, de la surveillance des contrôles, de l’activation des changements et de la responsabilité de gouvernance. Les références de conformité croisée du Zenith Blueprint mentionnent COBIT 2019 DSS05.04 et BAI09.02, ainsi que les attentes d’assurance ITAF relatives à la gestion des vulnérabilités, à l’application des correctifs et à la gestion sécurisée des changements.

Les normes ISO connexes renforcent le modèle opérationnel. ISO/IEC 27005:2022 soutient l’appréciation et le traitement des risques. ISO/IEC 27035:2023 soutient la réponse aux incidents lorsque des vulnérabilités sont exploitées. ISO/IEC 30111 soutient les processus de traitement des vulnérabilités. ISO/IEC 29147 soutient la divulgation des vulnérabilités et les avis. ISO/IEC 27017 soutient la gestion des vulnérabilités dans le cloud. ISO 22301 soutient la planification de la continuité lorsque des vulnérabilités techniques pourraient perturber des services métier.

Comment différents auditeurs testent le même processus

Différents évaluateurs utilisent des prismes différents. Les éléments probants peuvent être les mêmes, mais les questions changent.

La politique indique ce qui doit se produire. Les éléments probants opérationnels montrent ce qui s’est produit. Les enregistrements de revue montrent que la direction a eu connaissance, a questionné et a agi.

Raisons fréquentes d’échec de la gestion des correctifs en audit

La plupart des constats ne sont pas dus à l’absence de scanner. Ils sont dus à une traçabilité défaillante.

L’inventaire des actifs est incomplet.
Si un scanner trouve des actifs absents de la CMDB ou du registre des actifs, la propriété et l’impact métier ne peuvent pas être évalués de manière fiable. Cela compromet le domaine d’application ISO 27001:2022, l’appréciation des risques et leur traitement.

Les vulnérabilités ne sont suivies que dans le scanner.
Les tableaux de bord de scanner ne sont pas des registres de gouvernance. Il leur manque souvent l’approbation du propriétaire du risque, la justification d’exception, les références de changement et le contexte métier.

Les constats critiques n’ont pas d’éléments probants de SLA.
Une politique peut indiquer que les vulnérabilités critiques sont corrigées dans les trois jours. La question d’audit est de savoir si les enregistrements prouvent que cela a été fait.

Les exceptions sont informelles.
Les systèmes hérités, les contraintes d’interruption de service et les retards fournisseurs existent. Mais « nous n’avons pas pu appliquer le correctif » doit devenir une exception documentée avec contrôles compensatoires, date d’expiration et approbation du risque résiduel.

Les correctifs d’urgence contournent la gestion des changements.
Les changements d’urgence restent des changements. En l’absence d’approbation, de tests ou d’éléments probants de retour arrière, les auditeurs peuvent conclure que la remédiation a créé un risque opérationnel.

Les systèmes tiers sont invisibles.
Au titre de NIS2 et DORA, le risque fournisseur et le risque lié aux tiers prestataires TIC sont centraux. Si un prestataire applique les correctifs à la plateforme, vous avez tout de même besoin d’éléments probants, de droits contractuels, de rapports de service et de circuits d’escalade.

Personne ne revoit les tendances.
Les vulnérabilités récurrentes peuvent indiquer une gestion des configurations faible, de mauvaises pratiques de codage sécurisé, des actifs non pris en charge ou une défaillance fournisseur. La revue mensuelle transforme les données techniques en action de gouvernance.

Le dossier d’audit Clarysec sur les vulnérabilités

Pour une prochaine revue de préparation ISO 27001:2022, NIS2 ou DORA, Clarysec aide les organisations à constituer un dossier d’audit de gestion des vulnérabilités et des correctifs comprenant :

• Politique de gestion des vulnérabilités et des correctifs, incluant le périmètre, les rôles, la cadence de scan, les SLA de correctifs et les règles d’exception
• Extrait de l’inventaire des actifs montrant les systèmes dans le périmètre, les propriétaires, la criticité et l’exposition
• Derniers rapports de scans de vulnérabilités internes et externes
• Registre central de gestion des vulnérabilités avec les éléments ouverts, clôturés et en exception
• Journaux de correctifs indiquant l’appareil, la mise à jour, la date du correctif et les raisons des retards
• Enregistrements de changements pour un échantillon de vulnérabilités critiques et élevées
• Éléments probants de nouveaux scans ou de validation après remédiation
• Approbations d’exception et de risque résiduel pour les systèmes retardés ou non corrigeables
• Processus de surveillance des avis de sécurité pour les fournisseurs, bibliothèques et services cloud
• Comptes rendus mensuels de revue par le RSSI ou la direction
• Table de correspondance avec les obligations ISO 27001:2022, NIS2, DORA, GDPR et COBIT 2019
• Résultats d’audit interne ou de vérification des contrôles techniques

Dans le Zenith Blueprint, phase Audit, revue et amélioration, Étape 24, Clarysec insiste sur la traçabilité entre la Déclaration d’applicabilité, le registre des risques et le plan de traitement des risques :

Votre SoA doit être cohérente avec votre registre des risques et votre plan de traitement des risques. Vérifiez que chaque contrôle choisi comme traitement du risque est marqué « Applicable » dans la SoA.

C’est particulièrement important pour la gestion des vulnérabilités. Si la mesure 8.8 est applicable, le dossier d’audit doit prouver non seulement que des scans sont réalisés, mais que les constats sont gouvernés par le traitement des risques et l’amélioration continue.

Un sprint de préparation de 30 jours

Si votre audit approche, ne commencez pas par tout réécrire. Commencez par constituer rapidement les éléments probants.

Ce sprint n’éliminera pas toute la dette technique. Il changera la conversation d’audit. Au lieu de défendre un export de scanner désordonné, vous pourrez montrer un processus gouverné avec des propriétaires, des délais, des actions, des décisions et une supervision.

Passer des scans aux éléments probants défendables

La préparation à l’audit en matière de gestion des vulnérabilités et des correctifs ne consiste pas à prouver que vous n’avez aucune vulnérabilité. Elle consiste à prouver que vous savez les trouver, les comprendre, les prioriser, les corriger, maîtriser les exceptions et démontrer la supervision.

Zenith Blueprint, Zenith Controls, la Politique de gestion des vulnérabilités et des correctifs, la Politique de gestion des vulnérabilités et des correctifs pour PME, la Politique d’audit et de surveillance de la conformité et la Politique d’audit et de surveillance de la conformité pour PME de Clarysec fournissent la structure nécessaire pour bâtir ce processus de production d’éléments probants.

Si votre organisation prépare une certification ISO 27001:2022, la préparation à NIS2, la résilience opérationnelle numérique DORA, une diligence raisonnable client ou un audit interne, commencez par une question :

Chaque vulnérabilité critique peut-elle être tracée du scan à la clôture ?

Si la réponse est non, Clarysec peut vous aider à construire le registre, le jeu de politiques, la cartographie de conformité croisée, le dossier de revue de direction et le processus d’éléments probants auditables qui transforment le scan technique en gouvernance défendable.