SOC2-CC8-CODE-REVIEW
Code Review and Approval Process
What this control does
Peer code review requirement for all changes to production application code before merging.
Implementation guidance
Enforce branch protection rules requiring at least one approving review before merge to main/production branches. No self-merges. For security-sensitive changes (auth, encryption, payment), require sign-off from the security lead. Log all code reviews in your VCS.
Requirements satisfied
Why it matters
Unreviewed code changes are a primary attack vector for introducing vulnerabilities, malicious logic, and compliance violations directly into production. Without mandatory peer review, a single compromised or careless developer can deploy backdoors, weak cryptography, or unlogged transactions. Code review enforces accountability and catches defects before they reach customers or auditors.
Evidence to collect
- GitHub/GitLab branch protection rule configuration showing required review count ≥1 and dismiss stale reviews disabled
- Pull request audit log for the past 90 days showing reviewer name, approval timestamp, and commit SHAs for all merged commits
- Screenshots of security-sensitive change PRs (authentication, encryption, payment) with documented security lead approval and sign-off timestamp
- Evidence of attempted self-merge rejection (failed merge attempt by PR author or automated rule enforcement message)
Testing procedure
Auditor should (1) verify branch protection rules are active on main/production branches via VCS admin console and confirm review requirement is set to ≥1 with 'dismiss stale reviews' disabled, (2) sample 20 merged pull requests from the past 90 days and confirm each has ≥1 approving review from a user other than the author, (3) locate ≥3 security-sensitive changes (authentication, encryption, payment logic) and verify security lead approval is documented in PR comments with timestamp and name, (4) attempt to create a test PR as a developer, self-approve it, and confirm merge is blocked by policy.
Common gotchas
The most common failure is allowing authors to dismiss reviewer feedback or auto-dismissing stale reviews after branch updates—these settings must be explicitly disabled to prevent reviewers' concerns from being buried. Second gotcha: security-sensitive changes are often missed in the escalation process because teams lack a clear definition of what requires security lead approval (define this explicitly in your process: specific file paths, function names, or API endpoints that always trigger escalation).