Keep, for each production release, the pull request with its approvals, the results of required checks and dependency scans, the deploy record with time and approver, any exceptions with reasons and the rollback note. Generate it automatically where possible, store it in one place and keep it as long as your retention rule says.
Why release evidence helps
Buyers in health ask how you ship software. So do auditors and, eventually, your own incident response team. Answering from memory is weak. Answering with a dated record is strong. The cheapest time to capture it is at release, when the tools already hold the data.
The evidence list
| Item | Source | Notes |
|---|---|---|
| Change description and ticket | Pull request | Links the why |
| Reviewer approvals | Pull request | Names and times |
| Required check results | CI | Build, tests, scan |
| Dependency scan output | Scanner | Versions and findings |
| Dependency changes | Lockfile diff | What changed |
| Deploy record | Pipeline | Who, when, which environment |
| Exceptions | Pull request comment | Skipped checks with reasons |
| Rollback note | Release ticket | Tested or not |
GitHub documents the controls that create several of these records: required approving reviews, required status checks that must succeed before merge and required deployments to named environments. Using those settings means the record exists because the control exists.
Steps to build it
- Pick one place: a folder, a wiki space or an evidence tool.
- Make the pipeline write a short release summary file with the items above.
- Link the summary from the release ticket.
- Record exceptions in the same format every time.
- Review a random release each quarter and check the record is complete.
- Set retention and access for the evidence store, like any other data store.
Be careful what you claim
Evidence shows what you did. It does not create a certification. Describe it in plain words, such as: required reviews and checks are enforced on the main branch and each release has a saved record. Avoid wording that suggests a compliance status you do not hold. Check your claims with your counsel or auditor.
What not to store
Release evidence should not contain patient data, secrets or raw production logs. Screenshots of dashboards can contain identifiers, so check them before saving.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a control maps to the evidence that supports it. Look for which evidence items you already produce.
Where Safeguard fits
Safeguard offers compliance and evidence automation along with policies, gates and dependency scanning, which are the sources for most rows in the table. A free scan is available at gold.safeguard.sh/scan.
Quick check
How long should release evidence be kept?
Follow your own retention rule and ask counsel about obligations. Write the period down and apply it consistently.
Can a screenshot be evidence?
It can, but exported records with timestamps are stronger and easier to check.
Sources
Last reviewed: 19 October 2026.
