How do I prove change management for SOC 2 using GitHub PRs?
March 6, 20262 min readSOC 2 Evidence Collection
Why GitHub PRs Are Great SOC 2 Evidence
GitHub pull requests naturally create the audit trail that CC8.1 requires. Each PR contains:
- Description: What changed and why
- Diff: Exactly what code was modified
- Review: Comments and approval from a peer
- CI checks: Automated test results
- Merge timestamp: When the change went to production
This is better evidence than most enterprise change management systems produce.
Setting Up GitHub for CC8.1
Branch Protection (Required)
Configure branch protection on your main branch:
- Require pull request reviews before merging (minimum 1 reviewer)
- Require status checks to pass (your CI pipeline)
- Prevent force pushes to main
- Do not allow bypassing the above settings (even for admins)
CI Pipeline
Ensure GitHub Actions (or your CI tool) runs on every PR:
- Unit tests
- Linting or type checking
- Build verification
PR Template (Recommended)
Create a PR template that prompts for:
- Summary of changes
- Type of change (feature, bugfix, refactor)
- Testing performed
- Related ticket or issue number
Evidence to Collect
| Evidence | How to Get It |
|---|---|
| Branch protection settings | Screenshot of GitHub settings page for main branch |
| Sample PRs with reviews | Links to 25+ PRs from the audit period showing approval |
| CI pipeline configuration | GitHub Actions YAML file or screenshot |
| Deployment records | Vercel/deployment platform showing deploys triggered by merges |
Handling Edge Cases
Direct commits to main: These will show up in audit sampling. Prevent them with branch protection rules.
Hotfixes: Document emergency changes with a post-deployment PR explaining the urgency and why normal review was bypassed.
Admin bypasses: Set branch protection to "Do not allow bypassing" — even for admins. This eliminates the temptation and the audit risk.