SLA de remédiation des vulnérabilités pour NIS2 et DORA

À 08 h 17, un mardi matin du début de l’année 2026, Anna, RSSI d’une fintech en forte croissance, reçoit le premier message avant même d’avoir terminé son café.

Le centre des opérations de sécurité a signalé des discussions actives sur l’exploitation d’une vulnérabilité dans une passerelle d’API exposée aux clients. L’ingénierie indique que le correctif est disponible, mais risqué, car la passerelle se trouve en amont des flux de paiement. Le responsable conformité transmet une demande formelle d’une autorité nationale compétente sollicitant des éléments probants sur la « gestion et la divulgation des vulnérabilités » ainsi que la preuve de l’efficacité du processus sur les 12 derniers mois. Les achats ajoutent un troisième problème : la passerelle est administrée par un prestataire de services managés (MSP), et le contrat précise seulement que le prestataire appliquera les « mises à jour de sécurité en temps utile ».

À 09 h 00, il ne s’agit plus seulement d’un sujet d’application des correctifs. C’est un sujet d’éléments probants ISO/IEC 27001:2022, d’hygiène cyber NIS2, de gestion des risques liés aux TIC au titre de DORA, de gouvernance fournisseur et, potentiellement, de notification des incidents si l’exploitation affecte la continuité de service ou des données à caractère personnel.

C’est l’écart de conformité opérationnelle auquel de nombreuses organisations seront confrontées en 2026. Elles disposent de scanners, de tableaux de bord, de tickets et d’outils de gestion des correctifs, mais ne savent pas répondre clairement aux questions d’audit :

• Qui a approuvé le SLA de remédiation ?
• En quoi le SLA est-il fondé sur les risques ?
• Que se passe-t-il lorsqu’un correctif critique dépasse l’échéance ?
• Comment les actifs exposés à Internet sont-ils priorisés ?
• Comment les fournisseurs sont-ils soumis aux mêmes délais ?
• Où se trouve l’enregistrement d’acceptation du risque pour un système non corrigé ?
• Quels éléments probants démontrent que le contrôle a fonctionné, et pas seulement qu’il existait ?

La réponse n’est pas une nouvelle feuille de calcul d’échéances. Les SLA de remédiation des vulnérabilités doivent être gérés comme un système de contrôle vivant qui relie la propriété des actifs, la cotation des vulnérabilités, le renseignement sur les menaces, la gestion des changements, les SLA fournisseurs, la gestion des exceptions, la surveillance, la réponse aux incidents et la revue de direction.

C’est là que la Politique de gestion des vulnérabilités et des correctifs Enterprise de Clarysec (VPMP), la Politique de gestion des vulnérabilités et des correctifs pour PME (VPMP-SME), la Politique de sécurité des tiers et des fournisseurs pour PME (TPSSP-SME), Zenith Blueprint (ZB) et Zenith Controls (ZC) deviennent utiles. Ensemble, ils transforment « appliquer les correctifs plus vite » en processus de gouvernance défendable, capable de résister à l’examen d’audit ISO, NIS2, DORA, GDPR, NIST et de type ISACA.

Pourquoi les SLA de remédiation des vulnérabilités sont devenus des éléments probants au niveau du conseil

La remédiation des vulnérabilités était auparavant traitée comme un indicateur d’hygiène informatique. En 2026, elle s’apparente davantage à un engagement réglementé de résilience opérationnelle.

NIS2 fait de la cybersécurité un sujet de responsabilité managériale. Les entités essentielles et importantes doivent faire approuver les mesures de gestion des risques de cybersécurité par leurs organes de direction, en superviser la mise en œuvre et recevoir une formation leur permettant de comprendre les risques ainsi que l’impact des pratiques de sécurité sur les services. NIS2 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 et la maintenance sécurisées, la gestion et la divulgation des vulnérabilités, l’hygiène cyber, la formation, le contrôle d’accès, la gestion des actifs et l’authentification.

Pour les entités financières, DORA constitue le régime spécialisé de résilience opérationnelle. Il exige des dispositifs de gouvernance et de contrôle du risque lié aux TIC, l’organe de direction définissant, approuvant, supervisant et assumant la responsabilité de la gestion des risques liés aux TIC. Il exige également l’identification des actifs TIC et de leurs dépendances, des contrôles de protection et de prévention tels que l’application des correctifs et la gestion des changements, la gestion des incidents liés aux TIC, les tests de résilience opérationnelle numérique et la gestion des risques liés aux tiers prestataires de services TIC.

L’impact pratique est important. Le dépassement d’une échéance de correction peut indiquer une défaillance de :

• Gouvernance, si la direction n’a pas approuvé des SLA fondés sur les risques
• Gestion des actifs, si le propriétaire du système affecté est inconnu
• Gestion des changements, si l’application d’urgence des correctifs n’est pas maîtrisée
• Gestion des fournisseurs, si les délais du prestataire sont vagues
• Réponse aux incidents, si les signes d’exploitation ne sont pas qualifiés
• Gestion des éléments probants, si les tickets et les journaux ne peuvent pas démontrer la clôture
• Traitement des risques, si les exceptions ne sont pas approuvées et revues

ISO/IEC 27001:2022 fournit l’ossature du système de management. Les clauses 4.1 à 4.3 exigent que les organisations comprennent les enjeux internes et externes, les exigences des parties intéressées, les obligations légales et contractuelles et les interfaces avec d’autres organisations. Les clauses 6.1.1 à 6.1.3 exigent l’appréciation des risques, le traitement des risques, une Déclaration d’applicabilité et l’approbation du risque résiduel par le propriétaire du risque. Les clauses 9.1, 9.2, 9.3, 10.1 et 10.2 exigent la surveillance, l’audit interne, la revue de direction, l’amélioration continue, les actions correctives et la conservation des éléments probants.

En clair, si vous voulez que vos SLA de remédiation des vulnérabilités soient auditables, ils doivent faire partie du SMSI, et ne pas rester un simple indicateur DevOps.

Le modèle de SLA que les auditeurs s’attendent à voir

Un SLA de remédiation des vulnérabilités doit répondre à trois questions :

1. Dans quel délai devons-nous agir ?
2. Qui est responsable ?
3. Quels éléments probants démontrent le résultat ?

La Politique de gestion des vulnérabilités et des correctifs définit un point de départ pratique pour des délais de remédiation fondés sur les risques :

L’organisation doit classifier toutes les vulnérabilités détectées selon une méthodologie standardisée (par exemple CVSS v3.x) et appliquer des délais de remédiation alignés sur la criticité métier : 5.2.1 Critique (CVSS 9.0-10.0) : revue immédiate ; délai maximal d’application du correctif de 72 heures. 5.2.2 Élevée (7.0-8.9) : réponse dans les 48 heures ; délai d’application du correctif de 7 jours calendaires. 5.2.3 Moyenne (4.0-6.9) : réponse dans les 5 jours ; délai d’application du correctif de 30 jours calendaires. 5.2.4 Faible (<4.0) : réponse dans les 10 jours ; délai d’application du correctif de 60 jours calendaires.

Cette clause est puissante parce qu’elle distingue le délai de réponse de l’échéance d’application du correctif. Une vulnérabilité élevée ne doit pas rester invisible pendant six jours puis être corrigée le septième jour. Le délai de réponse confirme la qualification, la propriété, l’évaluation d’impact et la planification de la remédiation. L’échéance d’application du correctif confirme la clôture technique ou l’existence d’une exception approuvée.

Pour les organisations plus petites, la Politique de gestion des vulnérabilités et des correctifs pour PME utilise une formulation plus simple, mais toujours auditable :

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

Et pour le parc de correctifs plus large :

Tous les autres correctifs doivent être appliqués dans les 30 jours, sauf si une exception valide est documentée

L’enjeu n’est pas d’imposer des délais identiques à toutes les organisations. ISO/IEC 27001:2022, NIS2 et DORA reposent tous sur la proportionnalité. L’enjeu est que les SLA de remédiation soient définis, approuvés, fondés sur les risques, surveillés et étayés par des éléments probants.

C’est ici que beaucoup d’entreprises échouent. Elles définissent le SLA, mais pas les éléments probants. Du point de vue de l’auditeur, une politique sans enregistrements opérationnels est une promesse, pas un contrôle.

La propriété des actifs est la dépendance cachée

Un scanner peut indiquer qu’une CVE existe sur un serveur. Il ne peut pas dire si ce serveur prend en charge un processus de paiement critique, stocke des données à caractère personnel de catégorie particulière, se connecte à un prestataire de règlement ou est planifié pour mise hors service.

Ce contexte provient de la gestion des actifs, de la classification des données, de l’inventaire des fournisseurs et de l’appréciation des risques.

ISO/IEC 27001:2022 Annexe A contrôle 8.8, Gestion des vulnérabilités techniques, est central, mais il ne fonctionne pas isolément. Il dépend fortement de la gestion des configurations, de la gestion des changements, de la surveillance des fournisseurs, de la gouvernance du cloud, de la journalisation, de la surveillance et du traitement des risques.

NIST CSF 2.0 exprime le même problème en termes de résultats. La fonction GOVERN attend que les exigences de cybersécurité légales, réglementaires et contractuelles soient comprises et gérées, que l’appétence au risque et la tolérance au risque soient documentées, que les rôles et ressources soient attribués et que les politiques de cybersécurité soient établies, appliquées, revues et mises à jour. Les résultats IDENTIFY incluent les inventaires du matériel, des logiciels, des services, des systèmes, des données et des cycles de vie, ainsi que l’identification des vulnérabilités, l’analyse des risques, la gestion des exceptions et les processus de divulgation des vulnérabilités.

Dans le scénario du mardi matin d’Anna, la première question technique est : « où se trouve le composant vulnérable ? » La première question de gouvernance est : « quel service et quel risque affecte-t-il ? »

Le Zenith Blueprint, phase Gestion des risques, Étape 13 : Planification du traitement des risques et Déclaration d’applicabilité, traite ce point en reliant les risques aux contrôles, aux propriétaires et aux échéances :

Attribuez également un propriétaire et une échéance à chaque action (éventuellement dans une colonne distincte ou dans les commentaires). Par exemple : « Propriétaire : responsable informatique, échéance : d’ici le T3 2025. » Cela en fait un véritable plan.

C’est exactement ce qu’exige la remédiation des vulnérabilités. Un constat sans propriétaire devient du bruit dans le backlog. Un constat doté d’un propriétaire, d’une échéance, d’une décision de traitement des risques et d’une piste d’éléments probants devient un contrôle auditable.

Comment Zenith Controls cartographie les relations entre contrôles

Zenith Controls traite le contrôle ISO/IEC 27002:2022 8.8, Gestion des vulnérabilités techniques, comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité. Il le relie aux concepts de cybersécurité Identifier et Protéger, à la capacité opérationnelle de gestion des menaces et des vulnérabilités et aux domaines de sécurité que sont la gouvernance, l’écosystème, la protection et la défense.

C’est important parce que les SLA de remédiation ne sont pas seulement un mécanisme de protection. Ils constituent aussi un mécanisme de gouvernance et un mécanisme écosystémique. Votre exposition est façonnée par les fournisseurs, les plateformes cloud, les services managés, les composants open source et les dépendances exposées à Internet.

Zenith Controls cartographie 8.8 avec plusieurs contrôles de soutien :

Zenith Controls relie également la gestion des vulnérabilités à ISO/IEC 27005:2024, en particulier l’identification des vulnérabilités et les scénarios de risque impliquant des systèmes non corrigés. Cela renforce l’argument selon lequel les échéances d’application des correctifs doivent être fondées sur les risques, et non arbitraires. Il relie aussi la surveillance des fournisseurs à ISO/IEC 27036-4:2016 pour les niveaux de sécurité des accords de services cloud et à ISO/IEC 20000-1:2018 pour la planification de la fourniture de services et la gestion des changements.

Cette structure multi-référentiels compte lors de l’audit. Si une organisation affirme que « les vulnérabilités critiques sont corrigées dans les 72 heures », l’auditeur testera si cette déclaration est étayée par l’appréciation des risques, la classification des actifs, les obligations fournisseurs, les enregistrements de changement et les éléments probants de surveillance.

Hygiène cyber NIS2 : de la gestion des vulnérabilités à l’action corrective

NIS2 Article 21 exige une approche tous risques pour les réseaux et systèmes d’information. Pour les SLA de remédiation des vulnérabilités, plusieurs éléments de Article 21 sont directement pertinents :

• Analyse des risques et politiques de sécurité des systèmes d’information
• Gestion des incidents
• Continuité d’activité et gestion de crise
• Sécurité de la chaîne d’approvisionnement
• Acquisition, développement et maintenance sécurisés, y compris la gestion et la divulgation des vulnérabilités
• Procédures d’évaluation de l’efficacité de la cybersécurité
• Hygiène cyber de base et formation
• Contrôle d’accès et gestion des actifs
• Authentification multifacteur ou authentification continue lorsque cela est approprié

NIS2 Article 20 rend les organes de direction responsables de l’approbation et de la supervision des mesures de gestion des risques de cybersécurité. Cela signifie que les métriques de remédiation des vulnérabilités ne peuvent pas rester uniquement dans un tableau de bord d’ingénierie. Elles doivent apparaître dans les rapports de direction, les dossiers du comité des risques ou les enregistrements de revue de direction du SMSI.

Article 21 attend également des entités qui identifient une non-conformité aux mesures requises qu’elles prennent des actions correctives sans retard injustifié. Cette formulation est importante. Si votre tableau de bord affiche des vulnérabilités critiques en retard, les éléments probants de conformité ne doivent pas s’arrêter à « nous le savons ». Ils doivent montrer l’escalade, la revue du risque, la visibilité donnée à la direction, l’action corrective et la réévaluation.

NIS2 Article 23 ajoute une autre dimension. Si l’exploitation d’une vulnérabilité non corrigée provoque, ou est susceptible de provoquer, une perturbation opérationnelle grave, une perte financière ou un préjudice à d’autres personnes, elle peut devenir un incident significatif. Le cycle de notification comprend une alerte précoce dans les 24 heures suivant la prise de connaissance de l’incident significatif, une notification d’incident dans les 72 heures, des rapports intermédiaires sur demande et un rapport final dans un délai d’un mois après la notification de l’incident. Ce rapport final doit inclure la gravité, l’impact, la cause racine probable, les mesures d’atténuation et l’impact transfrontalier le cas échéant.

Le processus de SLA doit donc être relié à la réponse aux incidents. Une vulnérabilité critique assortie d’éléments probants d’exploitation active doit déclencher une qualification de sécurité, une surveillance, la conservation des éléments probants et une évaluation de notification, et pas seulement un ticket de correctif courant.

Risque lié aux TIC DORA : les délais de remédiation comme preuve de résilience

Pour les entités financières, DORA s’applique depuis le 17 janvier 2025 et crée des exigences uniformes en matière de gestion des risques liés aux TIC, de notification des incidents majeurs liés aux TIC, de tests de résilience opérationnelle numérique, de partage d’informations et de gestion des risques liés aux tiers prestataires de services TIC. Il est traité comme l’acte juridique sectoriel de l’UE applicable aux entités financières couvertes identifiées au titre des règles nationales NIS2.

Le modèle opérationnel de DORA est proche d’un SMSI intégré. Articles 5 et 6 exigent la gouvernance, des politiques, des procédures, des outils, une revue annuelle ou périodique, l’audit, la remédiation des constats d’audit critiques et une stratégie de résilience opérationnelle numérique. Article 8 exige l’identification et l’inventaire des fonctions métier soutenues par les TIC, des actifs informationnels, des actifs TIC, des dépendances, des processus tiers et des risques liés aux TIC hérités. Article 9 exige des contrôles de protection et de prévention, notamment l’application des correctifs et la gestion des changements. Articles 11 et 12 exigent la continuité, la réponse, le rétablissement, la sauvegarde, la restauration et les objectifs de reprise.

DORA Articles 17 à 19 exigent un processus de gestion des incidents liés aux TIC qui détecte, gère, enregistre, classifie, escalade, notifie, communique, analyse la cause racine et rétablit des opérations sécurisées. Articles 24 à 26 exigent des tests de résilience opérationnelle numérique, notamment des tests appropriés des outils et systèmes TIC, des évaluations de vulnérabilités, des évaluations de sécurité réseau, des analyses d’écarts, des revues de code source lorsque cela est possible, des tests d’intrusion et des tests d’intrusion fondés sur la menace pour certaines entités financières. Articles 28 et 30 exigent la gestion du risque lié aux tiers prestataires de services TIC, des registres des contrats de services TIC, la diligence raisonnable, des droits d’audit et d’inspection, des niveaux de service, l’assistance du prestataire pendant les incidents, des droits de résiliation et des dispositifs de sortie.

Pour les SLA de remédiation, DORA modifie les attentes en matière d’éléments probants de trois façons.

Premièrement, les constats de vulnérabilité issus des tests doivent alimenter un processus de remédiation priorisé. Un rapport de scan ne suffit pas.

Deuxièmement, la remédiation des constats critiques doit être suivie par la gouvernance et l’audit. DORA attend une remédiation formelle des constats d’audit critiques pour les entités autres que les microentreprises.

Troisièmement, les prestataires tiers de services TIC doivent être soumis à des obligations mesurables. Si votre fournisseur cloud, SaaS ou MSP contrôle la fenêtre d’application des correctifs, votre contrat et votre registre doivent montrer comment ses délais de remédiation soutiennent vos obligations de résilience.

La Politique de gestion des vulnérabilités et des correctifs traite ce point directement :

Application des correctifs par les tiers et supervision des risques SaaS 6.6.1 Tous les systèmes tiers (SaaS, PaaS, administrés par un MSP) doivent démontrer des contrôles adéquats de gestion des vulnérabilités et des correctifs. 6.6.2 Les SLA fournisseurs doivent inclure des délais de remédiation équivalents aux seuils internes définis sur la base de la criticité.

Cette clause constitue souvent le pont manquant entre les éléments probants ISO internes et la supervision des fournisseurs au titre de DORA.

GDPR : quand les retards de correctifs deviennent des défaillances de responsabilité sur les données à caractère personnel

GDPR n’est pas une norme de gestion des vulnérabilités, mais il modifie les conséquences d’un échec d’application des correctifs.

GDPR Article 5 exige que les données à caractère personnel soient traitées de manière sécurisée et impose au responsable du traitement d’être en mesure de démontrer la conformité. Article 32 exige des mesures techniques et organisationnelles appropriées pour garantir un niveau de sécurité adapté au risque. Lorsque des systèmes non corrigés traitent des données à caractère personnel, en particulier des données d’identité, des données financières, des données biométriques, des données de santé, des données d’emploi ou des informations KYC, les SLA de remédiation deviennent partie intégrante de la responsabilité relative à la sécurité du traitement.

Un retard d’application d’un correctif peut être défendable si le risque a été évalué, si des contrôles compensatoires ont été appliqués et si le risque résiduel a été accepté par la personne appropriée. Il est beaucoup plus difficile à défendre si la vulnérabilité était en retard, exposée à Internet et sans propriétaire.

Zenith Controls cartographie la gestion des vulnérabilités avec GDPR Articles 32 et 5(1)(f), car l’application des correctifs en temps utile réduit les risques pesant sur la confidentialité et l’intégrité des données à caractère personnel. Il cartographie également la gestion des changements avec GDPR Article 24 et Article 32, car les changements apportés aux systèmes traitant des données à caractère personnel doivent être appréciés au regard des risques, approuvés, documentés et revus.

La leçon de conformité est simple : si des données à caractère personnel sont concernées, vos éléments probants d’application des correctifs doivent inclure le contexte des données. Les auditeurs et les autorités de régulation ne demanderont pas seulement « le correctif a-t-il été appliqué ? », mais aussi « quelles données ont été exposées au risque, pendant combien de temps, et quels contrôles ont réduit ce risque ? »

Un workflow Clarysec pratique pour des éléments probants de SLA auditables

Un processus mature de remédiation des vulnérabilités ne commence pas lorsqu’un auditeur demande des enregistrements. Il est conçu pour produire des enregistrements chaque mois.

Étape 1 : Approuver la politique de SLA

Commencez par la Politique de gestion des vulnérabilités et des correctifs ou la Politique de gestion des vulnérabilités et des correctifs pour PME, selon votre modèle opérationnel. Adaptez les seuils de SLA à votre appétence au risque, à votre périmètre réglementaire, à la criticité des services, à la sensibilité des données et aux contraintes techniques. Faites approuver la politique par le RSSI, le comité des risques ou l’organe de direction.

Pour les environnements d’entreprise, utilisez le CVSS, la criticité de l’actif, l’exploitabilité, l’exposition à Internet, la sensibilité des données et l’impact métier. Pour les PME, gardez un modèle simple mais explicite : correctifs critiques dans les trois jours, autres correctifs dans les 30 jours sauf exception valide.

Étape 2 : Cartographier les actifs avec les propriétaires et les services critiques

Chaque constat de vulnérabilité doit être rattaché à :

• Nom de l’actif et identifiant unique
• Service métier ou application
• Propriétaire du système
• Propriétaire technique
• Classification des données
• Exposition à Internet
• Dépendance fournisseur, le cas échéant
• Criticité de la fonction prise en charge

Cela soutient la propriété du risque selon ISO/IEC 27001:2022, la gestion des actifs NIS2, l’inventaire des actifs et dépendances TIC DORA et les résultats IDENTIFY du NIST CSF.

Étape 3 : Qualifier la vulnérabilité

Créez un ticket pour chaque constat ou groupe de constats. Incluez le score CVSS, le scanner source, l’actif affecté, le statut d’exploitation, le renseignement sur les menaces, la criticité métier et le SLA requis. Si une exploitation est suspectée, reliez le ticket à une évaluation d’incident.

Étape 4 : Exécuter via la gestion des changements

L’application d’un correctif est un changement. Utilisez un changement standard pour les mises à jour courantes et un changement d’urgence pour les vulnérabilités critiques exploitées. Incluez les éléments probants de test, l’approbation, l’horodatage de mise en œuvre, le plan de retour arrière et la validation post-changement.

Cela correspond à la relation établie par Zenith Controls entre 8.8 et 8.32, où l’application des correctifs est gouvernée par la gestion des changements afin d’équilibrer urgence et stabilité opérationnelle.

Étape 5 : Valider la clôture

Ne clôturez pas les tickets uniquement sur la base de la mention « correctif installé ». Exigez une validation par nouveau scan, confirmation de version, vérification de configuration ou confirmation du contrôle compensatoire. Lorsque le correctif ne peut pas être appliqué, ouvrez une exception.

Étape 6 : Enregistrer les exceptions et le risque résiduel

La Politique de gestion des vulnérabilités et des correctifs définit le contenu requis des exceptions :

Les demandes de dérogation doivent inclure : 7.2.1 La justification métier du retard ou de l’absence de remédiation 7.2.2 L’appréciation des risques (fondée sur le CVSS, la criticité de l’actif et le renseignement sur les menaces) 7.2.3 Les contrôles compensatoires proposés 7.2.4 Le délai de remédiation ou de réévaluation

Elle définit également l’approbation et la revue :

Les exceptions doivent être approuvées par le RSSI ou par le comité des risques délégataire et enregistrées dans le registre des dérogations du SMSI, avec un intervalle de revue ne dépassant pas 90 jours.

Ce registre des dérogations devient un élément probant essentiel pour le traitement des risques et l’acceptation du risque résiduel au titre de ISO/IEC 27001:2022 Clause 6.1.3, ainsi que pour la revue de direction.

Cet enregistrement démontre que l’organisation n’a pas ignoré la vulnérabilité. Elle a évalué le risque, appliqué des contrôles compensatoires, approuvé le risque résiduel et fixé une date de revue.

Étape 7 : Constituer le dossier mensuel d’éléments probants

Votre dossier mensuel d’éléments probants de remédiation des vulnérabilités doit inclure :

Pour les PME, les éléments probants peuvent être plus légers, mais ils doivent rester cohérents. La Politique de gestion des vulnérabilités et des correctifs pour PME exige des journaux des correctifs assurant la traçabilité :

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

Cette clause unique a une forte valeur d’audit. Elle transforme l’application des correctifs d’une affirmation en un enregistrement.

Application des correctifs par les fournisseurs : le contrat doit correspondre à votre SLA

Si un MSP, un fournisseur SaaS, un fournisseur PaaS ou un fournisseur de services cloud contrôle le déploiement des correctifs, les SLA internes sont inutiles sauf si les obligations fournisseurs leur correspondent.

La Politique de sécurité des tiers et des fournisseurs pour PME inclut les obligations de sécurité de l’information comme exigence de gouvernance. Pour la remédiation des vulnérabilités, ces obligations doivent devenir des clauses contractuelles mesurables :

• Fenêtres de notification des vulnérabilités critiques
• Délais de remédiation critiques, élevés, moyens et faibles
• Processus de changement d’urgence
• Exigences d’approbation client en cas d’indisponibilité
• Format des éléments probants d’achèvement des correctifs
• Processus de divulgation des vulnérabilités
• Obligations d’assistance en cas d’incident
• Droit d’audit ou de réception de rapports d’assurance
• Obligations d’application des correctifs des sous-traitants ultérieurs ou sous-traitants
• Support de sortie et de transition pour les services critiques

Le Zenith Blueprint, phase Contrôles en action, Étape 20, Contrôle 8.21 Sécurité des services réseau, énonce clairement le principe :

Lorsque les services sont fournis par des tiers, notamment des FAI, des fournisseurs SD-WAN ou des fournisseurs de cloud privé, les exigences de sécurité doivent être intégrées dans les contrats et les SLA. Cela inclut les garanties de disponibilité, les temps de réponse aux incidents, les obligations d’application des correctifs ou d’atténuation des vulnérabilités et des limites claires de traitement des données. Vous ne devez jamais supposer qu’un prestataire répond à vos attentes si cela n’est pas écrit, mesurable et auditable.

DORA rend ce point particulièrement important pour les entités financières. Les accords avec les tiers prestataires de services TIC doivent inclure les niveaux de service, l’assistance du prestataire pendant les incidents TIC, l’accès aux données et leur récupération, la coopération avec les autorités, les droits de résiliation et des dispositions renforcées pour les fonctions critiques ou importantes, notamment la surveillance, les droits d’audit, les plans de continuité et les mesures de sécurité.

NIST CSF 2.0 dit la même chose à travers les résultats relatifs aux risques de chaîne d’approvisionnement : les fournisseurs doivent être connus, priorisés selon leur criticité, évalués avant l’engagement, encadrés par des exigences contractuelles, surveillés pendant toute la relation, intégrés à la planification des incidents et gérés lors de la fin de la relation.

Ce que les auditeurs demanderont réellement

La conversation d’audit change selon le profil de l’auditeur.

Un auditeur ISO/IEC 27001:2022 commencera par le SMSI. Il vérifiera si la gestion des vulnérabilités est incluse dans la Déclaration d’applicabilité, si l’appréciation des risques identifie les systèmes non corrigés comme un risque, si les plans de traitement des risques ont des propriétaires et des échéances, si le contrôle 8.8 de l’Annexe A est mis en œuvre, si les éléments probants sont conservés et si l’audit interne et la revue de direction évaluent la performance.

Le Zenith Blueprint, phase Contrôles en action, Étape 19, rend explicite l’attente d’audit :

Il s’agit d’un contrôle prioritaire pour les auditeurs, qui l’examineront généralement en profondeur. Attendez-vous à ce qu’ils demandent à quelle fréquence les systèmes sont corrigés, quel processus vous suivez lorsqu’une vulnérabilité zero-day est annoncée et quels systèmes sont les plus difficiles à corriger.

Il poursuit avec des attentes pratiques en matière d’éléments probants :

Les auditeurs demanderont probablement les résultats des scans de vulnérabilités. Si vous utilisez des outils comme Nessus, OpenVAS ou Qualys, exportez un rapport montrant les vulnérabilités récemment détectées et la façon dont elles ont été traitées. Idéalement, celui-ci doit inclure les niveaux de risque (CVSS) et les délais de remédiation.

Un auditeur ou une autorité compétente centrés sur NIS2 recherchera l’approbation par le conseil, la proportionnalité, l’hygiène cyber, la gestion des vulnérabilités, la sécurité des fournisseurs, la gestion des incidents, l’évaluation de l’efficacité, l’action corrective sans retard injustifié et les enregistrements de décision de notification si l’exploitation a causé un impact significatif.

Un superviseur DORA testera si les constats de vulnérabilité sont intégrés à la gestion des risques liés aux TIC, aux tests de résilience opérationnelle numérique, à la classification des incidents, à l’analyse de la cause racine, aux registres des tiers, aux obligations contractuelles, aux droits d’audit et à la remédiation des constats critiques.

Un évaluateur NIST CSF organisera probablement la revue autour de GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND et RECOVER. Il demandera si les exigences légales et contractuelles sont comprises, si la tolérance au risque est documentée, si les vulnérabilités sont identifiées et priorisées, si les exceptions sont gérées, si la surveillance détecte l’exploitation et si les actions de réponse et de rétablissement sont coordonnées.

Un auditeur COBIT 2019 ou de type ISACA se concentrera sur les objectifs de gouvernance, la capacité des processus, les pratiques de management, les métriques, la propriété, la conception des contrôles, le fonctionnement des contrôles et la suffisance des éléments probants. Il demandera si la remédiation des vulnérabilités est répétable, mesurée, escaladée, améliorée et alignée sur les objectifs de l’entreprise et l’appétence au risque.

Escalade et métriques : comment prouver que le SLA est géré

Un SLA sans escalade n’est qu’une cible. Un programme défendable de remédiation des vulnérabilités nécessite une escalade avant le dépassement, au moment du dépassement et après les échecs répétés.

Clarysec recommande un modèle d’escalade à quatre niveaux :

1. Escalade opérationnelle, le propriétaire du ticket et le responsable technique sont notifiés avant le dépassement.
2. Escalade du risque, le propriétaire de l’actif et le propriétaire du risque examinent l’impact lorsque le dépassement est probable.
3. Escalade de gouvernance de la sécurité, le RSSI ou le comité des risques approuve l’exception ou l’action d’urgence.
4. Escalade vers la direction, les dépassements de SLA répétés ou critiques sont présentés en revue de direction avec des actions correctives.

La Politique de gestion des vulnérabilités et des correctifs renforce cette attente d’audit :

Des audits périodiques doivent être menés par l’audit interne ou par un tiers indépendant afin de vérifier : 5.6.1 La conformité aux SLA 5.6.2 Les éléments probants de la priorisation fondée sur les risques 5.6.3 L’efficacité des correctifs déployés 5.6.4 Les contrôles portant sur les systèmes non corrigés

Les métriques doivent soutenir les décisions, et non décorer les tableaux de bord. Les métriques les plus solides en 2026 incluent :

• Pourcentage de conformité aux SLA critiques
• Pourcentage de conformité aux SLA élevés
• Délai moyen de qualification
• Délai moyen de remédiation par classe d’actifs
• Nombre de vulnérabilités critiques en retard
• Nombre d’exceptions acceptées par ancienneté
• Exceptions dépassant 90 jours
• Nombre d’expositions critiques exposées à Internet
• Dépassements de SLA fournisseurs
• Vulnérabilités rouvertes après validation
• Changements d’urgence causés par des vulnérabilités exploitées
• Échecs de correctifs par plateforme ou unité métier

Reliez ces métriques à ISO/IEC 27001:2022 Clause 9.3 relative à la revue de direction, aux rapports de gouvernance DORA et à la supervision de la direction au titre de NIS2. Pour NIST CSF 2.0, utilisez-les pour mettre à jour les profils actuels et cibles, l’analyse des écarts et les plans d’action.

La liste de contrôle Clarysec pour les SLA de remédiation

Utilisez cette liste de contrôle pour évaluer votre programme actuel :

• Existe-t-il une politique approuvée de gestion des vulnérabilités et des correctifs ?
• Les SLA de remédiation sont-ils définis selon la gravité et la criticité métier ?
• Les vulnérabilités exposées à Internet et exploitées sont-elles accélérées ?
• Les actifs sont-ils cartographiés avec leurs propriétaires, services, données et fournisseurs ?
• Les constats des scanners sont-ils convertis en tickets attribués ?
• Les correctifs sont-ils exécutés via la gestion des changements ?
• Les changements d’urgence sont-ils documentés et revus ?
• Les résultats de remédiation sont-ils validés par de nouveaux scans ou des contrôles de version ?
• Les exceptions font-elles l’objet d’une appréciation des risques, d’une approbation et d’une revue au moins tous les 90 jours ?
• Les contrôles compensatoires sont-ils documentés pour les systèmes non corrigeables ?
• Les contrats fournisseurs sont-ils alignés sur les seuils internes de remédiation ?
• Les journaux des correctifs sont-ils suffisamment complets pour prouver ce qui s’est produit et quand ?
• Les dépassements de SLA sont-ils escaladés et corrigés ?
• Les métriques sont-elles revues par la direction ?
• Les incidents et les évaluations de violation sont-ils déclenchés lorsqu’une exploitation est suspectée ?

Si plusieurs réponses sont « non », le problème n’est pas l’outillage. C’est la conception des contrôles.

Prochaines étapes : transformer les échéances de correctifs en résilience auditable

En 2026, les SLA de remédiation des vulnérabilités doivent faire plus que satisfaire un tableau de bord de scanner. Ils doivent prouver que votre organisation sait identifier l’exposition, prioriser le risque, agir dans des délais approuvés, maîtriser les exceptions, gouverner les fournisseurs et documenter ses décisions au regard des attentes d’audit ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT 2019.

Clarysec peut vous aider à passer de tickets de correctifs fragmentés à un programme intégré de remédiation des vulnérabilités piloté par les éléments probants, en utilisant :

• Politique de gestion des vulnérabilités et des correctifs
• Politique de gestion des vulnérabilités et des correctifs pour PME
• Politique de sécurité des tiers et des fournisseurs pour PME
• Zenith Blueprint : feuille de route en 30 étapes pour auditeurs
• Zenith Controls : guide de conformité croisée

Commencez par un service à haut risque. Cartographiez ses actifs, fournisseurs, vulnérabilités, tickets, changements, exceptions et éléments probants. Soumettez-le ensuite aux questions d’audit. Si vous ne pouvez pas prouver le SLA de la détection à la clôture, c’est votre premier projet de remédiation.

L’objectif n’est pas une application parfaite des correctifs. L’objectif est une remédiation gouvernée, fondée sur les risques, mesurable et auditable. Téléchargez les modèles de politiques Clarysec, réalisez une évaluation ciblée des écarts ou réservez une démonstration Clarysec pour transformer la remédiation des vulnérabilités d’une pression d’audit en résilience opérationnelle.