Service
SOC 2 change management that does not slow your releases
SOC 2 change management asks you to show that production changes are authorised, tested and approved. So for most software teams, the evidence already lives in pull requests, if the rules are set up right.
- Readiness, not the audit
- An independent CPA firm signs
- Written estimate, no call
What CC8 expects in SOC 2 change management
Criterion CC8.1 covers authorising, designing, testing, approving and implementing changes. Therefore auditors sample changes and look for proof of each step. The criterion is in the AICPA Trust Services Criteria.
Using the workflow you already have
Most teams already use pull requests. So the work is usually configuration, not new process.
- Branch protection on the main branch
- At least one reviewer other than the author
- Automated tests before merge
- Deploys only from the main branch
- Tickets linked to changes
SOC 2 change management check
Tick what your repositories enforce today.
Your result appears here as you tick, so you can see what is still open.
Emergency changes
Hotfixes happen. However, they still need a record, so define an emergency path and review it after the fact.
| Change type | Required evidence |
|---|---|
| Standard | Reviewed and approved pull request. |
| Emergency | Post-deploy review within an agreed time. |
| Infrastructure | Reviewed configuration change, also via code. |
Separation of duties for small teams
In a small team, the same person may write and deploy code. That is acceptable if a different person reviews it. Also, admin bypass of branch rules should be logged and rare.
SOC 2 change management in readiness
We configure and document the workflow with your engineers, as part of the fixed readiness fee. Meanwhile evidence builds automatically, which the CPA firm later samples.
Configuration matters as much as code. For example, a firewall rule changed by hand in a cloud console is still a production change. So either route such changes through code review too, or log and review them separately. Otherwise the auditor may sample a change that left no approval behind. One reviewed route for every change is simpler to defend.
SOC 2 change management questions
Do we need a change advisory board for SOC 2 change management?
No. For most software teams, reviewed pull requests are enough.
Can a two-person team comply?
Yes, as long as each person reviews the other's changes.
What do auditors sample in SOC 2 change management?
A set of production changes, checking review, testing and approval for each.
Do database changes count?
Yes, so route them through reviewed scripts or migrations.
Related guides
Set up SOC 2 change management properly
Tell us your repositories and deploy tools. We reply with a written scope and a fixed fee.
See if we can help