Emergency changes bypass parts of the standard change process when there is insufficient time for the usual assessment, approval, and scheduling. Urgency is exactly what makes emergency changes risky.
The emergency change control process exists to keep speed from turning into chaos: a lighter, faster route through Change Management that still keeps structure, accountability, and a way to roll things back if the fix makes matters worse.
Here's how that process works, what ITIL recommends, and the practices that stop emergency changes from becoming a habit.
Change in ITIL
Change management is a process used to ensure that a change within the IT infrastructure is handled with the least disruption to IT services and the least impact on the business processes. From an ITIL perspective, change can be anything from migrating to a different service desk solution or a shift from on-premise infrastructure to cloud.
There are different change categories with different steps, starting with submission, where change requests are made and tickets are created, and ending with closure, where the change is marked as successful, failed, or incomplete. After submission is the planning stage, where the expected time, service disruptions, etc. are calculated and conveyed to the stakeholders. The plan is further approved by the change advisory board in the next stage, following which the change is implemented. After this comes the review stage where any issues that arose during implementation are fixed out, following which comes the closure stage.
Since ITIL 4, change management became change enablement. The name change signified how the responsibility for the change was shared among all the employees of the organization and how instead of managing the change, employees were empowered to make the change themselves.
When does a change become an emergency change?
An emergency change is a change that cannot wait for the standard change process without creating unacceptable risk or impact. A major service outage, an actively exploited vulnerability, or a failed deployment affecting a critical service can all require immediate action.
ITIL generally distinguishes three types of change:
- Standard change: A low-risk, routine change with a known outcome and a documented, repeatable procedure. Examples include routine software patches, hardware replacements, and other recurring maintenance.
- Normal change: A change that requires assessment, planning, and authorization because it is not routine and carries risks that need to be evaluated. Normal changes can range from relatively low-impact changes to major changes with significant risk or business impact.
- Emergency change: A change that must be implemented quickly because delaying it could cause significant service disruption, security exposure, or other serious impact. The process is accelerated, with appropriate controls maintained where time allows and a review conducted afterward.
Emergency changes may involve less testing or a shorter approval path because there is no time for the full process. That increases the risk, which is why organizations need clear criteria for declaring an emergency change and a defined process for handling and reviewing it.
What does ITIL recommend for handling emergency changes?
According to ITIL, the process for emergency change should begin just like any other change - by creating a request for change. The change manager will bring this to the attention of the ECAB or Emergency Change Advisory Board. This will be composed of members of the Change Advisory Board who are available and have the expertise and authority to make decisions regarding the change.
The ECAB members are responsible for weighing the risks of implementing the proposed change as an emergency change and the risks of delaying the change and implementing it as a normal one. In some cases, if the risks outweigh the benefits, the ECAB may decide to proceed with the change as a normal one.
If ECAB approves the change, the change owner will plan and design the change. They’re also responsible for building and testing the change if required. Once tested, the change owner will coordinate the implementation of the change. The configuration management database is updated to reflect the changes during the implementation phase.
Once implemented, the change owner will review to mark it as a success or a failure.
If failed, the change owner will initiate the back-out process. Back-out is an element that is rather unique to emergency changes. It is used to bring the systems back to the initial state if the change fails, or if the change presents new risks or issues.
In practice, this means that the emergency change is handled like an accelerated version of a normal change. Since it won’t be expected or routine, you’ll need unique approaches to tackle the change. But because of the time constraint, the approval and testing will be limited. And often a higher level of risk will be accepted by the ECAB, as the delays may prove costly.
How to handle an emergency change in InvGate Service Management
The process above is the theory. Here's how it plays out in practice when the tool is doing the work of moving an emergency change from request to resolution — with the ECAB approval kept fast without losing the paper trail.
-
1Log the change. Create the change request with the details of what needs to happen and why. There's no need to pre-label it as emergency here; the workflow will make that call a step later, based on evidence rather than the requester's judgment.
-
Run the Risk and Impact Assessment. The workflow's assessment step scores the change on how much risk it carries and how much is at stake if it's delayed. AI Hub's predictive risk and impact analysis can feed this step, giving a faster read on likely blast radius so the score reflects more than a manual guess.
- Let the conditional route it. Based on the assessment result, a single conditional branches the change down one of two paths: a high-risk, can't-wait result routes it to the Emergency Change Advisory Board (ECAB); anything below that threshold goes to the standard Change Advisory Board (CAB) on the normal path.
- Implement and record the work. Once approved, the change owner carries out the fix and the workflow moves into implementation. As they go, the request keeps the record — what was done, by whom, and when — so the account of the change stays complete even though testing and planning were compressed for speed.
- Review, then roll back if needed. After implementation, the change is marked a success or a failure in the review step. If it failed or created new problems, the back-out plan returns systems to their previous state — the safety net that matters most when testing was cut short for speed.
Best practices for handling emergency change
Set standards for classifying changes as emergency or normal
One of the most discussed points about change management is deciding if a change is to be treated as a normal one or an emergency. It's easy to classify the extremes of both, for example, it's easy to classify mitigating a cyberattack as an emergency change, and it's easy to treat a feature update as a normal change.
But boundaries often get blurred, let’s say when a feature update is blocking key business processes. And the organizational environment can make change requesters to treat all of their changes as emergencies. For example, if the change advisory board convenes only every two months or so, people may not way to wait that long to get their change approved, making them submit every change request as an emergency.
Emergency changes present high risks to the organization as the priority is on speed. So its important to set standards to classify changes as emergency or normal changes.
If there are way too many emergency changes, you need to understand why
As mentioned above, too many emergency changes can add unnecessary risks to the organization. And at some point, these risks can outweigh the benefits. Therefore you have to keep monitoring the overall picture when it comes to changes across the organization.
Analyze the number of normal, standard, and emergency changes, how many of them were successful, how many emergency changes were in fact actually emergencies, and if the risks were actually worth it. This should help you understand if you have way too many emergency changes approved in your organization.
If you do, try to understand why. Maybe it's an organization’s culture that encourages high-risk behavior in exchange for speed. Or it could be a passing trend; maybe the organization is fending off a series of targeted cyber-attacks.
Either way, focus on reducing emergency changes in the long run. This will be a fine balance; inculcate a culture of treating all changes as normal and you may face significant costs as services go down for long durations.
Make sure the ECAB team has the expertise and authority for approving the change
It’s relatively easy to build a CAB with members having the relevant expertise and authority for the change, but it requires a bit more effort for ECAB. When speed is important, it may not be easy to get all the members of CAB to discuss and approve the change - hence the ECAB. But this does not mean people without the expertise should make the decision.
It may be a good idea to form a clear picture of the chain of command and field of expertise among the CAB so that everyone knows who is absolutely necessary to form the ECAB for the specific emergency. For example, in the case of isolating a network to mitigate a cyberattack, network engineers may be important.
And at the same time, it would be prudent to not rely on one single person for expertise on a subject. Emergency changes should not be delayed just because of the absence of one person.
Fix first, (but definitely) document later
When delays in change can be costly, you’ll need to come up with quick solutions and deploy them in the shortest possible time. And while documenting the changes and their impact is important, the priority should be on implementing the change. Focus on designing the solution and planning how it will be rolled out.
But once implemented, the change and the affected components must be tracked and documented, both for further support and for clarity among the IT support team.
Don’t forget to communicate
When changes are rolled out rapidly, communication often takes a backseat, and this is reasonable. When a plane is on a downward spiral, the first job of the pilots is not to announce to the passengers that the engines are on fire or that there’s smoke in the cabin.
But once the changes are implemented and the smoke clears up, it's important to let the stakeholders, the employees, and the users know what necessitated the change, what was changed, and how it will affect them. To use the aviation analogy again, it may be a good idea to keep the ANC acronym - Aviate, Navigate, Communicate in your mind. Get your aircraft flying again, point it in the right direction, and communicate with the affected players.
Frequently Asked Questions
What are the different types of change according to ITIL?
The three types of changes are normal, standard, and emergency changes. Standard changes are carried out often, they’re predictable and often follow a set of repeatable steps. Normal changes are planned changes, but require a specific and unique approach, and are not routine. Emergency changes are similar to normal changes but are in response to something that requires immediate attention, such as security issues. They’re often executed on a shorter timeframe compared to other changes.
When does a change become an emergency change?
When a change has to be executed in a short time frame, when delays can be costly to the business, the change becomes an emergency change. They’re necessary to ensure service continuity and uninterrupted service delivery.
What is the ECAB?
The Emergency Change Advisory Board (ECAB) is a group authorized to assess and approve emergency changes when there is not enough time to follow the normal Change Advisory Board (CAB) process. It typically includes the people needed to make a rapid decision based on the change’s urgency, risk, and potential impact.
