Search for SOC 2 in pull requests and you mostly get process checklists: require reviews, status checks, and signed commits. Those settings matter. They are evidence that a change-management process exists. CC8.1 (Common Criteria change management) is also about whether the control operated for a given change: was the change authorized the way your policy says, or did a hotfix, bot, or emergency path skip a required step.
This guide is the PR-grain slice. It does not re-teach Type I versus Type II (see /guides/how-to-pass-soc-2-as-a-startup) and does not map the whole CC6 access family (see /guides/what-soc-2-actually-checks-in-your-repo). It focuses on change management at the moment a pull request is merged.
Branch protection is necessary, not sufficient
Requiring one approving review and a green CI check is the usual baseline. Auditors sample whether that process ran over the observation window. A repo with protection on still produces exceptions when someone merges with admin override, when a deploy path bypasses the protected branch, or when an automation account merges without the human approval your policy claims is required.
The code-facing tell is not always in application source. It is often in workflow files, CODEOWNERS, deploy scripts, or a one-line change to who can approve. Those still land as pull requests.
Worked example: emergency path that skips the required approval
On-call is paged. An engineer opens a pull request that adds a workflow_dispatch job with continue-on-error and a path that deploys production from a personal fork using a long-lived token, documented as "break-glass." A second PR the same day changes CODEOWNERS so that path no longer requires the platform team. Both PRs look like ops hygiene. The application code may not change at all.
What CC8.1 cares about is whether changes to production still go through the authorized change process. A break-glass path that permanently weakens required approvals is a control change, not just a convenience. During a Type II window, if the auditor samples deploys that used that path without the documented approval, you are explaining an exception. Catching the workflow and CODEOWNERS diffs at review time is cheaper than explaining them six months later.
How this ties to the observation window (without re-teaching the audit)
For Type II, the auditor tests whether controls operated over a period. A single skipped approval inside that window can become a sampled exception even if the rest of the year was clean. That is why change-management hygiene during the window is not bureaucracy for its own sake; it is how you avoid surprising the opinion you spent months preparing. Details of readiness, scoping, and auditor selection stay on the startup SOC 2 process guide.
A pull-request compliance check that cites CC8.1 on a weakened approval gate does not approve the emergency. It makes the process change visible while the PR is still open.
Where heygrc fits, and the honesty boundary
heygrc is built to read pull requests against the frameworks you selected, including SOC 2 when enabled, and to name criteria such as CC8.1 when a change appears to weaken change management (approval gates, required checks, deploy authorization). It does not run your audit, collect IdP or HR evidence, or issue an opinion.
Keep your code-quality reviewer. CC8.1 is about process integrity on the change, not whether the hotfix was elegant.