Two engineers can meet SOC 2 change management by requiring that every change to production code is reviewed and approved by someone other than the author, enforcing that in the repository settings, and logging exceptions. The rule is simple. The proof comes from the platform, not from memory.
The criterion in one line
CC8.1 covers authorizing, designing, testing, approving and implementing changes to infrastructure, data, software and procedures. The criteria do not say how many reviewers you need. Your policy sets it, and the auditor tests that you follow it.
A workable rule for two people
- Every change goes through a pull request.
- The author cannot approve their own pull request.
- The other engineer reviews and approves.
- Automated tests and checks run before merge.
- Direct pushes to the main branch are blocked for everyone, including admins.
With two people, that means each of you is the other's reviewer. It is a real control as long as it is enforced.
Enforce it with settings
Do not rely on habit. Turn on branch protection: required approvals, required status checks, no force pushes, and no bypass for administrators. Then export the settings as evidence with a date.
If you cannot block admin bypass, log every bypass and review the log monthly.
Urgent fixes
An outage at night will tempt you to push directly. Write an emergency change path into the policy before it happens.
- Allowed when production is down or customers are harmed.
- The change still goes through a pull request, but may be merged first and reviewed within a set time, say the next business day.
- A ticket records the reason, the person who approved, and the follow up review.
Auditors accept emergency paths. They do not accept unrecorded ones.
When one engineer is away
State the fallback. A trusted non engineer, a contractor reviewer or a founder with technical background can approve in a pinch. Or the change waits. Choose one and write it down.
Infrastructure and configuration
Code is not the only change. Apply the same flow to infrastructure as code, database migrations and production configuration. If something is changed by hand in a console, record it in a ticket. Better, move it into code.
Evidence to keep
- Branch protection settings export.
- A sample of merged pull requests with approver, checks and timestamps.
- Emergency change tickets with follow up reviews.
- The policy itself, with a review date.
See change management with git pull requests for a deeper walkthrough.
Pitfalls that cause exceptions
Watch for approvals given before the final commit, since a late change can slip in after review. Turn on the setting that dismisses approvals when new commits arrive. Watch for merges by a bot account with broad rights. Watch for repositories created outside the protected organization and for forks used to deploy. Run a monthly check that lists merged changes without an approval and explain each one in writing.
Quick check
Can the CTO approve their own change?
Not under a no self approval rule. Seniority does not replace review. Write any exception into policy and log each use.
Do dependency updates need review?
Yes, if they reach production. Automated update pull requests can be approved by an engineer after checks pass.
Last reviewed: 19 October 2026.
