What Auditors Actually Ask For: Building an Evidence Trail Before the Audit

Auditors ask for three things, in this order: the policy that says what should happen, the record showing it happened, and the date proving when. Almost every painful audit I have seen went wrong at the second item. Companies have excellent policies and almost no records, so the weeks before fieldwork become an archaeology project.

The fix is not working harder before the audit. It is capturing the record at the moment the control runs, when it costs nothing.

What counts as evidence?

Evidence is a dated artefact, produced by a system or a person, that a specific control operated on a specific occasion. That definition rules out a surprising amount of what teams offer up.

A policy is not evidence. It states intent. A screenshot with no timestamp is weak evidence, because it proves a state, not a date. An email saying "we do this quarterly" is not evidence of anything except the email. What auditors want looks more like this:

The pattern in the right column is always the same: who, what, when, and an outcome. If your artefact has all four, it will usually be accepted. If it is missing "when", expect a follow-up request.

Why does evidence collected after the fact look worse?

Because auditors can tell, and because it usually is worse.

If a control was supposed to run quarterly and you produce four review exports all created in the same week, three weeks before fieldwork, you have proved the opposite of what you intended. You have demonstrated that the review was not happening on schedule. I have watched a company fail a control on exactly this, having genuinely done the reviews, because they redid the exports for neatness and destroyed the original dates.

Keep the original artefact with its original timestamp, even if it is ugly. A messy CSV exported in April beats a tidy PDF generated in September.

The evidence people forget to keep

Some records only exist if someone deliberately captured them, and these are the ones that go missing.

Decisions not to act. You assessed a risk and accepted it. That is a legitimate outcome, but only if it is written down with a rationale and an approver. An unrecorded acceptance looks identical to an oversight.

Exceptions. Someone got access outside the standard process because a customer escalation demanded it. Record the exception, the approver, and the expiry. Exceptions are not failures; undocumented exceptions are.

Negative results. The incidents that turned out to be nothing, the scans that found nothing, the reviews that changed nothing. A breach register containing only real breaches looks curated. One containing thirty triaged events, of which two were reportable, looks like a functioning process.

Approvals given in conversation. A verbal sign-off in a meeting is real, but it leaves no artefact. Follow it with two lines in a ticket or a channel that names the decision, the approver, and the date.

How do you capture evidence without adding work?

Move the trigger out of people's heads and into a system, then let the system's own record be the evidence.

The rule I use: if proving a control requires someone to remember, the evidence will eventually be missing. If the control runs on a date, an event, or a state change, the record generates itself.

Three examples of the shift:

• A vendor review that happens because someone checks a spreadsheet becomes a review that opens automatically at the renewal date, in the vendor inventory. The completed task is the evidence.
• A privacy assessment that happens because someone files it becomes one that opens when a system is registered as high risk. The assessment record is the evidence.
• An incident write-up that happens if the incident felt serious becomes a log entry created for every triaged event, in an incident log. The log is the evidence.

None of this requires enterprise tooling. It requires the trigger to stop being a human's memory.

How long should evidence be kept?

Long enough to cover the audit period plus the look-back the framework requires, which in practice means at least two years for most SOC 2 and ISO programmes, and longer for anything touching regulated records.

Two cautions specific to Canada. First, evidence containing personal information is still personal information, so your retention schedule applies to it. An access review export listing every employee account is a record about people. Second, do not solve retention by keeping everything forever. That converts an evidence archive into a breach liability, which is a bad trade.

If you are still deciding which framework you are collecting evidence for, ISO 27001 certification in Canada compares the options and what each one demands.

This is general information, not legal advice.

Valdra captures evidence as controls run rather than asking you to assemble it later, and keeps assessments, vendor reviews, and incidents in one dated trail. The documents view is where that trail lives.