SOC 2 CC8.1: Change Management - Changes to Infrastructure, Data, Software, and Procedures
What This Control Requires
The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. Changes are managed through a defined change management process that includes authorization, testing, approval, and implementation controls.
In Plain Language
Uncontrolled changes cause more outages and security incidents than most organisations want to admit. CC8.1 is about making sure every change to your production environment - code, infrastructure, configuration, data, procedures - goes through a process that catches problems before they reach your users.
You need a formal process governing how changes are requested, reviewed, tested, approved, and deployed. Changes must be authorised by the right people, tested before hitting production, documented for traceability, and reversible when things go wrong. This applies to everything from major releases to routine configuration tweaks.
Change management is one of the most heavily tested areas in a SOC 2 audit. Auditors sample change records to verify proper authorisation and testing, compare production changes against approved requests, and check whether emergency changes have appropriate compensating controls. Sloppy change management is an easy finding.
How to Implement
Set up a formal change management policy covering all production environment changes. Define change categories (standard, normal, emergency), approval levels for each, documentation requirements, testing requirements, and implementation procedures. Apply this to application code, infrastructure modifications, configuration changes, database modifications, and procedural updates.
Use a change request and tracking system. Every change needs a formal request covering: description, business justification, risk and impact assessment, testing plan, rollback plan, implementation schedule, and required approvals. A ticketing system or change management platform should track changes through their full lifecycle.
Enforce separation of duties. The person who writes a change should not approve or deploy it to production. Use technical controls to enforce this - branch protection rules, deployment pipeline restrictions, and access controls - not just written procedures.
Define testing requirements based on change risk: unit testing, integration testing, security testing, UAT, performance testing as appropriate. Maintain separate development, testing, and production environments so testing happens in a controlled setting before anything touches production.
Set up a change advisory board (CAB) or equivalent review process for significant changes. Include security, operations, development, and business stakeholders. Review proposed changes for risk, impact, and readiness before authorising production deployment.
Define your emergency change process. Emergency changes can bypass some normal steps to address urgent issues, but they still need documentation, a justification for the emergency, and post-implementation review and approval. Track emergency change frequency - a high rate is a red flag for auditors and usually signals that your normal process is too slow.
Evidence Your Auditor Will Request
- Change management policy and process documentation covering all change types and categories
- Change request records showing authorization, testing, approval, and implementation for sampled changes
- Evidence of separation of duties in the change process (different individuals for development, approval, and deployment)
- Testing documentation for changes deployed to production during the audit period
- Emergency change records with justification and post-implementation review documentation
Common Mistakes
- Changes are deployed to production without formal change requests, testing, or approval
- Separation of duties is not enforced, allowing developers to deploy their own changes to production
- Emergency change process is overused, with a high percentage of changes bypassing normal controls
- Testing is performed in production rather than in separate testing environments
- Change records lack key information such as testing results, approval evidence, or rollback plans
Related Controls Across Frameworks
Frequently Asked Questions
How do we manage change management in an agile/DevOps environment?
What percentage of changes should go through the emergency process?
Do infrastructure-as-code changes need change management?
Track SOC 2 compliance in one place
AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.
Start Free Assessment