Show that no change reaches the main branch without review and passing checks, and that outside changes get extra scrutiny. The evidence is mostly settings and records you already have: branch protection, required checks, approval logs, code owner rules and workflow permissions, exported with dates.
What the control looks like
A typical change management control says that code changes are reviewed and tested before production. For open source or inner source projects, an auditor will ask how that holds for contributions from people outside the team. You do not need new software to answer. You need to show the control is configured and that it operated.
Evidence list
| Evidence | What it shows | How to capture |
|---|---|---|
| Branch protection or ruleset export | Review and status checks are required | Screenshot or API export with date |
| Required status check list | Which checks gate merging | Same export |
| Sample of merged outside pull requests | Reviews and checks happened | Pick a sample, record links |
| Fork workflow approval setting | Outside runs need maintainer approval | Settings screenshot |
| CODEOWNERS file for workflows | Pipeline changes need owner review | File with commit history |
| Default token permission setting | Least privilege | Settings screenshot |
| Environment protection rules | Secrets need approval | Settings screenshot |
| Exceptions log | Bypasses were recorded | A simple table of who, when, why |
Make the sample meaningful
An auditor typically samples items over the period. Pick merged pull requests from outside contributors across several months. For each, record the contributor type, reviewers, checks passed, and any approval of fork runs. If a check was skipped or bypassed, record why.
Be careful with claims
Say what you operate today, in plain words. Do not describe an attestation or certification as complete unless you hold it. A statement like "all merges to the default branch require one approving review and passing required checks" is specific and testable. Note also that required checks on GitHub must pass on the latest commit, and that skipped statuses can count as success, so describe your summary gate if you rely on one.
Keep the evidence fresh
- Export settings on a schedule, such as quarterly.
- Record changes to the settings, with who approved them.
- Review the exceptions log.
- Store exports where the audit team can read them.
Map it to frameworks
Many frameworks include a change management or secure development practice. Mapping your controls to the relevant requirement saves time later. The interactive framework mapping demo shows how a control maps across frameworks.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a single control is tied to several framework requirements.
Where Safeguard fits
Safeguard's compliance and evidence automation helps collect and organize records like these, alongside policies and gates on pull requests. The free scan covers the dependency side.
Quick check
Do I need a tool to produce this evidence?
No. Settings exports and pull request records are enough to start. Tools help keep it current.
Should I mention bypasses to the auditor?
Yes. A logged exception with a reason is a stronger answer than a claim of none.
Sources
- Troubleshooting required status checks, GitHub Docs
- Secure use reference, GitHub Docs
- Approving workflow runs from forks, GitHub Docs
Last reviewed: 19 October 2026.
