Standard vs Normal vs Emergency Changes: ITIL Guide

If your team treats every change request the same way, you’re either moving too slowly on routine work or taking unnecessary risks with high-impact updates. ITIL change management defines three distinct change types — standard, normal, and emergency — each with its own approval process, risk profile, and timeline. Understanding the difference helps IT teams reduce bureaucracy where it’s safe to do so, while keeping the right controls in place where they matter most.

What Is Change Management in ITIL?

Change management (called Change Enablement in ITIL 4) is the practice of controlling the lifecycle of all changes to IT services and infrastructure. The goal is to maximize the number of successful changes while minimizing the risk of disruption to live services.

A change is any addition, modification, or removal of anything that could affect IT services. That includes software deployments, configuration updates, hardware replacements, access control adjustments, and more. ITIL groups these changes into three types based on how well-understood they are, how much risk they carry, and how urgently they need to happen.

The Three ITIL Change Types at a Glance

Standard Changes

What is a standard change?

A standard change is a pre-authorized change to a service or infrastructure that follows an established procedure. Because the change has been assessed and approved in advance, it does not require a new change request or CAB review each time it is performed. The risk is well understood, the steps are documented, and the outcome is predictable.

Standard changes are the most efficient type. Once your organization defines and approves the procedure, technicians can execute it repeatedly without additional overhead. This frees the Change Advisory Board (CAB) to focus on changes that actually require deliberation.

Characteristics of standard changes

• Pre-authorized: Approval is granted once at the procedure level, not per request.
• Low risk: The change is well-understood and has a proven track record.
• Documented procedure: A step-by-step work instruction exists and is followed consistently.
• Defined rollback: A clear remediation path exists if something goes wrong.
• Routine: The change is performed frequently enough that the procedure is familiar to the team.

Standard change examples

• Password resets for standard user accounts
• Adding a user to an existing security group
• Installing a pre-approved software package via a software catalog
• Replacing a failed hard drive on a server with a hot-swap spare
• Provisioning a new laptop using a standard build image
• Applying a routine OS patch during a scheduled maintenance window

When does a standard change stop being standard?

A change that has been classified as standard can lose that status if the underlying technology, environment, or risk profile changes significantly. For example, a password reset procedure that was standard for on-premises Active Directory may require re-assessment after a migration to a cloud identity provider. Periodic review of your standard change catalog is important — typically at least once a year or after major infrastructure changes.

Normal Changes

What is a normal change?

A normal change is any change that is not pre-authorized (standard) and not urgent enough to be treated as an emergency. It follows the full change management workflow: a change request is raised, assessed for risk and impact, reviewed by the CAB or a designated approver, scheduled during an appropriate change window, and then implemented.

Despite the name, “normal” does not mean low-risk or simple. A normal change can range from a minor configuration tweak to a major infrastructure migration. The defining characteristic is that it follows the standard approval process at the time of request.

Characteristics of normal changes

• Requires a change request: Each instance must be submitted and reviewed individually.
• Risk assessment: Impact and risk are evaluated before approval is granted.
• CAB review: High-risk or high-impact changes go to the full Change Advisory Board; minor normal changes may be approved by a designated change manager.
• Scheduled implementation: The change is planned for a maintenance window or agreed timeframe.
• Documented rollback plan: A remediation plan is required before approval.

Normal change examples

• Upgrading a database server to a new major version
• Migrating a business application to a new hosting environment
• Modifying firewall rules to open a new port for a business application
• Deploying a new third-party integration between two core systems
• Changing the configuration of a load balancer

Minor vs. significant normal changes

Many organizations sub-categorize normal changes into minor (low risk, small scope, approved by the change manager alone) and significant (higher risk or broader impact, requiring full CAB review). This tiering reduces CAB meeting load while maintaining governance over changes that genuinely need scrutiny. The exact thresholds should be defined in your change management policy.

Emergency Changes

What is an emergency change?

An emergency change is a change that must be implemented as quickly as possible to resolve a major incident, restore a service, or address a critical security vulnerability. The normal approval process is too slow for the situation, so an expedited path is used instead.

Emergency changes carry the highest risk of all three types — not because the change itself is inherently dangerous, but because the pressure of time compresses the assessment and testing phases. Mistakes made under urgency can cause additional outages or security issues.

Characteristics of emergency changes

• Urgent by definition: The business or service impact of waiting exceeds the risk of acting quickly.
• Emergency CAB (ECAB): A smaller, on-call group of approvers who can convene quickly — sometimes via phone or chat — rather than waiting for a scheduled meeting.
• Abbreviated assessment: Risk and impact assessment still happens, but is condensed to fit the timeline.
• Post-implementation review mandatory: Documentation is often completed after the fact, but it must be completed. A PIR (post-implementation review) should always follow.
• Not a shortcut for poor planning: Emergency changes should be genuinely rare. If your team is raising emergency changes frequently, that is a process problem, not a feature.

Emergency change examples

• Applying a security patch to close an actively exploited vulnerability
• Rolling back a failed deployment that has taken a production service offline
• Replacing a failed network switch causing a site-wide outage
• Rerouting traffic after a data center failure
• Disabling a compromised user account during an active security incident

The danger of emergency change overuse

Emergency changes should represent a small fraction of total changes — most ITIL practitioners suggest below 5–10% of all change requests. When teams routinely label changes as emergencies to bypass the CAB, it signals a breakdown in planning or an overly bureaucratic normal change process. Both problems need to be fixed at the process level, not worked around with emergency labels.

How the Three Types Work Together

The three change types are not competing options — they are complementary layers of a single change management system. Think of them as a tiered filter:

1. Standard changes handle routine volume. A well-maintained standard change catalog keeps the CAB from being buried in low-risk, repetitive requests. The more you can safely pre-authorize, the faster your team moves on day-to-day work.
2. Normal changes provide governance for everything else. Any change that doesn’t qualify as standard goes through a structured review. The depth of that review scales with the risk — a minor config change doesn’t need the same scrutiny as a platform migration.
3. Emergency changes are the safety valve. When something breaks or a critical threat emerges, the emergency path lets you act without abandoning control entirely. The ECAB and mandatory PIR keep the process accountable even under time pressure.

How to Categorize a Change Correctly

Start with urgency. If waiting even a few hours would cause significant business harm, the change is likely an emergency. If there is time to plan and schedule, it is not.

Then check your standard change catalog. If the change matches an existing, approved procedure exactly, it qualifies as standard. If it deviates in any meaningful way — different scope, different environment, different risk profile — treat it as normal and submit a change request.

If neither applies, it is a normal change. Determine whether it needs full CAB review or can be approved by the change manager based on your organization’s risk thresholds. Document the risk assessment, the rollback plan, and the implementation window.

When in doubt, escalate. Misclassifying a high-risk change as standard or minimizing its impact in a normal change request shifts the risk to the business. A brief conversation with the change manager before submission is always faster than managing a change-related incident afterward.

Frequently Asked Questions

What is the main difference between standard and normal changes?

A standard change is pre-authorized at the procedure level — meaning the approval was granted once when the procedure was defined, and individual requests don’t need separate CAB review. A normal change requires a fresh assessment and approval each time it is submitted, because the change hasn’t been pre-authorized or its risk profile isn’t fully established.

Can an emergency change become a standard change later?

Yes, and this is actually good practice. If your team responds to the same type of emergency repeatedly — for example, applying a specific kind of security patch under incident conditions — you should analyze whether that scenario can be turned into a documented, pre-authorized standard change. That way the next occurrence can be handled faster and with less risk.

Does every normal change have to go to the full CAB?

Not necessarily. Many organizations use a tiered approach where low-risk normal changes are approved by the change manager or a peer review group, while high-risk or high-impact changes go to the full Change Advisory Board. The criteria for each tier should be defined in your change management policy and applied consistently.

How do you handle documentation for emergency changes?

Because time is the constraint, some documentation steps are deferred — but not skipped entirely. The change record should be created as soon as possible, even if it is partially completed during implementation. A post-implementation review (PIR) is mandatory after every emergency change to capture what happened, whether the change was successful, and what improvements could prevent the same emergency in the future.

What is an ECAB and when is it used?

An ECAB (Emergency Change Advisory Board) is a smaller subset of the full CAB — typically the change manager, a few senior technical leads, and relevant business stakeholders — who can convene quickly to review and authorize an emergency change. Instead of waiting for a scheduled CAB meeting, the ECAB can approve via a conference call, a dedicated chat channel, or an asynchronous vote in the ITSM tool. The key requirement is that approval is documented, even if it happens in minutes.

Pricing accurate as of the publish date and subject to change. Verify current pricing on each vendor’s official site before purchasing.

Photo by Vitaly Gariev on Unsplash