How to create a change control process
How to design a change control process: define your change categories, keep the pre-approved list short, require a rollback plan, and draw the emergency route rather than pretending it does not exist.
A change control process governs how a proposed change is assessed, authorised, implemented, verified and closed, with categories that determine how much scrutiny each change gets.
The short version
- Three categories: standard, normal, emergency: defined by risk and blast radius, not size.
- Keep the pre-approved standard list short enough that someone maintains it.
- The assessment record's contents belong in the process, not in the submitter's judgement.
- Every change has a rollback plan, and rollback returns to planning rather than ending.
- Draw the emergency route; the alternative is an undocumented one.
Choose the workflow for the change object
Categories decide whether the process is used
Change control lives or dies on its categories. Route every change through a weekly board and people will find ways not to raise changes, which converts a control problem into an invisibility problem. Pre-approve too much and the board reviews nothing that matters. The category definitions (standard, normal, emergency) are the actual design work, and they are usually written last and vaguest.
The second thing worth getting right is the assessment record. A change advisory board can only be as good as what it is shown, and "assess impact and risk" as a step name guarantees inconsistent submissions. Naming what the record must contain (affected services, downtime window, risk rating, dependencies, test approach and rollback approach) turns the board's decision from an impression into a review.
The example below is a change control flow across five lanes. It contains the three routes any working process needs: a standard change that skips the board entirely, a normal change through assessment and CAB, and an emergency route with its own authority, plus a rollback path that returns to planning rather than ending.
This example focuses on IT services. For a released physical part, drawing or BOM, see /templates/engineering-change-request-process for illustrative ECR-014: alongside assessment and authority, record part revisions, effective lots, authorised old-stock disposition and first-article verification. Approved document revisions continue at /templates/document-change-control-workflow, with release evidence returned to the change owner before closure.
Three routes through one process
A change control flow from request to closure. Watch the triage decision send three categories three different ways.
Triage decides everything downstream
Raised, logged in the register, then a three-way type decision. Standard changes skip straight to implementation, normal changes go to assessment, emergencies go to their own authority: one decision that determines the cost of the whole change.
The assessment is the board's input
Impact and risk assessed, scope and downtime window confirmed, the assessment recorded, then CAB review and approval. If the record does not specify what it must contain, the board spends its meeting asking for information rather than deciding.
Rejection is a route, not a stop
CAB feedback returns to the requester, who can revise and resubmit or accept deferral, and the emergency route joins here with its own authorisation. Processes without a revise loop produce changes that are abandoned rather than improved.
Plan the rollback before the change
Implementation and rollback planned together, window scheduled, change implemented. Planning the rollback at the same time as the change is what makes it real; written afterwards it is a paragraph nobody has tested.
Verify, and loop if it failed
Test and verify, with failure executing the rollback and returning to planning, then a post-implementation review and closure. A change control process that ends at implementation has no way of knowing its changes work.
How it works
Define your three categories
Write down what qualifies as standard, normal and emergency in your organisation, in terms of risk and blast radius rather than effort. A one-line configuration change to a payment system is not a standard change; a large but well-rehearsed routine deployment might be.
Keep the pre-approved list short and owned
Standard changes only work if the list is maintained. Give it an owner and a review date, and require a normal change to prove itself repeatedly before it joins. An unmaintained standard list becomes the route people use for everything.
Specify the assessment record
Turn the assessment step into a checklist: affected services and users, downtime window, risk rating, dependencies, test approach, rollback approach and who has been consulted. This is the single change that most improves a change advisory board's usefulness.
Name the change authority and its cadence
Who approves, how often they meet, and the cut-off for the agenda. Then name the emergency authority separately: the person who can authorise an out-of-hours fix is rarely the whole board, and leaving that undefined is how emergency changes end up unapproved.
Require a rollback plan and decide who calls it
Every change gets one, planned alongside the implementation. Decide in advance who has the authority to trigger it, how long it takes, and what threshold makes the call: during an incident nobody wants to be interpreting a policy.
Draw the emergency route honestly
Every organisation has one. Give it criteria, a named authority and a mandatory retrospective record within a fixed window afterwards. A drawn emergency route with a documentation obligation is a control; an undrawn one is just what happens at 2am.
Mistakes to avoid
One route for every change
Routing trivial changes through a weekly board teaches people to avoid the process, and you lose visibility of the changes that matter.
Vague assessment requirements
The board becomes a forum for requesting information rather than making decisions, and approval quality tracks whoever wrote the best submission.
Rollback written after the plan
A rollback devised as an afterthought is untested and frequently impossible. Plan both together or you do not have one.
Pretending there are no emergencies
Refusing to document the emergency route does not remove it: it removes the criteria, the authority and the record.
Create your own change control process
Open the change control example as your own chart, write in your categories, and name your change authority.
Related guides
Frequently asked questions
What is the difference between change control and change management?
Change control is the 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: the strategy, categories, roles, communication and improvement of the process itself, and in some organisations the people-side of organisational change entirely. The flowchart people need first is almost always change control, because it is what they follow day to day.
What are standard, normal and emergency changes?
A standard change is pre-approved, low-risk and repeatable, so it skips the board and follows a defined procedure. A normal change goes through assessment and authorisation. An emergency change is authorised by a reduced authority because waiting for the normal route would cause more harm than the change's risk. Define each by risk and blast radius rather than by size, and require emergencies to be documented retrospectively within a fixed window.
Who should be on a change advisory board?
People who can assess impact and speak for the affected services: service owners, operations, security where relevant, and someone representing the customer or business impact. Keep it small enough to make decisions and give it a chair with a casting vote. A board of fifteen reviews nothing carefully, and if a member has never raised a concern, they are attending rather than reviewing.
What should happen when a change fails verification?
Execute the rollback and return to planning, rather than trying to fix forward under time pressure. That is why the rollback plan is written alongside the change and the authority to trigger it is named in advance. After recovery, the failed change goes back through assessment with what was learned; treating it as a new change with no history repeats the same failure with different people.
How is change control different from version control?
Version control identifies and remembers successive states of a single artefact: which one is current, and what came before it. Change control is the broader assessment-to-authorisation-to-implementation-to-verification-to-closure process that decides whether a proposed change is even allowed to happen in the first place, usually producing a new version once it is approved. See /guides/version-control-vs-change-control for the conceptual distinction in depth, and /templates/document-change-control-workflow and /templates/sop-change-control-process for the document-type-specific variants of this same shape.
