Code review is a change management control only when the platform enforces it. A team that reviews every pull request out of habit has a good practice. A team whose default branch rejects unreviewed merges has a control, and an auditor can test it.
Branch protection is where that enforcement lives. It is a handful of settings or a ruleset, and the questions auditors ask about it are predictable: what is required, who can get around it, and was it in place for the whole period.
This article covers the rules that matter, the repositories they should cover, the bypass paths auditors probe, and the evidence that shows the configuration held. The review practice itself (who reviews, what a good review looks at) is covered in code review as a change management control.
Why the setting matters more than the habit
Under SOC 2, the relevant criterion is CC8.1: the entity authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to infrastructure, data, software and procedures. ISO 27001:2022 covers the same ground in Annex A 8.32 (change management), with 8.4 (access to source code) and 8.25 (secure development life cycle) close by. PCI DSS v4.0 addresses changes to system components in Requirement 6.5.
None of these names branch protection. They require that changes are approved before they reach production. Branch protection is how most software teams make that approval mandatory rather than customary.
The difference shows up in testing. If review is a habit, the auditor samples merged changes and checks each for an approval, and one unapproved merge is an exception. If review is enforced, the auditor can also inspect the configuration and the list of people who can bypass it. Many auditors still sample changes, but the question shifts from "did people remember" to "could anyone skip it". That is an easier question to answer well.
The rules that matter
Source control platforms name these differently. The substance is the same.
Require a pull request before merging. No direct pushes to the default branch or to release branches. Every other rule assumes this one.
Require at least one approval from someone other than the author. Check the edge case: on some configurations, a person who pushed commits to the branch can approve it. A rule requiring approval from someone other than the last person to push closes that gap.
Dismiss stale approvals when new commits arrive. Without this, a reviewer approves a small change and the author pushes a large one afterward. The approval on record covers code the reviewer never saw.
Require named status checks to pass. Tests, builds and any security scans you describe as controls. A rule that requires checks but names none enforces nothing.
Require code owner review for sensitive paths. Infrastructure definitions, authentication code, pipeline configuration and the code owners file itself. The file maps paths to the people or teams who must approve.
Block force pushes and branch deletion. A force push rewrites history, which destroys the record the auditor samples from. Blocking deletion keeps a release branch, and its history, from disappearing.
Apply the rules to administrators. If administrators are exempt, the control holds for everyone except the people with the most access.
Signed commits, linear history and merge queues are useful, and some teams adopt them. They are not usually what an auditor tests. A signed commit proves which key created it, not that anyone reviewed it.
Which repositories need protection
Scope follows your SOC 2 system description or your ISMS scope. In practice that means repositories that build and deploy software into the in-scope production environment, plus the infrastructure code and pipeline definitions that can change it.
The repositories teams most often miss:
The infrastructure repository. It can change production as directly as application code, often more so.
Pipeline definitions held separately. If someone can change the deploy workflow without review, they can deploy without review.
New repositories. Rules configured one repository at a time leave each new one unprotected until someone remembers. Organization-level rules that apply by default close this gap.
Release branches and tags. If production deploys from them rather than from the default branch, they need the same protection.
Expect the auditor to ask for the list of in-scope repositories before anything else. That list is the population, and every later test depends on it being complete.
The bypass paths auditors probe
A sceptical auditor asks one question: how could a change reach production without passing through the protected branch? Prepare an answer for each of these.
Bypass lists. Most platforms let named users, teams or apps bypass rules. Keep the list short and named, with a reason for each entry. A bypass granted to an administrators team that includes half of engineering is not an exception, it is the rule.
Bots and service accounts. Automation that merges dependency updates or pushes release commits often holds bypass rights. Scope it to the repositories and branches it needs, and keep status checks mandatory for its merges.
Deploying from unprotected branches. If the pipeline will deploy any branch to production, protection on the default branch is decorative. Production deploy jobs should run only from protected references, and production credentials should be available only to those jobs.
Direct production access. Console changes and shell sessions skip the code path entirely. That belongs to managing privileged access, but the auditor will raise it in the same conversation.
Turning protection off and on again. An administrator disables a rule, merges, and re-enables it. The configuration looks correct at every point you check except the one that mattered. Only the platform's audit log shows it.
Evidence that covers the whole period
A screenshot of the settings page shows one moment. A SOC 2 Type II report covers months. Auditors give more weight to system-generated records than to images of a screen, for the reasons set out in screenshots vs system-generated evidence.
A set that holds up:
The rule configuration, exported. Pulled from the platform's API for each in-scope repository, on a schedule (monthly is common), and stored with the date.
The bypass list, with the reason for each entry and the date it was last reviewed.
The audit log of rule changes. Every creation, edit or removal of a protection rule during the period, and who made it. If there were none, a dated query showing no results over the period is itself evidence.
Bypass events. Each merge that used a bypass, linked to its emergency change record and after-the-fact review.
A list of merged changes for the period, exported from the platform, so the auditor can select a sample and check approvals and status checks on each.
Audit log retention on source control platforms varies by plan and can be shorter than your audit period. Export the log on a schedule. Pulling it during fieldwork may return only the last few months.
What teams get wrong
Most failures here are not missing rules. They are rules that look right and stopped working.
Renamed checks. A required status check is named after a CI job. Someone renames the job, and the requirement either blocks every merge until someone deletes it, or stops matching anything. After any pipeline change, confirm the required checks still correspond to real jobs.
A policy that promises more than the platform enforces. "All changes are peer reviewed" in the policy, with no enforcement behind it, invites a sample-based test. Write the policy to match the configuration, then keep the configuration.
Protecting the branch nobody deploys from. Confirm which reference production actually builds from, and protect that.
Forgetting that the rules are changes too. A change to branch protection is a change to a control. If you manage rules as code, review them through the same protected path as everything else. If you manage them by hand, the audit log is your only record.
The useful habit is a short quarterly check: export the rules, compare them with the last export, and review the bypass list. It takes an hour and it finds drift before the auditor does.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the code and cloud systems you connect and routes failures to their owners. Evidence collection pulls configuration from those systems on a schedule, timestamped and attributed, so the audit period is covered by records rather than a screenshot taken during fieldwork.