Prove it with three things: the branch protection or ruleset settings on your main and release branches, a sample of recent merged pull requests showing real reviews, and a short log of any exceptions. A written policy helps, but settings and history are what a reviewer can check.
What reviewers are looking for
An investor or acquirer wants to know whether one person can push code to production unchecked. The risk is both accidental, a bug nobody caught, and deliberate, an attacker or insider adding something malicious.
The OpenSSF Scorecard documentation frames its Code-Review check the same way: it checks whether a project requires human review before pull requests are merged, and notes that reviews can detect unintentional problems and deter an attacker inserting malicious code. Its Branch-Protection check looks at whether default and release branches are protected with GitHub branch protection or repository rules, for example by requiring review or passing status checks, or by preventing rewriting of public history.
The evidence pack
| Evidence | What it shows | How to produce |
|---|---|---|
| Ruleset or branch protection settings | Rules exist and apply | Screenshot or exported settings with date |
| Sample of merged pull requests | Rules are followed | Ten recent PRs, with reviewer and approval time |
| Required status checks list | Tests and scans gate merges | Settings view |
| Exceptions log | Bypasses are rare and recorded | Admin override history and reasons |
| Admin list | Few people can change the rules | Export of repository admins |
Steps
- For each production repository, confirm the default branch and release branches have a rule requiring pull requests.
- Set the number of required approvals and decide whether the author can approve their own change. Make it not allowed.
- Require status checks that matter: build, tests, dependency review, secret scanning.
- Limit who can bypass the rules, and decide how bypasses get recorded.
- Pull a sample of merged pull requests across authors and weeks. Include small and large changes.
- Write a one paragraph note describing how the process works for emergency fixes.
The small team problem
With three engineers, strict two approver rules can stall work. A defensible setup is one required approval from someone other than the author, with an emergency path that allows a merge and requires a retroactive review within a day. Describe that honestly. Buyers know startups are small.
Red flags
Direct pushes to main in the commit history. Admins who routinely bypass protections. Review approvals that arrive seconds after a pull request opens, which suggests rubber stamping. Repositories with no protection at all, especially infrastructure and deployment code.
Do not overclaim
Say what is enforced by settings and what is convention. "All production repositories require one approving review, enforced by branch rules" is a claim you can back with a screenshot. "Every change is reviewed" is a claim someone will test.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a pull request can be stopped by a policy check before merge, the kind of control a buyer wants to see enforced rather than promised.
Safeguard offers policies, gates and guardrails that can block risky changes at pull request time. A free scan is available for a first look at a repository.
Quick check
Is a screenshot enough evidence?
It is a start. Add the pull request sample, since it shows the rule working over time.
What if bots merge dependency updates?
Say so, and show the rules the bot is subject to, such as passing tests and a human approval for major version changes.
Sources
Last reviewed: 19 October 2026.
