How to Prepare Evidence for an ISO 27001 Audit

Evidence is the backbone of an ISO 27001 audit. You can have the best policies in the world, but without evidence that controls are actually implemented and working, auditors have nothing to assess.

This guide covers what auditors expect, how to collect evidence efficiently, and the freshness requirements that catch most organizations off guard.

The Evidence Hierarchy

Not all evidence is created equal. Auditors have a clear preference:

Rank	Type	Example	Why It's Better
1	API export (JSON/CSV)	IAM policy export, user access list	Timestamped, reproducible, tamper-evident
2	System-generated report	Vendor SOC 2 report, SIEM export	Authoritative source with metadata
3	Configuration export	Terraform state, policy JSON	Shows intended state, version-controlled
4	Screenshot with system clock	Console settings screenshot	Visual proof, but harder to validate
5	Manual attestation	Signed statement	Last resort, requires corroboration

The key principle: automated evidence from source systems beats manual evidence every time. An API export with ISO 8601 timestamps is always preferable to a screenshot.

Evidence Freshness Requirements

This is where organizations get caught. Evidence has a shelf life.

Evidence Type	Maximum Age	Refresh Cadence
Access lists	90 days	Quarterly
Vulnerability scans	30 days	Monthly
Configuration exports	90 days	Quarterly
Training records	12 months	Annual
Penetration test	12 months	Annual
Policy documents	12 months	Annual review
Incident records	Audit period	Continuous
Risk assessment	12 months	Annual + on change

If your access review is 4 months old, the auditor may reject it. If your vulnerability scan is 6 weeks old, it doesn't demonstrate a monthly scanning program.

Naming Convention

Use a consistent naming scheme. I recommend:

{control_id}_{evidence_type}_{YYYY-MM-DD}.{ext}

Examples:

• A.5.15_user-access-list_2026-02-28.json
• A.8.8_vulnerability-scan_2026-02-28.csv
• A.8.13_backup-test-results_2026-02-28.pdf

This makes evidence instantly traceable to the control it supports.

Collection by Platform

GitHub

Export branch protection rules, merged PRs with reviews (change management evidence), Dependabot alerts (vulnerability management), secret scanning alerts, and audit logs.

Cloud Platforms (GCP/AWS/Azure)

Export IAM policies, service account lists, audit logging configuration, compute instances (asset inventory), backup configurations, and firewall rules.

Identity Provider

Export user lists with MFA enrollment status, admin role assignments, and mobile device inventory.

Endpoints

Collect FileVault/BitLocker encryption status, system configuration profiles, and screen lock settings.

Building an Evidence Package

Step 1: Identify gaps

Compare your Statement of Applicability against available evidence. Every applicable control needs at least one piece of evidence demonstrating implementation.

Step 2: Prioritize collection

1. Missing evidence for Critical-tier controls — these are audit blockers
2. Stale evidence past its renewal date — auditors will reject it
3. Evidence for Relevant-tier controls — expected but not blocking
4. Checkbox-tier evidence — policies and attestations

Step 3: Collect systematically

Group collection by platform to minimize context-switching. Run all GCP commands together, then all GitHub commands, then all IdP commands.

Step 4: Validate completeness

Before submitting to the auditor, verify:

• Completeness — Evidence exists for every applicable control
• Freshness — Every piece is within the required age
• Format — API exports have timestamps; screenshots include the system clock
• Naming — Files follow your convention
• Coverage — Critical-tier controls have at least two forms of evidence

Step 5: Create an evidence index

Build a master index mapping each control to its evidence files:

Control	Evidence File	Type	Collected	Status
A.5.15	gcp-iam-policy_2026-02-28.json	API export	2026-02-28	Current
A.5.17	workspace-users-mfa_2026-02-28.csv	API export	2026-02-28	Current
A.8.8	dependabot-alerts_2026-02-28.json	API export	2026-02-28	Current

This index becomes your roadmap during the audit and helps the auditor navigate quickly.

Common Mistakes

• Screenshots without system clock — Auditors reject undated evidence. On macOS, the menu bar clock must be visible.
• Collecting from staging instead of production — Evidence must come from the production environment.
• Waiting until the week before the audit — Start collecting 4-6 weeks out. You need time to fill gaps.
• Manually editing evidence — Auditors may verify against the source system. Altered evidence destroys trust.
• Mixing audit periods — Keep evidence from different time periods in separate files.

The Bottom Line

Evidence collection is unglamorous but essential. The organizations that pass certification efficiently are the ones that treat evidence as an ongoing process — collecting quarterly access reviews, monthly vulnerability scans, and annual training records on schedule rather than scrambling before the audit.

Need help identifying what evidence you're missing? Book an internal audit and we'll map your current evidence against every applicable control.