Keep a dated record that shows what was vulnerable, what you changed, when the fix was running in production, and who approved any delay. For OS patches that is update logs and scan results by host group. For dependencies it is the pull request, the lockfile diff and the deployed artifact scan.
Why evidence matters
Customers, auditors and your own incident reviews ask the same thing: how do you know it was patched, and how fast? A policy document answers the first half badly. Records answer both. We do not claim any framework requires a specific format, so check what your own obligations ask for and keep the evidence that answers it.
Evidence by layer
| Evidence | OS patching | Dependency updates |
|---|---|---|
| Detection | Scan or advisory feed with date | Alert or scan finding with date |
| Decision | Ticket with severity and chosen response | Pull request or ticket with the same |
| Change record | Update logs, change ticket | Merged pull request, lockfile diff |
| Testing | Canary results | CI results, canary notes |
| Deployment | Restart or image rollout record | Deployment record with commit and build ID |
| Verification | Version query or follow up scan | Artifact scan showing fixed version |
| Exceptions | Register entry with owner and expiry | Same register |
Build the trail as a by-product
The cheapest evidence is the kind your tools already produce. Pull requests carry timestamps, reviewers and test results. Deployment systems record commits and times. Scans produce dated reports. NIST SP 800-40 Rev. 4 asks for exceptions to be closely tracked and reviewed regularly, and for actionable metrics, which this trail supports.
A lightweight routine
- Tag findings with a service and owner when they are created.
- Link the fix to the finding: ticket, pull request or change record.
- Capture the verification scan after deployment and attach it.
- Store exceptions in one register with a reason and a review date.
- Export monthly a summary: findings opened, closed, time to fix, open exceptions.
- Retain according to your own retention policy. See audit evidence retention.
What to avoid
- Screenshots with no date or system name.
- A single percent patched figure with no scope.
- Evidence kept only in someone's inbox.
- Claiming a certification or attestation you do not hold.
Try it yourself
Click through it at your own pace, or open it full screen. See how one piece of evidence can support more than one control.
Where Safeguard fits
Safeguard's compliance and evidence automation collects scan and remediation records so they are ready when a questionnaire or review arrives. See also patch exception register.
Quick check
How long do I keep patch records?
Set it in your retention policy, based on contract and legal needs you have confirmed.
Is a scan report enough evidence?
It shows state at a point in time. Pair it with the change record and the deployment record to show the full path.
Sources
Last reviewed: 19 October 2026.
