Auditors usually want five kinds of evidence for vulnerability management: the written policy, dated scan output, a record of what you did about each finding, proof of closure, and approved exceptions. Together they show the process exists and ran as described, not just that a scanner was switched on.
The evidence list
| Evidence | What it proves | Good form |
|---|---|---|
| Vulnerability management policy | The standard you set | Versioned document with owner and review date |
| Scan configuration | What is in scope | Export or screenshot showing assets and schedule |
| Dated scan results | Detection happened | Reports or exports with timestamps, across the period |
| Tickets or fix pull requests | Findings were evaluated and acted on | Links with created and closed dates |
| Closure proof | The fix landed | Merged pull request, rescan showing the finding gone |
| Exception register | Deferrals were decided, not forgotten | Reason, approver, expiry date |
Population matters. Auditors often pick a sample from a full list, so your list of findings has to be complete and exportable, not a hand picked set of good examples.
Common gaps
- Scans exist, but nobody can show who looked at them.
- Tickets are closed with no link to the fix.
- Remediation targets in the policy are shorter than what the data shows you met.
- Exceptions live in chat messages.
- Evidence is collected only in the weeks before the audit. For a Type 2 period, the whole window needs coverage.
How to build the trail as you go
- Export scan results on a fixed schedule and store them in a dated folder.
- Make every finding above your threshold a ticket or pull request automatically, with a link back to the finding.
- Record severity, detected date and closed date as fields, so you can compute time to fix.
- Keep the exceptions register in one place with an expiry for each entry.
- Before the window ends, test one sample yourself: pick a finding and trace it from detection to closure.
If you have to rebuild history from memory, you will miss things. If your tools write the record while the work happens, the audit mostly becomes an export.
Quick check
Is a screenshot of a clean scan enough?
Rarely. It shows one moment. Auditors also look at the process: dated runs over the period, findings, actions and closure.
Where should exceptions be recorded?
In a register with a reason, an approver and an expiry date. Chat messages are hard to sample and easy to lose.
Where Safeguard fits
Safeguard's compliance and evidence automation keeps dated scan results, fix pull requests and policy decisions together, so the trail builds during normal work. Run a free scan to see what a finding record looks like.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022), aicpa-cima.com (criteria text paraphrased). Sampling practice differs by auditor, so confirm with yours.
Last reviewed: 19 October 2026.
