Change management evidence from pull requests: what to show

For many teams, the pull request is the change record. It can serve as audit evidence if it shows who proposed the change, who reviewed and approved it, what tests ran, and a link to the deployment. Branch protection makes that trail hard to skip.

What the auditor wants to see

For a sample of production changes, the auditor asks: was the change authorised, tested and approved by someone other than the author, and can you tie the approved code to what went live?

A pull request gives you most of this in one place: author, reviewers, approval timestamps, status checks and the merge commit.

Settings that create the trail

Turn these on for production branches:

• Required reviews before merge, with at least one reviewer who is not the author.
• Required status checks, such as tests and security scans.
• No direct pushes, with the same rules for admins where you can.
• Dismiss stale approvals when new commits arrive.

Export or record the settings regularly so you can show they were on across the whole period, not just today.

Tie the code to the release

Approved code is not enough if the deployed build differs. Link the merge commit to the pipeline run and the release. Many teams do this by tagging builds with the commit ID. The auditor should be able to follow one change from request to production.

Handle the exceptions honestly

Emergency fixes happen. Define in your policy how an urgent change is made, who approves it and how it is reviewed afterwards. Then keep the after the fact review record. An emergency path that exists in practice but not in policy becomes a finding.

Also expect small changes that bypass the flow, such as configuration edits in a console. If those can touch production, they need their own record.

Prepare the population

Before the audit, produce a list of all production changes in the period, from your deployment system rather than from memory. The auditor will pick from that list. Check that it matches the merged pull requests.

Where tooling fits

Safeguard's policies and gates can enforce checks in the pull request, and its compliance and evidence automation can record that those controls were active. Pair that with your own review discipline.

A last check before fieldwork: sample a handful of merged pull requests yourself. Confirm each had an independent approval, passing checks and a traceable deployment. If two or three fail, look for a pattern, such as a repository missing branch protection or a bot account that merges without review. Fixing a pattern before the audit is far cheaper than explaining it afterwards.

Quick check

Last reviewed: 19 October 2026.