SOC 2 change management: controlling how code reaches production
Change management under CC8.1 is where auditors test whether every change to production actually followed your documented process over the audit period. Here is what they sample, what evidence holds up, and the gaps that generate exceptions.
What CC8.1 actually asks for
Change management lives in the SOC 2 common criteria under CC8.1, which states that the entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures. In plain terms, a change should not reach production unless someone designed it, it was tested somewhere other than production, and an appropriate person approved it before release. The criterion deliberately covers more than application code; database schema changes, infrastructure-as-code, firewall rules, and configuration updates all count as changes. Most companies operationalize this through a short, written change management policy that defines what qualifies as a change, who can approve, what testing is required, and how the process is recorded. The policy is the baseline auditors measure your actual behavior against, so it should describe the workflow you genuinely follow rather than an aspirational one.
The control chain auditors expect to see
A defensible change process strings together a few discrete control points: a change is requested or tracked somewhere, peer review happens before merge, automated or manual testing runs, an authorized party approves, and deployment is restricted to people or systems with the right permissions. In modern SaaS shops this maps cleanly onto a pull request workflow with branch protection, required reviewers, status checks that must pass, and a CI/CD pipeline that handles promotion to production. The point auditors care about most is separation of duties: the person who writes a change should not be the only person who approves and ships it. Branch protection that requires at least one independent reviewer and blocks self-merges is the most common way teams enforce this, because it produces a clean, queryable trail. The same logic applies to infrastructure changes, which is why Terraform or CloudFormation pull requests and pipeline approvals increasingly carry the same review requirements as application code.
What Type 2 testing looks like in practice
A Type 2 report covers operating effectiveness across a period, usually six or twelve months, so the auditor is not satisfied that a process exists on paper. They will pull a sample of production changes from across the window and trace each one back through your evidence to confirm it followed the documented steps. A six- or twelve-month period at an active engineering org can include thousands of merges, and the auditor typically samples on the order of twenty-five to forty of them. For each sampled change they look for an independent review or approval, evidence that testing occurred, and confirmation that deployment was authorized. A single self-merged pull request with no reviewer, or a hotfix that went straight to production with no record, can surface as a deviation in the sample. Because the testing is sample-based and retrospective, you cannot fix gaps after the fact; the control either operated consistently during the period or it did not.
Evidence that holds up
The strongest evidence is the artifact your tooling already generates as a byproduct of doing the work. For application changes that means pull requests showing the reviewer, the approval, and the passing status checks, plus CI/CD logs tying the merge to a specific production deployment. For tracked work, change tickets or issues that link the request to the eventual release help auditors connect the business reason to the technical change. Many teams supplement this with deployment logs from their pipeline and access configurations proving that only the pipeline or a small set of authorized accounts can push to production. Screenshots of branch protection settings on in-scope repositories demonstrate that the control was enforced by the system rather than left to individual discipline. The advantage of system-enforced evidence is that it scales to thousands of changes without manual recordkeeping and is far harder to dispute than after-the-fact attestations.
Emergency changes and common gaps
Emergency changes are the most frequent source of friction because incidents tempt teams to bypass the normal workflow. CC8.1 does not grant an exception for emergencies; instead it expects a documented fast-track process with retroactive review and approval, so that even an urgent hotfix gets a recorded second set of eyes shortly after the fact. The most common gaps auditors flag are developers who can deploy their own unreviewed code, repositories in scope that lack branch protection, changes that skipped any documented testing, and emergency fixes with no retroactive approval recorded. Another recurring problem is scope drift: infrastructure and database changes that follow no formal process even though application code is well governed. The practical fix is to make the compliant path the path of least resistance, enforcing review and approval in the tooling itself so engineers cannot easily circumvent it, and to define a realistic emergency procedure your team will actually use under pressure.