What Is a Change Management Procedure? A Step-by-Step Guide for IT Managers
Every uncontrolled change performed on the IT infrastructure carries the risk of operational downtime and service continuity disruption. The Change Management Procedure allows you to manage this risk systematically without preventing change—offering a controlled 10-step approach from RFC creation to impact analysis, approval processes, and rollback planning.
Change Management Procedure is an ITIL-based process ensuring that every change in IT systems is implemented in a controlled manner, passing through request, risk assessment, approval (CAB), planning, implementation, testing, and review steps. The goal is to minimize change-induced downtime and risks without disrupting business continuity.
The majority of downtimes stem not from external attacks, but from uncontrolled or inadequately tested changes. A patch, a configuration update, a server migration—every intervention made without knowing beforehand which production environment it will affect carries the risk of unplanned downtime.
The Change Management Procedure exists precisely to manage this risk: not to prevent change, but to guarantee that every change is traceable, approved, and reversible. Based on the ITIL framework, this process increases change reliability, not change velocity, in corporate IT environments.
The 10 Steps of the Change Management Procedure
The workflow below is the standard path a change follows from request to closure in a mature ITSM environment. The order of steps is crucial—each serves as the input for the next.
-
01
Change Request (RFC) The requesting team answers
what will change,why, andwhich systems will be affectedvia a formal RFC form. Unjustified or vaguely scoped requests are filtered out at this stage. -
02
Classification The change is categorized into pre-approved, low-risk Standard, evaluation-requiring Normal, or Emergency for resolving a critical issue. This classification determines which approval path to follow.
-
03
Impact and Risk Assessment Systems, users, and dependent services affected by the change are analyzed. The risk level is determined, and a rollback plan becomes mandatory at this stage.
-
04
Approval (CAB) The Change Advisory Board (CAB) evaluates the change with the participation of relevant stakeholders. For emergency changes, a smaller ECAB (Emergency CAB) provides rapid approval.
-
05
Planning and Scheduling Implementation is usually scheduled during a low-traffic maintenance window. Assignees, required resources, and a communication plan for affected users are clarified at this stage.
-
06
Implementation The change is first verified in a test environment, then deployed to the production environment following documented steps. Manual and undocumented implementations directly increase the margin of error.
-
07
Testing and Verification It is checked whether the change yields the expected result. If this step is skipped, the issue will be noticed in the production environment via a user complaint—which is exactly what this process aims to prevent.
-
08
Rollback A plan to revert the system to its previous stable state if the change fails is kept ready at all stages. A change without a rollback plan should, by definition, not be approved.
-
09
Closure and Review The result is documented, and the change is closed as successful or failed. If there are unexpected issues, a lessons learned analysis is conducted.
-
10
Documentation and Traceability The entire process is recorded and linked with the CMDB (Configuration Management Database); thus, every change becomes retrospectively traceable for audit and compliance purposes.
⚠️ Common Mistake: In many organizations, the Change Management Procedure is managed via a spreadsheet or an email chain. This leads to lost RFCs, skipped approval steps, and rollback plans not being ready during implementation—bringing back the exact risk the process tries to prevent.
Why Do Manual Processes Hinder IT Managers?
Although the Change Management Procedure looks clear on paper, when executed with manual tools (email, Excel, disjointed ticketing systems), three fundamental issues recur:
Change Management Procedure and Its Relationship with ITIL
The Change Management Procedure is defined as the "Change Enablement" practice under the ITIL 4 framework. ITIL handles changes with three authorization models: predefined automatic approval for standard changes, CAB evaluation for normal changes, and an accelerated ECAB process for emergency changes. As an organization's ITIL maturity level increases, the rate of standard changes is expected to rise—because this indicates that recurring, low-risk operations have been extracted from the process and automated.
What to Consider When Establishing a Change Management Procedure?
1. Clarify Category Definitions
Which changes will be considered "standard" must be predetermined in writing, otherwise, every request falls to the CAB and the process bottlenecks.
2. Mandate the Rollback Plan
No RFC without a rollback plan should be approved—this is the most frequently skipped but operationally most critical rule of the process.
3. Keep the CMDB Up to Date
Impact analysis is only meaningful if the asset inventory is accurate. A dirty and outdated CMDB will always mislead risk assessments.
4. Design the Emergency Path Separately
The ECAB process must be different and faster than the normal workflow. Otherwise, technical teams will start bypassing the approval process entirely.
How does failing to keep the CMDB up to date trigger operational risks and downtime?
Frequently Asked Questions
Q: Is the Change Management Procedure the same as Change Management?
Yes. They are used interchangeably in ITSM literature and are synonymous with the "Change Enablement" practice in the ITIL framework.
Q: Who should make up the CAB (Change Advisory Board)?
The CAB generally consists of technical team leaders affected by the change, a security officer, relevant business unit representatives, and the change manager. Participants are determined on a case-by-case basis according to the scope of the change.
Q: What is the difference between a standard change and a normal change?
Standard changes are pre-approved, low-risk, and recurring operations (e.g., routine patch updates) and do not require CAB approval every time. Normal changes are undefined changes that must go through the evaluation and approval process.
Q: How does the emergency change process differ from the normal process?
Emergency changes go through the ECAB, an accelerated approval mechanism, to resolve a critical issue (such as a production outage). Standard approval steps are narrowed down, but the rollback plan and documentation requirements remain mandatory.
Q: Why should the Change Management Procedure be executed with an ITSM tool?
In email and spreadsheet-based processes, RFCs can get lost, approval steps skipped, and CMDB association remains manual. An ITSM platform combines these steps into a single traceable workflow, streamlining audit and compliance processes.
Q: Is a rollback plan mandatory for every change?
Yes, in a mature Change Management Procedure, a change without a rollback plan should not be approved. The only exceptions are standard changes that are so low-risk they wouldn't require reverting; even then, keeping a rollback note is recommended.
Manage Your Change Management Procedure on a Single Platform
SPIDYA IT Service Management unifies RFC creation, CAB approval workflows, risk assessment, and CMDB integration in a single platform. Your changes won't get lost, approvals won't be delayed, and audit trails are generated automatically.
Explore SPIDYA IT Service Management →