Une preuve de conformité cybersécurité est utile lorsqu’elle permet de démontrer de façon vérifiable qu’une exigence ou une mesure est réellement satisfaite sur le périmètre et pendant la période évalués. Posséder une politique, une capture d’écran ou un fichier ne suffit donc pas. Il faut vérifier ce que l’élément démontre, son origine, sa date, sa couverture, sa période de validité et son rattachement à la mesure. Une procédure prouve qu’une pratique est définie ; elle ne prouve pas nécessairement qu’elle est exécutée. De même, une configuration correcte sur un serveur ne démontre pas automatiquement qu’elle couvre l’ensemble du parc.
C’est l’une des différences fondamentales entre collecter des documents et constituer des preuves d’audit.
ISO 19011:2026 définit l’audit evidence comme des enregistrements, déclarations de faits ou autres informations qui sont pertinents par rapport aux critères d’audit et vérifiables. Les constats d’audit résultent ensuite de l’évaluation de ces preuves par rapport aux critères retenus.
Cette définition contient deux conditions particulièrement importantes :
pertinente : l’information doit réellement répondre à l’exigence évaluée ;
vérifiable : l’auditeur doit pouvoir contrôler sur quoi repose l’affirmation.
Une preuve n’est donc pas simplement :
« un fichier que l’entreprise possède ».
C’est un élément qui contribue à répondre de manière défendable à une question précise.
Prenons une entreprise qui affirme réaliser des tests de restauration chaque année.
Elle fournit :
Politique_de_sauvegarde_v3.pdf
Le fichier existe, il est daté et il décrit l’obligation de tester les restaurations.
Mais il ne démontre pas que le dernier test a effectivement été réalisé.
Pour répondre à cette deuxième question, il faudrait rechercher par exemple :
La politique est donc une preuve pertinente de formalisation, mais pas nécessairement une preuve suffisante d’exécution.
Cette distinction entre ce qui est documenté et ce qui est réellement mis en œuvre est également visible dans les méthodes d’évaluation du NIST. Le SP 800-171A distingue notamment les specifications — politiques, procédures, architectures — des mechanisms et activities, c’est-à-dire les mécanismes techniques et les activités effectivement réalisées. Il combine ensuite examen, entretien et test pour obtenir les éléments nécessaires à l’évaluation.
Une capture d’écran peut être parfaitement authentique et ne rien prouver sur l’exigence évaluée.
Exemple :
Critère
Tous les comptes administrateurs du périmètre doivent utiliser le MFA.
Preuve
Capture montrant que le MFA est activé sur le compte de l’administrateur principal.
La capture démontre l’activation du MFA sur un compte.
Elle ne démontre pas la couverture de tous les comptes administrateurs.
La question à poser n’est donc pas :
« Avons-nous une preuve ? »
mais :
« Qu’est-ce que cette preuve permet exactement de conclure ? »
Il n’existe pas de barème universel donnant automatiquement le statut « preuve acceptée ».
La décision dépend notamment :
Il est néanmoins possible d’évaluer systématiquement la qualité d’un élément avec neuf critères.
Premier niveau : la preuve existe-t-elle réellement ?
Des réponses telles que :
« Le prestataire doit avoir le document. »
« Nous l’avions montré lors du dernier audit. »
« Il doit être quelque part dans SharePoint. »
ne constituent pas des preuves exploitables.
L’élément doit pouvoir être :
Secureframe identifie précisément ce problème dans son contenu consacré aux audits ISO 27001 : les preuves peuvent exister tout en étant difficiles à retrouver parce qu’elles sont dispersées entre disques, Google Drive, pièces jointes ou autres systèmes.
Une personne différente de celle qui a collecté la preuve peut-elle la retrouver ?
Si la réponse est non, la traçabilité est déjà fragile.
Une preuve doit être reliée au critère qu’elle contribue à démontrer.
Prenons une politique de contrôle d’accès.
Elle peut soutenir plusieurs sujets :
Mais cela ne signifie pas qu’elle démontre l’exécution de chacun de ces processus.
Une organisation devrait pouvoir répondre :
Pour l’exigence X, quelles preuves avons-nous ?
mais aussi :
Cette preuve contribue à démontrer quelles exigences ?
Ce rattachement devient particulièrement important dans les démarches multi-référentiels.
Une même revue des accès peut contribuer à plusieurs exigences ISO 27001, NIS2, SOC 2 ou internes sans qu’il soit nécessaire de recopier le document quatre fois.
Si je retire le nom du fichier, puis-je expliquer en une phrase ce qu’il démontre pour cette mesure ?
C’est une cause fréquente de surévaluation.
Preuve :
Capture de la politique de mots de passe Microsoft 365.
Conclusion trop large :
« La politique de mots de passe est appliquée sur l’ensemble du SI. »
La preuve couvre peut-être :
mais pas nécessairement :
La preuve doit donc documenter le périmètre qu’elle représente.
Il peut s’agir :
Le NIST rappelle qu’il appartient à l’évaluateur de sélectionner les méthodes et objets fournissant suffisamment d’éléments pour soutenir les conclusions de conformité. Tous les objets possibles ne sont pas automatiquement requis, mais les éléments sélectionnés doivent permettre de soutenir raisonnablement l’évaluation.
Quels systèmes, personnes ou processus cette preuve couvre-t-elle — et lesquels ne couvre-t-elle pas ?
Une preuve exacte lors de sa création peut devenir obsolète.
Exemple :
capture de la liste des comptes administrateurs du 14 février 2024.
Pour un audit réalisé en août 2026, elle démontre principalement :
la situation du 14 février 2024.
Elle ne permet pas nécessairement de connaître les accès actuels.
La date peut correspondre à :
Ces dates ne doivent pas être confondues.
Secureframe recommande par exemple que les captures utilisées comme preuves disposent, lorsque cela est applicable, d’informations permettant d’identifier leur origine et leur date. Sa documentation de juillet 2026 mentionne notamment l’URL et le timestamp pour aider l’auditeur à déterminer où et quand la capture a été produite.
La date démontre-t-elle que la preuve représente encore la situation évaluée ?
La date et la période ne répondent pas à la même question.
Prenons un export daté du 30 juin.
Il peut contenir :
ou :
Dans le deuxième cas, la preuve permet d’évaluer une activité sur une période.
Cette distinction est essentielle lorsqu’un contrôle doit fonctionner régulièrement.
La Cour des comptes européenne rappelle dans sa méthodologie d’audit qu’une preuve pertinente doit également correspondre à la période examinée et, lorsque nécessaire, être représentative de l’ensemble de cette période.
Les plateformes de compliance automation rencontrent exactement cette problématique. Dans son module d’audit, Secureframe utilise une observation window : seules les preuves correspondant à la période définie sont prises en compte dans le périmètre de l’audit.
Pour démontrer :
« les comptes à privilèges sont revus trimestriellement »
une revue effectuée la semaine précédant l’audit ne démontre pas nécessairement que les quatre revues attendues ont été réalisées.
Il faut rechercher les exécutions correspondant à la période étudiée.
Cette preuve démontre-t-elle une situation ponctuelle ou le fonctionnement du contrôle pendant toute la période attendue ?
Une preuve doit être traçable jusqu’à sa source.
Pour chaque élément, il est utile d’identifier :
Liste_comptes.xlsx
Export des comptes Entra ID réalisé le 12 août 2026 par l’administrateur IAM, couvrant le tenant de production.
Le deuxième libellé permet de comprendre :
Le « propriétaire de la preuve » n’est pas une exigence universelle de tous les référentiels.
Il constitue néanmoins une métadonnée de gouvernance très utile : lorsqu’une preuve doit être renouvelée six mois plus tard, quelqu’un doit savoir qui peut la produire ou confirmer sa validité.
Sait-on d’où vient cette information et qui peut la confirmer ?
ISO 19011 place précisément la vérifiabilité au cœur de la définition d’une preuve d’audit.
Il ne faut cependant pas traduire cela par :
« toute preuve doit porter une signature électronique ».
Le niveau de vérification approprié dépend de la nature de l’information.
Une preuve peut gagner en crédibilité lorsqu’elle comporte :
Faible
tableau Excel recréé manuellement indiquant « tous les serveurs sont patchés ».
Plus probant
export daté de l’outil de gestion du parc montrant les niveaux de correctifs des équipements du périmètre.
Le premier fichier peut être exact.
Mais il est plus difficile de vérifier :
Un PDF signé n’est pas automatiquement pertinent.
Un export automatique n’est pas automatiquement complet.
Une capture d’écran n’est pas automatiquement mauvaise.
L’objectif est de disposer d’un niveau de confiance suffisant pour soutenir la conclusion recherchée.
C’est probablement le critère le plus important.
Une organisation peut disposer d’un contrôle bien conçu sur le papier mais mal exécuté.
Elle démontre généralement :
Elle démontre qu’une activité a réellement été réalisée.
Exemples :
Elle permet d’aller encore plus loin :
Le mécanisme produit-il réellement le résultat recherché ?
Pour les sauvegardes :
politique
→ définit la sauvegarde ;
historique des jobs
→ montre leur exécution ;
test de restauration
→ démontre qu’une restauration peut effectivement être réalisée.
Le NIST illustre cette logique en distinguant les spécifications, mécanismes et activités et en proposant de combiner examen, entretien et test selon les objectifs de l’évaluation.
Cette preuve démontre-t-elle que le contrôle est prévu, qu’il est exécuté ou qu’il fonctionne réellement ?
Les trois niveaux ne sont pas équivalents.
Une bonne preuve aujourd’hui peut devenir une mauvaise preuve demain.
Il faut donc définir quand elle doit être renouvelée.
La règle ne devrait pas être :
« Toutes les preuves sont renouvelées une fois par an. »
La fréquence doit être cohérente avec :
Une politique peut être mise à jour :
Une revue trimestrielle des droits génère naturellement de nouvelles preuves à chaque occurrence.
Une configuration MFA peut devoir être réévaluée après :
Une preuve de test d’intrusion correspond à l’environnement et à la date du test : elle ne démontre pas indéfiniment la sécurité de l’application.
Secureframe illustre ce principe avec des intervalles de tests et la détection des preuves anciennes pouvant nécessiter une actualisation.
Quel événement ou quelle date rendra cette preuve insuffisamment représentative de la situation actuelle ?
La distinction « faible / solide » doit être maniée avec prudence.
Une politique n’est pas une mauvaise preuve si l’exigence consiste précisément à démontrer qu’une politique existe.
Elle devient insuffisante lorsqu’on essaie de l’utiliser pour démontrer l’exécution d’un contrôle.
Le tableau suivant doit donc se lire comme :
preuve souvent insuffisante lorsqu’elle est utilisée seule → élément plus probant pour démontrer l’effectivité.
| Situation | Preuve souvent insuffisante seule | Preuve plus probante |
| Sauvegardes | Politique de sauvegarde | Historique des sauvegardes + rapport d’un test de restauration |
| MFA | Capture d’une option « MFA enabled » | Export daté des comptes concernés et de leur couverture MFA |
| Revue des accès | Procédure de revue | Compte rendu de la dernière revue + population examinée + anomalies corrigées |
| Correctifs | Politique de patch management | Export du parc indiquant les niveaux de correctifs et les exceptions |
| Gestion des incidents | Procédure d’incident | Registre d’incidents ou exercice documenté montrant l’utilisation du processus |
| Sensibilisation | Support PowerPoint | Rapport de participation ou résultats de la campagne sur la population concernée |
| Départs collaborateurs | Checklist RH vierge | Ticket ou checklist complétée sur un départ réel |
| Gestion fournisseurs | Modèle de questionnaire | Évaluation datée d’un fournisseur réellement réalisée et validée |
| Revue des sauvegardes | Déclaration du prestataire | Compte rendu ou export permettant de vérifier la réalisation du contrôle |
| PRA | Plan de reprise | Rapport d’exercice avec résultats, incidents rencontrés et actions correctives |
Ce type de distinction rejoint les recommandations opérationnelles publiées par Secureframe en 2026. Par exemple, sa documentation indique qu’une capture d’une politique ne doit pas être utilisée pour démontrer la configuration réelle d’un outil lorsque celle-ci peut être examinée directement.
Une méthode simple consiste à classer les preuves en quatre niveaux.
| Niveau | Question | Exemple |
| 1. Définition | Avons-nous défini ce qui doit être fait ? | Politique |
| 2. Mise en œuvre | Le mécanisme existe-t-il réellement ? | Configuration MFA |
| 3. Exécution | Le processus est-il effectivement réalisé ? | Compte rendu de revue |
| 4. Efficacité | Produit-il le résultat attendu ? | Test, métrique ou réévaluation |
Cette classification n’est pas un modèle ISO officiel de notation.
C’est une grille GRC destinée à empêcher un raccourci fréquent :
« Le document existe, donc la mesure est maîtrisée. »
Définition
Politique indiquant que les administrateurs doivent utiliser un compte distinct.
Mise en œuvre
Liste des comptes montrant des comptes administrateurs nominatifs.
Exécution
Revue trimestrielle des comptes privilégiés.
Efficacité
Les anomalies de la revue sont corrigées et aucune dérive importante n’est retrouvée lors de la revue suivante.
Chaque niveau renforce la conclusion.
La capture d’écran est très utilisée parce qu’elle est rapide à produire.
Elle peut constituer une bonne preuve.
Mais elle devrait être évaluée avec plusieurs questions :
| Contrôle | Question |
| Origine | Quel outil ou système est visible ? |
| Date | Quand a-t-elle été réalisée ? |
| URL / contexte | Peut-on identifier l’écran présenté ? |
| Identité | Quel tenant, environnement ou organisation ? |
| Périmètre | Un élément ou toute la population ? |
| Lisibilité | L’information nécessaire est-elle visible ? |
| Intégrité | La capture semble-t-elle avoir été modifiée ? |
| Pertinence | La configuration visible répond-elle réellement au critère ? |
Secureframe recommande notamment de conserver URL et timestamp lorsque cela est applicable, précisément pour aider les auditeurs à identifier l’origine et la date d’une capture.
Capture A
Écran :
Security > MFA > Enabled
Problème :
on ignore :
Capture B
L’écran permet d’identifier le tenant, la date et le compte.
Elle est meilleure.
Export C
Liste datée de tous les administrateurs avec l’état MFA.
Si le critère consiste à contrôler la couverture de l’ensemble des comptes privilégiés, l’export est généralement beaucoup plus adapté à la question.
Ce n’est donc pas le format qui rend une preuve bonne ou mauvaise.
C’est sa capacité à soutenir la conclusion recherchée.
Pas toujours.
Certaines exigences sont simples.
Exemple :
« Une politique de sécurité doit être formellement approuvée. »
Une version actuelle, approuvée et correspondant au périmètre peut fournir une partie essentielle de la démonstration attendue.
D’autres exigences combinent :
Une seule pièce devient alors rarement suffisante.
La corroboration de plusieurs sources augmente également la confiance dans une conclusion. La Cour des comptes européenne souligne que des éléments provenant de sources différentes et cohérentes entre elles rendent la preuve plus persuasive.
Pour contrôler la désactivation des comptes :
preuve 1
procédure RH ;
preuve 2
liste des départs pendant la période ;
preuve 3
échantillon de tickets d’offboarding ;
preuve 4
export permettant de vérifier la désactivation effective des comptes.
Ensemble, ces éléments répondent beaucoup mieux à la question :
« Le processus fonctionne-t-il réellement ? »
Cette question est essentielle dans les audits d’efficacité opérationnelle.
Supposons qu’une organisation affirme :
« Les droits administrateurs sont revus chaque trimestre. »
Pour une période allant du 1er janvier au 31 décembre, une seule revue de décembre ne suffit pas nécessairement à démontrer l’exécution trimestrielle du contrôle.
Il faut alors identifier :
| Contrôle | Fréquence | Période auditée | Exécutions attendues | Preuves disponibles |
| Revue privilèges | Trimestrielle | Jan.–Déc. | 4 | 4 |
| Test restauration | Annuelle | Jan.–Déc. | 1 | 1 |
| Revue fournisseurs | Selon règle interne | Jan.–Déc. | Selon périmètre | À vérifier |
Attention : la présence d’un nombre suffisant de fichiers ne garantit pas leur qualité.
Chaque occurrence doit toujours être examinée selon les critères précédents.
Une preuve devient beaucoup plus facile à maintenir lorsqu’elle dispose de métadonnées minimales.
| Champ | Exemple |
| ID | PREUVE-IAM-014 |
| Intitulé | Revue Q2 des comptes privilégiés |
| Mesure associée | Revue des accès privilégiés |
| Source | Microsoft Entra ID |
| Propriétaire | Responsable IAM |
| Périmètre | Tenant production |
| Date d’exécution | 30/06/2026 |
| Période couverte | 01/04/2026 – 30/06/2026 |
| Date de collecte | 02/07/2026 |
| Ce que la preuve démontre | Revue trimestrielle des comptes privilégiés |
| Ce qu’elle ne démontre pas | Applications hors Entra ID |
| Localisation | Lien vers GED |
| Prochaine revue | 30/09/2026 |
| Statut | Validée |
| Validée par | Consultant / RSSI |
Le champ :
« Ce que la preuve ne démontre pas »
est particulièrement utile.
Il oblige à expliciter les limites au lieu de donner à chaque élément une portée excessive.
Prenons une PME préparant un audit.
Les droits à privilèges doivent être revus périodiquement.
Procedure_Gestion_Acces_V4.pdf
Existence : oui.
Rattachement : oui, la procédure couvre bien les revues.
Périmètre : elle concerne Microsoft 365 et l’ERP.
Date : approuvée en janvier 2026.
Période couverte : aucune exécution particulière.
Source : document interne validé par la DSI.
Vérifiabilité : la règle formelle peut être vérifiée.
Nature : preuve de définition.
Renouvellement : selon le cycle documentaire.
La preuve démontre que la revue est prévue.
Elle ne démontre pas qu’elle a effectivement été réalisée.
Revue_Habilitations_Q2.xlsx
Le fichier contient :
Il apporte désormais une preuve d’exécution.
L’auditeur sélectionne trois comptes devant être supprimés et vérifie leur état dans le SI.
Il obtient alors un élément supplémentaire sur l’efficacité du processus.
La conclusion finale est beaucoup plus solide que celle obtenue avec la procédure seule.
Une preuve devrait suivre son propre cycle :
attendue → collectée → examinée → validée → utilisée → à renouveler → obsolète / archivée.
L’objectif n’est pas de supprimer les anciennes preuves.
Elles peuvent être utiles pour démontrer l’historique.
Il faut simplement éviter qu’une ancienne pièce continue d’être présentée comme représentative de la situation actuelle.
Exemple :
la prochaine occurrence du contrôle arrive.
Exemple :
L’élément disponible ne couvre pas correctement la période ou le périmètre de la prochaine évaluation.
Secureframe utilise déjà cette logique dans ses outils : les preuves peuvent être associées à des intervalles, et les éléments anciens sont identifiables pour être réactualisés.
Capture1.png
Même si l’information est juste, il sera très difficile de comprendre ce qu’elle représentait six mois plus tard.
La donnée était exacte à sa date de création mais ne représente plus l’environnement actuel.
Un contrôle est testé sur Microsoft 365 puis extrapolé à toutes les applications.
Le processus est défini, mais rien ne démontre qu’il fonctionne.
Vingt comptes sont contrôlés, mais personne ne sait si la population en comprend 20 ou 2 000.
Un tableau créé juste avant l’audit peut être utile comme synthèse.
Il doit cependant permettre de retrouver les données ou enregistrements sur lesquels il repose.
Impossible de déterminer si elle répond à la période évaluée.
Le fichier contient des informations de sécurité, mais ne répond pas à la question posée.
La preuve dépend entièrement de la personne qui sait dans quel dossier elle se trouve.
L’environnement qu’elle représentait n’existe plus sous la même forme.
L’erreur consiste à lancer quelques semaines avant l’audit une grande campagne :
« Envoyez tous vos documents cybersécurité. »
On obtient alors des centaines de fichiers qu’il faut trier.
Une méthode plus efficace part des contrôles.
1. Définir ce qu’il faut démontrer
Exemple :
les comptes privilégiés sont revus périodiquement.
2. Identifier les éléments nécessaires
3. Attribuer un propriétaire
Qui pourra produire la preuve lors du prochain cycle ?
4. Documenter le périmètre
Quels systèmes sont concernés ?
5. Définir la fréquence
Quand l’élément devra-t-il être renouvelé ?
6. Vérifier avant l’audit
Le fichier disponible répond-il réellement au critère ?
Cette dernière étape constitue précisément l’un des axes de développement des plateformes de compliance automation.
Secureframe a par exemple ajouté en 2025 un mécanisme de validation de preuves destiné à détecter certains problèmes avant l’audit, notamment les documents incorrects, les timestamps obsolètes ou les fichiers qui ne correspondent pas au test concerné.
L’enjeu dépasse cependant l’automatisation.
Même lorsqu’un fichier est automatiquement collecté, quelqu’un doit toujours comprendre :
ce qu’il démontre dans le contexte de l’organisation.
CompliKey adopte une logique différente d’une plateforme principalement orientée collecte automatique des artefacts techniques.
L’objectif est de conserver le lien GRC entre :
référentiel → mesure → audit → preuve → constat → remédiation.
Les preuves peuvent être référencées directement au niveau des mesures.
Le consultant ou le RSSI peut ainsi retrouver pourquoi un élément a été collecté plutôt que de maintenir un dossier documentaire indépendant du référentiel.
CompliKey utilise des liens vers les preuves plutôt que d’imposer le stockage des documents sensibles dans la plateforme.
Cette approche permet par exemple de conserver :
tout en maintenant dans CompliKey la relation avec la mesure correspondante.
Lors de l’évaluation, les preuves peuvent être rapprochées :
Cela permet d’éviter une situation fréquente :
un score existe dans Excel et les éléments censés le justifier sont dispersés dans un autre dossier.
L’absence de preuve devient également une information exploitable.
Elle peut conduire à distinguer :
Cette distinction évite de considérer systématiquement :
« aucune pièce fournie = aucun dispositif ».
Lorsque l’élément révèle une faiblesse réelle, le constat peut être relié à une remédiation puis à une action suivie.
On conserve alors la chaîne :
mesure → preuve examinée → limite identifiée → constat → action → nouvelle preuve.
Cette dernière preuve pourra servir à vérifier la clôture lors d’une prochaine revue.
CompliKey ne détermine pas automatiquement qu’une preuve est « acceptable ».
La plateforme ne réalise pas aujourd’hui :
Une capture peut être parfaitement datée et rester insuffisante.
Un export peut provenir directement d’un système et couvrir le mauvais périmètre.
La qualité d’une preuve reste donc une appréciation GRC et d’audit.
L’outil sert à conserver le contexte nécessaire pour rendre cette appréciation défendable.
Une bonne preuve de conformité n’est pas celle qui remplit un dossier d’audit.
C’est celle qui permet de soutenir une conclusion.
Avant d’accepter un élément, vérifiez neuf points :
Cette approche rejoint le principe fondamental d’ISO 19011 : une preuve d’audit doit être pertinente par rapport au critère et vérifiable.
Le changement de posture est simple mais structurant :
Ne demandez plus seulement : « avons-nous une preuve ? »
Demandez :
« Qu’est-ce que cette preuve nous autorise réellement à conclure ? »
Une preuve acceptable doit avant tout être pertinente par rapport au critère évalué et vérifiable, principes repris dans ISO 19011. Son caractère suffisant dépend ensuite du contexte de l’audit : périmètre, période, échantillonnage et objectif du contrôle. Une politique peut démontrer qu’une règle est définie mais ne suffit pas nécessairement à prouver son exécution. L’auditeur peut donc demander plusieurs éléments complémentaires.
Elle peut l’être pour certains objectifs, mais pas systématiquement. Il faut pouvoir déterminer sa source, sa date, son environnement et son périmètre. Une capture montrant le MFA activé sur un compte ne prouve pas nécessairement qu’il est activé pour tous les administrateurs. Secureframe recommande notamment l’utilisation de timestamps et, lorsque pertinent, de l’URL afin de faciliter la vérification de l’origine des captures.
Une preuve documentaire démontre généralement qu’une règle ou un processus a été défini : politique, procédure ou instruction. Une preuve d’exécution montre qu’une activité a effectivement eu lieu : rapport de test, ticket, compte rendu de revue ou export. Le NIST distingue également les spécifications documentées des mécanismes et activités effectivement mis en œuvre lors de ses méthodes d’évaluation.
Il n’existe pas de durée universelle. La validité dépend de la fréquence du contrôle, de l’exigence, de la période auditée et des changements du SI. Une preuve peut devenir obsolète après une migration même si elle ne date que de quelques semaines. À l’inverse, une politique toujours applicable peut rester pertinente jusqu’à sa prochaine revue. Il est donc préférable d’associer chaque preuve à une date ou un événement de renouvellement.
Pas automatiquement. Un export provenant directement d’un système réduit certains risques de reconstitution manuelle et facilite souvent la vérification, mais il peut être incomplet ou couvrir le mauvais périmètre. Une preuve automatisée doit donc toujours être reliée au contrôle qu’elle évalue. Le NIST rappelle que les méthodes et objets d’évaluation doivent fournir suffisamment d’éléments pour soutenir la conclusion recherchée.
Non. Certaines preuves peuvent contenir des informations sensibles qu’il est préférable de conserver dans les systèmes documentaires ou techniques du client. L’outil GRC peut référencer leur emplacement, leur date, leur périmètre et la mesure concernée. L’essentiel est de maintenir la traçabilité entre l’exigence et l’élément qui la démontre, tout en maîtrisant les droits d’accès et le cycle de vie de l’information.
Reliez chaque preuve à la mesure qu’elle démontre, à l’audit qui l’a examinée et aux actions nécessaires lorsqu’elle est absente ou insuffisante.
Structurer vos preuves de conformité dans CompliKey
