The Change Management Process explained

Q: 3. What types of changes are there?

Typically, ITSM distinguishes three main types: Standard Changes: Pre-approved, low-risk, repeatable (e.g., password resets). Normal Changes: Require assessment, approval, and scheduling (e.g., system patching). Emergency Changes: Urgent changes to resolve major incidents or vulnerabilities (e.g., critical security patch).

Q: 5. Who approves a change?

Approval depends on the change type and impact. Standard changes are pre-approved. Normal changes go through the Change Advisory Board (CAB). Emergency changes may be approved by an Emergency CAB (ECAB) or the Change Manager directly.

Q: 9. How does Change Management integrate with other ITSM processes?

With Incident Management Process : To fix root causes. With Problem Management Process : For permanent solutions. With Configuration Management: To track CIs affected by the change. With Release Management: To coordinate deployments.

Purpose & Scope

Purpose

The purpose of Change Management process is to ensure that:

Standardized methods and procedures are used for efficient and prompt handling of all changes to the <Customer’s Name>’s IT service.
All Changes to <Customer’s Name>’s service assets & configuration items are recorded in the Configuration Management System.
Overall <Customer’s Name>’s business risk is optimized.

Scope

To ensure that your Change Management process is both effective and aligned with evolving ITIL 4 practices, it’s important to periodically assess its maturity and integration across ITSM disciplines. I would suggest that you consider a short ITSM Process Maturity and Gap Analysis engagement that helps organizations identify inefficiencies, process overlaps, and improvement opportunities across ITIL V4 change enablement, release, and configuration management.

The outcome is a clear, actionable roadmap that strengthens control, improves agility, and minimizes the risk of failed or emergency changes. We have in our site laid out how a typical complete 4-week engagement looks like, and you could get it done — a strategic first step toward optimizing your ITSM ecosystem.

Scope of the Change Management Process includes the following:

Definitions

Configuration Item

Configuration Item is any component that needs to be managed in order to deliver <Customer’s Name> IT Service.

Request for Change (RFC)

This is the formal change request, including a description of the change, components affected, business need, cost estimates, risk assessment, resource requirements, and approval status.

Service Asset

It can be any Resource or Capability that contribute to the delivery of a service.

Assets can be of the following types: Management, Organization, Process, Knowledge, People, Information, Applications, Infrastructure and financial capital.

Change Initiator

A person who initiates a request for change; this person can be a business representative or a member of the IT organization.

Change Advisory Board (CAB)

The CAB is a cross-functional group set up to evaluate change requests for business need, priority, cost/benefit, and potential impacts to other systems or processes. Typically the CAB will make recommendations for deployment, further analysis, deferment or cancellation.

Emergency Change Advisory Board (ECAB)

It is the subset of the CAB that deals only with Emergency Changes, which is described in our blog Emergency Change Management. It is established to be able to meet on short notice to authorize or reject changes with emergency priority.

Roles and Responsibilities

Change Manager

Responsibilities

Receives, Logs and allocates a priority, in collaboration with the Change Initiator, to all RFCs; rejects any RFCs that are impractical.
Tables all RFCs for a CAB meeting; issues an agenda and circulates all RFCs to CAB members in advance of meetings to allow prior consideration.
Decides which people will come to which meeting, who gets specific RFCs depending on the nature of the RFC, what is to be changed and people’s areas of expertise.
Organize ECAB meetings for all Emergency RFCs.
Chairs all CAB & ECAB meetings.
After consideration of the advice given by the CAB or ECAB, authorizes acceptable changes.
Issues change schedules, via service desk.
Liaises with all necessary parties to co-ordinate change planning, building, testing & implementation.
Updates the change log with all progress that occurs.
Reviews all the implemented changes to ensure that their objectives.
Analyses change records to determine any trends or apparent problems that occur; seek rectification with relevant parties.
Review all pending RFCs.
Close RFCs.
Produces regular & accurate management reports.

Change Authority

Formal change authorization is obtained for each change from change authority that may be a role, person or a group of people. The levels of authorization for a particular type of change should be judged by the type, size & the risk of the change.

Responsibilities

Authorizes the Change based on the type, size, risk, anticipated business risk, financial implications and the scope of the change.

Change Advisory Board

Responsibilities

Assists change management in the assessment and prioritization of the changes.
Consider and recommend the adoption or rejection of changes appropriate for higher level authorization and then recommendations will be submitted to the change authority.
Recommend the follow-up actions for the emergency changes and the changes implemented as workarounds to incidents.

ITSM Maturity Self Assessment Kit Button

Input, Output

Inputs

Request For Change (RFC)
Configuration Management System (CMS)
Change Schedule (CS)
Test results, test reports & evaluation reports
Change & Release policies
Change, Transition, Release, Deployment, Test, Evaluation & Remediation plans

Outputs

Approved/Rejected RFCs
New, changed or disposed assets or configuration items
Request For Change (RFC)
Change Schedule (CS)
CAB/ECAB meeting minutes & actions
Management Information (Reports)

Change Management Process

Generic Change Management Process

Activity No.	Step	Description	Input/Output	Role
1	RFC	A change is raised by a request from the initiator – the individual or the organizational group that requires the change. It can be triggered from various service lifecycle phases.	Input RFC	Change Initiator
2	Record RFC	RFC should be recorded and allocated a unique identification number.	Input RFC Output Change Record	Change Manager
3	Review RFC	Change management should briefly consider each request and filter out any that seems to be: Totally Impractical, Repeats of earlier RFCs, accepted, rejected or still under consideration.	Input Change Record Output Accepted/Rejected	Change Manager
4	Incomplete? /Wrongly Routed?	If the RFC found to be Incomplete? /Wrongly Routed? Then inform the initiator and close the change record.	Input Output	Change Manager
5	Change Categorization	All changes should be categorized. If the change identified as the standard change then standard change management process should be followed. Refer: <Standard Change Matrix – Template>	Input Change Record Output Categorization Standard Change	Change Manager
6	Change Prioritization	All the changes should be prioritized based on the impact & the urgency of the change. If the change is an emergency change then follow the emergency change management process. Refer: <Change Priority Matrix – Template>	Input Change Record Output Prioritization Emergency Change	Change Manager
7	Risk & Impact Analysis	All the changes should be assed for Risk & impact of the change. Impact can be identified by referring CMS. Refer: <Change Impact & Risk categorization Matrix>	Input Change record Output Risk Impact	Technical team/ Change Manager
8	Technical Assessment	Technical assessment should be done to check the technical feasibility to implement the change.	Input Change record Output Technical Assessment	Technical team/ Change Manager
9	Change Planning	Change should be planned for build, test, implementation & remediation. This activity should be carried out with the help of “Release & Deployment Management”.	Input Change record Output Change Plan	Technical team/ Change Manager
10	Asses & Evaluate Change	All the changes should be assessed and evaluated and approved. CAB will asses & evaluate all the planned changes. If the results are not satisfactory then CAB will instigate the Change planning activities.	Input Change record Output Approved Rejected	CAB
11	Co-ordinate Build	After the approval from CAB, change should be built in order to test the change. This activity should be carried out with the help of “Release & Deployment Management”.	Input Change record Output Build	Change Manager
12	Co-ordinate Test	After the change is built, change should be tested & the results will be published. This activity should be carried out with the help of “Release & Deployment Management”.	Input Change record Output Test results	Change Manager
13	Change Authorization	Test results & the change plan will be sent for the authorization. Level of the authorization will be decided based on the type, risk & impact of the change. Refer: <Change Authorization Matrix – Template>	Input Test Results Change record Output Authorization	Change Manager
14	Co-ordinate Implementation	Once the change is authorized, change will be implemented as per the planned schedule. This activity should be carried out with the help of “Release & Deployment Management”.	Input Change record Authorization Output Change Implementation	Change Manager
15	Change Failed?	If the change is failed, then Change remediation plan should be instigated. An incident record will be raised for the further investigation. A Problem record will be raised for RCA and will be reviewed during the Change Review. Existing change record will be reviewed & closed.	Input Change record Implementation results Output Change Closure Incident	Change Manager
16	Co-ordinate Change Remediation	If the change is failed, then the remediation plan should be implemented to bring the service into the earlier status. This activity should be carried out with the help of “Release & Deployment Management”.	Input Change record Change remediation plan Output Remediation	Change Manager
17	Review & Close Change	All the implemented changes should be reviewed and the necessary actions should be triggered. Changes will be reviewed in the CAB meetings.	Input Output	Change Manager

Standard Change Management Process

Activity No.	Step	Description	Input/Output	Role
1	Choose Change Model	Standard changes are changes to the services for which the approach is pre-authorized by change management that has an accepted and established procedure to provide specific change requirement. Change models will be created to implement the standard changes. Refer: <Standard Change Matrix – Template>	Input Standard Change Output Change Model	Change Manager/Service Desk/Technical Team
2	Assign Resources	Resources will be assigned as per the requirement to implement the change	Input Standard Change Output Resource Allocation	Change Manager
3	Change Implementation	Change will be implemented using the change model and the results will be communicated to the Change Initiator.	Input Standard ChangeChange Model Output Change Results	Service desk/Technical Team
4	Review & Close Change	All the implemented changes should be reviewed and the necessary actions should be triggered.	Input Change record Output Improvement Actions	Change Manager

Emergency Change Management Process

Emergency change is reserved for changes intended to repair an error in an IT service request management, that is negatively impacting the business at a high degree.

Emergency Change management process will follow the normal change management processes expect that:

Approval will be given by the ECAB rather that waiting for a CAB meeting.
Testing may be reduced, or in extreme cases forgone completely, if considered a necessary risk to deliver the change immediately.
Documentation of the change record and configuration data may be deferred, typically until normal working hours.

Measurements

Reports are generated based on the below metrics.

Metrics	Description
Benefits of the change	Benefit of Change = (Value of Improvements) + (Negative impacts prevented or terminated) – (Cost of the Change Process)
Unauthorized changes	Reduction in the number of unauthorized changes
Backlog Changes	Reduction in backlog of change requests
Unplanned changes/Emergency fixes	Reduction in the number and percentage of unplanned changes and emergency fixes
Change Success Rate	Percentage of changes implemented successfully
Remediation of changes	Reduction in the number of changes where remediation invoked
Failed Changes	Reduction in number of failed changes
Change Implementation Time	Average time to implement based on urgency/priority/type.
Incidents caused by changes	Incidents attributable to the changes
Change Estimation	Percentage accuracy in change estimation
Impact assessment	Number of changes implemented with incomplete impact assessment
Frequency of the changes	Frequency of the changes by service, business unit etc.
Change Volume	Volume of the changes & trends
Planned Vs Unplanned	Ration of planned Vs unplanned changes
Accepted Vs Rejected	Ratio of Accepted to rejected change requests

FAQs

1. What is Change Management in ITSM?

Change Management is the structured process used to control modifications to IT systems, infrastructure, and services.
Its goal is to ensure that changes are implemented efficiently, with minimal risk and disruption to business operations.

2. Why is Change Management important?

Without a formal process, uncoordinated changes can lead to service outages, security vulnerabilities, or compliance breaches.
Change Management ensures accountability, traceability, and controlled deployment across the IT landscape.

3. What types of changes are there?

Typically, ITSM distinguishes three main types:
Standard Changes: Pre-approved, low-risk, repeatable (e.g., password resets).
Normal Changes: Require assessment, approval, and scheduling (e.g., system patching).
Emergency Changes: Urgent changes to resolve major incidents or vulnerabilities (e.g., critical security patch).

4. What is an RFC (Request for Change)?

An RFC is a formal proposal to make a change. It captures details such as purpose, scope, risk assessment, implementation plan, testing results, and back-out procedures before approval.

5. Who approves a change?

Approval depends on the change type and impact.
Standard changes are pre-approved.
Normal changes go through the Change Advisory Board (CAB).
Emergency changes may be approved by an Emergency CAB (ECAB) or the Change Manager directly.

6. What is a Change Advisory Board (CAB)?

The CAB is a group of stakeholders — typically including IT, operations, business, and security representatives — who evaluate and authorize significant changes.
Their goal is to ensure that the change aligns with business priorities and risk tolerance.

7. What is a Post Implementation Review (PIR)?

A PIR is conducted after a change to confirm whether objectives were met, assess any incidents or deviations, and identify lessons learned for continuous improvement.

8. How are emergency changes handled differently?

Emergency changes bypass the full approval process to restore service or prevent severe issues quickly.
They’re documented afterward and reviewed retrospectively to ensure governance is maintained.

9. How does Change Management integrate with other ITSM processes?

With Incident Management Process: To fix root causes.
With Problem Management Process: For permanent solutions.
With Configuration Management: To track CIs affected by the change.
With Release Management: To coordinate deployments.

10. What metrics are used to measure Change Management performance?

Key metrics include:
Change success rate (percentage implemented without incidents)
Number of emergency changes
Average time for change approval
Percentage of failed or rolled-back changes
Post Implementation Review (PIR) completion rate