Identifier un écart lors d’un audit n’est que le début de la remédiation. Un plan de remédiation cybersécurité réellement pilotable doit conserver le lien entre le constat initial, l’action décidée, son responsable, son échéance, la preuve de réalisation puis la validation de cette preuve. La clôture ne devrait intervenir qu’après vérification du résultat attendu. Pour les sujets importants, une étape supplémentaire est nécessaire : contrôler quelques semaines ou quelques mois plus tard que la correction reste efficace. Cette chaîne évite deux erreurs fréquentes : clôturer une action parce que son responsable déclare qu’elle est terminée, ou laisser indéfiniment des constats ouverts alors que le problème a effectivement été corrigé.
La logique à retenir est simple :
Un écart n’est pas clôturé parce qu’une tâche est terminée. Il est clôturé lorsque la correction prévue est démontrée et validée.
Et, lorsqu’un risque significatif le justifie :
La remédiation n’est réellement maîtrisée que lorsque son efficacité a été vérifiée.
Un plan de remédiation organise le traitement des faiblesses identifiées lors :
Il ne doit pas être confondu avec le rapport d’audit.
Le rapport répond principalement à :
Qu’avons-nous observé ?
Le plan de remédiation répond à :
Que faisons-nous maintenant, qui en est responsable et comment vérifierons-nous que le problème est traité ?
Cette logique apparaît explicitement dans le ReCyF 2.5 de l’ANSSI. Pour chaque système d’information, l’entité doit identifier les écarts puis établir, mettre en œuvre et suivre dans la durée un plan d’action destiné à les corriger. Ce plan prévoit au minimum une échéance raisonnable et un responsable pour chaque action.
Pour les audits de sécurité applicables aux entités essentielles dans le ReCyF, l’ANSSI prévoit également que les non-conformités et vulnérabilités identifiées alimentent un plan d’action destiné à les corriger.
Le NIST utilise une logique comparable avec le Plan of Action and Milestones : après l’évaluation des contrôles, les déficiences donnent lieu à des actions de remédiation et à un plan permettant d’en suivre le traitement. Le RMF prévoit ensuite que les changements résultant de la remédiation soient intégrés à la situation de sécurité du système.
Ces termes sont souvent utilisés comme synonymes alors qu’ils ne recouvrent pas exactement la même idée.
La terminologie ISO distingue notamment :
Correction
action destinée à supprimer une non-conformité détectée.
Action corrective
action destinée à éliminer la cause d’une non-conformité afin d’empêcher qu’elle se reproduise.
Cette distinction est présente dans la terminologie publique ISO relative aux systèmes de management.
Un ancien salarié possède encore un compte actif.
Correction immédiate :
désactiver le compte.
Le problème observé disparaît.
Mais si la cause est un processus d’offboarding incomplet, le même écart peut réapparaître le mois suivant.
Action corrective :
intégrer systématiquement la révocation des accès au processus de départ, attribuer un responsable et contrôler périodiquement les comptes orphelins.
La deuxième action traite la cause.
Dans un plan de remédiation cybersécurité, les deux dimensions peuvent être nécessaires.
| Niveau | Question | Exemple |
| Correction | Comment supprimer immédiatement l’écart observé ? | Désactiver le compte |
| Action corrective | Comment éviter qu’il se reproduise ? | Corriger l’offboarding |
| Contrôle d’efficacité | Comment vérifier que la correction fonctionne dans le temps ? | Rechercher à nouveau les comptes orphelins lors de la prochaine revue |
Cette distinction est particulièrement importante pour une correction d’écart ISO 27001 : traiter le symptôme sans examiner sa cause peut conduire à revoir exactement la même non-conformité lors de l’audit suivant.
Un workflow robuste comporte huit étapes.
| Étape | Question à résoudre | Résultat attendu |
| 1. Constat | Quel est précisément l’écart ? | Constat validé |
| 2. Décision | Que décide-t-on d’en faire ? | Traitement choisi |
| 3. Action | Que faut-il réellement réaliser ? | Action exploitable |
| 4. Pilotage | Qui, pour quand, avec quelles dépendances ? | Responsable et échéance |
| 5. Réalisation | Le travail prévu a-t-il été exécuté ? | Action terminée |
| 6. Preuve | Peut-on démontrer le nouveau résultat ? | Preuve de clôture |
| 7. Validation | La preuve répond-elle au constat d’origine ? | Clôture acceptée ou rejetée |
| 8. Efficacité | La correction reste-t-elle effective ? | Contrôle ultérieur |
Cette dernière étape est souvent oubliée.
Or le NIST définit justement l’évaluation d’un contrôle par sa capacité à déterminer s’il est correctement mis en œuvre, fonctionne comme prévu et produit le résultat attendu.
La remédiation doit toujours rester reliée au constat qui l’a déclenchée.
Ne créez pas simplement :
ACT-048 - Mettre en place MFAsans conserver le contexte.
Quelques mois plus tard, personne ne saura nécessairement :
Une fiche de remédiation devrait donc conserver au minimum :
| Champ | Exemple |
| Audit | Audit interne juin 2026 |
| Référentiel | ISO 27001 / référentiel interne |
| Mesure | Gestion des accès privilégiés |
| Constat | MFA absent sur deux interfaces d’administration |
| Preuve initiale | Export des comptes + configurations |
| Risque | Compromission d’un compte privilégié |
| Qualification | Écart prioritaire |
| Date du constat | 18/06/2026 |
La remédiation devient alors traçable jusqu’à sa source.
Le constat décrit la situation au moment de l’audit.
Une fois la correction réalisée, il ne faut pas réécrire :
« MFA absent »
en :
« MFA désormais en place ».
Sinon, vous perdez l’historique de ce qui avait réellement été observé.
Conservez plutôt :
Constat initial
→ action
→ preuve de correction
→ statut clôturé
→ nouvelle évaluation.
Un constat ne conduit pas systématiquement à une correction immédiate.
La décision peut être :
L’essentiel est que la décision soit explicite.
Une application historique ne supporte pas le MFA.
Remplacer immédiatement l’application.
Appliquer une mesure compensatoire temporaire :
Puis prévoir son remplacement au prochain exercice budgétaire.
Dans le plan :
Décision : traitement différé avec mesure compensatoire jusqu’au remplacement de l’application.
Le constat reste ouvert ou fait l’objet d’un statut spécifique jusqu’à la réalisation de la trajectoire décidée.
L’acceptation est une décision de gouvernance.
Elle ne signifie pas que la faiblesse a disparu.
Un statut tel que :
Risque accepté
est généralement plus fidèle que :
Clôturé - corrigé.
Une action doit décrire ce que quelqu’un peut réellement exécuter.
Améliorer la gestion des sauvegardes.
Réaliser un test de restauration.
Restaurer une sauvegarde récente de l’ERP dans un environnement isolé, vérifier l’intégrité des données, mesurer la durée de restauration et consigner les anomalies rencontrées.
La troisième formulation facilite immédiatement :
Un constat :
« Les comptes privilégiés sont insuffisamment maîtrisés »
peut produire plusieurs actions :
A1 - Recenser les comptes privilégiés
A2 - Identifier leurs propriétaires
A3 - Séparer les comptes standards et administrateurs
A4 - Déployer le MFA
A5 - Mettre en place une revue périodique
La remédiation devient alors un petit chantier plutôt qu’une tâche artificiellement large.
Une action n’est pilotable que lorsque quelqu’un en répond.
Le ReCyF 2.5 est explicite : le plan de correction des écarts doit comporter au minimum une échéance raisonnable et un responsable pour chaque action.
Évitez :
Responsable : DSI / RSSI / prestataire / RH.
Préférez :
Responsable : responsable infrastructure
Contributeur : MSP
Validation : RSSI
Le responsable ne doit pas nécessairement effectuer toutes les tâches.
Il doit être celui qui répond de leur progression.
L’échéance doit dépendre :
Un correctif simple portant sur un accès administrateur exposé ne devrait pas nécessairement attendre le même délai qu’une refonte d’architecture.
Lorsqu’une action initialement prévue au :
30/09/2026
est repoussée au :
30/11/2026
conservez :
Sinon, une action peut rester en retard pendant un an tout en apparaissant toujours « dans les délais ».
Une action peut dépendre :
Exemple :
A2 - Déployer le MFA
dépend de :
A1 - Recenser les comptes à privilèges.
Cette relation doit être visible.
Le responsable doit pouvoir mettre à jour l’action pendant sa réalisation.
Un workflow simple suffit généralement.
| Statut | Signification |
| À faire | Action approuvée mais non commencée |
| En cours | Travail réellement commencé |
| Bloqué | Une dépendance empêche l’avancement |
| À valider | Le responsable estime l’action terminée |
| Clôturé | Le résultat a été vérifié et accepté |
| Risque accepté | Pas de correction décidée, décision tracée |
| Abandonné | Action annulée avec justification |
Le statut À valider est particulièrement important.
Sans lui, beaucoup de workflows passent directement de :
En cours
à :
Clôturé.
Le responsable de l’action devient alors juge de sa propre remédiation.
Lorsqu’elle satisfait trois conditions :
Le statut signifie :
« Je considère mon action terminée ; elle doit maintenant être vérifiée. »
Il ne signifie pas :
« Le constat est officiellement clôturé. »
Cette séparation améliore fortement le suivi de remédiation d’audit.
La preuve de clôture répond à une question très précise :
Qu’est-ce qui démontre que la situation ayant produit le constat a réellement changé ?
Elle devrait être définie dès la création de l’action.
Le MFA n’est pas généralisé aux comptes administrateurs.
Déployer le MFA.
Ticket MFA deployment completed.Le ticket montre surtout que quelqu’un considère le travail terminé.
L’auditeur ou le valideur peut alors rapprocher :
population attendue
et
population protégée.
| Action | Preuve de clôture pertinente |
| Réviser les droits d’accès | Population examinée + compte rendu + anomalies traitées |
| Tester une restauration | Rapport de test avec résultat et anomalies |
| Corriger un serveur | Export ou vérification de configuration après correction |
| Formaliser une procédure | Document validé et versionné |
| Réaliser une sensibilisation | Support + population + suivi de participation |
| Supprimer des comptes obsolètes | Export après suppression |
| Revoir un fournisseur | Évaluation datée et décision |
| Corriger une vulnérabilité | Scan ou test démontrant sa disparition |
La preuve doit démontrer le résultat, pas seulement l’activité réalisée.
La validation est le point de contrôle central.
Le valideur doit revenir au constat initial et poser quatre questions.
Une correction réalisée sur 90 postes ne clôt pas nécessairement un constat portant sur 120 postes.
Une ancienne capture ne permet pas de confirmer une nouvelle configuration.
Installer une solution ne signifie pas nécessairement qu’elle fonctionne.
Un constat peut concerner à la fois :
Déployer le MFA ne corrige que la première partie.
Cette matrice peut être utilisée directement par un RSSI ou un consultant.
| Action réalisée ? | Preuve disponible ? | Résultat conforme ? | Décision |
| Non | Non | Non | Rester ouvert |
| Oui | Non | Inconnu | À valider / preuve requise |
| Oui | Oui | Non | Réouvrir ou créer une action complémentaire |
| Oui | Oui | Partiellement | Clôture refusée / remédiation complémentaire |
| Oui | Oui | Oui | Clôture possible |
| Non applicable | Décision formelle | Risque accepté | Statut “risque accepté”, pas “corrigé” |
Cette grille évite une grande partie des fausses clôtures.
Cela dépend du niveau de risque.
Pour une petite action :
responsable IT → vérification par RSSI ou consultant.
Pour une action plus critique :
responsable opérationnel → RSSI → éventuellement propriétaire du risque.
Pour certaines corrections techniques, un contrôle indépendant peut être préférable :
Il serait disproportionné d’exiger une indépendance complète pour chaque tâche mineure.
La profondeur de validation doit rester proportionnée au risque.
C’est l’étape qui distingue une véritable remédiation d’un simple suivi de tickets.
Le NIST définit l’évaluation de l’efficacité d’un contrôle à partir de trois dimensions :
Cette logique constitue le cœur du NIST RMF et de SP 800-53A.
NIS2 comporte également parmi ses mesures de gestion des risques des politiques et procédures permettant d’évaluer l’efficacité des mesures de cybersécurité mises en œuvre.
Les droits ne sont pas revus.
Mettre en place une revue trimestrielle.
Première revue réalisée le 30 septembre.
Peut-on clôturer ?
Oui, potentiellement, si le constat portait sur l’absence de processus et que la première exécution démontre sa mise en place.
Mais trois mois plus tard, le contrôle d’efficacité peut vérifier :
Si aucune nouvelle revue n’a eu lieu, la mesure a été lancée mais n’est pas réellement pérenne.
| Contrôle | Question |
| Validation de clôture | Avons-nous corrigé le problème identifié ? |
| Contrôle d’efficacité | La correction continue-t-elle à produire l’effet attendu ? |
Toutes les actions ne nécessitent pas nécessairement une seconde vérification formelle.
Elle est particulièrement pertinente lorsque :
Il n’existe pas de délai universel.
La bonne date dépend de la nature du contrôle.
| Remédiation | Contrôle d’efficacité pertinent |
| MFA généralisé | Revue de couverture lors de la prochaine revue IAM |
| Revue trimestrielle des droits | Contrôler l’exécution du cycle suivant |
| Test de restauration | Nouveau test selon le programme prévu |
| Sensibilisation | Mesurer participation ou résultat de la campagne suivante |
| Correctifs | Vérifier que les nouveaux correctifs suivent désormais le processus |
| Offboarding | Examiner les prochains départs |
| Gestion des incidents | Vérifier sur le prochain incident ou lors d’un exercice |
| Processus fournisseur | Contrôler la prochaine nouvelle évaluation |
L’objectif n’est pas de maintenir artificiellement toutes les remédiations ouvertes.
Une action peut être clôturée, puis faire l’objet d’un contrôle d’efficacité planifié séparément.
Ne modifiez pas simplement la preuve précédente.
Conservez l’historique.
Exemple :
Écart identifié.
Action réalisée et clôturée.
Contrôle d’efficacité : nouvelle dérive constatée.
Créez alors :
L’information importante devient :
La première remédiation n’a pas permis d’empêcher la récurrence.
Cette donnée est utile pour :
ISO définit justement l’action corrective comme une action portant sur la cause afin d’éviter la récurrence, ce qui distingue clairement une correction ponctuelle d’une remédiation durable.
Pour la plupart des PME, ETI ou missions de consultant, un modèle comme celui-ci suffit.
| Champ | Utilité |
| ID | Identifier la remédiation |
| Audit / origine | Retrouver la source |
| Mesure / exigence | Conserver le lien avec le référentiel |
| Constat | Situation initiale |
| Risque | Expliquer l’importance |
| Décision | Traiter, accepter, différer… |
| Action | Travail à réaliser |
| Responsable | Propriétaire |
| Contributeurs | Participants |
| Priorité | Ordre de traitement |
| Échéance initiale | Engagement d’origine |
| Échéance révisée | Engagement actuel |
| Dépendances | Blocages et prérequis |
| Effort | Charge interne |
| Coût | Achat ou prestation |
| Statut | État actuel |
| Preuve attendue | Critère de clôture |
| Preuve fournie | Élément réellement reçu |
| Validé par | Contrôle de clôture |
| Date de clôture | Historique |
| Contrôle d’efficacité | Vérification ultérieure |
| Résultat | Efficace / à revoir |
| Commentaire | Justifications et décisions |
Cette structure est volontairement plus riche qu’une simple liste de tâches.
Elle conserve le raisonnement d’audit.
Le dashboard doit permettre d’identifier immédiatement les exceptions.
| Indicateur | Ce qu’il révèle |
| Remédiations ouvertes | Charge restante |
| P1 ouvertes | Exposition importante |
| Actions en retard | Dérive du plan |
| Actions bloquées | Arbitrages nécessaires |
| Actions à valider | Goulot d’étranglement de clôture |
| Preuves manquantes | Corrections non démontrées |
| Clôtures du mois | Progression |
| Contrôles d’efficacité à venir | Pérennité |
| Contrôles d’efficacité échoués | Récurrence des problèmes |
| Délai moyen de clôture | Capacité d’exécution |
Évitez néanmoins de chercher artificiellement un « taux de conformité parfait ».
Une organisation peut réduire fortement son risque tout en ayant encore plusieurs chantiers ouverts.
Une action en retard ne doit pas simplement devenir rouge dans un tableau.
Elle doit déclencher une décision.
Le délai supplémentaire reste-t-il acceptable ?
Le report doit rester traçable.
Une série d’échéances continuellement repoussées constitue elle-même une information de gouvernance utile.
Le ReCyF demande justement que le plan de traitement des écarts soit suivi dans la durée, pas uniquement établi lors de l’évaluation initiale.
Prenons une PME auditée sur ses sauvegardes.
Les sauvegardes des serveurs principaux sont exécutées quotidiennement. Aucun test de restauration documenté n’a toutefois pu être présenté pour les douze derniers mois.
Une sauvegarde techniquement réussie pourrait se révéler inexploitable lors d’un incident réel.
Traiter.
Restaurer une sauvegarde récente de l’ERP dans un environnement isolé, vérifier l’intégrité des données et documenter le résultat.
Responsable infrastructure.
Prestataire IT.
30 octobre 2026.
La date est illustrative.
Rapport de test comprenant :
Test effectué le 14 octobre.
Une première restauration échoue.
Une configuration est corrigée.
Un second test réussit.
Le RSSI examine :
Remédiation validée.
Date : 17 octobre 2026.
Preuve reliée au constat initial.
Le processus prévoit désormais un test annuel.
Le contrôle d’efficacité consistera à vérifier lors du cycle suivant :
La boucle complète est donc :
constat → décision → action → exécution → preuve → validation → clôture → contrôle futur.
Prenons un audit interne ISO/IEC 27001.
Trois comptes appartenant à d’anciens collaborateurs sont encore actifs.
Les trois comptes sont désactivés.
Pas nécessairement.
La question suivante est :
Pourquoi ces comptes sont-ils restés actifs ?
L’analyse révèle que les RH informent l’IT des départs par email sans workflow obligatoire.
La correction technique traite les trois comptes.
Elle ne traite pas la cause.
Créer une procédure d’offboarding comprenant :
Examiner les prochains départs puis vérifier qu’aucun compte orphelin ne subsiste.
Cette logique est précisément celle que cherche à instaurer une démarche de non-conformité et d’action corrective : ne pas seulement corriger l’écart observé, mais réduire sa probabilité de récurrence.
Certaines corrections simples n’exigent pas un workflow lourd.
Exemple :
Une documentation publique contient une ancienne adresse email de contact sécurité.
Adresse mise à jour.
Page corrigée vérifiée.
Faible, aucun problème systémique identifié.
La clôture peut être rapide.
Il serait disproportionné d’imposer :
Le niveau de gouvernance doit rester proportionné au risque.
Une validation plus poussée est pertinente lorsque le constat concerne :
Dans ces situations, la preuve de clôture peut nécessiter :
« C’est fait. »
n’est pas toujours une preuve suffisante.
Demandez ce qui démontre le résultat.
Le responsable peut avoir réalisé ce qui lui était demandé alors que le résultat reste insuffisant.
Vous perdez l’historique de l’audit.
Conservez-le puis ajoutez la remédiation.
Les anciennes actions constituent des preuves de pilotage et permettent de comprendre la trajectoire.
Archivez-les plutôt que de les supprimer.
À la fin du projet, personne ne sait ce qui permettra de valider la correction.
Définissez-la au départ.
Le risque existe toujours.
Utilisez un statut distinct.
La correction fonctionne quelques semaines, puis le même écart réapparaît.
Le plan devient inutilisable.
Clôturez lorsque la correction est démontrée, puis utilisez si nécessaire un contrôle d’efficacité séparé.
Il ne distingue pas :
Une action peut sembler récente alors qu’elle est repoussée depuis un an.
Une PME peut rester simple.
Responsable
→ exécute.
RSSI / consultant
→ valide la preuve.
Responsable
→ exécute.
RSSI
→ contrôle.
Propriétaire du risque
→ accepte la clôture si nécessaire.
Équipe technique
→ corrige.
Auditeur / expert différent
→ reteste.
RSSI / direction
→ décide de la clôture.
L’indépendance absolue n’est pas nécessaire partout.
Le principe est surtout d’éviter une auto-validation trop faible sur les écarts importants.
Ces statuts ne doivent jamais être fusionnés.
| Statut | Signification |
| Clôturé | L’écart a été corrigé et la correction validée |
| Risque accepté | L’écart subsiste mais son maintien a été explicitement accepté |
| Non applicable | Le critère ne s’applique pas au périmètre, justification documentée |
| Faux positif | Le constat initial a été invalidé par de nouveaux éléments |
| Remédié partiellement | Une partie de l’écart subsiste |
| Non évalué | Les éléments ne permettent pas de conclure |
Cette précision améliore considérablement la qualité des dashboards.
Un plan comportant :
92 % des constats « fermés »
est peu significatif si la catégorie « fermé » contient simultanément :
Pour une remédiation importante, conservez :
Ce qui avait été observé.
Pourquoi l’organisation a choisi ce traitement.
Ce qui devait être réalisé.
Dates, reports, changements de responsable et commentaires importants.
Ce qui démontre le nouvel état.
Qui a accepté la clôture et à quelle date.
Lorsqu’il est nécessaire, sa date et son résultat.
Cette chaîne rend la remédiation défendable lors du prochain audit.
L’intérêt d’un outil GRC n’est pas seulement de créer une liste de tâches.
Il est de conserver la relation entre :
audit → mesure → constat → remédiation → tâche → preuve → nouvelle évaluation.
Dans CompliKey, les mesures auditées conservent leurs scores, commentaires, preuves et remédiations.
Le rapport de démonstration illustre déjà cette relation : chaque mesure auditée peut être reliée à ses preuves et aux écarts ou remédiations qui en découlent. Le rapport présente ensuite un plan de remédiation regroupant les observations et recommandations.
Le consultant n’a donc pas besoin de recréer manuellement le contexte dans un tableur indépendant.
L’écart peut alimenter une action suivie.
Le pilotage peut alors conserver :
L’objectif est de passer directement de :
« voici ce qui ne va pas »
à :
« voici ce qui doit maintenant être réalisé ».
Les preuves initiales permettent de comprendre le constat.
Les nouvelles preuves permettent ensuite de démontrer l’évolution de la situation.
Le cycle devient :
preuve d’audit → constat → action → nouvelle preuve.
CompliKey référence les preuves par liens, ce qui permet de conserver les documents sensibles dans l’environnement documentaire choisi par le client.
Un audit représente une situation à une date donnée.
La remédiation ne doit pas effacer cette photographie.
Une évaluation ultérieure permet ainsi de constater :
score initial → écart → remédiation → nouvelle situation.
Cette continuité est particulièrement importante pour les consultants et RSSI externalisés qui suivent leurs clients plusieurs mois après l’audit.
Dans l’espace consultant, cette logique peut être appliquée à plusieurs organisations tout en conservant les espaces clients séparés.
Le consultant peut ainsi concentrer ses revues sur :
CompliKey ne décide pas automatiquement :
Une vérification technique peut nécessiter un autre outil :
CompliKey fournit la traçabilité de gouvernance permettant de relier cette vérification à l’écart initial.
Un bon plan de remédiation cybersécurité ne s’arrête ni à la recommandation de l’auditeur ni au statut « tâche terminée ».
Une remédiation complète suit une chaîne précise :
constat → décision → action → responsable → échéance → réalisation → preuve → validation → clôture → contrôle d’efficacité.
Trois règles permettent d’éviter la majorité des erreurs :
Cette logique rejoint aussi bien l’approche de l’ANSSI, qui demande dans ReCyF de suivre les plans de correction des écarts dans la durée, que celle du NIST, qui associe l’évaluation des contrôles, la remédiation et la vérification de leur efficacité.
La prochaine fois qu’une action passe en « terminée », ne demandez donc pas seulement :
« Le travail a-t-il été fait ? »
Demandez :
« Quelle preuve permet de clôturer le constat initial, et comment saurons-nous que cette correction fonctionne encore dans trois ou six mois ? »
Un plan de remédiation cybersécurité organise le traitement des écarts, faiblesses ou vulnérabilités identifiés lors d’un audit ou d’une évaluation. Il relie chaque constat à une décision, une ou plusieurs actions, un responsable et une échéance. Pour être réellement exploitable, il doit également prévoir la preuve permettant de valider la correction et, lorsque le risque le justifie, un contrôle d’efficacité ultérieur.
Un constat peut être clôturé lorsque les actions décidées ont été réalisées, que des éléments suffisants permettent de démontrer le nouveau résultat et qu’une personne habilitée a validé que la correction répond au constat initial. Une tâche indiquée comme « terminée » n’est donc pas automatiquement un constat clôturé. Si la correction ne couvre qu’une partie du périmètre, le constat doit rester ouvert ou être partiellement remédié.
La preuve dépend de la nature de l’écart : export de configuration, résultat de scan, rapport de test, compte rendu de revue, procédure approuvée ou autre élément vérifiable. Elle doit démontrer le résultat attendu, pas simplement que l’activité a été lancée. Une bonne pratique consiste à définir la preuve attendue au moment de créer l’action afin que le responsable sache dès le départ ce qui permettra sa validation.
La clôture confirme que la correction décidée a été réalisée et démontrée. Le contrôle d’efficacité vérifie ensuite que cette correction fonctionne durablement et produit toujours le résultat attendu. Par exemple, réaliser une première revue des droits peut permettre de clôturer la mise en place du processus ; vérifier que la revue suivante est réellement réalisée permet d’en contrôler l’efficacité. Le NIST place précisément l’efficacité des contrôles au cœur de son processus d’évaluation.
Il faut conserver la non-conformité ou le constat d’origine, documenter les actions décidées, identifier leurs responsables, suivre leur réalisation puis conserver la preuve du résultat obtenu. Une distinction utile consiste à séparer la correction immédiate de l’action corrective : la première élimine le problème observé, tandis que la seconde vise sa cause afin d’empêcher sa réapparition. Cette distinction reprend la terminologie ISO des systèmes de management.
Il est préférable de distinguer « risque accepté » de « corrigé ». L’acceptation signifie que l’organisation décide consciemment de conserver tout ou partie du risque ; elle ne signifie pas que la faiblesse a disparu. La décision doit préciser le propriétaire du risque, le motif, les éventuelles mesures compensatoires et la date de réexamen. Cette distinction évite de donner une vision artificiellement favorable du niveau de remédiation.
Conservez le lien entre l’audit, les actions, leurs responsables et les preuves qui permettent de vérifier la remédiation.
Voir comment CompliKey suit un écart de l’audit jusqu’à sa clôture
