CC8.1 Change Management Controls: What Auditors Test

Introduction

CC8.1 is the SOC 2 criterion for change management. It says the entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. In practice, it is where auditors test whether code, configuration, and infrastructure changes reached production through the process you described.

This guide explains what CC8.1 covers and how auditors commonly test it: the population, the sample, the attributes they check on each change, and the configuration they inspect. For the full set of engineering artifacts to collect, see Change Management Evidence for SOC 2. For the definition, see What Is Change Management?.

What CC8.1 Says

CC8.1 sits in the Common Criteria of the AICPA 2017 Trust Services Criteria, with revised points of focus published in 2022. The criterion itself is one sentence. The points of focus add detail on what an entity may consider, including:

• Managing changes throughout the system life cycle
• Authorizing, designing, documenting, tracking, testing, approving, and deploying changes
• Configuring software and maintaining baseline configurations
• Identifying changes needed to fix incidents
• Providing for changes needed in emergency situations
• Protecting confidential and personal information during changes

Points of focus are guidance, not a checklist every company must satisfy. Auditors test the controls you describe in your system description, and they use the criterion and points of focus to judge whether those controls are suitable.

What Auditors Commonly Test

Auditors set their own procedures, and procedures differ between firms. Testing for CC8.1 commonly includes four parts.

1. Inquiry and walkthrough

The auditor asks the control owner how a change moves from idea to production and walks through one real example. Expect questions such as: where is work requested, how is it reviewed, what tests run, who can deploy, and what happens in an emergency.

2. Configuration inspection

The auditor inspects settings that enforce the process. For engineering teams that often means branch protection settings on production repositories, required CI checks, who can deploy, and who can bypass those rules.

3. Population and sample

For a SOC 2 Type 2 report, the auditor asks for a complete list of changes deployed to production during the audit period. They test that the list is complete, then select a sample. Sample sizes depend on the auditor's methodology and how often the control runs.

4. Attribute testing on each sampled change

For each sampled change, the auditor checks the attributes your control describes. Common attributes are listed in the next section.

In a Type 1 report, the auditor generally evaluates design at a point in time, often through inquiry, inspection, and a walkthrough, rather than testing a sample across a period. See SOC 2 Type 1 vs Type 2.

Attributes Auditors Commonly Check

Your control wording decides which attributes apply. If your description says every change has a linked ticket, the auditor will look for a ticket on every sampled change. Write controls you actually run.

Building a Complete Population

The population is where many CC8.1 tests stall. Auditors need confidence that the list includes every change, not only the tidy ones.

Common sources include:

• Merged pull requests to production branches, exported from the code host for the period
• Deploy history from the CI/CD system
• Infrastructure change records, such as infrastructure as code merges or cloud audit logs
• Database migration history
• Change tickets for manual or configuration changes

Agree with your auditor early on which systems are in scope and how you will produce the list. Reconciling merged pull requests with deploy records is a common completeness check.

Configuration Evidence

Configuration evidence shows the process was enforced, not just followed. It commonly includes:

• Branch protection or ruleset settings for each in-scope repository
• The list of people or apps allowed to bypass protection
• Which CI checks are marked as required
• Who has permission to deploy to production
• Evidence that these settings stayed in place across the period, such as code host audit log entries

A screenshot from the last week of the period shows the current state. It does not prove the settings were in place for the whole period. Keep dated records when settings change.

Emergency Changes

Most teams need a way to ship urgent fixes faster than the normal path. CC8.1 points of focus mention emergency changes, and auditors commonly ask how they are handled.

A defensible approach usually includes:

• A written definition of what qualifies as an emergency
• A record for each emergency change, such as a ticket created during or right after the fix
• Review and approval after the fact by someone other than the author, within a set time
• Inclusion of emergency changes in the population, not a separate list that gets forgotten

Common Reasons CC8.1 Tests Produce Exceptions

• Self-approved pull requests, or merges with zero approvals
• Administrators bypassing branch protection without a record
• Changes deployed outside the pipeline, such as manual console edits
• Population exports that miss a repository or a deploy path
• Control wording that promises a ticket or a test plan on every change when the team does not do that
• Emergency changes with no after-the-fact review
• Protection settings changed mid-period with no documentation

If an auditor finds a deviation, see Exception Management and Audit Findings Remediation. If a primary control could not operate for part of the period, see Compensating Controls Evidence for SOC 2.

A Practical Preparation Checklist

1. Confirm which repositories, pipelines, and infrastructure are in scope.
2. Read your CC8.1 control wording and remove promises you do not keep.
3. Turn on branch protection with required approvals and required checks for every in-scope production branch.
4. Limit and document who can bypass protection and who can deploy.
5. Define the emergency change path and the after-the-fact review window.
6. Practice exporting a full change population for one month and reconciling it with deploys.
7. Sample a few changes yourself each month and check each attribute.

Framework Notes

The AICPA Trust Services Criteria place change management in CC8.1. Related criteria commonly touch the same evidence, including CC5.1 for control activities and segregation of duties, and CC6 for logical access to production. Outside SOC 2, NIST SP 800-53 Rev. 5 covers configuration change control in CM-3, and ISO/IEC 27001:2022 Annex A includes change management in control 8.32. See Mapping Controls Across SOC 2 and ISO 27001.

How AuditFlo.co Helps

AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.

For CC8.1, that can mean dated history of pull requests, approvals, and linked tickets, so building a population and pulling samples does not depend on reconstructing records at the end of the period. Your code host, CI/CD system, and ticketing tools remain the systems of record. AuditFlo.co does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.

To see the workflow for your stack, request a demo.

Final Thoughts

CC8.1 testing comes down to three questions: was the process enforced, is the change list complete, and does each sampled change show the attributes your control promises. Write control wording that matches how your team really ships, enforce it with branch protection and pipeline permissions, and keep the records for the whole period.

For related reading, see Change Management Evidence for SOC 2, Secure Software Development Evidence for SOC 2, What Is Segregation of Duties?, and how to prepare for a SOC 2 audit.

FAQ

What does CC8.1 cover in SOC 2?

CC8.1 covers how changes to infrastructure, data, software, and procedures are authorized, designed, tested, approved, and implemented. For most software companies, that means code, configuration, infrastructure, and database changes that reach production.

Is a pull request approval enough for CC8.1?

It is often a core piece of evidence, but auditors usually test more than one attribute, such as authorization, testing, and implementation through the approved path. Which attributes apply depends on how your control is written.

How do auditors sample changes for CC8.1?

For Type 2, auditors commonly request a complete population of production changes for the period, test its completeness, and select a sample. Sample size depends on the auditor's methodology.

Do emergency changes need approval?

CC8.1 points of focus mention providing for emergency changes. A common approach is to allow faster deployment with documented review and approval after the fact within a set time.

Does SOC 2 require branch protection?

No. SOC 2 does not name specific tools. Branch protection is a common way engineering teams enforce review and testing in support of CC8.1.

Does AuditFlo.co test our changes for the auditor?

No. Your auditor performs testing. AuditFlo.co helps organize dated evidence such as pull requests, approvals, and tickets from systems you already use.