Gouvernance CISA KEV pour ISO 27001, NIS2 et DORA

La vulnérabilité du vendredi devenue une question pour le conseil d’administration

Il est 16 h 40 un vendredi. Votre responsable SOC transmet une alerte CISA KEV, l’outil d’analyse des vulnérabilités confirme une exposition sur une passerelle accessible depuis Internet, et ENISA EUVD contient un enregistrement correspondant à une vulnérabilité exploitée. Le fournisseur a publié un correctif, mais le propriétaire de l’environnement de production signale qu’une application immédiate pourrait perturber un service orienté client. Le service juridique demande si des données à caractère personnel pourraient être concernées. Le responsable DORA demande si la plateforme soutient une fonction critique ou importante. Le coordinateur NIS2 demande si la situation pourrait devenir un incident significatif.

Le RSSI pose la seule question qui compte :

“Pouvons-nous prouver que nous avons pris la bonne décision, assez vite, avec les bonnes approbations ?”

C’est le véritable enjeu de la gouvernance des vulnérabilités exploitées connues en 2026. Il ne s’agit pas seulement d’identifier des CVE ou d’accélérer l’application des correctifs. Il s’agit de transformer le renseignement sur l’exploitation en un modèle opérationnel défendable : réception, triage, priorisation, changement d’urgence, contrôles compensatoires, escalade fournisseur, approbation de dérogation, conservation des éléments probants, rapport à la direction et décisions de remédiation prêtes pour un examen réglementaire.

De nombreuses organisations disposent déjà de SLA de gestion des vulnérabilités. Certaines utilisent des flux de renseignement sur les menaces. Quelques-unes exploitent une gestion continue de l’exposition. Mais lorsqu’une vulnérabilité est déjà exploitée en conditions réelles, le contexte de risque change. Une vulnérabilité exploitée connue figurant dans CISA KEV ou ENISA EUVD ne doit pas rester dans la même file que l’arriéré ordinaire des correctifs. Elle doit déclencher un circuit de gouvernance distinct, car le risque n’est plus théorique.

La position de Clarysec est simple : la remédiation pilotée par l’exploitation doit être gérée comme un processus métier producteur d’éléments probants, et non comme une réaction technique informelle. Ce processus peut être construit sur ISO/IEC 27001:2022 ISO/IEC 27001:2022, renforcé par ISO/IEC 27002:2022 ISO/IEC 27002:2022, et cartographié avec les attentes de gouvernance de NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT 19.

De l’application des correctifs à une gouvernance démontrable

La gestion traditionnelle des vulnérabilités commence souvent par la gravité : score CVSS, criticité de l’actif, exposition et disponibilité du correctif. La gouvernance pilotée par l’exploitation ajoute une question plus précise : cette vulnérabilité est-elle déjà utilisée par des attaquants, et avons-nous des actifs, fournisseurs, services cloud ou flux de données affectés ?

Ce changement modifie le processus. Une vulnérabilité exploitée connue doit déclencher :

1. Une validation du renseignement sur les menaces à partir de sources de confiance telles que CISA, ENISA, les CERT nationaux, les fournisseurs, les ISAC et les MSSP.
2. Une corrélation avec les actifs, incluant l’exposition à Internet, la fonction métier, la classification des données et la dépendance fournisseur.
3. Une décision de risque d’urgence, incluant l’application immédiate du correctif, l’isolement, la désactivation d’une fonction, l’application d’un contournement, la surveillance ou l’acceptation temporaire d’un risque résiduel.
4. Une approbation de changement avec traçabilité, même lorsque le changement est accéléré.
5. Une collecte des éléments probants, incluant horodatages, approbations, journaux, captures d’écran, résultats d’analyse, déclarations des fournisseurs et enregistrements des contrôles compensatoires.
6. Un rapport à la direction, en particulier lorsque la vulnérabilité affecte des services critiques, des données à caractère personnel, des services financiers réglementés ou des services essentiels ou importants au titre de NIS2.
7. Une validation post-remédiation et un retour d’expérience.

ISO 27001:2022 donne à ce processus une ossature de gouvernance. Les clauses 4.1 à 4.4 exigent que l’organisation comprenne les enjeux internes et externes, les parties intéressées, les exigences légales et réglementaires, les interfaces et les dépendances, puis définisse et maintienne le domaine d’application du SMSI. Dans la gouvernance des vulnérabilités, cela signifie que le périmètre doit inclure les systèmes réels, services cloud, tiers et services réglementés dans lesquels l’exposition à une vulnérabilité exploitée peut créer un impact métier.

Les clauses 5.1 à 5.3 déplacent le sujet au-delà de l’exploitation informatique. La direction doit aligner le SMSI sur l’orientation stratégique, attribuer les responsabilités, allouer les ressources, communiquer l’importance de la conformité et recevoir des rapports de performance. En pratique, une correspondance CISA KEV sur un service critique n’est pas seulement un ticket de correctif. C’est un événement engageant la responsabilité au niveau exécutif.

Les clauses 6.1.1 à 6.1.3 fournissent l’ossature du risque : critères de risque, propriétaires du risque, évaluation de la vraisemblance et des conséquences, options de traitement, déclaration d’applicabilité, plan de traitement des risques et acceptation du risque résiduel. C’est le mécanisme qui transforme “nous ne pouvions pas encore appliquer le correctif” en une dérogation documentée, approuvée, limitée dans le temps et assortie de contrôles compensatoires.

La clause 8.1 devient ensuite déterminante lorsque l’équipe passe de la décision à l’exécution. Elle exige une planification et une maîtrise opérationnelles, y compris la maîtrise des changements planifiés et la revue des changements non intentionnels. Lors d’un événement KEV, l’organisation doit agir vite sans perdre le contrôle.

Le triangle de contrôle Clarysec pour les vulnérabilités exploitées

Zenith Controls: The Cross-Compliance Guide de Clarysec Zenith Controls traite la gouvernance des vulnérabilités exploitées connues comme la combinaison de trois thèmes centraux de contrôle ISO/IEC 27002:2022. Il cite les contrôles liés au sujet comme “Renseignement sur les menaces (5.7)”, “Gestion des vulnérabilités techniques (8.8)” et “Gestion des changements (8.32)”.

Ensemble, ces contrôles forment un triangle pratique :

Ce triangle évite une défaillance d’audit fréquente : traiter la gestion des vulnérabilités comme une sortie d’outil d’analyse plutôt que comme une chaîne de décision gouvernée. Un auditeur, une autorité de régulation ou une équipe d’assurance client ne demandera pas seulement si un correctif a été appliqué. Ils demanderont comment l’organisation a identifié, priorisé, approuvé, mis en œuvre et vérifié la décision.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint rend cela concret dans la phase Controls in Action, Étape 22, où il demande aux équipes de constituer un registre de renseignement sur les menaces :

Établir une liste documentée des sources de renseignement sur les menaces (5.7), provenant de fournisseurs, d’ISAC ou de sources ouvertes, et déterminer comment le renseignement est validé et intégré dans la prise de décision. Définir qui reçoit les mises à jour relatives aux menaces et comment elles sont appliquées (par exemple, priorisation des correctifs, formation de sensibilisation).

À l’Étape 19, Zenith Blueprint présente la gestion des vulnérabilités comme une composante moderne de la cyberhygiène et insiste sur la remédiation accélérée des vulnérabilités critiques :

La gestion des vulnérabilités est l’un des domaines les plus critiques de la cyberhygiène 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.

Il avertit également que les constats d’analyse ne doivent pas être archivés passivement. Ils doivent être triés, attribués et suivis jusqu’à leur clôture. Cette discipline est exactement ce qu’exige la gouvernance CISA KEV et ENISA EUVD.

La politique transforme l’urgence en règles

Un modèle de gouvernance ne fonctionne que s’il est reflété dans une politique. La Politique Entreprise de gestion des vulnérabilités et des correctifs de Clarysec Politique de gestion des vulnérabilités et des correctifs, également référencée dans les kits documentaires comme P19 Politique de gestion des vulnérabilités et des correctifs, attribue clairement l’exigence de surveillance et d’escalade :

Surveiller les avis sur les menaces (par exemple, CVE, CISA KEV, bulletins fournisseurs) et escalader les vulnérabilités critiques.

Extrait de la section “Rôles et responsabilités”, clause de politique 4.5.1.

La même politique Entreprise définit une exigence de remédiation stricte pour les vulnérabilités critiques :

Critique (CVSS 9.0-10.0) : revue immédiate ; délai maximal d’application du correctif de 72 heures.

Extrait de la section “Exigences de gouvernance”, clause de politique 5.2.1.

Pour les PME, la Politique PME de gestion des vulnérabilités et des correctifs de Clarysec Politique PME de gestion des vulnérabilités et des correctifs, également référencée comme P19S Politique PME de gestion des vulnérabilités et des correctifs, rend le même concept opérationnel et direct :

Avis de renseignement sur les menaces de confiance (par exemple, CISA, ENISA, alertes CERT nationales)

Extrait de la section “Exigences de mise en œuvre de la politique”, clause de politique 6.2.1.3.

Elle fixe également le standard pratique d’application des correctifs :

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 la section “Exigences de mise en œuvre de la politique”, clause de politique 6.1.1.

La formule “en particulier pour les systèmes exposés à Internet” est importante. La gouvernance des vulnérabilités exploitées connues doit prioriser les systèmes exposés, les services d’accès à distance, l’infrastructure d’identité, les équipements en périphérie du réseau, les consoles d’administration SaaS et les systèmes traitant des données sensibles ou réglementées.

Mais que se passe-t-il lorsque le métier ne peut pas appliquer le correctif dans le SLA ? La politique Entreprise boucle le processus :

Si une vulnérabilité ne peut pas être remédiée dans les SLA définis en raison de contraintes opérationnelles, techniques ou fournisseur, un formulaire de demande de dérogation formelle doit être soumis.

Extrait de la section “Traitement des risques et exceptions”, clause de politique 7.1.

La version PME exige des journaux de correctifs qui soutiennent l’auditabilité :

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

Extrait de la section “Exigences de gouvernance”, clause de politique 5.4.2.

Ces clauses de politique créent la colonne vertébrale des éléments probants. Elles permettent au RSSI d’affirmer : nous avons des règles pour la réception du renseignement, la priorisation, les délais de correctifs, les dérogations et les motifs de retard. C’est la différence entre l’application réactive des correctifs et une remédiation gouvernée.

Changement d’urgence sans perte de contrôle

Les vulnérabilités exploitées connues imposent souvent des changements d’urgence. Attendre la prochaine réunion du comité consultatif des changements peut être négligent. Contourner entièrement la gestion des changements peut être imprudent. La réponse est une maîtrise des changements accélérée et traçable.

La Politique Entreprise de gestion des changements de Clarysec Politique de gestion des changements, également référencée comme P05 Politique de gestion des changements, indique :

Les changements d’urgence peuvent être exécutés avec une approbation verbale accélérée ou déléguée par des rôles autorisés.

Extrait de la section “Exigences de mise en œuvre de la politique”, clause de politique 6.5.1.

Pour les PME, la Politique PME de gestion des changements de Clarysec Politique PME de gestion des changements reconnaît la même réalité opérationnelle :

Les changements d’urgence ou non planifiés peuvent être mis en œuvre immédiatement en réponse à des interruptions critiques ou à des menaces. Toutefois :

Extrait de la section “Traitement des risques et exceptions”, clause de politique 7.4.1.

Le mot “toutefois” est l’endroit où réside la gouvernance. Un changement d’urgence doit malgré tout documenter le déclencheur, les systèmes affectés, la décision de risque, l’approbateur, l’heure de mise en œuvre, le résultat de validation et la revue rétrospective. Zenith Blueprint, phase Controls in Action, Étape 21, décrit la gestion des changements comme un processus reproductible dans lequel les changements sont évalués, autorisés, mis en œuvre et revus. Il rappelle que de nombreux incidents ne sont pas causés par des attaquants, mais par des changements mal maîtrisés : une règle de pare-feu ouverte trop largement, un paramètre de débogage laissé activé ou une dépendance oubliée après une migration.

Pour la remédiation d’une vulnérabilité exploitée connue, les éléments probants minimaux d’un changement d’urgence doivent inclure :

Ce n’est pas de la bureaucratie. C’est la piste d’audit minimale viable pour une décision prise sous pression adverse.

Cartographier CISA KEV et ENISA EUVD avec les éléments probants ISO 27001

ISO 27001:2022 n’impose pas de source spécifique de renseignement sur les menaces. Elle exige que l’organisation identifie les exigences, gère les risques, mette en œuvre les contrôles, conserve les informations documentées et s’améliore. CISA KEV et ENISA EUVD peuvent devenir des entrées faisant autorité dans ce système de management.

Zenith Blueprint, phase Gestion des risques, Étape 13, recommande la traçabilité entre les risques, les contrôles et les clauses :

Référencer les réglementations de manière croisée : si certains contrôles sont mis en œuvre spécifiquement pour se conformer à GDPR, NIS2 ou DORA, vous pouvez l’indiquer soit dans le registre des risques (dans la justification de l’impact du risque), soit dans les notes de la SoA.

Pour une vulnérabilité exploitée connue, l’entrée du registre des risques ne doit pas seulement indiquer “corriger la CVE”. Elle doit identifier la source de la menace, le service affecté, la pertinence réglementaire, le propriétaire du risque, le traitement, les références de contrôle et l’emplacement des éléments probants.

Cartographie de conformité croisée pour NIS2, DORA, GDPR et le reporting de gouvernance

La valeur de la gouvernance pilotée par l’exploitation tient au fait qu’un processus contrôlé peut répondre à plusieurs questions réglementaires. Le même ticket, enregistrement de changement, formulaire de dérogation, courriel fournisseur et analyse de validation peuvent soutenir des récits probants différents lorsqu’ils sont cartographiés délibérément.

NIS2 change la discussion pour les entités essentielles et importantes, car l’Article 20 fait de la cybersécurité une question de responsabilité de l’organe de direction. L’Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, le traitement et la divulgation des vulnérabilités, la cyberhygiène, le contrôle d’accès, la gestion des actifs et l’authentification.

L’Article 23 ajoute une notification échelonnée pour les incidents significatifs, notamment une alerte précoce dans les 24 heures, une notification dans les 72 heures et un rapport final dans le mois suivant la notification de l’incident. Une correspondance CISA KEV ou ENISA EUVD n’est pas automatiquement un incident notifiable. Mais elle doit déclencher une évaluation documentée de l’incident lorsque l’exploitation, une interruption de service, un préjudice client ou un impact sur les données sont plausibles.

DORA ajoute une lecture sectorielle pour les entités financières. Il s’applique depuis le 17 janvier 2025 et exige une gouvernance, une gestion documentée des risques liés aux TIC, des tests, de la résilience, une gestion des incidents et une maîtrise des risques liés aux prestataires tiers de services TIC. L’Article 13 est particulièrement pertinent, car il exige des capacités relatives aux vulnérabilités et au renseignement sur les cybermenaces, aux enseignements tirés et à la surveillance des développements technologiques. L’Article 17 exige un processus de gestion des incidents liés aux TIC qui enregistre les incidents et les cybermenaces significatives, les classe par priorité et gravité, les escalade, identifie les causes racines et rétablit des opérations sécurisées.

Les Articles 28 et 30 de DORA imposent également une discipline fournisseur. Si une plateforme de paiement dépend d’un WAF cloud, d’une base de données gérée, d’un fournisseur d’identité ou d’un moteur de flux de travail SaaS affecté par une vulnérabilité exploitée connue, les éléments probants ne peuvent pas s’arrêter à “le fournisseur dit avoir corrigé”. Ils doivent inclure la notification fournisseur, l’évaluation de criticité, les droits contractuels exercés, les contrôles compensatoires, l’évaluation de l’impact client et la vérification post-remédiation.

GDPR ajoute la question centrée sur les données. L’Article 32 exige la sécurité du traitement, tandis que l’Article 5(2) crée la responsabilité. La revue de la protection des données doit commencer avant la confirmation d’une violation, et non après que l’exfiltration soit prouvée.

Un enregistrement pratique de remédiation KEV et EUVD

Prenons un scénario réaliste. ENISA EUVD et CISA KEV indiquent l’exploitation active d’une vulnérabilité affectant un service de transfert de fichiers exposé à Internet. Le service soutient l’intégration des clients et stocke un volume limité de données à caractère personnel. Un correctif fournisseur existe, mais le propriétaire d’application demande une fenêtre de maintenance et un composant SaaS associé dépend d’une remédiation fournisseur.

Créez un enregistrement unique dans le registre de gouvernance des vulnérabilités avec les champs suivants :

Appliquez ensuite les règles de politique Clarysec :

• Utilisez la Politique Entreprise de gestion des vulnérabilités et des correctifs si vous exploitez une organisation de plus grande taille avec des rôles, SLA et circuits d’escalade formels.
• Utilisez la Politique PME de gestion des vulnérabilités et des correctifs si vous avez besoin d’un modèle léger mais compatible avec les exigences d’audit.
• Utilisez la Politique Entreprise de gestion des changements ou la Politique PME de gestion des changements pour documenter l’approbation d’urgence, les tests, le déploiement et la revue rétrospective.
• Reliez l’enregistrement au registre des risques et à la déclaration d’applicabilité comme recommandé dans Zenith Blueprint, Étape 13.
• Marquez les contrôles dans Zenith Controls comme 5.7, 8.8 et 8.32, puis ajoutez les éléments probants de support pour la gestion des fournisseurs, la gouvernance du cloud, la journalisation, la gestion des incidents et la continuité d’activité lorsque cela est pertinent.

Enfin, conservez les éléments probants d’audit. La Politique Entreprise d’audit et de surveillance de la conformité de Clarysec Politique d’audit et de surveillance de la conformité, également référencée comme P33 Politique d’audit et de surveillance de la conformité, définit un objectif explicite :

Produire des éléments probants défendables et une piste d’audit à l’appui des demandes des autorités de régulation, des procédures juridiques ou des demandes d’assurance de clients.

Extrait de la section “Objectifs”, clause de politique 3.4.

C’est l’objet du processus. Vous ne corrigez pas seulement une vulnérabilité. Vous produisez des éléments probants défendables attestant que l’organisation a agi de manière proportionnée, rapide et contrôlée.

Comment les auditeurs testeront la même décision KEV

Un processus mature de gestion des vulnérabilités exploitées connues doit résister à différents angles d’audit.

Un auditeur ISO 27001:2022 commencera par le domaine d’application du SMSI, les parties intéressées, les obligations réglementaires, la méthode d’appréciation des risques, la déclaration d’applicabilité et les informations documentées. Il demandera si le renseignement sur les menaces est intégré à l’appréciation des risques, si la gestion des vulnérabilités est reproductible, si les changements d’urgence sont maîtrisés, si le risque résiduel est accepté par le bon propriétaire du risque et si les éléments probants sont conservés.

Un évaluateur orienté NIS2 se concentrera sur la responsabilité de la direction, les mesures de gestion des risques de l’Article 21, les vulnérabilités fournisseurs, la gestion des incidents, la continuité d’activité et l’évaluation des incidents significatifs au titre de l’Article 23. Il s’intéressera aux horodatages, aux escalades, aux enregistrements de décision et au fait que les organes de direction aient été informés lorsque cela était approprié.

Un auditeur DORA ou une autorité compétente demandera si le cadre de gestion des risques liés aux TIC a capturé l’actif affecté, la fonction métier, la dépendance et le service tiers. Il attendra une classification des incidents, des enregistrements des cybermenaces significatives, une escalade vers la direction, un suivi des causes racines, des éléments probants fournisseurs, des tests et un suivi de la remédiation.

Un réviseur GDPR demandera si des données à caractère personnel étaient impliquées, si la confidentialité, l’intégrité ou la disponibilité auraient pu être affectées, quelles mesures techniques et organisationnelles étaient en place, si la notification d’une violation a été évaluée et si des éléments probants de responsabilité existent.

Un évaluateur NIST CSF 2.0 peut utiliser le noyau CSF et les profils pour vérifier si les résultats de gouvernance, d’identification, de protection, de détection, de réponse et de rétablissement sont définis et mesurés. Un profil cible pratique pourrait énoncer : “Toutes les vulnérabilités exploitées connues affectant des actifs critiques exposés à Internet sont triées dans les 24 heures, traitées dans les 72 heures ou formellement exceptées avec contrôles compensatoires et approbation du propriétaire du risque.”

Un auditeur COBIT 19 demandera qui est responsable, si les objectifs de gouvernance sont définis, si l’appétence au risque pilote l’urgence, si les indicateurs de performance sont revus, si les dérogations sont surveillées et si les fonctions d’assurance testent le processus de manière indépendante.

Le même enregistrement probant doit répondre à tous. C’est la valeur de l’ingénierie de conformité croisée.

Les indicateurs que le conseil d’administration doit voir

Les conseils d’administration n’ont pas besoin d’une liste de toutes les CVE. Ils ont besoin d’indicateurs de qualité décisionnelle qui montrent l’exposition, la réactivité et le risque résiduel. Pour la gouvernance des vulnérabilités exploitées connues, Clarysec recommande un rapport de direction concis avec :

Ces indicateurs soutiennent la revue de direction ISO 27001, la responsabilité de la direction au titre de NIS2, le reporting des risques TIC DORA et la communication de gouvernance NIST CSF. Ils aident aussi les propriétaires métier à comprendre pourquoi la capacité d’application des correctifs, la qualité de l’inventaire des actifs, les contrats fournisseurs et les fenêtres de maintenance ne sont pas des “détails informatiques”. Ce sont des décisions de résilience.

Schémas d’échec courants à éliminer

Dans les évaluations Clarysec, la gouvernance des vulnérabilités exploitées connues échoue généralement de manière prévisible.

Premièrement, les sources de renseignement sont informelles. Un ingénieur sécurité suit CISA KEV, un autre suit les bulletins fournisseurs, et un troisième s’appuie sur la sortie de l’outil d’analyse. Il n’existe ni registre documenté de renseignement sur les menaces, ni règle de validation, ni propriété claire.

Deuxièmement, la corrélation avec les actifs est faible. L’organisation sait qu’une CVE existe, mais ne peut pas identifier rapidement où le produit est exécuté, s’il est exposé à Internet, qui en est propriétaire, quelles données il traite ou quel fournisseur l’administre.

Troisièmement, le changement d’urgence est soit trop lent, soit trop peu maîtrisé. Les équipes attendent plusieurs jours une approbation, ou elles corrigent la production sans notes de retour arrière, validation ni revue rétrospective.

Quatrièmement, les dérogations sont vagues. “Impossible de corriger en raison de l’impact métier” n’est pas une acceptation du risque. Une dérogation appropriée doit définir la contrainte, les actifs affectés, les contrôles compensatoires, le risque résiduel, l’approbateur, la date d’expiration et la cadence de revue.

Cinquièmement, les éléments probants sont dispersés. Captures d’écran de l’outil d’analyse, approbations dans une messagerie instantanée, courriels fournisseurs, requêtes SIEM et enregistrements de changement se trouvent à des endroits différents. Lors d’un audit ou d’une demande d’une autorité de régulation, l’organisation ne peut pas reconstituer la chronologie de décision.

Le remède n’est pas d’ajouter du bruit. Il consiste à mettre en place un processus unique de gouvernance pilotée par l’exploitation, qui intègre les processus de renseignement, de risque, de changement, d’incident, de fournisseur et de gestion des éléments probants.

Construire votre moteur probant piloté par l’exploitation

Les vulnérabilités exploitées connues resteront une préoccupation opérationnelle à fort volume en 2026. CISA KEV et ENISA EUVD rendent le renseignement sur l’exploitation plus visible, mais la visibilité seule ne satisfait pas les attentes probantes d’ISO 27001:2022, NIS2, DORA ou GDPR. Vous avez besoin d’un processus gouverné qui transforme le renseignement en action et l’action en preuve.

Commencez par quatre actions :

1. Construisez un registre de renseignement sur les menaces avec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, phase Controls in Action, Étape 22.
2. Alignez les règles de politique avec la Politique de gestion des vulnérabilités et des correctifs de Clarysec Politique de gestion des vulnérabilités et des correctifs ou la Politique PME de gestion des vulnérabilités et des correctifs Politique PME de gestion des vulnérabilités et des correctifs.
3. Utilisez Zenith Controls: The Cross-Compliance Guide Zenith Controls pour cartographier 5.7 Renseignement sur les menaces, 8.8 Gestion des vulnérabilités techniques et 8.32 Gestion des changements avec les besoins d’éléments probants ISO, NIS2, DORA, GDPR, NIST et COBIT.
4. Testez un cas KEV ou EUVD réel de bout en bout, depuis la réception jusqu’à la remédiation, la gestion des dérogations, le changement d’urgence, la validation et le rapport à la direction.

Clarysec peut vous aider à transformer cela en un modèle opérationnel fonctionnel et compatible avec les exigences d’audit : politiques, registres, modèles d’éléments probants, cartographies de conformité croisée et reporting au niveau du conseil d’administration, afin de rendre la remédiation pilotée par l’exploitation défendable devant l’auditeur, l’autorité de régulation et vos clients.

Téléchargez Zenith Blueprint, explorez Zenith Controls, ou demandez une évaluation de préparation Clarysec afin de construire votre processus de gouvernance CISA KEV et ENISA EUVD avant que la prochaine vulnérabilité du vendredi ne devienne une question pour le conseil d’administration.