Controls30 April 2026 7 min read

CC8: Change Management Controls for SOC 2 Compliance

SOC 2 CC8 requires formal change management controls for software and infrastructure. Learn the requirements, evidence, and how to configure your CI/CD pipeline for compliance.

Key Takeaways

CC8.1 requires changes to be authorized, tested, and approved before deployment to production.
Code review (pull request approval) is the primary change authorization control for software.
Infrastructure-as-code with GitOps workflow provides the strongest change management evidence.
Emergency change procedures must be documented and any emergency changes must be retroactively approved.
Auditors sample production deployments and trace each back to an approved PR and test evidence.

In this guide

What Is CC8?
Change Authorization (CC8.1)
Testing Before Production
Infrastructure Change Management
Emergency Change Procedures
CI/CD Pipeline Configuration
CC8 Evidence Checklist

What Is CC8?

CC8 has a single sub-criterion: CC8.1, which requires the entity to authorize, design, develop or acquire, configure, document, test, approve, and implement changes to infrastructure, data, software, and procedures to meet its objectives. It is the change management criterion.

The spirit of CC8 is that uncontrolled changes are a major source of outages and security vulnerabilities. Unauthorized code changes could introduce backdoors; unreviewed infrastructure changes could expose data. CC8 ensures every change to the production system goes through a defined process before it takes effect.

Change Authorization

For software changes, the primary authorization control is pull request (PR) review and approval. Your GitHub, GitLab, or Bitbucket repository should have branch protection rules that require at least one approving review before merging to the main branch, and prohibit direct pushes to protected branches.

In GitHub, configure branch protection at Settings > Branches > Branch protection rules: require a pull request before merging, require at least 1 approving review, dismiss stale PR approvals when new commits are pushed, and require status checks to pass before merging.

The approver should be someone other than the author — self-approvals defeat the purpose of code review as a control. For small teams, having the CTO approve all infrastructure changes and requiring any team member review for application changes is a reasonable configuration.

Testing Before Production Deployment

CC8.1 requires testing as part of the change management process. Automated tests run as part of the CI/CD pipeline — unit tests, integration tests, security scans — satisfy the testing requirement when the pipeline blocks deployment if tests fail.

Your CI/CD pipeline (GitHub Actions, CircleCI, AWS CodePipeline) should: run automated tests on every PR, block merge if tests fail, run a security scan (Snyk, Semgrep, or Trivy for container images), and deploy to a staging environment before promoting to production.

Evidence: CI/CD pipeline configuration file (e.g., .github/workflows/deploy.yml), pipeline run logs showing tests passed for each production deployment during the audit period.

Infrastructure Change Management

Infrastructure changes must follow the same controlled process as software changes. The best practice is Infrastructure as Code (IaC) using Terraform, AWS CloudFormation, or AWS CDK, with all infrastructure changes made via code and deployed through the same PR review and CI/CD process.

Enable AWS Config to detect any infrastructure change made outside of your IaC process (drift detection). If Config reports that an EC2 security group was modified manually through the Console, that is a CC8 finding — the change bypassed the review process.

AWS CloudTrail provides an immutable record of all infrastructure changes with timestamps and actor identity. Cross-reference CloudTrail with your IaC deployment records to verify all changes were authorized.

Emergency Change Procedures

Emergency changes — hotfixes required immediately to prevent or recover from an outage or security incident — cannot always wait for the normal review process. Document an emergency change procedure that: defines what qualifies as an emergency, allows deployment with a single approver (instead of the normal two), and requires retroactive review and approval within 24 hours.

Emergency changes should be rare. Auditors will review any emergency change that occurred during the audit period and verify it met the emergency criteria and received retroactive approval. Frequent emergency changes suggest the normal change process is too slow and needs adjustment.

CI/CD Pipeline Configuration for CC8

A CC8-compliant CI/CD pipeline enforces the following: (1) All code changes go through a PR — no direct commits to main or release branches. (2) At least one reviewer who is not the author must approve. (3) Status checks (tests, security scans) must pass. (4) The deployment is triggered by the merged PR — not by a manual "deploy" button that bypasses the gate.

Additional controls: separate deployment credentials for staging vs production (production deploy keys should not be accessible to developers), deployment notifications to a Slack channel or audit log, and environment-specific approval gates for production deployments.

CC8 Evidence Checklist

(1) GitHub/GitLab branch protection rules screenshot. (2) Change management policy documenting the requirement for PRs, reviews, and approvals. (3) Sample production deployments from the audit period — auditors typically request 5-10 samples — traced to approved PRs with reviewer identity and timestamp. (4) CI/CD pipeline configuration and sample run logs. (5) Emergency change records (if any) with retroactive approval. (6) AWS Config drift detection report showing no unauthorized infrastructure changes.

Frequently Asked Questions

Does every change need a ticket (Jira, Linear) for CC8, or is a PR sufficient?

A PR with a description, linked review, and approval is generally sufficient for code changes. A separate ticket adds traceability between the business requirement and the code change, and is preferred for significant changes. Your change management policy should define when a ticket is required.

Can founders or senior engineers approve their own PRs for CC8?

No. Self-approval defeats the segregation of duties purpose of code review. Branch protection rules should be configured to require an approving review from someone other than the PR author. GitHub's "Require review from Code Owners" can be used to enforce that certain files (infrastructure, security-critical code) require a specific named reviewer.

What about database schema changes — how do those fit CC8?

Database migrations should also go through the change management process — the migration script should be in source control, reviewed as part of a PR, and deployed through the CI/CD pipeline. Tools like Flyway or Liquibase manage database migrations as versioned files in your repo.

How do auditors sample production deployments for CC8?

Auditors request a list of all production deployments during the audit period (from your CI/CD tool or AWS CodeDeploy logs), then randomly select 5-25 samples depending on deployment frequency. For each sample, they trace it to an approved PR showing the reviewer, approval timestamp, and passing test status.

We do continuous deployment — hundreds of deployments per week. Do we need to evidence each one?

No. Auditors use statistical sampling. For high-frequency deployment environments, they will sample 20-30 deployments from across the audit period and verify the process was followed consistently. The key is that your pipeline enforces the controls — every deployment must go through the gate, not just the sampled ones.