A Practical Guide to SOC 2 Change Management Controls

SOC 2 change management controls are the documented policies, procedures, and technical configurations that authorize, test, approve, and deploy every change to production infrastructure, applications, configurations, and databases. They map to CC8.1 of the AICPA Trust Services Criteria. For a SOC 2 report you need to implement them and be able to evidence them, because auditors look for proof that changes were intentional and reviewed for risk.

Change management controls are a direct response to the AICPA’s Trust Services Criteria (TSC), specifically the Common Criteria CC8.1, which states, “The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.”

The Foundation of Change Management in SOC 2

Change management is how a change moves from a ticket to production with a record at each step. Auditors test it to confirm that no change reached production without authorization, testing and approval.

An auditor cannot test a process they cannot trace. A ticket, a reviewed pull request, a pipeline run, and a deploy record that point to each other show that a change was intentional, tested, and approved, and who requested, approved, and released it. A missing link between those records is the usual way a sampled change fails.

Key Components of a SOC 2 Compliant Change Management Process

1. Request & AuthorizationApproval from the designated owner

What happens: Document the proposed change and secure approval from the designated owner.

Evidence for audit: A formal record, such as a Jira ticket, proving changes are initiated through an authorized channel. It satisfies the “authorization” requirement of CC8.1.

2. Design & ReviewPeer review before deployment

What happens: Ensure the change is well-designed, secure, and peer-reviewed for potential issues.

Evidence for audit: Code reviews and design documents, showing that security and operational impacts were considered before deployment.

3. Testing & QANon-production environment

What happens: Validate that the change works as intended and does not introduce bugs or security vulnerabilities.

Evidence for audit: Test logs and QA sign-offs proving the change was validated outside the live system. They support the “testing” requirement.

4. Final ApprovalManagement or a Change Advisory Board (CAB)

What happens: Obtain a final sign-off before deployment.

Evidence for audit: A clear point of accountability and a timestamped record that the change is ready for production. It fulfills the “approval” requirement of CC8.1.

5. ImplementationLive environment

What happens: Deploy the approved change according to a documented plan.

Evidence for audit: Deployment logs showing a controlled, predictable process, often with rollback plans, which demonstrate operational control.

6. Post-Implementation ReviewCloses the change ticket

What happens: Confirm the change was successful and did not cause unintended negative consequences.

Evidence for audit: The closed change ticket, showing the change met its objectives and the system remains stable and secure after deployment.

Each step creates evidence your auditor may sample. A missing stage is a gap in your control process and can result in a finding in your SOC 2 report. Controls CM-01 to CM-06 in our library cover this ground, each with its evidence and a common gap; see the SOC 2 controls list.

CC8.1 Change Management Requirements

CC8.1 is the only criterion in the change management family (CC8). It requires that changes to infrastructure, data, software, and procedures are authorized, designed, tested, approved, and implemented to meet the entity’s objectives. In practice that means a formal process that stops unauthorized or untested changes from reaching production, and that produces the evidence an auditor needs to test whether it operated. The criterion itself does not name segregation of duties. The AICPA’s 2022 points of focus mention it once, as “consideration of segregation of responsibilities” when deploying changes, and points of focus guide the auditor rather than bind you.

Which changes CC8.1 covers

CC8.1 names four things: infrastructure, data, software, and procedures. Application code is the obvious case. A sample can also reach infrastructure-as-code and cloud console changes, configuration, manual database fixes, and edits to your own procedures. Our library covers the less obvious edges with CM-05, which keeps development and test environments separate from production and keeps unmasked customer data out of them, and CM-06, which sends manual changes to production data through an approved ticket with a record of exactly what was run.

Who may approve their own change

Auditors usually expect that the person who writes a change is not the only person who approves and deploys it. That stops one person from introducing unreviewed or malicious code. CM-01 in our library asks for an approval from someone other than the author on every merge to the production branch, enforced by branch protection rather than convention.

A team too small for a second reviewer has a different problem. With one engineer, the library suggests relying on a required test gate and a recorded self-review before deploy, keeping the deployment log so every change can be traced, and agreeing the arrangement with your auditor.

Start from your own policy library and map each procedure to the change controls auditors will test. Our SOC 2 internal control procedure template includes a worked change-management procedure you can adapt.

What Auditors Look For

For a SOC 2 Type 2 audit, an auditor will select a sample of changes made during the audit period and test the operating effectiveness of your controls. They trace each sampled change from its request through to its deployment. Our SOC 2 Type 2 controls guide explains populations in general, and the sampling section below shows how it plays out for deployments.

The auditor’s primary goal is to verify that your documented process was followed for every change in their sample. A deviation can lead to an audit exception.

What to prepare, with the matching control in our library:

Turning Theory Into Audit-Ready Evidence

Auditors test whether the policy was followed, so every change needs a record your tools create as it ships.

From Control Language to Concrete Proof

Your change management controls must be described in specific, testable language. Vague statements like “Changes are approved” are not auditable. You need precise control descriptions that point directly to the evidence you will provide.

Here is an example of a well-defined, auditable control statement:

“All changes to production systems are initiated via a ticket in Jira, which requires peer review via a GitHub pull request and formal approval from a designated change manager before deployment through our CI/CD pipeline.”

This single sentence gives the auditor a test plan. It identifies the systems to inspect (Jira, GitHub, the CI/CD pipeline) and the control activities to verify (ticketing, peer review, formal approval).

Configuring Tools for Automated Evidence Collection

Put the requirements into the tools engineers already use, so evidence is a byproduct of shipping rather than a task someone does later.

Automated collection reduces manual work, but it does not guarantee a particular audit timeline or outcome. Retain configuration exports, approval records, test results, and deployment logs for the reporting period, and agree the evidence and retention with your auditor. Screenshots are not universally prohibited.

Evidence Requirements for Type 1 vs. Type 2 Audits

A Type 1 report assesses the design of your controls at a single point in time. A Type 2 report tests their operating effectiveness over an observation period, which needs far more evidence.

That evidence belongs with the rest of your SOC 2 documentation.

What does a sampled change look like from ticket to deploy log?

A sampled change is one production deploy that the auditor traces backward through four records: the ticket, the pull request approval, the CI run, and the deploy log. Each record has to exist, carry a timestamp in the right order, and point to the next. The packet below is an illustrative example, not a client record.

Procedures vary by firm, but the ticks fall into two kinds. Some check that a record exists. Others check that two records agree, such as the commit hash in the CI run matching the one in the deploy log. The second kind is where packets tend to break, because each tool is configured on its own and nobody joins them. The cheapest fix is the naming rule in the failures section below: the ticket number in the pull request title, and the commit hash in the deploy log.

The same chain applies to the other change types in the table above. An emergency change swaps the pre-merge approval for a later one (CM-04), and a manual database fix swaps the pull request for a ticket and the query that was run (CM-06).

How do auditors sample deployments, and what happens when one fails?

For a Type 2 report, the auditor asks for the complete list of production deployments in the period, usually from the pipeline or release log, and tests a sample of it. No standard sets the number. For a population this size, 25 is a common starting sample, and a deviation extends it to 40, then 60. Our SOC 2 sample size guide covers the logic.

A worked example with 1,100 deployments

Take a SaaS company that made 1,100 production deployments in a 12-month observation period. The numbers follow the approach Linford & Co publishes for populations of 250 or more, the same one our sample size guide uses. Other firms use other tables.

1. The population. The list comes from the deploy log, not from tickets. A list built from tickets would miss exactly the changes that never had one. The auditor usually checks that the list is complete, for example against the pipeline’s own run count.
2. The sample. The auditor draws 25 of the 1,100 and traces each through the four hops above.
3. The deviation. Twenty-four pass. Deploy 17 is a dependency update whose pull request was merged with no recorded approval. The author is a repository administrator who bypassed branch protection. That is the common gap CM-01 names: admins can bypass protection, and did.
4. The extension. One deviation in 25 means the auditor pulls 15 more, for a sample of 40, to see whether this was isolated. The stopping points for a second or third deviation are in the sample size guide linked above.
5. The conclusion. If the 15 extra items are clean, the result is 1 deviation in 40. The auditor weighs the risk of the control and whether the bypass looks like a one-off, and can conclude the control operated effectively. A single deviation is often still reported as an exception, because the control as written failed once.

What the exception and the response can look like

In the tests-of-controls section of a Type 2 report, the example above could read as follows. This is illustrative wording, not a quote from a report.

Control: Production deployments are made through the pipeline from a branch that requires an approved pull request from someone other than the author.

Test: Inspected a sample of 40 production deployments selected from the 1,100 deployments made from January 1, 2025 to December 31, 2025.

Result: For 1 of the 40 deployments sampled, the pull request was merged without a recorded approval.

If the report carries a management response, a useful one names the cause, the fix, the date, and how the fix was checked. For example: “A repository administrator merged a dependency update using an administrator bypass. Management removed the bypass permission from production repositories on [date], and the pipeline now blocks any merge without an approval. Management reviewed the bypass log for the period and found no other bypassed merges.”

A response is a commitment, not proof that the fix works, and the exception stays in the report for that period. Readers weigh both together; our guide to SOC 2 exceptions and qualified opinions shows how.

You can avoid this particular exception by keeping the bypass list short, logging every bypass, and treating each one as a change that needs an after-the-fact ticket. CM-01’s evidence list includes the bypass list and its log for this reason.

How should emergency changes work under CC8.1?

CC8.1 has a point of focus asking for a process to authorize, test, approve and implement changes needed in emergency situations. Urgency changes the route, not the requirement. Define who may use the emergency path, let them ship the fix, then complete review, test evidence and approval within a deadline your policy sets. Points of focus are guidance, not requirements.

CM-04 in our library takes that shape: the urgent fix ships first, and review, test evidence and approval follow within a set number of business days. Pick a deadline you can meet, because the auditor tests against your own wording. For each emergency change in the period, the evidence is a ticket marked as an emergency, who invoked the path, what changed, and the date and name of the later approval, linked to the incident that prompted it. A post-incident review of the root cause belongs in the same ticket.

The common gap is a hotfix that goes straight to production with no ticket and no later review, so nobody can say which changes were emergencies. Label emergency tickets so you can filter them. If you had none in the period, a filter that returns nothing is how you show it, and every deploy outside the normal path should still lead to a ticket.

Common Change Management Failures and How to Fix Them

Exceptions in change management mostly come from informal approvals, records that do not connect, and production touched outside the pipeline. A retained chat approval may be usable evidence if it identifies the change, approver, and timing. An undocumented verbal approval is much harder to substantiate. The auditor evaluates the evidence against the control as you described it, not against a tool.

Informal or ‘Tap-on-the-Shoulder’ Approvals

Approvals given verbally, or in messages that are not retained, leave no trail. When an auditor asks for proof of authorization, a deleted chat message cannot serve as evidence, so the approval fails the “authorization” and “approval” language of CC8.1 and is likely to be reported as an exception.

The fix is to enforce approval where the change is merged. In GitHub or GitLab, set branch protection rules that require at least one approval before a pull request merges into a production branch. Keep the timestamped approval records linked to the change, and protect their integrity.

Poor Documentation and Traceability

An auditor opens a Jira ticket for a new feature and finds no link to the pull request that contains the code or the deploy log that released it. Without that chain, the auditor cannot verify that the change that was approved is the one that shipped.

The fix is a naming convention that ties the artifacts together. Require the ticket number in every pull request title (for example, “FEAT: Implement user authentication [PROJ-123]”), and record the commit hash in the deploy log. Both are checkable, so the link is searchable instead of remembered.

Production Touched Outside the Pipeline

Engineers deploy from their laptops, or support staff fix customer records directly in the database. The changes have no review and no record, and they cannot be matched to an approval. These are the gaps behind CM-03 and CM-06. Restrict direct write access to production and keep a list of who has it and why, deploy only through the pipeline, and require a ticket for any manual data fix, with the script or query attached.

Building Your Audit-Ready Change Management Program

Building the program means writing the rules, setting the tools to enforce them, and checking the result on yourself before your auditor does.

Define Your Change Management Policy

The policy is the document your auditor reads first and tests your operation against. It must be clear and formally approved by management. Name the systems it covers, such as production infrastructure, source code repositories, and critical databases. Name who can request, approve, and implement changes, using defined titles such as “Change Owner,” “Peer Reviewer,” and “Change Manager.” Define change categories such as Standard, Minor, and Emergency, with the approval workflow for each; the emergency workflow is covered above.

Then train the engineering team on it. With the tools set up as in the table above, the approved path is the only way code reaches production.

Test a Sample of Your Own Before Fieldwork

Do not wait for your external auditor to find the weak spots. Each quarter, pull the deploy log for the period, draw 25 deployments at random, and walk each one through the four hops in the sample packet. For each, ask whether it had an approved ticket, whether the approver was someone other than the author, whether the passing run and the deployed commit match, and whether the deploy came from the pipeline.

Your number will not match your auditor’s, but the same gaps surface, and a record of the self-test shows you monitor your own controls. For help closing change-control gaps before fieldwork, see SOC 2 readiness firms.

---

Compare scope, pricing, and timelines in the SOC 2 auditor directory. Ask each firm how it will sample changes and evaluate your emergency-change process.