Change management — CC8 in SOC 2 terms — is the control that governs how the organization modifies its systems. The risk it addresses is fundamental: unauthorized or inadequately tested changes are among the most common causes of security incidents and system outages. CC8 requires that every change to in-scope systems follows a defined, documented process with appropriate authorization, testing, and review before production deployment.
Change Categories and Requirements
| Change Type | CC8 Requirements | Evidence Required |
|---|---|---|
| Standard infrastructure changes | Documented change request; business justification; risk assessment; approval by authorized reviewer; test evidence; rollback plan | Ticketing system record with all fields completed; approval timestamp; test results or test sign-off |
| Software releases / deployments | Code review completed and documented; automated test pass; security scan pass; deployment approval; release record | Pull request with review approvals in version control; CI/CD pipeline logs showing all gates passed; deployment record |
| Emergency changes | Expedited approval (documented); post-deployment review within defined timeframe (typically 24–48 hours) | Emergency change ticket with expedited approval; post-deployment review record; root cause of urgency documented |
| Security configuration changes | Elevated approval requirement (security team or CISO sign-off); impact assessment; testing in non-production environment first | Change ticket with security team approval; test environment testing records; production deployment confirmation |
| Third-party / vendor updates | Assessment of vendor change for impact on security controls; approval before implementation in production | Vendor release notes review; impact assessment; approval record; post-implementation verification |
The Change Evidence Trail
CC8 auditors focus on whether changes can be fully reconstructed from evidence: who requested the change, who approved it, what testing was performed, and when it was deployed. In Type II audits, auditors will sample 20–40 changes from the observation period and attempt to trace each through the complete lifecycle from request to deployment. Any gap in the evidence trail — a missing approval, a missing test record, a deployment that predates its approval timestamp — is a finding.
| KEY IDEA | The most efficient change management implementation for DevOps-oriented teams is enforcing the change process through tooling, not documentation. If the CI/CD pipeline requires a passing security scan and at least one code review approval before a pull request can be merged, and production deployments only happen through the automated pipeline, the change management evidence is automatically generated in the version control and pipeline logs — requiring no additional manual documentation. |
Secure Development Lifecycle (SDLC) Integration
CC8 extends to the software development lifecycle. Security must be integrated into the development process — not added at the end as a pre-release check. For SOC 2 compliance, this means: security requirements considered during design, security testing (SAST, DAST, SCA) integrated into the CI/CD pipeline, dependency management with vulnerability scanning, and code review processes that include security considerations.
Evidence for the secure SDLC includes: documented SDLC policy or procedure; SAST scan results in CI/CD logs; SCA scan reports showing dependency vulnerability monitoring; code review statistics from the version control platform; and any security architecture review records for significant new features or architectural changes.
| BITLION INSIGHT | Organizations that implement automated security scanning in CI/CD pipelines — even simple SAST and SCA scans — generate continuous CC8 evidence with zero additional operational effort. The scan runs on every commit, the results are logged in the pipeline, and the pipeline can be configured to block deployments for critical findings. This is the most efficient possible CC8 implementation: security enforcement generates audit evidence as a byproduct. |
Change Management in Cloud Environments
For cloud-native organizations, infrastructure changes often happen through infrastructure-as-code (IaC) tools like Terraform or AWS CloudFormation. These tools provide natural change management controls: changes to infrastructure are proposed as code changes in a version control system, reviewed by peers before merge, and applied through automated pipelines. IaC change management is excellent evidence for CC8 — the full change history is in the version control audit log, with approvals and deployment records automatically captured.
The gap for many cloud-native organizations is ad-hoc changes made directly in cloud consoles — bypassing the IaC process for speed or convenience. These console changes are detected by cloud audit logs (CloudTrail, Azure Activity Log) but lack the approval evidence of an IaC workflow. A policy against direct console changes to production, enforced through Service Control Policies or Azure Policy, closes this gap and keeps the change management evidence trail clean.