Why change management is a critical SOC 2 control
Change management is one of the most-tested areas in SOC 2 Type II audits. It's also where many fast-moving SaaS startups fail — not because they're reckless, but because their practices are good and informal rather than documented and evidenced.
SOC 2 CC8 (Change Management) requires that changes to infrastructure and software are authorised, tested, and reviewed before deployment to production. The question isn't whether you do code review — almost everyone does. The question is whether you can prove it with evidence auditors can see.
What frameworks require
| Framework | Reference | Requirement |
|---|---|---|
| SOC 2 | CC8.1 | Changes to infrastructure, data, software, and procedures are authorised, designed, developed, tested, configured, and implemented to meet change management controls |
| ISO 27001:2022 | A.8.32 | Changes to information processing facilities and systems subject to change management procedures |
| ISO 27001:2022 | A.8.8 | Technical vulnerabilities managed — patch management as a change management process |
| HIPAA | §164.308(a)(5)(ii)(B) | Protection from malicious software — includes change control to prevent unauthorised software deployment |
| PCI DSS | Req 6.3–6.5 | Security vulnerabilities addressed, development and testing separated, code reviews required |
| NIS2 | Art. 21(2)(e) | Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure |
The core change management controls
1. Separation of development, staging, and production environments
The most fundamental change management control: code should never go directly to production from a developer's machine. At minimum, you need:
- Development environment: where code is written and unit tested
- Staging/pre-production: where changes are tested against production-like data and infrastructure
- Production: live customer-facing environment
Production access should be limited to the deployment pipeline and specific on-call roles — not every engineer. This is a common SOC 2 gap: developers with direct production database write access because "we might need to fix things fast."
2. Code review requirements
Code review is your primary change management control for software changes. SOC 2 auditors look for:
- At least one peer review required before merge (documented in PR)
- Branch protection rules enforced in your repository (GitHub: protected branches with required reviews)
- No self-approvals (the author cannot also be the sole reviewer/approver)
- Security-sensitive changes (authentication, access control, payment processing, data exports) require review by a senior engineer or security reviewer
Evidence auditors will ask for: screenshots of branch protection settings, sample PRs with review approvals, pull request history for the audit period.
3. Testing requirements
What testing is required before deployment? At minimum for most SOC 2 assessments:
- Automated unit/integration tests passing in CI pipeline
- Staging environment test before production deploy (especially for major changes)
- Security testing: dependency vulnerability scanning (Dependabot, Snyk, npm audit), SAST (Semgrep, CodeQL) for security-critical code paths
- Regression testing for changes that affect existing functionality
4. Deployment authorisation
Who can authorise and trigger a production deployment? This should be explicit in your policy. Common models:
- Auto-deploy on merge to main: Works if your branch protection and review requirements are strong. CI/CD pipeline IS the authorisation gate. Document this explicitly.
- Manual deploy trigger: Engineer triggers deploy after merge. Creates an additional approval moment but adds friction.
- Release manager model: Designated person authorises each production release. Required for HIPAA-adjacent environments or higher-risk changes.
Whatever model you use, document it — and make sure your CI/CD pipeline logs are retained as evidence.
5. Change documentation
Changes should be documented before deployment. The minimum documentation set:
- Description of change and business justification
- Affected systems/components
- Risk assessment (low/medium/high)
- Test results
- Rollback plan
- Approver and timestamp
For most SaaS companies, the pull request IS the change documentation. A well-maintained PR with description, test evidence, reviewer sign-off, and linked ticket satisfies this requirement if you can produce it during an audit.
6. Emergency change procedures
Every policy needs an emergency change procedure — what happens when production is down and you need to deploy a fix immediately without the normal review cycle. The key principle: emergency changes bypass normal process but are documented and reviewed retroactively.
- Designated emergency approvers (on-call lead + CTO, for example)
- Emergency change logged immediately (ticket, Slack #incidents, PagerDuty record)
- Post-emergency review within 24–48 hours: root cause, what was deployed, was it appropriate
- Emergency changes tracked separately and reviewed in regular change review meetings
SOC 2 auditors will ask: "How do you handle emergency changes?" Having a documented process — even one that's rarely used — demonstrates mature change management.
Evidence collection: what SOC 2 auditors actually want
SOC 2 Type II auditors typically sample 10–25 changes from your audit period and review evidence for each. What they look for:
| Control | Evidence | Where to Find It |
|---|---|---|
| Code review required | PRs showing ≥1 approving review from someone other than the author | GitHub/GitLab PR history |
| Branch protection enforced | Screenshot of branch protection settings requiring PR + reviews | GitHub Settings → Branches |
| Automated testing in pipeline | CI/CD pipeline logs showing tests run and passed before deploy | GitHub Actions / CircleCI / Jenkins logs |
| Staging test before production | Deployment logs showing staging deploy preceded production deploy | CI/CD logs, deployment records |
| Change description documented | PR descriptions or change tickets with description and justification | GitHub PRs, Jira tickets |
| Production deploy authorisation | Approval in pipeline or sign-off in change ticket before production deploy | CI/CD approval gates, Jira workflow |
| Emergency changes reviewed retroactively | Post-emergency review ticket or meeting notes | Jira, Notion, incident log |
Infrastructure changes: same process applies
Change management doesn't just apply to application code. Infrastructure changes — Terraform/Pulumi changes, Kubernetes config updates, cloud IAM changes, database schema migrations — follow the same principles:
- Infrastructure as Code (IaC) in version control: Terraform/Pulumi changes go through pull requests with the same review requirements as application code
- Plan before apply:
terraform planoutput reviewed beforeterraform applyin production - Automated drift detection: infrastructure should match code; untracked manual changes are a red flag
- Database migrations: schema changes tested in staging, migration rollback plan documented
Security patches and vulnerability management as change management
ISO 27001 A.8.8 requires vulnerability management. Patches are a type of change and should flow through your change management process — but with tighter timelines:
| Severity | Patch Timeline | Change Process |
|---|---|---|
| Critical (CVSS 9.0+) | 24–72 hours | Emergency change process; immediate patch or mitigating control; post-patch review |
| High (CVSS 7.0–8.9) | 7–14 days | Prioritised in next sprint; standard review + testing; staging before prod |
| Medium (CVSS 4.0–6.9) | 30 days | Standard change process; included in scheduled maintenance windows |
| Low (CVSS <4.0) | 90 days | Tracked and addressed in normal development cycle |
Common change management failures in SaaS audits
| Failure | SOC 2 Impact | Fix |
|---|---|---|
| PRs merged without review | CC8.1 finding — no evidence of authorisation | Enforce branch protection: required reviews, cannot self-approve |
| No documented emergency change process | Gap finding — "what happens when you need to move fast?" | Write a 1-page emergency change SOP; train on-call engineers |
| Direct pushes to main/master | Critical finding — branch protection not enforced | Protect main branch; force all changes through PRs |
| Developers with prod database write access | CC6 + CC8 overlapping finding | Restrict prod DB access to DBA role + deployment pipeline service account only |
| No staging environment | Testing gap — changes not tested before production | Even a basic staging environment on the same cloud satisfies this; document it |
| CI/CD logs not retained | Can't produce evidence for sampled changes | Retain CI/CD logs for minimum 1 year; export to log management system |
Related guides and generators
- Information Security Policy Generator
- Access Control Policy Generator
- Incident Response Plan Generator
- SOC 2 Gap Assessment Generator
- SOC 2 Evidence Pack Generator
- ISO 27001 Gap Assessment Generator
- SOC 2 Gap Analysis: How to Assess Readiness Before Hiring an Auditor
- SOC 2 Evidence Collection: What Auditors Actually Need to See
- ISO 27001 Gap Assessment Guide
⚠️ This guide is for informational purposes only and does not constitute legal advice. SOC 2 requirements depend on your Trust Service Criteria scope and assessor interpretation. Engage a qualified SOC 2 auditor for your specific programme.