How to prove branch protection for SOC 2

Branch-protection evidence is strongest when it proves both the rule that should prevent an unreviewed change and recent pull requests that show the rule operating. A settings screenshot alone proves configuration at one moment; an approval list alone does not prove that review was required.

Define the population first

List the repositories and default or release branches that can affect production. Reconcile that list with the repositories you collect. Archived experiments may be out of scope; a deployment repository omitted by accident is not. Keep the organization, repository, branch, and capture time with the artifact.

Capture the preventive configuration

Depending on your change policy, inspect and retain:

• required pull-request reviews and the minimum approval count;
• required status checks and whether the branch must be current;
• code-owner review requirements for sensitive paths;
• stale-approval dismissal or last-push approval;
• restrictions on direct pushes, force pushes, deletion, and bypass; and
• whether administrators are subject to the rule.

GitHub's protected-branch documentation describes these settings and their interactions. Rulesets may also apply, so confirm which effective rule governs each branch instead of assuming a single branch-protection object tells the full story.

Pair configuration with operating evidence

Select recent, in-period pull requests from the in-scope branches. Retain the author, commits, approvals, reviewer identity, status checks, merge actor, and merge time. Link the pull request to the change ticket or other approval record when your process requires it. Include exceptions such as emergency changes and show the retrospective review defined by policy.

What branch evidence does not prove

• A repository has protection, but the production branch uses a different name.
• Reviews are required, but a broad bypass role can merge without them.
• An approval predates a material new push and stale approvals are not dismissed.
• Status checks exist, but the required check names no longer match the CI jobs.
• The rule is present today, but there is no evidence it operated during the audit period.

AuditFetch reads declared GitHub scope, captures supported branch-protection and review facts, and packages them with provenance. It does not infer deployment criticality, decide whether an exception is acceptable, or guarantee that a control is satisfied.