Why this matters
Change management is the control SOC 2 auditors spend the most time sampling, because it touches the systems that produce your service. Under CC8.1, you need to show that changes to software, infrastructure, configuration and data are authorized, tested and approved before they reach production. The wording is broad on purpose. A new pricing rule in a SaaS admin panel can matter as much as a code deploy if it changes what customers see or how data moves.
A weak process usually fails in one of two ways. The team does good work but leaves no record, so the auditor cannot tell an approved deploy from an unapproved one. Or the record exists but is created after the fact: a ticket opened days later, an approval added in a batch, a screenshot with no timestamp. Both turn a routine audit into a long question and answer session.
Good change control is boring. Every production change has a ticket, a named approver, a test or review, and a deployment record. The evidence comes from the tools you already use, not from a folder someone builds in the last week.
Before you start
Write down what counts as a change before you touch tools. Include application code, database schema and data fixes, cloud infrastructure, CI/CD pipeline definitions, production configuration, and admin changes in vendor platforms that affect customers or data. Leave out local development and routine reads.
Split changes into risk tiers. A normal change needs a ticket, review, approval and test evidence. A standard change is low risk, repeated and pre-approved by a written procedure, such as a dependency patch that passes the same pipeline. An emergency change fixes an incident or security issue and follows a shorter path with retrospective approval.
Name the roles, even in a small team. The change owner writes the request and rollback plan. The approver accepts the risk. The deployer runs the release. The verifier checks the result. One person can hold more than one role, but the ticket should show who did what. If the same person writes and approves every change, document a weekly sample review by someone else.
Pick your systems of record. Most teams already have a ticketing tool, Git hosting, a CI/CD system and cloud audit logs. Decide where the change record lives and how the ticket ID appears in the branch, pull request and deployment. Set a retention period that covers your audit window and check that old records are not deleted by a tool's default cleanup.
How to do it
Build one path from request to production. A change ticket should state what changes, why, which systems, the risk, the test plan, the rollback plan, the planned window, and the approver. Use a template so people do not skip fields. The most useful field is the ticket ID, because it joins the request to the commit, the review, the test run and the deploy.
Put approval before the deploy, not after. The approver should see the actual diff or configuration change, not just a summary. In Git, protect production branches and require a pull request review from someone other than the author. In your pipeline, require a manual approval step for production. In cloud consoles, restrict who can change production and require the ticket ID in the change description or tag. For standard changes, record each use of the pre-approved procedure.
Handle emergency changes with a separate route. Open an incident or emergency ticket, state the risk, get the best available approval, deploy, and record what happened. Require a retrospective review within one business day, with a named approver and a note on whether the change should be made permanent. Auditors look for emergency changes that never got reviewed.
Capture proof without extra work. Link the ticket to the pull request, attach the pipeline run, keep the deployment log, and record the verification step: smoke test, error rate check, customer confirmation, or rollback. For vendor admin changes, export the audit log entry and attach it to the ticket. If a change is made through a console, record the before and after state. The goal is a package a stranger can follow.
- Inventory production systems and change types. List the systems that serve customers or hold customer data: app repos, cloud accounts, databases, CI/CD and admin consoles. For each, note who can change it and where the log lives.
- Write the procedure and risk tiers. Put the normal, standard and emergency paths on one page. Define approval roles, required fields and review timelines. Get management sign-off so the rule has an owner.
- Build a ticket template. Add fields for systems, risk, test plan, rollback plan, approver and verification. Make the ticket ID a required field in the pull request and deploy step.
- Tie tickets to code and deploys. Use branch protection, pull request reviews and a production approval gate in the pipeline. Put the ticket ID in the commit message or deployment tag. That link is the evidence an auditor follows.
- Set a separate emergency path. Create an emergency ticket type with a short form and a named approver. Require a retrospective review within one business day and record whether the fix stays.
- Review changes monthly. Sample tickets, deployment logs and cloud audit records for missing approvals or orphan changes. Fix the template or tool gate that allowed the gap.
How to check it worked
Run a sample before the auditor does. Pick changes across the period, including a normal deploy, an infrastructure change, a vendor admin change and an emergency fix. For each, check that the ticket existed before the deploy, the approver was not the author, the test or review happened before release, the deployment record matches the ticket, and the verification step is present.
Then look for changes missing from the sample. Search deployment logs, Git history and cloud audit logs for production events with no ticket. A single orphan deploy is not a crisis, but a pattern means your process has a side door. Check whether hotfixes got retrospective review and whether standard changes were logged each time.
Ask two engineers to walk you through a recent change without preparation. If they cannot find the ticket or explain the approval, the process is not usable. That is a design problem, not a discipline problem. Simplify the template or move the approval into the tool they already use.
Keep a short monthly review. Look at changes without tickets, emergency changes past their review deadline, and approvers who approve everything in seconds. Fix the cause before the audit window closes.
Mistakes to avoid
The first mistake is writing a policy that describes a process nobody follows. Auditors test the process, not the document. If your policy says a change advisory board meets weekly but your team deploys daily through pull requests, the evidence will contradict the policy. The same problem appears when approvals are added after the deploy or in a batch at month end.
The second is covering only code. SOC 2 change management includes infrastructure, database changes, CI/CD settings and vendor platform configuration. A team that controls Git but lets engineers edit production firewall rules from a console has a gap. Making the process too heavy is also a mistake. A weekly board for a one-line copy change will produce fake tickets. Use risk tiers, standard changes and a fast emergency path.
Do not rely on screenshots as your only evidence. They are easy to lose and hard to tie to a time. Use tool records first. If you must use a screenshot, include the system clock, the ticket ID and a note on who took it. Also check that emergency changes get their retrospective review; an unreviewed hotfix is a common finding.
If you want help, Cloudverg's SOC 2 readiness assessment is a fixed price $7,500 package that reviews your change process against the Trust Services Criteria and gives you a remediation roadmap. It is one option among others: you can run the review internally or bring in an independent CPA firm for the audit.
Frequently asked questions
What is the change management control in SOC 2?
It is control CC8.1. You need to show that changes to software, infrastructure, configuration and data are authorized, tested, approved and documented before they reach production. The auditor samples changes and checks the ticket, approval, test result and deployment record.
Do we need a change advisory board for SOC 2?
No. A board is optional. What matters is a risk-based approval before production, with evidence tied to the change. Small teams often use pull request reviews and a ticket instead of a weekly meeting.
How are emergency changes audited under SOC 2?
Auditors check for a documented emergency path, an approval or incident record, a deployment record and a retrospective review. They want to see that hotfixes were not exempt from control. Missing review is a common finding.