Code changes flow through a reviewed pull request workflow with committed evidence

SOC 2 CC8.1 requires that changes to production systems are authorized, tested, and approved before they ship, and the very first thing an auditor asks for is your change management evidence: pull requests, review approvals, and the CI checks that gated them. This is an evidence-pointer check: it verifies committed evidence of the control, which is what an auditor will ask for. Server-side branch protection settings live in the GitHub or GitLab dashboard and are invisible to a repository audit, so the repo needs artifacts that make the workflow real and auditable: CI that triggers on pull requests, a CODEOWNERS file, branch protection exported as code, or a PR template. AI-generated and vibe-coded apps typically fail here because the default workflow is a solo founder (or their coding agent) committing straight to main and letting Vercel deploy it: no PR, no reviewer, no gate. That habit is fine for a prototype, but for SOC 2 it means every change to production is a one-person unauthorized change, and an auditor will flag the entire change management criterion as not operating. Setting up a PR-based flow with branch protection takes about 10 minutes on GitHub, which makes this one of the cheapest readiness wins in the whole audit.

On GitHub this takes about 10 minutes: protect your default branch (Settings, Branches or Rulesets: require a pull request before merging, require at least one approval, require status checks), then commit the evidence so an auditor can see it in the repo. Add a pull_request trigger to your CI workflow:

# .github/workflows/ci.yml
on:
  pull_request:
  push:
    branches: [main]

Add a .github/CODEOWNERS file assigning reviewers to paths, a .github/PULL_REQUEST_TEMPLATE.md prompting for test evidence, and export your branch protection as code: either a probot .github/settings.yml with a branches: protection block, or the ruleset JSON from gh api repos/{owner}/{repo}/rulesets committed under .github/rulesets/. Server-side branch protection is invisible to a repo audit, so the committed export is what turns the setting into evidence.