Back to blog
Audit

What evidence auditors expect (and what they reject)

The evidence auditors actually accept for the most-tested controls, the four properties every artefact needs, and the common submissions that get rejected - with the stronger alternative for each.
GRC Copilot Team
What evidence auditors expect (and what they reject)

Auditors accept evidence that is attributable, dated, complete and from the period under review. Most rejected evidence fails one of those four tests - usually the date or the period. A perfect control that produced no record during the audit window cannot be tested, and an untestable control is a finding.

The four properties every artefact needs

  • Attributable - it shows who did it and, where relevant, who approved it.
  • Dated - a system-generated timestamp beats a filename containing a date.
  • Complete - the full population, not a curated highlight. Auditors sample from populations.
  • In-period - it falls inside the audit window. Evidence generated the week before fieldwork proves the control works today, not that it operated all year.

What good evidence looks like, control by control

Access control and user access reviews

Expected: a full user listing per system exported during the period, the reviewer's decisions (retain, modify, revoke), documented approval, and proof that revocations were actioned with dates.
Rejected: a screenshot of an admin page with no reviewer, no date, and no evidence of follow-through.

Joiners, movers and leavers

Expected: the HR leaver list for the period reconciled against account deactivation records, showing the gap in days.
Rejected: "We disable accounts on the last day" with no records. Auditors will pick five leavers and check.

Change management

Expected: a population of changes for the period, with approval, testing evidence and deployment records for the sampled ones - typically pull requests showing reviewer approval, and ticket references.
Rejected: a change policy with no tickets, or merges with self-approval.

Vulnerability and patch management

Expected: scan reports across the period, a remediation tracker showing findings closed within your stated SLA, and rescans proving closure.
Rejected: one recent clean scan. Auditors want the trend and the remediation history.

Backup and recovery

Expected: backup job logs plus a documented restoration test with date, scope, participants and outcome.
Rejected: successful backup logs alone. A backup that has never been restored is unproven.

Security awareness training

Expected: the completion report showing all in-scope staff, completion dates, and follow-up for non-completers.
Rejected: the training deck. Content is not completion.

Incident response

Expected: the incident register for the period, with sampled tickets showing detection time, actions, resolution and lessons learned - plus evidence of a tabletop exercise if you had no real incidents.
Rejected: an incident response plan with an empty register and no exercise.

Vendor management

Expected: the vendor inventory, evidence you obtained and reviewed supplier assurance reports, and contracts containing security clauses.
Rejected: a list of vendors with no due diligence records.

Never hunt for evidence again

GRC Copilot links every control to its supporting evidence, flags artefacts that are stale or outside the audit period, and assembles the auditor pack on demand.

Why screenshots so often fail

Screenshots are not banned, but weak ones are. A usable screenshot shows the system, the filter or query applied, the full result, the date and the user context. A cropped image of a settings toggle proves a setting existed at an unknown moment - which is not evidence of a control operating over a period.

Prefer system-generated exports, reports and logs. Where a screenshot is the only option, capture the surrounding context and record who took it and when.

The best evidence is a by-product of the control running, not something assembled for the auditor. If producing evidence requires a special effort, the control is probably not embedded.

Frequently asked questions

How far back does evidence need to go?

For ISO 27001, typically since the last audit or ISMS implementation. For SOC 2 Type II, across the entire observation window - commonly three to twelve months.

Are screenshots ever acceptable?

Yes, when they include system context, applied filters, full results and a visible date. System-generated exports are always stronger.

What if a control had no activity during the period?

Say so and evidence the absence - for example, an empty incident register plus a tabletop exercise demonstrating the process works. Silence without explanation reads as a gap.

Can the same evidence support multiple frameworks?

Yes, and it should. One access review record can satisfy the equivalent control in ISO 27001, SOC 2, the NCA ECC and SAMA CSF once your controls are mapped.

Key takeaways

  • Evidence must be attributable, dated, complete and from the audit period.
  • Populations beat samples - auditors choose the sample, not you.
  • Backups need restore tests; training needs completion records.
  • Prefer system-generated exports over screenshots.
#audit #evidence #iso27001 #soc2 #compliance