If you ask SOC 2 auditors where Type II exceptions most often appear, change management is a regular answer. The reason is simple: modern teams ship constantly, and every release is a potential sample. A process that works 98 percent of the time still produces exceptions when the auditor samples that remaining two percent.
This guide explains what CC8.1 asks for, how to design change controls that fit a fast-moving engineering team, how to treat emergency changes and infrastructure changes, which evidence to collect and where companies typically stumble. It complements our broader guide to secure SDLC for SOC 2 by focusing on the approval, segregation and evidence side.
What CC8.1 says
Criterion CC8.1 in the AICPA Trust Services Criteria addresses how the entity authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to infrastructure, data, software and procedures. The criteria are summarized on the AICPA SOC suite page, and the points of focus describe typical practices: change management processes, testing, approval, emergency change handling, configuration management and protection of code and data during changes.
Related criteria also matter:
- CC6.1 and CC6.3: who can access and deploy to production.
- CC7.1: detecting unauthorized configuration changes.
- CC2.1 and CC2.2: communicating process expectations to staff.
What counts as a change?
| Change type | Examples | Typical control |
|---|---|---|
| Application code | Feature releases, bug fixes, dependency updates | Pull request review, automated tests, approval to merge and deploy |
| Infrastructure and configuration | Cloud resources, network rules, IAM policies, database settings | Infrastructure-as-code review or change ticket with approval |
| Database and data changes | Schema migrations, production data fixes | Reviewed scripts, approval, backup before execution |
| Third-party and tooling | New SaaS tool, major vendor configuration | Vendor review and approval |
| Policies and procedures | Updates to security policies | Document approval history |
| Emergency changes | Hotfix for outage or active security issue | Expedited approval with retrospective review |
Define in your policy which categories are in scope. A common auditor concern is the unlogged change: someone edits a production setting in a console and nothing records why. Treat configuration drift as a change risk as well.
The core control: five steps every sampled change should show
- Request and authorization. A ticket, issue or pull request describing the change and its reason, created by an authorized person.
- Development and peer review. Someone other than the author reviews the change. Many teams enforce this with branch protection rules.
- Testing. Automated tests, staging verification or documented manual testing, proportional to risk.
- Approval to release. An identified approver, which can be the same pull request approval for low-risk changes, or a change advisory step for high-risk ones.
- Deployment and verification. A deployment record, preferably automated, with post-deployment checks and a rollback path.
An auditor will sample changes from a population, then look for evidence of these five steps for each one. Strong teams make the evidence a by-product of their workflow, so no one has to assemble it later.
Segregation of duties for small teams
The principle is that no one should be able to push their own code to production without independent review. In a five-person startup this can feel bureaucratic, but there are practical designs:
- Enable branch protection requiring at least one approving review from someone other than the author.
- Prevent administrators and bots from bypassing protection, or log and review any bypass.
- Use CI/CD pipelines that deploy only from protected branches, so developers do not need standing production access.
- Where only one engineer exists for an area, require review by a founder or external reviewer, and document the compensating control.
Access to the deployment pipeline and production should itself be reviewed periodically, a topic covered in our articles on security culture and non-human identities.
Emergency changes done right
Outages and active attacks do not wait for approval meetings. SOC 2 allows emergency changes, provided you planned for them. A defensible emergency process includes:
- A clear definition of what qualifies (for example, service outage or active exploitation), so “urgent” does not become the default.
- Who can authorize an expedited change and how, such as a named on-call lead giving verbal or chat approval that is recorded.
- A ticket created at the time or immediately afterwards.
- Retrospective peer review and approval within a defined short period.
- A post-incident review linking the change to the incident record.
The red flag for auditors is a pattern: if many changes are labelled emergency, the exception has swallowed the rule. Track the proportion and investigate if it grows.
Infrastructure and configuration changes
Application code is only part of the story. A single security group or IAM policy edit can expose data. Reduce risk by:
- Managing infrastructure as code with the same review process as application code.
- Restricting direct console changes in production, or requiring a ticket for them.
- Using cloud audit logs and configuration monitoring to detect unreviewed changes. Our guides on cloud security best practices and continuous controls monitoring show how.
- Keeping a rollback or restore plan for risky changes.
Evidence auditors typically request
| Evidence | Purpose |
|---|---|
| Change management policy with approval and review history | Defines the control |
| Population of production changes for the period (from source control, CI/CD or ticketing) | Basis for sampling |
| For each sampled change: ticket or pull request, reviewer, test results, approval, deployment record | Shows the five steps operated |
| Branch protection and pipeline configuration screenshots | Shows enforcement is technical, not just procedural |
| Emergency change records with retrospective approval | Shows the exception path is controlled |
| List of users who can deploy or administer pipelines | Segregation of duties |
| Infrastructure change logs and review records | Covers non-code changes |
Produce the population directly from your source systems with documented parameters. If it is assembled by hand, auditors may question completeness. For the broader evidence set, see what documentation is required for a SOC 2 audit.
Common change management mistakes
- Self-approved changes. The author merges their own pull request because branch protection was not enforced for admins.
- Review without evidence of testing. The code was reviewed, but no test results exist.
- Direct production edits. Hotfixes applied on a server or console with no record.
- Population gaps. Changes made through a side channel, such as a manual deploy script, are missing from the list.
- Retroactive approvals. Approvals created after deployment for normal changes, which weakens the control.
- Inconsistent policy. The policy requires two reviewers while the tool allows one.
- Vendor and tool changes ignored. A new data-processing SaaS tool is adopted without review.
Many of these appear in our list of common SOC 2 audit mistakes.
Designing change management that does not slow engineering
Heavy approval boards frustrate developers and often make the process worse because people route around them. A lighter model usually works better for SaaS teams:
- Risk-tier your changes. Low-risk changes need a standard pull request review. Higher-risk ones, such as authentication, encryption or database migrations, need additional approval.
- Automate evidence. Pull requests, test pipelines and deployment logs create the record automatically.
- Use templates. Pull request and ticket templates prompt for the reason, test steps and rollback plan.
- Review samples yourself. Each month, pull ten recent changes and check that all five steps are present. Fix process problems early.
- Make exceptions visible. Report the number of emergency and bypassed changes to leadership.
What this means for your business
Customers care about change management because uncontrolled releases cause outages and security incidents. A clear, automated change control also shortens your own audit. The aim is not paperwork but dependable releases that you can prove.
Our SOC 2 readiness service reviews your release workflow against CC8.1 and helps close gaps before the observation period starts, and our SOC 2 for startups page shows how lean teams can stay compliant without slowing down. For help during the audit, Type I and Type II audit support and 24×7 GRC chat and Slack support are available. The report itself is issued by an independent CPA firm.
Frequently asked questions
What is change management in SOC 2?
It is the set of controls that ensure changes to production systems are authorized, tested, approved and recorded. CC8.1 is the main criterion, supported by access control and monitoring criteria.
Do we need a change advisory board for SOC 2?
No. SOC 2 does not require a board. Many SaaS companies use pull request reviews and automated pipelines instead, with extra approval only for high-risk changes.
Can a developer approve their own change?
Generally no. Auditors expect independent review. If your team is too small, document a compensating control such as review by another engineer or founder and enforce it technically where possible.
How are emergency changes handled in SOC 2?
They are acceptable if your process defines them, records them and requires retrospective review and approval. Frequent emergency changes may draw scrutiny.
Do infrastructure changes count as changes?
Yes. Changes to cloud resources, network rules, IAM policies and database configuration are in scope for change management and should follow reviewed, traceable processes.
What evidence do auditors sample for changes?
They take a sample from your population of production changes and look for the request, peer review, testing, approval and deployment record for each one.
Does using GitHub or GitLab satisfy change management?
These tools can provide strong evidence through protected branches, required reviews and deployment logs, but the control is your configured process, not the tool itself. Make sure settings enforce your policy.
Conclusion
SOC 2 change management comes down to one promise: nothing reaches production without a reason, a second pair of eyes, testing and a record. Build that promise into your pipeline, plan for emergencies, extend the same discipline to infrastructure and check your own samples each month. Do that, and CC8.1 becomes a routine part of how you ship rather than an audit-time scramble.
