SOC 2 CC8: Change Management Controls Explained

CC8 is a single-criterion category with outsized impact on audit outcomes. Companies that manage changes well generate audit evidence automatically. Companies that do not spend the audit scrambling to reconstruct what changed, when, and who approved it.

This post breaks down CC8.1, what auditors look for, and how to satisfy it with the tools most engineering teams already use.

What CC8 Covers

CC8 has one sub-criterion: CC8.1. It requires that changes to the systems in scope for SOC 2 go through a defined, authorized, and documented process before being applied to production.

The purpose is straightforward: unauthorized or undocumented changes are a security risk. An attacker who gains access to a production system can make changes that are invisible if there is no change management process. An insider threat can make unauthorized configuration changes. A well-intentioned engineer can introduce a misconfiguration. CC8.1 is the control that catches all three scenarios.

What Counts as a Change

Auditors interpret "change" broadly. Any modification to a production system that could affect the security, availability, or integrity of customer data falls under CC8.1.

This includes:

• Infrastructure changes: new cloud resources, modified security group rules, updated network configuration
• Application code deploys: any code merged to main and deployed to production
• Configuration changes: IAM policies, environment variables in production, firewall rules, database settings
• Third-party software updates: OS patches, dependency upgrades, agent version changes

What does not require the same level of change management: read-only changes like viewing logs, querying databases without modification, or monitoring configuration that does not affect system behavior.

What Auditors Look For

An authorized process exists

Auditors want to see that your change process is defined, not ad hoc. This means a written description of how changes are proposed, reviewed, approved, and deployed. A paragraph in your engineering handbook or a section of your change management policy document is sufficient.

Changes go through the process

Documentation of a process is not evidence that the process is followed. Auditors will sample specific changes from the audit period and verify that each one went through the defined process. They will look at PR history, CI/CD logs, and deployment records.

At least one approver before production

CC8.1 requires that changes are authorized. In practice this means a minimum of one peer review before a change can be merged and deployed. A single-approver requirement on your main branch satisfies this. Self-approvals and direct pushes to main are findings.

A log of what changed

Auditors need to trace a specific change back to a specific authorization event. Your CI/CD pipeline's deployment log, tied to the PR that triggered it, is the clearest possible evidence chain.

Terraform and CC8.1

Terraform is one of the strongest possible satisfiers of CC8.1 for infrastructure changes. A standard Terraform workflow generates evidence at every step:

1. Engineer opens a PR with infrastructure changes
2. CI runs terraform plan and posts the output as a PR comment
3. Reviewer approves the plan
4. Merge triggers CI to run terraform apply with logged output
5. The apply output is stored as a CI artifact

This workflow gives you: a proposed change, a human-readable plan, a documented approval, and a logged apply. Every piece of CC8.1 evidence is generated automatically.

The gap to close: Many teams use Terraform but do not require plan output in PRs or do not store apply logs durably. Configure your CI to post plan output and retain apply artifacts for at least 12 months to cover a full audit period.

GitHub Actions and CC8.1

GitHub Actions satisfies CC8.1 for application code changes when configured correctly:

• Branch protection requires at least one approval before merge
• Deployments to production are gated on CI passing
• GitHub provides a full audit log of deployments, approvals, and merges

Auditors will check that branch protection rules are enforced, not just documented. Export your branch protection configuration and keep a record of any changes to it.

Common CC8.1 Gaps

Direct pushes to main. A branch protection rule that allows maintainers to bypass review is a finding. Auditors check the actual configuration, not the intent.

Emergency changes without documentation. Under pressure, teams sometimes apply fixes directly to production and plan to clean up the PR later. These undocumented changes break the control chain. Train your team to document emergency changes as exceptions at the time they happen, not after.

No retention on CI logs. A deployment log that expired before the audit period started cannot be used as evidence. Configure your CI retention policies before your audit window opens.

Configuration changes outside the tracked process. A change applied through the AWS console or directly to a Kubernetes cluster, outside your IaC workflow, is invisible to your change management process. Audit CloudTrail and kubectl audit logs before your audit period to find these.

CC8.1 Evidence Summary

Mapping Terraform and CI/CD pipeline evidence to CC8.1 and keeping the change-management control current, without manual collection, is exactly the work a fractional CISO owns for you. Book a call to review your change-management controls.

Related reading

• Terraform SOC 2 Compliance Guide
• GitHub Actions SOC 2 Guide
• SOC 2 CC7: System Monitoring Requirements

Want a security leader to run this?

Xorabyte is a fractional CISO for startups who can review your cloud for the gaps found first, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.