CC8 and CC9 cover two of the most practically demanding areas of SOC 2 compliance: change management and risk mitigation through vendor and business continuity controls. Together, these two criteria account for a disproportionate share of Type II exceptions — not because organizations fail to implement the controls, but because the evidence trails required are extensive and operationally demanding to maintain consistently over a 12-month period.
CC8 — Change Management
CC8 requires that changes to the system — including infrastructure changes, application code deployments, and configuration changes — are authorized, tested, and implemented through a controlled process. The objective is to prevent unauthorized or inadequately tested changes from introducing security vulnerabilities or system instability into the production environment.
| Change Category | CC8 Requirements | Evidence Requested |
|---|---|---|
| Infrastructure changes (cloud, network, servers) | Changes documented in a change request system; approved by an authorized reviewer; tested before production deployment; rollback plan defined | Infrastructure change tickets with approval evidence; Terraform/CloudFormation pull request approvals; IaC merge history |
| Application code deployments | Code review completed before merge; deployment pipeline enforces review requirements; production deployments logged | GitHub/GitLab PR history showing code review approvals; CI/CD pipeline logs; deployment records |
| Emergency changes | Expedited approval process defined; emergency changes reviewed post-deployment within defined timeframe | Emergency change records; post-deployment review evidence; frequency of emergency changes as an indicator of control health |
| Configuration changes (security settings) | Security-relevant configuration changes require elevated approval; changes logged and reviewable | Configuration change audit logs; approval workflow evidence; change communication records |
| KEY IDEA | The most common CC8 finding in Type II audits is not the absence of change management — it is evidence gaps: a change was made but the ticket doesn’t exist, or the ticket exists but the approval is missing, or the approval exists but the test evidence is absent. A complete change management trail has request + approval + test evidence + deployment record, all linked to the same change. |
Secure Development Lifecycle
CC8 extends beyond operational changes to cover the security of the software development process itself. Organizations that develop their own software must demonstrate that security is considered throughout the development lifecycle: requirements include security considerations, code is reviewed for security defects, dependencies are managed and scanned for vulnerabilities, and production deployments follow a controlled release process.
Evidence for the secure development lifecycle includes: a documented SDLC policy; evidence of security requirements in user stories or design documents; static analysis security testing (SAST) results integrated into CI/CD; software composition analysis (SCA) for dependency vulnerability scanning; and the deployment approval workflow showing that code cannot reach production without review.
CC9 — Risk Mitigation: Vendor Risk Management
CC9 covers the risk mitigation strategies deployed for risks that cannot be fully controlled through internal controls alone. The two primary areas under CC9 are third-party / vendor risk management and business continuity.
Vendor risk management under CC9 requires that the organization identifies critical third-party service providers, assesses their security posture, and monitors ongoing compliance. For most technology organizations, this means maintaining a vendor inventory, risk-tiering vendors by their access to data and systems, performing annual due diligence on high-risk vendors (including requesting and reviewing their SOC 2 reports), and ensuring contractual security requirements are in place.
| Vendor Risk Element | SOC 2 Requirement | Evidence |
|---|---|---|
| Vendor inventory | Comprehensive list of third-party service providers with access to in-scope systems or data | Vendor register with vendor name, service description, data access, and risk tier |
| Risk tiering | Vendors classified by risk level based on data access, system access, and business criticality | Risk tier methodology; risk tier assignments for each vendor; rationale for tier assignment |
| Due diligence | High-risk vendors assessed annually; low-risk vendors assessed at onboarding | Vendor questionnaire responses; review of vendor SOC 2 reports; vendor security assessment records |
| Contractual requirements | Data processing agreements (DPAs) and security addenda in place with high-risk vendors; right to audit clauses where appropriate | Executed DPAs and security addenda; contract clauses referencing security requirements |
| Ongoing monitoring | Process for monitoring vendor SOC 2 report renewals; process for responding to vendor security incidents | Vendor SOC 2 review log; evidence of follow-up on vendor exceptions; vendor incident notification records |
CC9 — Risk Mitigation: Business Continuity
Business continuity under CC9 — particularly relevant when the Availability TSC is in scope — requires that the organization has documented recovery procedures, defined recovery time and recovery point objectives (RTO/RPO), and evidence of testing those procedures. The key failure mode here is organizations that have a business continuity plan on paper but have never tested whether it actually works.
Evidence for business continuity includes: the BCP/DR plan document; RTO and RPO definitions for critical systems; backup configuration and retention settings; evidence of backup restoration tests (not just backup creation); and tabletop exercise records showing that the DR process was walked through and gaps identified and addressed.
| BITLION INSIGHT | The most common CC9 finding is backup testing rather than backup configuration. Organizations configure automated backups correctly, but never test whether those backups can actually be restored within the defined RTO. Auditors will ask: “When did you last successfully restore from backup? What was the result?” Without a documented restoration test, the backup control cannot be relied upon — and auditors will note this. |