IT change management workflow (SOC 2 CC8.1)
A SOC 2-ready IT change management workflow: change request, impact assessment, approval, testing, deployment, post-implementation review, with approval signatures captured per gate.
What the IT change management workflow (SOC 2 CC8.1) process is
Change management is almost always documented as the long path: request, assessment, CAB meeting, approval, testing, release. And yet most real changes take a different route, because the long path takes four days. The process is not wrong: what is wrong is that it has only one route.
A diagram that survives a walkthrough therefore has three tracks: standard changes, which are pre-approved and run without further approval; normal changes, which go through assessment and approval; and emergency changes, which may be deployed first and approved afterwards, within a deadline and with a documented justification. The classification is the first decision in the process, not a note in the procedure.
The second thing an auditor tests is segregation of duties: can the person who developed the change release it to production themselves? That question is only answered by a diagram where approval and deployment sit in separate lanes with separate owners.
What this flowchart covers
In this template
- The change request: who may request, what must be described (purpose, affected systems and rollback plan), and how the request is logged
- Classification into standard, normal and emergency changes: the branch that decides which approval path a change follows
- Impact and risk assessment: affected systems and data, expected downtime, dependencies and security impact
- Approval by the change manager or the Change Advisory Board (CAB), with a branch for rejected and deferred changes
- Testing and approval in the test environment, including the requirement for a documented rollback plan before the change is released
- Deployment with segregation of duties between developer and releaser, post-deployment verification, rollback on failure and a closing review of emergency changes
When to use this template
- You are going through a SOC 2 audit where the CC8.1 walkthrough asks: how does a change reach production?
- Emergency changes are being used as the normal path because the formal process is too slow, and you want to see why
- Developers are releasing their own changes, and you need to either document or introduce segregation of duties
- You use Jira or ServiceNow for individual tickets but have no controlled description of the process itself
- Both SOC 2 CC8.1 and ISO 27001 A.8.32 must be covered, and you want one process rather than two descriptions that say different things
Controls documented
- CC8.1
- ISO 27001 A.8.32
Frequently asked questions
What does SOC 2 CC8.1 require for change management?
CC8.1 (changes affecting the system) requires documented procedures for evaluating, approving, testing, and deploying changes — plus evidence that the procedure was followed for sampled changes during the audit window.
How is QueryChart different from a ticketing system like Jira for change management?
Ticketing systems track individual change tickets; they do not document the controlled current version of the change-management process itself.
What is the difference between a standard, a normal and an emergency change?
A standard change is low-risk, frequent and pre-approved against a documented change model, so it needs no individual approval and goes straight to scheduling. A normal change is anything that has to be assessed and approved on its own merits. An emergency change is one where waiting for the next CAB meeting would do more harm than the change itself, so it gets an expedited approval in an emergency CAB.
Does every change have to go through the Change Advisory Board (CAB)?
No, and a CAB that reviews everything becomes a bottleneck the organization starts working around. Reserve the board for changes that are cross-system, affect customers, or require downtime, and let a named change manager approve the rest. What matters to an auditor is that the criterion for what goes to the CAB is written into the controlled process, not that the board has seen everything.
