Guide
What counts as valid evidence in a security audit
The difference between a screenshot and evidence that holds up comes down to four properties: origin, date, integrity and scope. None of them is optional.
Everyone knows an audit is won with evidence. Almost nobody defines what turns a file into evidence and what leaves it as a bare assertion. The result is the shared folder with 400 screenshots that nobody can use when the moment comes.
Evidence is valid when a third party who was not there can answer four questions without asking you: where it came from, when, whether it has changed since, and which part of the system it covers. If one of those fails, it stops being evidence.
Origin: which system produced it, and how
“A screenshot of the console” has no origin. A CSV export from the console, generated by an identified account, from a query that can be re-run, does.
The practical difference is that the second can be reproduced. When an auditor
doubts, the answer is not to argue: it is to re-run the same query in front of
them and compare. That is why it pays to store the command or query alongside
the result. One line of aws iam list-users --output json is worth more than a
screenshot of the user list, because anyone can repeat it.
This has an uncomfortable corollary: evidence produced manually by the same person who owns the control is the weakest kind there is. Not because bad faith is presumed, but because there is no way to distinguish it from an edit. Where you can, have the evidence produced by a system other than the one being audited.
Date: the date of the fact, not of the file
A PDF’s modification date is not the date of the fact. The date of the fact is the one inside the evidence: the log timestamp, the signature date, the date on the minutes.
The classic problem shows up in periodicity evidence. If your control says “quarterly access review”, the auditor does not want the latest review: they want all four for the year, with their four dates, and they will check that the gaps are plausibly quarterly. Three reviews performed in the same week of December do not evidence a quarterly control; they evidence an annual control with a guilty conscience.
Evidence of a point-in-time fact — an incident notification, a board approval — additionally needs a date and a time when a regulatory deadline sits behind it. Article 23 of NIS2 counts in hours; evidence dated only to the day is useless for demonstrating the 24-hour deadline was met.
Integrity: it should be obvious if someone has touched it
Integrity does not demand cryptography in every case, it demands proportionality. For most controls it is enough that the file lives in a system with access logging and versioning, and that it never passed through anyone’s desktop. For evidence that could end up in proceedings — incident files, audit reports, formal risk acceptances — raise the bar: published hash, electronic signature, or write-once storage.
The useful test is to ask what would happen if someone claimed the evidence was manufactured after the fact. If the only available answer is “trust me”, the evidence is weak.
Scope: which part of the estate it covers, and which it does not
This is the most frequent failure and the most expensive. Perfect evidence of a control applied to a subset of the estate proves exactly that: the subset.
A real and much-repeated example: patch management evidence is submitted as a report from the update server showing 98% compliance. The auditor asks how many machines that percentage is calculated over. It turns out to be the machines that report to the server — and a hundred and twenty do not report. The real control is not 98%, it is 98% of an undefined population.
Every quantitative piece of evidence needs to declare its denominator, and every configuration evidence needs to declare its reference inventory. If you cannot say how many assets it was calculated over, you have not supplied a metric: you have supplied a number.
What almost never stands alone
Four classes of artefact are constantly offered as evidence and, on their own, hold nothing up:
- The policy. It demonstrates intent, not execution. An auditor uses it to learn what should be happening, then goes looking for proof that it does.
- The context-free screenshot. No URL, no clock, no authenticated user — it only proves a screen exists that looks like that.
- The email. It proves somebody said something. It works as evidence of communication or approval if headers and date survive, but not as evidence that the action was performed.
- The supplier questionnaire. It proves what the supplier declared. Nothing more. It is the starting point of an assessment, not its result.
None of them is useless: all are valid as one piece of a set. The mistake is presenting them as the only piece.
Negative evidence: proving something did not happen
Some obligations require proving an absence, and that is much harder. “No unauthorised access occurred” or “no incident reached the reporting threshold” are not demonstrated by an absence of records.
They are demonstrated by the record that the check was performed: the query executed, the period covered, the criterion applied and the empty result, all dated. And by proof that the detection system was operational throughout that period, because silence with the sensor switched off is not silence.
How to assemble a file that can actually be audited
Three practices avoid most of the pain:
- One piece of evidence, one control, one period. Files that serve several controls end up filed in one place and looked for in another.
- The filename states control, period and source system.
AC-03_2026-Q2_okta-export.csvis findable in two years;final_evidence_v3.zipis not. - An index mapping obligation, control, evidence and date. It is the document an auditor asks for first, and the one that decides whether the review takes two days or two weeks.
The tedious part of all this is that evidence decays on its own: it expires, loses its denominator, loses the link to the control that justified it. That is why it is worth having the system that manages findings be the same one that retains their evidence with date and scope — the design decision Violet Security is built on — rather than a folder someone will have to reconstruct the week before the audit.