Audit evidence collection: stop taking screenshots for your auditor

Ask anyone who has prepared for a first SOC 2 audit what took the most time and you'll hear the same answer: finding and assembling evidence. The controls were mostly fine. Proving it took weeks.

If evidence collection is a separate project before the audit, your program is designed wrong. Evidence should be a byproduct of doing the control, collected from the source system, on a schedule, by the person who owns it.

I've prepared companies for SOC 2 and ISO 27001 audits, and I've watched teams spend more hours recreating proof of work than the work itself took.

What auditors actually want

Auditors test whether a control operated, and they need evidence they can rely on. For system generated evidence, they care about where it came from, when it was produced, what parameters were used and whether the population is complete. In audit language that's information produced by the entity, and auditors are required to consider whether it is complete and accurate before relying on it.

Then they sample. For a control that runs daily they may ask for 25 or more instances. For a quarterly control, two. For an annual one, one. If your evidence for each instance lives in a different place, every sample request becomes a small investigation.

Why screenshots are weak

A screenshot shows one view at one moment. It often has no trustworthy timestamp, it can't prove the list it shows is complete, and anyone can crop or edit it. Auditors accept screenshots when nothing better exists, then ask follow up questions to make up for what they can't see.

If you have a folder called "SOC2 evidence FINAL (2)", nobody needs to explain this to you.

The most expensive security tool in many companies is a senior engineer pressing Print Screen.

Better evidence, by control

Access reviews: an export of users and roles from the system, with the reviewer's decisions and a date, plus the tickets for any removals.

Joiners and leavers: HR records compared to identity provider logs, showing access created and removed with timestamps.

Change management: pull requests with approvals and the deployment record, straight from your code repository and pipeline.

Cloud configuration: scheduled configuration checks with dated results.

Backups: restore test records, not only backup job logs.

Even the people building compliance tools hear the same question from users. One open source project's issue tracker has a proposal to add guidance on what evidence to collect for each control, because people starting from scratch don't know.

Collecting it as you go

Give each control an owner, a frequency and a defined piece of evidence. Automate collection from the source where an integration exists. Where it doesn't, make the manual step small and dated. Store everything in one place, tied to the control it proves.

That's the idea behind how Steppe handles evidence: it lands against the control it proves, with the date and the source attached, so when the auditor asks for sample 14 of 25, it's a lookup.

Evidence you collect as you work is cheap, and evidence you reconstruct for an auditor is the most expensive paperwork your company produces.