ITIL: Change Management Process

Change Management Process


The purpose of this process is “to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.

  • Keep abreast of the changes that happen in the business environment.
  • Ensure that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.
  • To control the items recorded in the configuration management system (CMS).
  • Optimize risk for the business.


The scope of this process covers everything that require changes, from the architecture and infrastructure to the processes, documentation, metrics, and tools that support your services, as well as changes to IT services and configuration items.

This scope covers changes that are required to run IT Services. However, it can exclude some changes:

  • Minor operational changes that need to be done as part of day-to-day management of the infrastructure may also excluded from the change management process.
  • You don’t need to enter a change request record if you are performing troubleshooting steps to restore normal service in response to an incident.
  • Restarting a client machine not require any change request. However, if an application server requires a reboot, then the action of rebooting may have an effect on large user population and requires a change request.

Type of changes

  • Standard changes: All those changes that has a pre-authorized approach to its execution. These changes are well-known and clearly understood risk. Because the procedures are known and risk is low; there is no steering committee approval is required; refer Change Management Process.
  • Emergency Changes: This type of change is in response to or in order to prevent a business-critical error. Emergency change advisory board (ECAB) should be given same rights as Change Advisory board.
  • Normal Changes: Where the request has came through Service Desk. The Seven Rs of assessment should be followed:

Who raised the change? What is the reason for the change? What is the return required from the change? What are the risks involved in the change? What resources are required to deliver the change? Who is responsible for the build, test and implementation of the change? What is the relationship between this change and other changes?


Documents from Change Management:

The change schedule can be updated.

The projected schedule outage document can be updated.

The remediation plan should be in place to restore service back to normal; in case of change failure.