CC8.1 — Change management

Changes to infrastructure, data, software, and procedures are authorized, designed, developed or acquired, configured, documented, tested, approved, and implemented.

Also written as CC 8.1, TSC CC8.1, SOC2 CC8.1, SOC 2 Type 2 CC8.1.

Written by Jett N. · Last reviewed 22 July 2026

What SOC 2 CC8.1 requires

Change management is one of 1 criteria in the Change Management (CC8) series of the Security (Common Criteria) category. Changes to infrastructure, data, software, and procedures are authorized, designed, developed or acquired, configured, documented, tested, approved, and implemented. CC8 is a single criterion but a broad one — every change to infrastructure, software, and configuration needs an authorisation and testing trail, and auditors commonly sample changes straight from your ticketing or version-control system.

Audit evidence assessors look for

When preparing for a SOC 2 audit against CC8.1, gather artefacts such as:

Points of focus for CC8.1

The Trust Services Criteria set out points of focus that describe what an auditor considers when assessing CC8.1. They are not themselves requirements, but they shape the testing:

• Changes are authorised before implementation.
• Changes are designed, developed or acquired, and configured in a controlled manner.
• Changes are tested before being placed into production.
• Changes are documented and approved, including emergency changes.

How to implement CC8.1

1. Let the tooling be the evidencePull request approvals, CI pipeline records and deployment logs are contemporaneous, complete and cheap. A separate change register maintained by hand is duplicative and will disagree with reality at some point during a 12-month period.
2. Define what counts as a changeInfrastructure-as-code, configuration toggles, feature flags and database migrations are all changes. Organisations that define change narrowly as application releases leave the majority of production modifications outside the control.
3. Enforce separation between author and approverWhere team size makes true separation impossible, a documented compensating control — post-deployment review by a second person, or automated policy checks — is acceptable. What is not acceptable is silence on the point.
4. Handle emergency change explicitlyEmergency changes will happen. Define the path, require retrospective approval within a stated window, and keep those records. Auditors deliberately look for emergency changes and treat an organisation claiming none as either untested or not looking.
5. Evidence rollback capabilityThe criterion covers implementation, and being able to reverse a change is part of controlled implementation. Rollback plans in the change record, or demonstrable pipeline rollback, satisfy this.

Common audit findings for CC8.1

What actually gets raised against CC8.1, in rough order of how often it comes up:

• Direct production changes bypassing the pipeline, visible in deployment logs but absent from the change records.
• Self-approved changes where the author and approver are the same person, with no compensating control documented.
• Emergency changes with no retrospective approval, or an organisation asserting no emergency changes occurred in 12 months.
• Infrastructure and configuration changes excluded from the change process entirely.

Scoping CC8.1

CC8.1 is a single criterion covering an unusually broad surface, and it is Common Criteria so it always applies. Because auditors sample directly from version control and deployment tooling, the evidence is largely outside your ability to curate — which makes fixing the process the only real preparation.

ISO 27001 mapping

CC8.1 corresponds to the following ISO 27001:2022 Annex A control(s): A.5.8, A.8.4, A.8.9, A.8.19, A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.30, A.8.31, A.8.32, A.8.33. If you already run an ISO 27001 ISMS, map your existing evidence for these controls to CC8.1 rather than duplicating work.