The Change Management Process: 6 ITIL Steps with a Process Flow Diagram
"What was meant to be a minor config tweak ended up taking production down." If you work in IT operations, you have probably had at least one of those heart-stopping moments. Nobody can trace who changed what or when, and rolling back takes forever. Most change-related trouble starts the same way: an unclear process where decisions are made on the fly.
The mechanism that prevents this chaos is change management. In ITIL, every change to an IT service is put through a defined flow of raising, assessing, approving, implementing, and reviewing. The goal is to control risk through an agreed process rather than individual gut feel.
In this article, we break the ITIL-aligned change management process into six steps. We visualize the whole picture from raising an RFC to CAB approval and closure with a process flow diagram, and we work through how to choose between standard, normal, and emergency changes, along with the common pitfalls. By the end, you should have a clear path for drawing your own change management flow.
What you will learn in this article
- The purpose of change management and where it sits within ITIL
- The six steps: raise an RFC → assess impact → CAB approval → implement → review → close
- The difference between standard, normal, and emergency changes and how to decide which applies
- The role of the CAB (Change Advisory Board) and how to keep approvals from stalling
- The benefits of visualizing your change management flow as a process diagram and how to build one
What Is Change Management?
Change management is the mechanism for assessing, approving, implementing, and recording every change to an IT service or system according to a defined procedure. Fixing a server setting, releasing an app, swapping out network equipment—any change that could affect the production environment is in scope.
The goal is simple: deliver the changes you need quickly while minimizing the risk and service downtime that comes with them. The aim is not to avoid change, but to build a foundation for changing things safely and fast.
In ITIL (the collection of best practices for IT service management), change management is positioned as one of the core processes. In the latest ITIL 4 it is called "change enablement," emphasizing the idea of managing risk while keeping business velocity, rather than getting in the way of change.
What happens when change management isn't working
- No record of who changed what and when, so isolating the cause during an incident takes a long time
- Changes are made without assessing the scope of impact, dragging in unexpected systems and taking them down
- No rollback procedure is prepared, leaving no clear path to recovery when trouble hits
- Unauthorized "rogue changes" become common, and the configuration data (CMDB) drifts away from reality
Minami
Process improvement lead
Honestly, if we had to push every little change through the process, wouldn't the team grind to a halt? It feels like it would slow us down...
Spark
DrillSpark consultant
Great question. That's exactly why ITIL splits changes into three types. Low-risk, routine work can be pre-approved as a 'standard change,' so you don't have to go through the CAB every time. Only the heavy changes get careful scrutiny—getting that balance right is the trick to combining speed and safety.
Standard, Normal, and Emergency Changes
In ITIL change management, not every change is treated with the same weight. The basic approach is to classify changes into three broad types according to risk and urgency, and to use a different approval route for each. This very distinction is what makes change management a mechanism that actually works on the ground.
| Change type | Overview | Approval route | Examples |
|---|---|---|---|
| Standard change | Low-risk, routine change with an established procedure. Pre-approved | No per-instance approval needed (pre-approved) | Routine patching, account provisioning, routine releases |
| Normal change | Change requiring impact assessment and individual approval | Approved by the CAB or the responsible owner depending on impact | Production DB configuration changes, new feature releases, middleware updates |
| Emergency change | Change requiring immediate action, such as incident response | Approved quickly by the ECAB (Emergency CAB) | Stopgap fixes for major incidents, urgent security patches |
Standard change: approve it in advance
A standard change is low-risk, repetitive work with an established procedure and risk assessment. Once you approve the process, it can be carried out without individual approval thereafter. Once you start running change management, you'll find that the bulk of changes actually fall into this category. Building out standard changes well is the shortcut to lowering the load on your teams.
Normal change: assess the impact and approve individually
A normal change is one where you assess the scope of impact and risk individually and obtain approval before implementing. The common approach is to stage it: high-impact changes go to the CAB (Change Advisory Board) for review, while smaller ones proceed with the change manager's approval.
Emergency change: prioritize stopping the bleeding while keeping records
An emergency change is one that cannot wait for the normal approval flow, such as responding to a major incident. A small group known as the ECAB (Emergency CAB) approves it quickly, but the cardinal rule is to not put off the record-keeping. Once the response settles down, always conduct a post-implementation review and formally document what was changed.
The 6 Steps of the Change Management Process
From here, using a normal change as an example, we'll look at the whole picture of the change management process across six steps. It becomes easier to grasp if you think of an emergency change as this flow shortened and parallelized, and a standard change as this flow with the Step 3 approval already done in advance.
- Raise an RFC: register the Request for Change and clarify its purpose, content, and desired timing
- Assess impact: evaluate the scope of impact, risk, and rollback procedure, then set the priority and classification
- CAB approval: the Change Advisory Board reviews and approves whether to proceed and the schedule
- Implement: carry out the change according to the approved plan and confirm the result with testing
- Review (PIR): in the post-implementation review, verify whether the goal was achieved and whether there were side effects
- Close: finalize the record, update the configuration data (CMDB), and complete the change
Step 1: Raise an RFC (Request for Change)
Every change starts with raising an RFC (Request for Change). You record what you want to change, why, and when, and clarify the requester, the target system, and the expected schedule. Enforcing this entry point prevents unauthorized 'rogue changes.'
Step 2: Impact assessment and risk assessment
Next, you assess which systems, services, and users the change will affect. At the same time, you always prepare a rollback procedure in case it fails. A common technique here is to check the 7 Rs (who raised it, the reason, the return/benefit, the risk, the resources required, who is responsible, and the relationship to other changes).
Step 3: Approval by the CAB
High-impact normal changes are reviewed by the CAB (Change Advisory Board). They judge not only whether to proceed, but also whether there are conflicts with other changes and whether the timing is appropriate. We'll cover the CAB in detail in the next chapter.
Step 4: Implementation and testing
You carry out the change in line with the approved change plan. Wherever possible, test it in advance in a verification environment, and confirm behavior after applying it to production as well. If a problem occurs, follow the rollback procedure prepared in Step 2 to promptly return to the original state.
Step 5: Post-implementation review (PIR)
After implementation, you conduct a PIR (Post Implementation Review). You verify whether the change achieved its original goal and whether any unexpected side effects appeared. Even for changes that failed, recording what caused the failure raises the quality of the next round of change management.
Step 6: Closure and updating configuration data
Finally, you finalize the change record and close it. The thing you must not forget here is updating the CMDB (Configuration Management Database). If the actual configuration and the record drift apart, the impact assessment for the next change becomes inaccurate. Only when you see it through to closure is one cycle of change management complete.
Minami
Process improvement lead
Following the six steps in text gives me a vague sense that I get it... but once you include the actual branches, it feels like it would get confusing if I only kept it in my head.
Spark
DrillSpark consultant
Right. Once you add the approve/reject branch and the rollback on failure, text alone can't keep up. So in the next chapter, let's turn this flow into a process diagram and visualize it. When you draw it out, missing branches become obvious at a glance.
Visualizing the Change Management Flow as a Process Diagram
We explained the six steps in text, but change management has many branches—whether approval passes, the rollback on failure—so it's hard to take in the whole picture from text alone. This is exactly when a process flow diagram comes in handy. It lets you share the flow and branches at a glance.
Turning the normal change process into a flow diagram looks like this. The key is to draw out the routes for approval rejection and implementation failure too.
Drawing it as a diagram like this makes clear the branches that text tends to gloss over: 'where do you go back to if it's rejected?' and 'how do you recover if it fails?'. You can use the same diagram as a base to explain the differences too—an emergency change simplifies the CAB approval from here, and a standard change skips the approval.
Three benefits of visualizing with a flow diagram
- Faster alignment: requesters, approvers, and implementers can share their roles and order by looking at the same single page
- Gaps become visible: you can check with your eyes whether the rollback and send-back branches are drawn in
- Strong for audits and handovers: you can convey 'this is how our change management works' more reliably than with text
With DrillSpark, you can create a change management flow like this just by speaking in plain language. Say "create a change management flow from raising an RFC to impact assessment, CAB approval, implementation, review, and closure," and the AI generates a draft in about three seconds. From there, you just refine it through dialogue to match your own routes. The diagram can be output in Mermaid format, so you can paste it straight into internal docs or your repository.
The Role of the CAB (Change Advisory Board) and How to Run It
The linchpin of change management is the CAB (Change Advisory Board). The CAB is the forum where high-impact changes are reviewed from multiple angles—whether to proceed, the schedule, and risk countermeasures. The change manager holds responsibility for approval, and the CAB is positioned as playing an advisory and deliberative role.
Key points the CAB checks
- Business impact: the impact the change has on users and services, and whether it's acceptable
- Technical risk: the likelihood of failure and the soundness of the rollback procedure
- Schedule: whether there are conflicts with other changes or busy periods
- Resources: whether the people and time needed to implement and verify are secured
Tips for keeping the CAB from stalling
In exchange for its thoroughness, the CAB tends to become a bottleneck due to slow approvals. Changes pile up while you wait for the meeting—a common headache. To avoid this, the following tips are effective.
| Problem | Countermeasure |
|---|---|
| Approvals are slow if you convene the CAB every time | Pre-approve low-risk routine changes as standard changes and remove them from the CAB's scope |
| You can't wait for the CAB in an emergency | Establish a small standing ECAB (Emergency CAB) to provide an immediate approval route |
| Review judgments vary | Define an impact/urgency matrix so anyone classifies a change the same way |
Three Common Pitfalls in Change Management
Even after you go to the trouble of introducing change management, there are plenty of cases where it becomes a formality and doesn't function. The common failures generally boil down to the following three. Knowing them in advance means you can reliably avoid them.
Failure 1: The process is so heavy that the team works around it
If you impose the same heavy procedure on every change, the team feels that 'the official route won't make it in time' and quietly makes changes on the sly. This defeats the whole purpose. Building out standard changes to weight things according to risk, and letting light changes through lightly, is the first step to preventing this from becoming a hollow formality.
Failure 2: No rollback procedure is prepared
Approval went through, but there's no recovery procedure for when it actually fails—this is the most dangerous pattern. At the impact assessment stage, always prepare the rollback procedure as a set. Consider that only once you've confirmed 'it can be reverted' is it a change worthy of approval.
Failure 3: Records and the CMDB aren't updated
Once implementation is done, people relax and tend to put off the review and the CMDB update. But if no record remains, the impact assessment for the next change becomes unreliable. It's important to include closure in the process and make updating the record a mandatory step.
Spark
DrillSpark consultant
What the three failures have in common is that 'the process isn't visible.' When the procedure is buried in someone's head or deep in a thick manual, people drift toward the easy path. Just putting it on a single flow diagram in a place everyone can see dramatically reduces both workarounds and gaps.
Summary: Start by Turning Your Change Management Flow into a Diagram
Summary of this article
- Change management is the process for delivering changes to IT services safely and quickly
- Classify changes into three types—standard, normal, and emergency—and use different approval routes
- A normal change has six steps: raise an RFC → assess impact → CAB approval → implement → review → close
- Never skipping the rollback procedure and the CMDB update is the key to preventing a hollow formality
The trick to making change management work is not crafting a perfect set of rules from the start. First, turn your own changes—'what flow do they follow, and where do they branch?'—into a single process flow diagram and share it among stakeholders. This is the shortest route to operations with no workarounds and no gaps.
That said, drawing a branch-heavy change management flow from a blank page is hard work. That's exactly when DrillSpark comes in. Just speak the change management flow you want in plain language, and the AI generates a draft flowchart in about three seconds. You can refine the approval branches and rollback routes by digging in through dialogue.
Change management, which tends to get complicated, can also be organized into layers—'the overall flow' and 'the details of each step'—with the drill-down feature. The finished diagram can be output in Mermaid format and embedded straight into your internal wiki or repository. No credit card required, and you can start for free.
Start by speaking one of your change management flows to DrillSpark and turning it into a diagram. Once the process becomes visible, the points worth improving will naturally come to the surface.
Minami
Process improvement lead
The six steps and the flow diagram finally clicked, and I can grasp the whole picture now. I'll start by turning our normal change flow into a diagram with DrillSpark!
Spark
DrillSpark consultant
That first step is what matters. It doesn't have to be perfect—just draw one to start. Once you diagram it, the next thing to fix will naturally come into view. I'm rooting for you!