Change control process flowchart
A change control process flowchart covering request, impact assessment, CAB approval, implementation, verification and closure, plus an emergency route.
How it works
Rename the lanes to your real roles
Replace Requester, Change manager, CAB, Implementer and QA with the roles and teams you actually have. If one person is both change manager and CAB chair, merge those lanes rather than pretending they are separate. Keep the lane count at or below five so the chart stays readable.
Define your change categories at the triage decision
The triage decision already splits standard, normal and emergency. Write down what qualifies for each in your organisation and put those thresholds next to the decision. Set them by risk and blast radius rather than ticket size, and keep the pre-approved standard change list short enough that someone actually maintains it.
Name the change authority and its cadence
At the CAB review step, record who the approvers are, how often they meet, and the cut-off for getting on the agenda. Add the emergency authority separately, since the person who can approve an out-of-hours fix is usually not the whole board.
Specify what the assessment record must contain
Turn the assessment step into a real checklist: affected services and users, downtime window, risk rating, dependencies, test approach and rollback approach. The CAB decision is only as good as this record, and it becomes the audit trail for the change.
Set the rollback and verification rules
Decide who executes a rollback, how long it takes, and what triggers the call. Then define what verification means for your changes: smoke test, regression suite, sign-off by the service owner. Adjust the failed-verification loop if your policy is to roll back immediately rather than re-plan.
Publish it and keep it versioned
Share the diagram where the work happens, next to the change request form or in the runbook. Review it after any change that went badly, and keep the earlier versions so you can show when the procedure changed and why.
Frequently asked questions
What is the difference between change control and change management?
Change control is the narrow, procedural part: how a specific proposed change is requested, assessed, authorised, implemented, verified and closed, with a record at each step. Change management is broader and includes the strategy, categories, roles, communication and the ongoing improvement of the process itself. This flowchart is the change control procedure, which is normally the first thing you document because it is what people follow day to day.
Who should approve a change, and does everything need a full CAB?
No. Running every change past a full board creates a queue and pushes people to work around the process. Most teams use three tiers: pre-approved standard changes with a documented procedure that need no review, normal changes that go to the CAB, and emergency changes authorised by a single named authority such as the CAB chair or on-call manager. Set the thresholds by risk and blast radius, not by ticket size, and write them next to the triage decision.
How do emergency changes fit without undermining the process?
An emergency change compresses the approval, it does not remove it. In this chart the emergency branch skips the standing CAB agenda but still gets explicit authorisation, still goes through implementation planning with a rollback, and still lands in post-implementation review and closure. The practical rule most teams adopt: authorise verbally within minutes, but write the change record the same day, and review every emergency change at the next CAB to check the category was justified.
What happens to changes the CAB rejects or defers?
They need an explicit ending, otherwise they reappear as unrecorded work. In this template the change manager returns the CAB's reasoning to the requester, who then hits a decision: revise and resubmit, which loops back into impact assessment and a second review, or accept the outcome and close the request as deferred. Recording the reason matters as much as the decision, because deferred changes usually come back once the blocking dependency clears.