A poorly managed IT change management process is one of the leading causes of unplanned outages, failed deployments, and frustrated end users. Whether you are rolling out a network upgrade, patching servers, or migrating a critical application, how you plan, approve, and implement that change determines whether your service desk is flooded with incident tickets the next morning. This guide walks you through every stage of a structured change management process, aligned to ITIL v4, so your team can reduce risk and ship changes with confidence.
What Is IT Change Management and Why Does It Matter
Change management in IT is the practice of controlling how modifications are made to infrastructure, applications, and services. The goal is not to slow things down — it is to make sure every change is assessed for risk, approved by the right people, and tracked from request to closure.
Without a formal process, teams often make changes ad hoc. One engineer updates a firewall rule without telling anyone. Another patches a production database on a Friday afternoon. These are the scenarios that produce major incidents, compliance gaps, and CMDB drift.
ITIL v4 frames change management — now called the Change Enablement practice — around three core objectives:
- Maximise the number of successful changes
- Assess and manage risk proportionally
- Ensure changes are authorised before implementation
The emphasis on "proportional" risk assessment is important. Not every change needs a full CAB review. A rigid process applied to every ticket creates bottlenecks. A well-designed process scales its controls to the type and risk level of the change.
The Three Types of IT Changes You Need to Classify
Before you can build a workflow, you need a consistent taxonomy. ITIL v4 recognises three change types, and most mature ITSM teams use a version of this same model.
Standard Changes
Standard changes are pre-approved, low-risk, and follow a documented procedure every time. Because the risk is understood and the steps are repeatable, they do not require individual CAB approval.
Examples include:
- Adding a new user account
- Installing an approved software package on a workstation
- Resetting a hardware component that has a documented swap procedure
Standard changes should have a change model — a template that captures the steps, rollback plan, and any required checks. Teams that build a strong library of standard change models reduce approval overhead dramatically.
Normal Changes
Normal changes require assessment and authorisation before they are implemented. They carry moderate to high risk, affect multiple users or systems, or involve components that are not covered by an existing standard model.
Examples include:
- Upgrading a core network switch
- Deploying a new version of a business-critical application
- Migrating a service to a new hosting environment
Normal changes go through the full workflow: request, risk assessment, CAB review, approval, scheduling, implementation, and post-implementation review.
Emergency Changes
Emergency changes are needed to restore a service or prevent an imminent outage. They bypass the normal approval timeline but should still be authorised — typically by a smaller emergency CAB or a designated approver — and fully documented after the fact.
The danger with emergency changes is that teams treat them as a shortcut and then never close the loop. Every emergency change should be reviewed in the next CAB meeting to understand what caused the need and whether a standard model or a problem record should be created.
Building Your Change Management Workflow Step by Step
A practical change management workflow does not need to be complicated. The following steps cover the full lifecycle of a normal change and can be adapted for standard and emergency changes by removing or streamlining the approval gates.
- Step 1: Submit the Request for Change (RFC). The requester logs a change ticket that includes a description of the change, the reason, the systems affected, the planned implementation window, the rollback plan, and the risk assessment. Requiring all of this upfront forces requesters to think through the change before it reaches the CAB.
- Step 2: Initial triage and classification. A change manager or designated reviewer checks that the RFC is complete, assigns a change type, and routes it appropriately. Standard changes go straight to scheduling. Normal changes move to assessment.
- Step 3: Risk and impact assessment. The change manager works with the requester and any relevant technical leads to score the change on two axes: likelihood of failure and business impact if it fails. This assessment should reference the CMDB to understand which other services or assets depend on the component being changed.
- Step 4: CAB review and authorisation. The Change Advisory Board reviews the assessed RFC. CAB membership typically includes IT operations, security, application owners, and business stakeholders. The CAB either approves, rejects, or requests more information. For lower-risk normal changes, some organisations use an email-based or asynchronous approval rather than a full meeting.
- Step 5: Schedule and communicate. Approved changes are scheduled in the change calendar. Affected teams and users are notified of the planned window. Conflicts with other changes or major business events are checked at this stage.
- Step 6: Implement and monitor. The change is carried out according to the documented procedure. The implementer records what was done, any deviations from the plan, and whether the rollback was triggered.
- Step 7: Post-implementation review (PIR). After the change window closes, the team confirms whether the change was successful, whether any incidents were raised as a result, and whether the CMDB and documentation have been updated. The PIR is where most teams fall short — skipping it means you lose the feedback loop that improves future changes.
Common Mistakes That Cause Change Management to Fail
Even teams that have a documented process run into the same recurring problems. Understanding these failure modes helps you design a process that avoids them.
The CAB Becomes a Rubber Stamp
When the CAB approves every change that reaches it without meaningful review, it stops providing value. This usually happens when the CAB is too large, meetings run too long, or members have not read the RFCs in advance. Fix this by distributing RFCs before the meeting, keeping the agenda focused on higher-risk changes, and using asynchronous approval for lower-risk normal changes.
Changes Are Implemented Without Updating the CMDB
A change that moves a server, updates a software version, or retires a device should trigger a CMDB update. When this does not happen, your configuration data drifts and your risk assessments for future changes become unreliable. Linking CMDB updates as a required closure step in your change ticket workflow enforces this discipline. Our post on CMDB best practices covers this in detail.
Emergency Changes Are Never Reviewed
As noted above, emergency changes that are never reviewed create a blind spot. Over time, the change record becomes inaccurate, and the root cause of recurring incidents goes unaddressed. Treat every emergency change as an automatic problem record trigger.
No Rollback Plan
Approving a change without a documented rollback plan is a risk that is easy to avoid. Make the rollback plan a mandatory field on the RFC template. If the requester cannot describe how to undo the change, the change is not ready for approval.
Key Metrics to Track in Your Change Management Process
Measuring your change process is the only way to know whether it is improving. Most ITSM teams track a core set of change metrics:
- Change success rate: the percentage of changes implemented without causing an incident or requiring rollback. This is the headline metric.
- Failed change rate: the inverse of success rate, broken down by change type to identify where risk is concentrated.
- Change lead time: the average time from RFC submission to implementation. Long lead times often indicate CAB bottlenecks.
- Emergency change volume: a high proportion of emergency changes suggests that the normal change process is too slow or that incident management is not feeding into problem management.
- Post-implementation incident rate: incidents raised within a defined window after a change that are linked to that change.
Review these metrics monthly with your change manager and CAB chair. Trends matter more than individual data points.
How TIKTING and Odysseus Support Your Change Management Process
The TIKTING service management platform includes a dedicated Change Enablement module built to ITIL v4 standards. You can configure change types, define approval workflows, manage the change calendar, and link change records directly to incident and problem tickets — all within a single platform.
Odysseus, the asset discovery solution from IT DEV TECH, continuously scans your network and syncs discovered assets into the TIKTING CMDB. This means your risk assessments are based on current, accurate configuration data rather than a spreadsheet that was last updated six months ago. When a change affects a server, switch, or endpoint, the relationship map in the CMDB shows you exactly what else could be impacted — before the change window opens.
Together, TIKTING and Odysseus give change managers the context they need to make better decisions and the audit trail they need to satisfy compliance requirements.
Key Takeaways
- IT change management is about proportional risk control, not bureaucratic approval for its own sake.
- Classify every change as standard, normal, or emergency and apply the right level of scrutiny to each.
- A complete RFC — including risk assessment, rollback plan, and CMDB references — is the foundation of a good change process.
- The post-implementation review and CMDB update are the steps most teams skip, and they are the steps that matter most for continuous improvement.
- Track change success rate, lead time, and emergency change volume to identify where your process needs attention.
- Accurate, real-time CMDB data is what separates a change process that works from one that is guessing.
