What are the three categories of changes in data center change management, and how does the approval process differ for each?

Question

Accepted Answer

Data center change management classifies all changes into three categories based on their risk level, urgency, and the approval process they require. This classification ensures that each change receives the appropriate level of scrutiny without creating unnecessary bottlenecks for routine activities.

Standard changes are low-risk, pre-approved procedures that are performed frequently and have a well-documented, predictable outcome. Examples include replacing a failed hard drive in a RAID array, adding memory to a server following a tested procedure, swapping a network cable, or performing a routine firmware update using an approved process. Standard changes have been reviewed and approved in advance as a category, meaning that each individual instance does not require a separate approval cycle. The technician follows the documented procedure, records the change in the change management system, and completes any post-change verification steps. The key requirement for a change to qualify as standard is that it must have a proven track record of successful execution with minimal risk.

Normal changes are non-routine modifications that require individual evaluation and approval before implementation. These are changes that carry some degree of risk and do not have a pre-approved procedure. Examples include migrating a workload from one server cluster to another, upgrading the firmware on a core network switch, installing new equipment that changes the power or cooling load in a zone, or modifying the network topology. Normal changes follow a structured process: the requester submits a change request that describes the change, its purpose, the impact assessment, the implementation plan, the rollback plan, and the testing approach. The change request is reviewed by the change manager or the Change Advisory Board, depending on the risk level. Once approved, the change is scheduled for a maintenance window, implemented following the documented procedure, and verified before the change is closed.

Emergency changes are urgent modifications required to resolve an active incident or prevent imminent service disruption. Examples include applying a critical security patch to address an actively exploited vulnerability, reconfiguring a system to work around a failed component during an outage, or making an emergency power configuration change to prevent equipment damage. Emergency changes bypass the normal approval workflow because the delay of a standard review would cause greater harm than the risk of the change itself. However, they are not uncontrolled. An emergency change still requires authorization from a designated authority, typically the on-call manager or incident commander, and the change must be documented retrospectively within 24 to 48 hours. A post-implementation review is mandatory for all emergency changes to ensure that the change is validated, any temporary workarounds are replaced with permanent solutions, and the change records are complete.

The underlying principle is that the rigor of the approval process should be proportional to the risk. Standard changes are low-risk and pre-approved to avoid slowing down routine operations. Normal changes carry enough risk to warrant individual review and scheduled implementation. Emergency changes are too urgent for normal review but must still be authorized, documented, and reviewed after the fact.

A well-designed change management process also defines clear criteria for classifying changes. Without these criteria, there is a tendency for requesters to classify normal changes as standard to avoid the review process, or to classify non-urgent changes as emergencies to bypass the scheduling queue. Both behaviors undermine the integrity of the process and increase the risk of uncontrolled changes causing incidents.