# Journal de preuves cyber : conserver ce qui rend une décision défendable

Adrien Murillo — Murillo Consulting

Méthode pour tenir un journal de preuves cyber : logs, décisions, exceptions, tickets, contrôles, propriétaires et risques résiduels.

Dans beaucoup d'organisations, les preuves existent mais elles sont dispersées : tickets, exports, mails, captures, tableaux, conversations et rapports. Un journal de preuves ne remplace pas les outils, il relie les éléments pour expliquer ce qui a été décidé, par qui, quand et avec quel risque résiduel.

Version : Mai 2026

## À retenir

- Une preuve utile relie un contrôle, un responsable, une date, un résultat et une décision.
- Le journal doit rester léger pour être tenu pendant un incident ou un audit.
- Les exceptions sont des preuves à part entière si elles sont justifiées et limitées.
- La chaîne de décision complète souvent les logs techniques.

## Créer une ligne de preuve exploitable

Une bonne ligne de preuve tient en peu de champs : contrôle, périmètre, responsable, date, source, résultat, décision et prochaine action. Ce format suffit pour relire un audit, un incident ou une revue d'accès sans repartir de zéro.

Le journal n'a pas besoin d'être parfait. Il doit surtout être tenu au fil de l'eau et compréhensible par quelqu'un qui n'a pas participé à la réunion.

- contrôle
- périmètre
- responsable
- source
- résultat
- décision

## Protéger la preuve elle-même

Les preuves cyber peuvent contenir des données personnelles, des secrets, des IP internes, des noms de comptes, des traces d'attaque ou des informations contractuelles. Leur stockage doit donc être maîtrisé : accès limité, durée, version, anonymisation si nécessaire.

Cette protection est aussi un signal de maturité : on sait démontrer sans exposer inutilement.



## Relier incident, conformité et amélioration

Le même journal peut servir pendant une crise, une revue de conformité ou un plan de remédiation. Ce qui change, c'est la granularité. En crise, on note les décisions vitales. En audit, on relie les preuves aux contrôles. En amélioration, on suit les écarts jusqu'à leur clôture.

Ce lien évite de produire trois documentations incompatibles pour raconter le même risque.

- crise
- audit
- remédiation
- risque résiduel
- clôture

## À décider

- Quelle décision cette preuve doit-elle défendre ?
- Qui peut expliquer la preuve sans refaire toute l'enquête ?
- Combien de temps la preuve doit-elle être conservée ?
- La preuve contient-elle des secrets ou des données personnelles à protéger ?
- Quel élément manque pour transformer un constat en action ?

## À vérifier techniquement

- Contrôles déclarés sans export, ticket, capture ou journal associé
- Exceptions de sécurité sans propriétaire ou date de revue
- Actions d'incident non horodatées ou réparties dans plusieurs canaux
- Rapports de vulnérabilités sans décision de traitement ou acceptation du risque
- Revues d'accès sans périmètre, population ou résultat exploitable

## Preuves à conserver

- Identifiant du contrôle ou de l'action suivie
- Responsable, valideur, date, périmètre et source de preuve
- Résultat observé, écart éventuel et décision prise
- Risque résiduel accepté ou action corrective planifiée
- Lien vers ticket, export, log, rapport, capture ou compte rendu

## Erreurs fréquentes

- Accumuler des captures sans contexte, date ni décision.
- Mélanger preuves d'audit, données personnelles et secrets dans un dossier partagé sans règle.
- Archiver les logs mais perdre la raison métier de l'action.
- Documenter uniquement les réussites et jamais les exceptions.

## Un journal de preuves doit-il être un outil GRC complet ?

Non. Un tableur maîtrisé ou un outil de ticketing peut suffire au départ si les champs essentiels sont tenus et si les accès sont contrôlés.

## Sources

- [NIST - SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)
- [CNIL - Notifier une violation de données personnelles](https://www.cnil.fr/fr/services-en-ligne/notifier-une-violation-de-donnees-personnelles)
- [Counteractive Security - Incident Response Plan Template](https://github.com/counteractive/incident-response-plan-template)



## Navigation
- [Consultant DevOps et DevSecOps Cloud.](/profil)
- [Missions d’ingénierie.](/services)
- [Réalisations.](/realisations)
- [Projets open source.](/projets)
- [Des guides pour passer à l’action.](/ressources)
- [Parlons de votre projet.](/contact)
- [Du cadrage aux livrables.](/approche)
- [Des contextes. Des contraintes réelles.](/secteurs)
- [Apprendre en prenant des décisions.](/lab)
- [Mentions légales](/mentions-legales)
- [Confidentialité](/confidentialite)
- [Conditions générales d’utilisation](/conditions-utilisation)
- [Former vos équipes. Avec de la pratique.](/formation)

[Contact](mailto:contact@adrien-murillo.com)