Neven Zitek Everything in IT Service Management is a change, and the goal of Change Management is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes. This is in order to minimize the impact of change-related incidents on service quality, and consequently, to improve the day-to-day operations of the organization. But, there is one type of change that requires swift reaction and prompt implementation with little or no time for in-depth impact analysis or testing: the Emergency Change.
Before we continue, you can find a lot of information regarding Change Management (in order to familiarize yourself with Change Management, you can start with the following article: ITIL V3 Change Management – at the heart of Service Management).
What is an Emergency Change?
Every business is application driven, which leaves businesses vulnerable to a wide array of security and security-related risks. One of the most popular and dangerous risks is called “0-day exploit” (zero-day exploit). A zero-day vulnerability refers to a hole in software that is unknown to the vendor. This security hole is then exploited by hackers before the vendor becomes aware and hurries to fix it – this exploit is called a zero-day attack.
Even when a fix becomes available (and even more people become aware of the exploit), not all IT organizations implement the fix right away, leaving enough time for malicious people or software to actually try to break into systems that haven’t been patched.
Implementing such high-risk security patches is the most common example of an Emergency Change – a change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch.
Organizing the Emergency Change process
Due to the nature of the Emergency Changes, it’s clear that there is no time to wait for a formal Change Advisory Board (CAB) meeting, nor is it possible to even attempt to organize an impromptu meeting. However, Emergency Changes should not be handled outside of Change Management. According to ITIL, the Emergency Change process should still retain a high level of authorization and control, but those processes can be looser than those for a normal change. The number of Emergency Changes should be kept to an absolute minimum, with every Emergency Change being reevaluated after implementation to determine whether it was actually an Emergency Change, and if not, how to prevent such changes from being processed as Emergency Changes in the future.
A Normal Change relies heavily on changes being tested prior to deployment, and the decision on whether to allow deployment into the live environment will be based on test results. In the case of Emergency Changes, it is still strongly recommended to perform at least basic testing prior to deployment, as untested changes may cause even more damage than the risk we were trying to prevent! At the end of the day, it all comes down to numbers; is the potential damage caused by an untested emergency change (e.g., a patch) smaller or greater than the damage currently caused by the identified risk (e.g., a security breach)? If it’s smaller, then the Change Manager has a good argument to allow such change.
Roles in the Emergency Change process
In order to define roles specific to Emergency Change, first we have to look at who is doing what in the case of Normal or Emergency Change:
- Change Manager – primarily responsible for the lifecycle of all changes, allowing beneficial changes to be made with minimal or no disruptions to the service. For Emergency Changes, the Change Manager is responsible for forming the ECAB in order to discuss the proposed Emergency Change, and to decide whether it should be implemented as such, or if it can be re-categorized as a Normal Change. The Change Manager has to ensure that all necessary preparations are made before change implementation.
- Change Advisory Board (CAB) – advisory group consisting of representatives from all areas within the IT organization, business, and third parties with the goal of aiding the Change Manager in change assessment, prioritization, and scheduling. The CAB is not impacted by Emergency Changes, other than the fact that some members may also be a part of the ECAB.
- Emergency Change Advisory Board (ECAB) – specific type of CAB, responsible for making decisions regarding Emergency Changes. ECAB membership may be decided at the ECAB meeting and depends on the Emergency Change nature. The Change Manager can appoint anyone who may help with knowledge, experience, and expertise to the ECAB.
- Others – e.g., Configuration Manager, Application Analyst, Technical Analyst or others as appropriate for any given situation.
- IT operator – person(s) who are responsible for operating the underlining technology of a system (e.g., networking, storage, operating system, etc.). During an Emergency Change, the IT operator may be involved, depending on his/her technical skills, for Emergency Change testing, implementation, and performing the back-out plan if implementation fails.
- Change Requester – person who triggered the Change Management process.
Conclusion
In my personal experience, Emergency Change management often falls into the trap of being a quick way of implementing changes without the “bureaucracy” and hassle present in the normal change process. This may be an indicator that the normal change process requires some revision. Personally, I’ve seen cases in which changes on systems considered vital (ERP, E-mail, web, file share, printing, and the list goes on until you realize everything is considered vital) were not implemented unless approved by top-level management. IT found a “workaround” and started to implement changes on those systems as Emergency Changes, because no one from top-level management was part of the ECAB.
Emergency Change exists only to address the needs of the organization when normal Change Management can’t be followed, generally due to time constraints and risks involved. There is no magic wand that will solve all of the specifics, and each organization should find the solution that fits best into their own operational model; prompt and efficient handling of all changes will serve to minimize the impact of change-related incidents on service quality.
Use our free ITIL Gap Analysis Tool to check how your activities comply with ITIL recommendations for Change Management.
