What Is the Change Management Process?
The change management process controls how modifications to production systems are requested, assessed for risk, authorised, scheduled, implemented, and reviewed. Its purpose is to make the risk of a change visible and its reversal planned before the change lands, and to leave a record that connects later failures back to what was modified.
The stages, and what each is actually for
Request. Someone states what will be modified, why, and when. The valuable content is specificity: which component, which version, which configuration. A request that says update the platform cannot be assessed by anyone.
Risk assessment and classification. The change is placed in a category that determines how much scrutiny it needs. The questions that matter are narrow: what breaks if this goes wrong, how many users are exposed, is it reversible, and has this class of change caused incidents before. Classification is the single highest value step, because it is what allows routine work to proceed without ceremony while genuinely risky work gets attention.
Authorisation. Someone accountable agrees the change may proceed. For routine classes this is pre-agreed, enforced by the pipeline rather than by a person. For novel or high impact work it is a human decision made by someone who understands the system.
Scheduling. When it lands, and what else is landing near it. Two safe changes deployed together are harder to diagnose than either alone, which is a sequencing concern rather than a risk one.
Implementation. The change is made, ideally by automation that produces its own record of what ran and when.
Verification and review. Confirming the change did what was intended, and for significant changes, looking back at whether the assessment was accurate.
Standard, normal, and emergency changes
Most frameworks separate three shapes. A standard change is pre-authorised because it is well understood, low risk, and usually automated; the record exists for the trail rather than for a decision. A normal change goes through assessment and authorisation. An emergency change is expedited because waiting causes harm, and it accepts reduced assessment in exchange for speed, with the review happening afterwards. The proportion of changes arriving as emergencies is a useful diagnostic: when the fast path is to declare an emergency, the standard path is too slow, and the correct fix is shortening the standard path rather than granting more exceptions.
What makes the process work or fail
Approval without context is theatre. A reviewer adds value only when they know enough about the system to change the outcome. A board reviewing fifty records for systems it does not operate produces delay and a signature, and everyone involved learns that the process is a formality. That lesson then applies to the changes where scrutiny would have helped.
The backout plan is the part to insist on. It forces a question that is otherwise skipped: what does failure look like here, and what do we do about it. It also needs to be reachable during an incident, which means where the on-call engineer already looks rather than inside a change record nobody opens at 3am.
Small batches beat heavy review. A single change deployed alone is diagnosable, because if the error rate moves the cause is obvious. Bundling twenty modifications into one window and one record satisfies the process while destroying its purpose.
The audit requirement is the trail, not the form. A pipeline that records commit, reviewer, test results, deploy time, and who triggered it produces stronger evidence than a ticket completed afterwards from memory.
Freeze windows should be specific. A blanket freeze that blocks a security patch is worse than no freeze. Tie restrictions to risk class and to real business events.
Measure, then set the weight. If incident close codes capture change related causes, you get a change failure rate, and that number tells you which classes are over-controlled and which are under-controlled. Without it, process weight is decided by anecdote and rarely revisited.
Frequently asked questions
- What is the change management process in ITSM?
- A controlled sequence for modifying production systems: request, risk assessment and classification, authorisation, scheduling, implementation, and review. Its purpose is to make risk visible and reversal planned before a change lands, and to leave a record linking later failures back to what was modified.
- What are the types of change in ITSM?
- Most frameworks use three. Standard changes are pre-authorised because they are well understood and low risk. Normal changes go through assessment and authorisation. Emergency changes are expedited, accepting reduced assessment for speed, with review afterwards. The mix between them is a useful diagnostic of process health.
- Is a change advisory board still necessary?
- Only where reviewers understand the systems well enough to change the outcome. A board reading records for systems it does not operate adds delay without reducing risk, and teaches everyone the process is a formality. Pre-authorising classes the pipeline can police keeps scrutiny where it helps.
- What is a change failure rate?
- The proportion of changes that cause a degradation needing remediation, such as a rollback or hotfix. It is the most defensible input for deciding how much control each class of change deserves, and incident close codes that record change related causes produce it almost for free.
- Is ITSM change management the same as organisational change management?
- No, despite the shared name. ITSM change management controls technical modifications to services and infrastructure. Organisational change management concerns how people adopt new ways of working. The practices, owners, and measures are unrelated, and conflating them causes confusion in tooling discussions.