SOC 2 Change Management

Change management is the most-tested control in SOC 2

If continuous monitoring is where Type II is won, change management is where it is most often lost. Every modern SaaS company deploys constantly. Every deployment is a change that auditors consider in scope under CC8.1. A SOC 2 Type II audit over a six- or twelve-month observation period may involve thousands of production changes, and auditors will sample them.

The good news is that mature engineering teams already have most of the controls — code review, CI/CD, infrastructure as code — they just need to be mapped to CC8.1, documented, and made visible to auditors. The bad news is that any change that bypasses those controls and reaches production creates an exception that is hard to explain away.

What CC8.1 requires

CC8.1 in the Trust Services Criteria requires that the entity "authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures." The points of focus expand this into seven expectations.

• Manages changes throughout the system development life cycle
• Authorizes changes before implementation
• Designs and develops changes with appropriate controls
• Documents changes so they can be traced and reproduced
• Tracks system changes to confirm authorization and intended outcomes
• Configures software with approved configurations
• Tests system changes before implementation

CC8.1 also intersects with CC6.1 (access control) because only authorized people should be able to approve and deploy changes, and CC7.1 (configuration monitoring) because unauthorized changes should generate alerts.

The four lanes of SOC 2 change management

Different types of changes need different controls. Organizations that try to use a single workflow for everything end up with either too much bureaucracy or too many exceptions.

1. Application code changes

Standard developer workflow: feature branch, pull request, code review, automated tests, merge to main, deploy. Controls to document:

• Branch protection requiring reviewer approval
• Required status checks (tests passing, security scans clean)
• Merge restrictions to authorized committers
• Automated deployment from the main branch
• Linkage from commit to pull request to deployment record

2. Infrastructure changes

Infrastructure-as-code is the cleanest path. Terraform, Pulumi, CloudFormation, or equivalent in version control means infrastructure changes follow the same review workflow as application code. Manual console changes to production should be minimized and, when made, logged with a ticket.

3. Configuration changes

Application configuration, feature flags, and runtime settings often change outside the code deployment workflow. Controls include:

• Config stored in version control or a secrets manager with audit logs
• Feature flag changes logged with actor and timestamp
• Production console access restricted and monitored

4. Emergency changes

Every engineering team has moments when normal process must be bypassed. SOC 2 accommodates this as long as the exception is managed.

• Define an emergency change procedure in policy
• Require at least one authorized approver (even if post-hoc)
• Require a written justification
• Log the change in the same system as normal changes
• Review emergency changes in a monthly or quarterly retrospective

Auditors look at the population of emergency changes and ask why each one qualified. If everything is an emergency, the normal process is not working.

Evidence auditors expect

A Type II audit will generate specific requests around change management.

• Change management policy document
• Inventory of systems covered by the process
• A list of changes deployed during the observation period
• Samples of individual changes with their full audit trail
• Evidence of emergency change approvals and justifications
• Evidence of segregation between developers and production deployers (where applicable)
• Branch protection and CI/CD configuration settings

The auditor may pull changes from your version control system directly or request an export. The fastest way to pass this section is to ensure the audit trail is complete by default rather than reconstructing it after the fact. Related glossary: change management and audit trail.

Approval workflows that satisfy SOC 2

The workflow itself is not prescribed. The outcomes are. The workflow must demonstrate:

1. Authorization. Someone with appropriate authority approved the change before it reached production.
2. Testing. The change was tested in a non-production environment (unless covered by emergency procedures).
3. Documentation. The change is recorded in a way that a reviewer can understand what changed and why.
4. Traceability. The deployment can be traced back to the approval and the approval back to the requesting actor.

For most modern teams, a pull request workflow with branch protection enforces all four by default. Older teams with manual deployment processes have more work to do.

How this fits into SOC 2

Change management generates some of the highest-volume evidence in a SOC 2 audit. Every pull request, every deployment, every configuration change contributes to the population auditors sample from. Weak change management often causes exceptions in adjacent areas:

• Continuous monitoring misses unauthorized changes if configuration drift alerting is absent
• Incident response requires change management correlation when an incident is traced to a deployment
• Access controls (CC6) overlap when emergency deployment access is granted temporarily

Change management also supports the availability criterion if applicable. Failed deployments are a common cause of outages, so rollback procedures and testing discipline feed both security and availability controls.

Common mistakes

• Manual console changes to production. Engineers who make one-off changes in the AWS console without a ticket leave evidence gaps. Restrict console write access or require change tickets for any change made that way.
• Overloaded emergency procedure. If half of your changes are emergency changes, the category is meaningless. Tighten the definition.
• No linkage between ticket and deployment. The auditor wants to trace from approval to deployed change. Without a link (commit message references, deploy metadata), the chain breaks.
• Configuration drift. Systems configured by hand drift away from declared baselines. Configuration monitoring catches this but only if it is deployed.
• Approver-as-author. The same person approved and deployed the change. Where possible, require separation. At minimum, document why separation is not feasible.

Implementation tips

• Turn on branch protection with required reviews and status checks across every repository in scope. Export the settings as evidence.
• Use CI/CD pipelines that record who deployed what, when, and against which commit. Retain deploy logs for the full observation period.
• Manage infrastructure with code. Manual console changes should be rare, logged, and revisited during quarterly audits.
• Write an emergency change procedure before you need it. During an actual emergency is not the time to design the process.
• Sample your own change evidence monthly to catch gaps before the auditor does.

How episki helps

episki maps your existing change management tooling — pull requests, CI/CD pipelines, ticketing systems — to CC8.1 and pulls evidence continuously so the audit trail is always current. Start a free trial or review the broader SOC 2 framework to see how change management fits alongside access, monitoring, and incident controls.