# 04 Evidence calendar: what to capture, when, and where it lives

An auditor tests a control by asking for its evidence. For a Type II, they pick samples across the window (for example, 25 changes, 3 quarterly access reviews, 2 monthly restore tests) and ask for each one. This calendar says what must exist, so nobody reconstructs it in a panic.

## Where evidence lives

- **A private evidence store**, never this public site and never a public repository. It holds access lists, screenshots of settings and logs that name people. Use the compliance platform if one is chosen; otherwise a private bucket with versioning and object lock, readable by the Security Owner and the auditor only.
- **Layout:** `evidence/<year>/<control-id>/<YYYY-MM-DD>-<short-name>.<ext>`. One file per occurrence.
- **Retain** for the length of the current window plus the previous one, and at least 3 years.
- **Never edit evidence after the fact.** If something was wrong, add a new dated file that explains it.
- **No secrets, no customer content.** Redact tokens, passwords and customer data from screenshots and exports before storing.

## Continuous (generated by the system itself)

| Evidence | Control | Source |
| --- | --- | --- |
| Pull requests with approvals and CI runs | CHG-01 to CHG-03 | GitHub |
| Deploy records (commit, who, when, result) | CHG-04 | Deploy pipeline log |
| Central logs and alert history | OPS-01, OPS-02 | Log platform |
| Incident records and postmortems | OPS-06, OPS-07 | Incident tracker |
| Backup job logs | AVL-03 | Backup job |
| Uptime history | AVL-02 | Uptime monitor |
| Coding-agent session logs | ACC-18 | Agent logging (see [17](/soc2/17-ai-agents)) |

## Weekly

| Evidence | Control |
| --- | --- |
| Vulnerability scan reports (dependencies, containers, hosts) | OPS-03 |

## Monthly

| Evidence | Control |
| --- | --- |
| MFA enforcement export for each workforce system | ACC-03 |
| Restore test record per in-scope database | AVL-04 |
| Patch log | OPS-04 |
| Trust-surface probe output (`audit/probe.py`) | MON-04 |
| Retention reaper run log | CNF-03 |

## Quarterly

| Evidence | Control |
| --- | --- |
| Access review, signed, with the list before and after and every change made | ACC-06 |
| Asset inventory export | ACC-01 |
| Host baseline configuration check output | OPS-05 |
| Endpoint checklist per device | ACC-17 |
| Control self-assessment | MON-01 |
| Security program review minutes | GOV-03 |
| External port scan of in-scope hosts | ACC-08 |

## Annual

| Evidence | Control |
| --- | --- |
| Policy set approval, signed | GOV-01 |
| Policy acknowledgements and training completion, per person | GOV-04, GOV-08 |
| Risk assessment, dated | RSK-01 |
| Vendor reviews (reports collected, exceptions read, CUECs mapped) | VND-02 |
| Penetration test report and remediation | MON-02 |
| Incident tabletop exercise notes | OPS-08 |
| Disaster recovery exercise with measured RTO and RPO | AVL-05 |
| System description refresh | COM-01 |
| Key rotation log review | ACC-14 |
| Cyber insurance decision | RSK-04 |

## On event

| Event | Evidence | Control |
| --- | --- | --- |
| Someone joins | Signed NDA, background check record, access request approvals, acknowledgement, training | GOV-04 to GOV-08, ACC-04 |
| Someone leaves or changes role | Offboarding checklist with the time each access was removed | ACC-05 |
| Emergency change | PR labelled `emergency` plus the retro review within 2 business days | CHG-05 |
| New vendor | Register entry, review, DPA | VND-01 to VND-03 |
| New sub-processor for customer data | Customer notice | VND-04 |
| Key exposed | Rotation record | ACC-14 |
| Hardware disposal | Wipe or destruction record | ACC-16 |
| Customer leaves | Data return or deletion record | CNF-04 |

## Automate these first

These are the cheapest to automate and the most often missed by hand:

1. A monthly job that exports the member list and MFA status of GitHub, Cloudflare and the cloud console into the evidence store.
2. A monthly restore test that restores the latest backup of each in-scope database into a scratch database and compares row counts. `Reach/scripts/verify-restore.sh` is the pattern; generalise it.
3. A deploy wrapper that appends commit, actor and result to a deploy log.
4. A weekly dependency and container scan whose report is stored and whose critical findings open tickets.