![Advisera Neven Zitek](https://advisera.com/wp-content/uploads/blog_authors/nevenzitek.jpg)
January 19, 2016
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).
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.
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.
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:
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.