SOC 223 April 2026 8 min read

SOC 2 Change Management: CC8.1 Requirements Explained

CC8.1 governs how you manage changes to infrastructure and applications. Learn what SOC 2 auditors look for in your change management process and how to build compliant controls.

Key Takeaways

CC8.1 requires that changes to infrastructure, data, and software are authorized, tested, and documented before deployment to production.
The core evidence is code review records — every production deployment must trace back to an approved pull request with at least one reviewer.
Change management controls apply to infrastructure-as-code changes (Terraform, CloudFormation) as much as application code changes.
Emergency changes are permitted but must follow a documented fast-track process with retroactive approval and post-change review.
Separation of the author and approver is the key principle — the person who writes the change should not be the only person who approves it.

In this guide

CC8.1 Explained
Required Controls
Code Review as Evidence
Infrastructure Changes
Emergency Changes
Testing Requirements
Evidence Auditors Collect

CC8.1 Explained

CC8.1 is the SOC 2 criterion governing change management. The full criterion requires that the entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. In plain English: no unauthorized changes should reach production, and every change should leave a documented trail showing it was reviewed and approved.

Change management is tested by auditors as one of the highest-confidence indicators of a mature engineering organization. An organization with strong change controls prevents accidental data exposure from untested code, unauthorized modifications by rogue engineers, and configuration drift between environments. Weak change management is a leading indicator of security incidents.

CC8.1 connects to several other criteria: CC6.1 (access controls, ensuring only authorized people can deploy), CC7.1 (monitoring, detecting unauthorized changes), and CC9.1 (risk mitigation through controls). A finding in CC8.1 often triggers follow-up examination of related criteria.

Required Controls

The minimum change management controls for SOC 2 compliance are: (1) a formal change management policy defining who can authorize changes, what the approval process is, and what types of changes require different levels of review; (2) branch protection rules on your production branch (e.g., `main` or `master` in GitHub/GitLab) preventing direct pushes; (3) required code review with approval from at least one person other than the author before merging; and (4) CI/CD pipeline integration ensuring automated tests must pass before deployment.

Additional controls that strengthen your posture include: staging environment testing before production deployment, security code scanning (SAST) integrated into the CI pipeline, manual QA for high-risk changes, deployment windows limiting when production deployments can occur, and change advisory board (CAB) review for major infrastructure changes.

Your change management policy must address the full lifecycle: request, review, approval, testing, deployment, and post-deployment verification. For most SaaS companies, the pull request process in GitHub or GitLab serves as the change request system — the PR description documents the change, the review process provides approval, and merged PR history provides the audit trail.

Code Review as Evidence

For the application code component of CC8.1, the primary evidence is your Git history: merged pull requests with reviewer approvals. Auditors sample production deployments during the observation period and trace each one back to the originating PR. For each sampled deployment, they verify: the PR was created by a developer (not self-merged), at least one other person approved the PR, automated CI tests passed, and the deployment occurred after approval (not before).

Configure your repository with branch protection settings that enforce these controls automatically. In GitHub, this means: require pull requests before merging (no direct pushes to main), require approvals (minimum 1, ideally 2 for critical paths), require status checks to pass (your CI pipeline), and dismiss stale reviews when new commits are pushed. Screenshot these settings as evidence that controls are enforced technically, not just by policy.

Auditors may sample 20–40 production deployments from across the observation period. If your team makes 200 deployments per month, they will not review all of them — but they will check that the sampled ones each have compliant PR records. A single self-merge (a developer merging their own PR without a reviewer) in a sample of 30 will generate an exception. Even one exception in a critical control like CC8.1 can create qualification risk for the report.

Infrastructure Changes

Infrastructure-as-code (IaC) changes — Terraform configurations, CloudFormation templates, Kubernetes manifests, Helm chart updates — are subject to the same CC8.1 requirements as application code. A common gap in first-time SOC 2 audits is a company with rigorous application code review but IaC changes committed directly to main without review.

Store all IaC in the same Git repositories (or separate repositories with the same branch protection rules) as application code. Treat a Terraform change that opens a security group rule as at least as high-risk as an application code change — arguably higher, since a misconfigured security group can expose your entire production environment. Require two reviewers for changes that affect network access, IAM policies, or database configurations.

Cloud console changes (clicking through the AWS or GCP console to modify infrastructure) are a change management anti-pattern for SOC 2. They leave weaker audit trails than IaC changes and cannot be reviewed in a PR workflow. If console changes are necessary for operational reasons, log them via CloudTrail (AWS), Cloud Audit Logs (GCP), or Activity Log (Azure) and document the business justification. Ideally, restrict console write access to a break-glass emergency role that requires MFA and generates an alert on use.

Emergency Changes

Emergency changes — urgent fixes deployed outside the normal approval workflow — are a recognized category in change management. SOC 2 does not prohibit emergency changes, but it requires them to be governed by a documented fast-track process. The typical emergency change process: declare an incident justifying the emergency change, implement the change with verbal or chat-based approval from a second engineer, document the change and the approval in a ticket or incident record, and complete a post-change review within 24–48 hours confirming the change was appropriate and did not introduce new risks.

Retroactive approval documentation is the critical evidence element for emergency changes. If an emergency change was deployed without a PR review, the post-incident record must capture: who made the change, what the change was, who verbally approved it, and the outcome of the post-change review. Auditors understand that emergencies happen; what they test is whether the emergency change process was followed and documented.

Limit who can declare emergency changes. If any engineer can self-declare an emergency and bypass review, the emergency process will be abused for routine deployments that engineers don't want to wait for review on. Define "emergency" in your policy with specific criteria (active P1 incident, data integrity issue affecting production customers) and track the frequency of emergency changes — an increasing trend is an indicator that the normal process is too slow and engineers are working around it.

Testing Requirements

CC8.1 requires that changes are tested before deployment. For most SaaS companies, this is satisfied by automated test suites run in CI/CD — unit tests, integration tests, and end-to-end tests that must pass before a PR can be merged. Document your testing requirements in your change management policy and enforce them through CI pipeline branch protection checks.

Manual testing in a staging environment is required for high-risk changes such as database schema migrations, major feature releases, or infrastructure changes affecting network topology. Your policy should define what constitutes a "high-risk change" and what additional testing is required. Document staging environment test results — a comment on the PR or a linked test record satisfies the evidence requirement.

Security testing of changes (SAST, dependency scanning, secrets detection) integrated into CI provides additional evidence that changes were reviewed for security implications before production deployment. Tools like GitHub Advanced Security, Snyk, Semgrep, or SonarQube integrated as required CI checks show auditors that security is embedded in the change process rather than applied retroactively.

Evidence Auditors Collect

Auditors testing CC8.1 will request: (1) your change management policy; (2) repository branch protection configuration screenshots; (3) a sample of production deployments with corresponding PR records showing reviewer approvals and CI pass status; (4) records of any emergency changes during the observation period with post-change review documentation; and (5) your CI/CD pipeline configuration showing automated testing requirements.

For IaC changes, auditors may also request screenshots of your Terraform plan/apply logs or CloudFormation deployment records linked to approved PRs. For cloud console changes, CloudTrail logs for the observation period may be requested to verify that console modifications were limited and documented.

The most efficient way to prepare change management evidence is to use a compliance automation platform that integrates with GitHub or GitLab. Platforms like AuditPath can automatically collect merged PR records with approval metadata, CI status, and deployment timestamps — assembling the change management evidence package without manual exports.

Frequently Asked Questions

Does SOC 2 require a change advisory board (CAB)?

No. SOC 2 does not require a formal CAB. The criterion requires authorization and approval, not a committee review body. For most SaaS companies, code review in the PR workflow satisfies the authorization requirement. A CAB may add value for organizations making complex infrastructure changes with cross-team impact, but it is not an audit requirement for typical SaaS products.

Can the same person write and approve a change?

No. The separation principle is central to CC8.1. The person who writes the change should not be the person who approves it. This prevents unauthorized changes (a rogue engineer making a malicious change and self-approving it) and catches errors that the author might miss. Branch protection rules should be configured to require approval from a person other than the PR author. Repository owners or administrators should not be able to override this rule without triggering an alert.

What if we are a two-person engineering team — can we review each other's PRs?

Yes. A two-person team satisfies the separation principle as long as neither engineer can self-approve their own PR. Engineer A reviews Engineer B's PRs and vice versa. If your team is so small that one engineer is regularly on call alone and cannot get a review, document this as a compensating control: the solo engineer documents the change rationale in the PR, deploys, and sends a review request to the other engineer for retroactive review within 24 hours. This is not ideal but is better than no review process.

Does change management apply to database changes as well as code changes?

Yes. Database schema changes (migrations) are subject to CC8.1 requirements. Store migration scripts in version control, review them in PRs, and test them in staging before running in production. Database data changes (direct SQL edits to production data) should follow an even stricter process — typically requiring a ticket, a reviewed script, a backup before execution, and dual approval. Direct production database modifications by individual developers should be restricted and auditable.

How does SOC 2 change management relate to ITIL change management?

SOC 2 CC8.1 covers the same conceptual ground as ITIL change management (change request, approval, testing, deployment, review) but is less prescriptive. ITIL defines specific record types, roles, and processes; SOC 2 only requires that the outcome is achieved — authorized, tested, documented changes. If your organization already follows ITIL, your existing change records will satisfy CC8.1 evidence requirements with minimal additional work.