SOC 2 CC8 Change Management Guide: Criteria, Evidence and Pitfalls

SOC 2 CC8 has a single criterion, CC8.1, yet it touches every deployment, infrastructure edit, configuration change and patch made during the review period, which makes it one of the easiest places to collect exceptions. This guide explains what CC8.1 asks, the points of focus that sit under it including the two added in the 2022 revision, how auditors build and test the change population, and the evidence that survives a Type 2 sample. It covers code, infrastructure as code, cloud console changes, data fixes and emergency changes, and the machine identities that now make most changes. It is for engineering managers, platform and DevOps leads, and compliance owners preparing for a SOC 2 examination. The general change process is in the Change Management Security guide; the wider SOC 2 picture is in the SOC 2 Guide.

A note on sources: the criteria are the AICPA's 2017 Trust Services Criteria (With Revised Points of Focus, 2022), distributed by the AICPA behind a free account. The criterion and point-of-focus wording below is paraphrased and was cross-checked against published secondary copies and an EY summary of the 2022 revisions, not against the AICPA download. Confirm exact wording against the AICPA text before quoting it in a system description. Confirm against the official text before relying on it.

Key takeaways

• One criterion, a long life cycle: CC8.1 asks that changes to infrastructure, data, software and procedures are authorised, designed, developed or acquired, configured, documented, tested, approved and implemented to meet the entity's objectives.
• The population is every change, not every ticket: auditors reconcile tickets to what actually reached production, so a deployment with no ticket is the classic CC8 exception.
• Segregation of duties is the core test: the person or pipeline that writes a change should not be the only one that approves and deploys it, or a compensating detective control must exist.
• The 2022 revision added patching and resilience: new points of focus cover identifying, testing and implementing software patches, and considering resilience requirements during change management.
• Pipelines are change actors: CI/CD service identities, deploy keys and bots make most production changes, so their permissions and any bypass of branch protection are CC8 evidence, not only CC6 evidence.

What CC8.1 asks

CC8.1 states, in summary, that the entity authorises, designs, develops or acquires, configures, documents, tests, approves and implements changes to infrastructure, data, software and procedures to meet its objectives. The verbs are the life cycle an auditor expects to see evidenced. The scope words matter as much: "infrastructure" covers cloud resources and network configuration, "data" covers direct production data fixes, and "procedures" covers changes to the documented process itself.

The AICPA attaches points of focus to each criterion. They help an entity design controls, but the EY summary of the 2022 revision notes that using the criteria does not require every point of focus to be met, and that the points of focus are unlikely to be exhaustive for most service organisations. The table lists the CC8.1 points of focus as shown in published copies.

How auditors test CC8

1. Walkthrough: the auditor follows one change from request to production to confirm the process matches the system description.
2. Population request: a complete list of changes in the period. Mature auditors ask for it from the system of record for production (deployment logs, merged pull requests on the release branch, infrastructure as code apply logs) rather than from the ticketing tool, and reconcile the two.
3. Sample selection: changes are sampled across the period and across change types, with emergency changes often tested separately.
4. Attribute testing: each sampled change is traced to its ticket, the reviewer or approver (who must differ from the author), test evidence, and a deployment record dated after approval.
5. Configuration inspection: branch protection, pipeline permissions and production access settings are inspected, and the auditor checks whether they held for the whole period.
6. Exception evaluation: failures appear in the description of tests and results, with management's response where given. See How to Read a SOC 2 Report Guide.

Evidence that survives a Type 2 sample

On GitHub, the branch protection settings most often relied on are "Require pull request reviews before merging" with a required approval count, "Dismiss stale pull request approvals when new commits are pushed", "Require approval of the most recent reviewable push", "Require status checks to pass" and "Do not allow bypassing the above settings". GitHub documents that, by default, administrators and roles with the bypass permission are exempt from branch protection unless that last setting is enabled, so an export showing it disabled invites a question about admin merges. Other platforms have equivalent settings. See the GitHub and GitHub Actions Security Guide.

Emergency changes and incidents

• Define emergency narrowly: service restoration or an actively exploited vulnerability, not a missed release date. A high emergency share is itself a signal the auditor will notice.
• Keep the trail: the expedited change still needs a ticket, an identifiable person who approved it at the time (even verbally, recorded after), and a retrospective review within a stated window, such as two business days (an NHI Mgmt Group suggestion).
• Link incidents: fixes arising from incidents are a named point of focus, so incident records should reference the change that resolved them. The incident side is tested under CC7; see the SOC 2 CC7 System Operations Guide.

Where identity fits: who is allowed to change production

Most production changes are now made by machine identities: CI/CD service accounts, cloud deployment roles, infrastructure as code runners, bots that merge dependency updates and, increasingly, AI coding agents that open pull requests. CC8 testing asks whether only authorised people or processes deploy changes, so these identities are part of the evidence.

• Deployment identity: production changes should come from a pipeline identity with scoped permissions, ideally using short-lived federated credentials, not a long-lived key copied into a runner. See the CI/CD Pipeline Identity Security Guide.
• Who can change the pipeline: anyone who can edit a workflow file or pipeline variable can change what is deployed. Treat pipeline definitions as changes subject to the same review.
• Bots and agents as authors: a dependency bot or AI agent can author a pull request, but approval should come from a human or a separate control, so author and approver are not the same identity.
• Third-party pipeline code: actions and plugins pulled by tag change without passing through your review. The tj-actions/changed-files compromise showed how repointed tags put new code into thousands of pipelines; pinning to commit SHAs brings those changes back under control. See How to Pin GitHub Actions to Commit SHAs.

Preparing CC8 for a first Type 2

1. Find every path to production: pipelines, console access, database clients, SaaS admin consoles and scheduled scripts. Each path is either closed, routed through the change process or covered by a detective control.
2. Choose the system of record: decide which log is the authoritative change population (usually deployment or merge history) and confirm it can be exported for any date range.
3. Enforce in tooling: branch protection with no bypass, pipeline-only deployment rights, and environment approvals where the platform supports them. Policies that rely on people remembering produce exceptions.
4. Write controls you can meet every time: "every change to the production branch requires one approving review by someone other than the author" is testable; "all changes are fully regression tested" is not.
5. Run a mock test: before the period starts, pull a month of deployments and trace ten to each attribute (our suggestion). Fix the reconciliation gaps first.
6. Add a detective control: a periodic reconciliation of production changes to approved tickets, reviewed and signed, catches what preventive controls miss and gives management something to show when an exception appears.

Decision guidance: small and large organisations

A small team where everyone has production access can still pass CC8 if the description is honest: preventive review on the main branch, plus a documented detective review of direct changes. Overstating the control is what produces exceptions.

Detection and measurement

• Share of production deployments that reconcile to an approved change record.
• Merges to protected branches without an independent approval, including administrator bypasses.
• Emergency changes as a share of all changes, and share approved retrospectively within the window.
• Infrastructure changes made outside the pipeline, from cloud audit logs.
• Configuration drift from baseline detected and resolved. See the Configuration Drift and Baseline Enforcement Guide.
• Exceptions self-identified during the period against those found by the auditor.

Framework mapping

This mapping is NHI Mgmt Group's own and indicative. NIST SP 800-128 covers security-focused configuration management in depth. For an ISO crosswalk see the SOC 2 to ISO 27001 Mapping Guide.

Common failure patterns

• Population drawn from tickets only: the auditor reconciles to deployment logs and finds changes that never had a ticket.
• Administrator bypass left on: branch protection exists but administrators merged without review during the period, and the export proves it.
• Author approves own change: self-approval through a second account, a shared bot or a pipeline that merges on the author's command.
• Console changes outside the process: security group or IAM edits made by hand in a cloud console, visible in audit logs but absent from change records.
• Emergency as the default: a large share of changes flagged emergency, with retrospective approvals missing or late.
• Unpinned pipeline dependencies: third-party actions, images or plugins that change underneath the pipeline without any review.

Practitioner checklist

• List every path to production and decide how each is controlled.
• Choose deployment or merge history as the change population and test the export.
• Enforce independent review on production branches with no administrator bypass.
• Restrict production deployment to pipeline identities with scoped, short-lived credentials.
• Route infrastructure, data fixes and SaaS configuration through the same process.
• Define emergency changes narrowly with a retrospective approval window.
• Show patch identification, testing and deployment as part of change management.
• Reconcile production changes to approved records monthly and sign the review.
• Pin third-party pipeline components to immutable references.

Standards and references

• AICPA and CIMA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• EY: AICPA revises guidance on applying its Trust Services Criteria and SOC 2 Description Criteria
• NIST: SP 800-128, Guide for Security-Focused Configuration Management of Information Systems
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• GitHub: About protected branches

Related NHI Mgmt Group resources: SOC 2 CC6 Logical Access Guide · Change Management Security · Change Management Policy Template · SOC 2 Readiness Checklist · Segregation of Duties Guide