IT change management is the process an organization uses to control changes to its technology: proposing a change, assessing its risk and impact, getting the right approval, scheduling it, carrying it out and recording what happened. It covers everything from a firewall rule or server patch to a major system upgrade. The aim is to let necessary changes happen while reducing the outages, security gaps and surprises that unplanned or poorly coordinated changes cause. It is a core practice within IT service management (ITSM).
At a glance
- Change management controls how changes to IT systems are requested, assessed, approved, scheduled and recorded.
- Changes are usually sorted by risk: pre-approved standard changes, normal changes that need review, and emergency changes.
- Higher-risk changes may go to a change advisory board (CAB); routine ones follow lighter, pre-agreed paths.
- A good record links each change to the systems it affects, often through a CMDB, and to any incidents that follow.
- It applies to your own team and, through the contract, to managed service providers working in your environment.
What problem it solves
A large share of IT outages follow a change: a configuration pushed to the wrong device, an update with an unexpected dependency, two teams working on the same system on the same night. Without a process, nobody can see what is about to change, what changed last night, or who to call when something breaks afterward. Troubleshooting slows down because the most likely cause is invisible.
Change management makes changes visible and deliberate. It asks the person making a change to think through impact and rollback, gets the right people to agree, avoids conflicts with other work and business events, and leaves a record. That record is also what auditors, cyber insurers and frameworks often ask for as evidence that changes to important systems are controlled.
How it works
Request. Someone raises a change request describing what will change, why, which systems are affected, the plan, the test approach and how to roll back if it fails. In most organizations this lives in the same ITSM tool as incidents and requests.
Assess and categorize. The change is rated for risk and impact. Common practice, drawn from the Information Technology Infrastructure Library (ITIL), separates standard changes (low-risk, repeatable, pre-approved), normal changes (assessed and approved case by case) and emergency changes (urgent, with a shortened approval path and later review). A configuration management database (CMDB), where one exists, helps show what else depends on the affected systems.
Approve and schedule. Low-risk changes may be approved by a team lead or automatically; higher-risk ones may go to a change advisory board. Approved changes are placed on a change calendar, often within agreed maintenance windows and outside freeze periods such as month-end or peak season.
Implement and review. The change is made, verified and closed with notes on the outcome. Failed changes and changes linked to incidents are reviewed so the process, testing or automation can improve. Teams practising DevOps often build these controls into automated pipelines, so approval comes from tests and peer review rather than a meeting.
When it matters for buyers
- When outsourcing IT or network operations. Agree whose change process applies, what the provider can change without asking, and how you are notified.
- When outages follow maintenance. A pattern of change-related incidents is a sign the process, or its enforcement, needs attention.
- When preparing for audits or compliance. Many frameworks expect evidence that changes to important systems are authorized and tested.
- When choosing an ITSM or help desk platform. Change workflows, calendars and CMDB integration vary by product.
- When routine work piles up. Defining standard changes, such as patch management cycles or moves, adds and changes, speeds things up without losing control.
Questions to ask vendors
- Do you follow our change process in our environment, or your own? How do they fit together?
- Which changes can you make without our approval, and how much notice do we get for the others?
- How do you handle emergency changes, and how are they reviewed afterward?
- What maintenance windows do you use, and can we set freeze periods?
- How are changes recorded and reported to us, and can we see them in our own tools?
- What is your change failure rate, and how do you measure it?
Our help desk overview covers service desk providers and platforms that run change workflows alongside incidents and requests.
How it differs from IT service management (ITSM)
IT service management (ITSM) is the whole discipline of designing, delivering and supporting IT services, covering incident, request, problem, asset and change practices, usually run on one platform. IT change management is one practice within it, focused on controlling modifications to systems. An organization can have a help desk and incident process with weak change control, and that gap often shows up as outages after maintenance. Change management also connects to site reliability engineering (SRE), where automated testing, gradual rollouts and fast rollback reduce change risk alongside, or in place of, manual approvals.