{"id":5551,"date":"2016-01-19T20:03:19","date_gmt":"2016-01-19T20:03:19","guid":{"rendered":"https:\/\/multiacademstg.wpengine.com\/20000academy\/?p=5551"},"modified":"2025-07-05T13:43:04","modified_gmt":"2025-07-05T13:43:04","slug":"how-to-manage-emergency-changes-as-part-of-itil-change-management","status":"publish","type":"post","link":"https:\/\/staging.advisera.com\/20000academy\/blog\/2016\/01\/19\/how-to-manage-emergency-changes-as-part-of-itil-change-management\/","title":{"rendered":"How to manage Emergency Changes as part of ITIL Change Management"},"content":{"rendered":"<p>Everything in IT Service Management is a change, and the goal of <a href=\"https:\/\/staging.advisera.com\/20000academy\/iso-20000-documentation-toolkit\/?rel=service-design-build-and-transition-processes&amp;doc=change-management-policy\" target=\"_blank\" rel=\"noopener noreferrer\">Change Management<\/a>\u00a0is 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 <strong>Emergency Change<\/strong>.<\/p>\n<p>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: <a href=\"https:\/\/staging.advisera.com\/20000academy\/knowledgebase\/itil-v3-change-management-at-the-heart-of-service-management\/\" target=\"_blank\" rel=\"noopener noreferrer\">ITIL V3 Change Management \u2013 at the heart of Service Management<\/a>).<\/p>\n<h2>What is an Emergency Change?<\/h2>\n<p>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 \u201c<strong>0-day exploit<\/strong>\u201d (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 \u2013 this exploit is called a zero-day attack.<\/p>\n<p>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\u2019t been patched.<\/p>\n<p>Implementing such high-risk security patches is the most common example of an Emergency Change \u2013 a change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch.<br \/>\n<div id=\"middle-banner\" class=\"banner-shortcode\"><\/div><script>loadMiddleBanner();<\/script><br \/>\n<div id=\"side-banner-trigger\" class=\"banner-shortcode\"><\/div><\/p>\n<h2>Organizing the Emergency Change process<\/h2>\n<p>Due to the nature of the Emergency Changes, it\u2019s clear that there is no time to wait for a formal\u00a0<a href=\"https:\/\/staging.advisera.com\/20000academy\/iso-20000-documentation-toolkit\/?rel=service-design-build-and-transition-processes&amp;doc=minutes-of-meeting-cab\" target=\"_blank\" rel=\"noopener noreferrer\"><strong>Change Advisory Board<\/strong> (CAB)<\/a> 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 <a href=\"https:\/\/staging.advisera.com\/20000academy\/what-is-itil\/\" target=\"_blank\" rel=\"noopener noreferrer\">ITIL<\/a>, 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 <a href=\"https:\/\/staging.advisera.com\/20000academy\/iso-20000-documentation-toolkit\/?rel=service-design-build-and-transition-processes&amp;doc=change-schedule\" target=\"_blank\" rel=\"noopener noreferrer\">implementation<\/a>\u00a0to 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.<\/p>\n<p>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\u2019s smaller, then the Change Manager has a good argument to allow such change.<\/p>\n<h2>Roles in the Emergency Change process<\/h2>\n<p>In order to define roles specific to <a href=\"https:\/\/staging.advisera.com\/20000academy\/iso-20000-documentation-toolkit\/?rel=service-design-build-and-transition-processes&amp;doc=change-management-process\" target=\"_blank\" rel=\"noopener noreferrer\">Emergency Change<\/a>, first we have to look at who is doing what in the case of Normal or Emergency Change:<\/p>\n<ul>\n<li><strong>Change Manager<\/strong> \u2013 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.<\/li>\n<li><strong>Change Advisory Board<\/strong> (CAB) \u2013 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.<\/li>\n<li><strong>Emergency Change Advisory Board<\/strong> (ECAB) \u2013 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.<\/li>\n<li><strong>Others<\/strong> \u2013 e.g., Configuration Manager, Application Analyst, Technical Analyst or others as appropriate for any given situation.<\/li>\n<li><strong>IT operator<\/strong> \u2013 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.<\/li>\n<li><strong><a href=\"https:\/\/staging.advisera.com\/20000academy\/iso-20000-documentation-toolkit\/?rel=service-design-build-and-transition-processes&amp;doc=request-for-change-and-change-record\" target=\"_blank\" rel=\"noopener noreferrer\">Change Requester<\/a> <\/strong>\u2013 person who triggered the <a href=\"https:\/\/staging.advisera.com\/20000academy\/iso-20000-documentation-toolkit\/?rel=service-design-build-and-transition-processes&amp;doc=change-management-process\" target=\"_blank\" rel=\"noopener\">Change Management process<\/a>.<\/li>\n<\/ul>\n<p><img decoding=\"async\" class=\"aligncenter size-full wp-image-8788\" style=\"margin-top: -5px; margin-bottom: -10px;\" src=\"\/wp-content\/uploads\/\/sites\/6\/2016\/01\/emergency-change-1.jpg\" alt=\"Change authorization model (example)\" width=\"2208\" height=\"4107\" \/><\/p>\n<h2>Conclusion<\/h2>\n<p>In my personal experience, Emergency Change management often falls into the trap of being a quick way of implementing changes without the \u201cbureaucracy\u201d and hassle present in the normal change process. \u00a0This may be an indicator that the normal change process requires some revision. \u00a0Personally, I\u2019ve 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 \u201cworkaround\u201d and started to implement changes on those systems as Emergency Changes, because no one from top-level management was part of the ECAB.<\/p>\n<p>Emergency Change exists only to address the needs of the organization when normal Change Management can\u2019t 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.<\/p>\n<p><em>To implement ISO 20000 easily and efficiently, use our<\/em> <a href=\"https:\/\/staging.advisera.com\/20000academy\/iso-20000-documentation-toolkit\/\" target=\"_blank\" rel=\"noopener\">ISO 20000 Documentation Toolkit<\/a> <em>that provides step-by-step guidance for full ISO 20000 compliance.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Everything in IT Service Management is a change, and the goal of Change Management\u00a0is 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. &#8230;<\/p>\n","protected":false},"author":33,"featured_media":8782,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[351,518,519,520,517,344],"class_list":["post-5551","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-change-management","tag-change-manager","tag-emergency-change","tag-emergency-change-advisory-board","tag-emergency-change-management","tag-itil"],"acf":[],"_links":{"self":[{"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/posts\/5551","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/users\/33"}],"replies":[{"embeddable":true,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/comments?post=5551"}],"version-history":[{"count":3,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/posts\/5551\/revisions"}],"predecessor-version":[{"id":18536,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/posts\/5551\/revisions\/18536"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/media\/8782"}],"wp:attachment":[{"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/media?parent=5551"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/categories?post=5551"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/tags?post=5551"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}