GitHub Branch Protection Evidence for SOC 2

Introduction

GitHub branch protection evidence for SOC 2 is the set of records showing that rules on your production branches required review and passing checks before code merged, that those rules stayed in place during the audit period, and that any bypass was limited and reviewed.

This guide covers what to collect for GitHub specifically: protected branch and ruleset settings, the repository inventory, bypass lists, audit log history, and sampled pull requests. For the definition, see What Is Branch Protection?. For how auditors test the broader criterion, see CC8.1 Change Management Controls: What Auditors Test.

Where Branch Protection Fits in SOC 2

SOC 2 does not require GitHub or branch protection by name. CC8.1 in the AICPA Trust Services Criteria expects changes to be authorized, tested, approved, and implemented in a controlled way. Many software teams write a control along these lines:

Hypothetical control: Changes to in-scope repositories are merged to the production branch only through pull requests that receive at least one approval from someone other than the author and pass required status checks.

When a control is written like that, branch protection is the configuration that enforces it, and auditors commonly inspect it alongside a sample of merged changes. What you need to show depends on how your control is worded, so match evidence to your own control description.

Protected Branches vs Rulesets

GitHub offers two ways to protect branches:

Many organizations use both. Collect evidence for whichever applies to each in-scope repository, and note when a ruleset and a branch rule both apply, because the most restrictive combination is what takes effect. See GitHub's documentation on about protected branches and about rulesets.

Evidence to Collect

1. In-scope repository inventory

Start with a list of every repository that can deploy to production systems in scope. Include the repository name, the production branch, the owner, and whether it is archived. Auditors commonly compare this list to deployment pipelines or infrastructure to check completeness. A repository missing from the inventory is a repository whose protection nobody checked.

2. Protection settings for each in-scope branch

For each production branch, capture the settings that support your control. Common ones include:

• Require a pull request before merging
• Required number of approvals
• Dismiss stale pull request approvals when new commits are pushed
• Require approval of the most recent reviewable push
• Require review from code owners, if your control relies on it
• Require status checks to pass, and which checks are required
• Block force pushes and deletions
• Whether rules apply to administrators, or who is on the bypass list

Screenshots work, but exports are easier to compare over time. The GitHub REST API returns branch protection settings for a branch and lists rulesets for a repository or organization, and it can return the rules that apply to a given branch. Keep the export date with the file.

3. Bypass list and admin access

Record who can bypass protection: repository admins, organization owners, specific teams, and GitHub Apps on a ruleset bypass list. Auditors commonly ask why each person or app needs bypass and how bypass use is reviewed. Keep this list short and named. Tie it to your access review process if bypass rights come from admin roles.

4. Settings stayed in place during the period

A screenshot taken on the last day of the audit period does not show what was configured in month three. For Type 2, show that protection held across the period:

• Organization audit log entries for changes to protected branch rules and rulesets, with who made each change and when
• A change ticket or approval for any intentional settings change
• Periodic exports of settings, for example monthly, that you can compare

GitHub retains audit log events for a limited time, so export or stream the audit log if your period is long. See GitHub's documentation on reviewing the audit log for your organization.

5. Sampled pull requests

Configuration shows the gate existed. Samples show changes went through it. For each sampled merged pull request, auditors commonly look for:

• The approving reviewer and timestamp, from someone other than the author
• Approval after the last code push, or a re-approval
• Required status checks passing on the merged commit
• A linked ticket or other authorization, if your control requires one
• The merge time and who merged

See What Is Pull Request Approval? and What Is an Audit Sample? for those terms.

6. Bypass and emergency merges

Any merge that skipped protection needs its own record: why it happened, who did it, and the after-the-fact review. If your control allows emergency changes, show that each one in the period followed that path.

Common Gaps

• New repositories created during the period with no protection applied
• Protection on main but not on release or deploy branches
• Required approvals set to zero, or stale approvals still counting
• Status checks configured but not marked required
• Administrators exempt with no review of their merges
• Settings changed and changed back with no ticket
• Audit log history lost because it was never exported
• Deployments that run from branches or tags outside the protected path

A Practical Preparation Checklist

1. Build and date the in-scope repository inventory.
2. Export protection settings and rulesets for every production branch.
3. Name everyone and every app on the bypass list, with a reason.
4. Export or stream the organization audit log for the full period.
5. Ticket every intentional change to protection settings.
6. Review any bypass or emergency merge after the fact and keep the record.
7. Confirm you can produce a complete list of merged pull requests for the period, per repository.
8. Spot-check a few merged pull requests against your control attributes before the auditor does.

Framework Notes

NIST SP 800-53 Rev. 5 covers configuration change control in CM-3 and access restrictions for change in CM-5. ISO/IEC 27001:2022 Annex A includes access to source code (8.4) and change management (8.32). None of these name GitHub branch protection; teams map it as an implementation. For the full set of change artifacts beyond GitHub, see Change Management Evidence for SOC 2.

How AuditFlo.co Helps

AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.

For branch protection, that can mean dated history for pull request reviews, merges, and related tickets, so samples are easier to pull for the audit period. GitHub remains the system of record for protection settings and its audit log. AuditFlo.co does not configure your repositories, does not test your controls, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.

To see the workflow for your stack, request a demo.

Final Thoughts

Strong GitHub branch protection evidence has three parts: the settings, proof they held for the whole period, and sampled changes that went through them. Most gaps come from scope, such as a repository or branch nobody protected, and from history, such as audit log events that were never kept.

FAQ

Does SOC 2 require GitHub branch protection?

No. SOC 2 does not name tools. Branch protection is a common way teams enforce review and testing in support of CC8.1 when their control is written that way.

Is a screenshot of branch protection settings enough?

For a Type 1 report, a dated screenshot or export may support design. For a Type 2 report, auditors commonly also want evidence that settings stayed in place across the period and samples of changes that went through them.

Should rulesets or protected branch rules be used?

Either can support a control. Rulesets can apply across many repositories and have explicit bypass lists, which can make evidence easier to collect at scale. Document whichever you use.

What if an admin bypassed protection during the period?

Record why, who, and the after-the-fact review. Your auditor will decide how to treat it based on your control description and the records you provide.

Does AuditFlo.co change our GitHub settings?

No. GitHub remains the system of record for branch protection. AuditFlo.co helps organize dated evidence, such as pull requests, approvals, and tickets, from systems you already use.