An independent reviewer is someone other than the author, with the knowledge and authority to approve the change. In practice that means a different person from the one who pushed the latest commit, enforced by repository settings rather than by trust. Write the rule down and let the platform check it.
What independence means
Three tests help:
- Different person. The approver did not write the change. Pairing is a gray area, so decide in advance whether a co-author may approve.
- Authority. They are allowed to approve changes to that area. A new intern is not independent in the useful sense for an authentication change.
- Awareness. They saw the actual change, not an earlier version.
The third test is the one teams miss. If an author pushes new commits after approval, the approval may no longer apply to what ships.
Settings that enforce it in GitHub
GitHub's documentation describes these options for protected branches:
| Setting | What it does |
|---|---|
| Required approving reviews | Pull requests need a set number of approvals before merging |
| Dismiss stale approvals | Approvals are dismissed when commits that affect the diff are pushed |
| Require review from code owners | Changes touching owned code need an approval from an owner |
| Require approval of the most recent reviewable push | The latest reviewable push must be approved by someone other than the person who pushed it |
| Do not allow bypassing the settings | Applies the rules to administrators too, who are otherwise exempt by default |
The "most recent reviewable push" option directly addresses self-approval after a late edit. The bypass setting matters because, per the documentation, restrictions do not apply to people with admin permissions by default.
Code owners and independence
With CODEOWNERS, GitHub notes that owners need explicit write access and that when a line lists several owners, approval from any one of them satisfies the requirement. That is fine for most code, but if the author is also listed as an owner of that path, check whether the rule still gives you an independent second person. Combine code owner review with the most recent push rule to be safe.
Steps to put it in place
- Write the independence rule in your change policy, including who may approve what.
- Enable required approvals and the most recent push setting on production branches.
- Enable dismissal of stale approvals.
- Decide on admin bypass, and if you allow it, require an incident or ticket link and review the bypass list monthly.
- For small teams with only two people, document who reviews whom and how the founder's own changes are checked.
- Export branch rule settings quarterly as evidence, dated.
What to show an auditor
- The setting export.
- A sample of merged PRs showing different author and approver.
- The list of bypass events and their tickets.
- The written rule.
Edge cases
- Bots: an automated account is not a judgment-making reviewer. Treat bot-authored changes as a separate class with their own checks and a human approver.
- Pair programming: say whether the pair counts as one person for independence.
- Urgent fixes: use the emergency path, not silent bypass.
Quick check
Can the author approve their own pull request?
Not if your policy requires independence. Configure the platform so that it cannot happen without a recorded bypass.
Does an approval stay valid after new commits?
Only if you leave stale approval dismissal off. Turning it on forces re-review of the changed diff.
Safeguard policies, gates and guardrails can enforce review conditions on pull requests, with compliance and evidence automation to record them. Try a free scan.
Sources
Last reviewed: 19 October 2026.
