Not every IT change should follow the same approval process. Installing a routine software update isn't the same as migrating a production database, and neither should be handled like an urgent security patch that needs immediate deployment.
ITIL recognizes these differences by grouping changes into three categories: standard, normal, and emergency. Each category reflects a different level of risk, urgency, and oversight, helping organizations decide how much assessment, approval, and planning a change requires before it is implemented.
Getting this classification right is one of the most important steps in Change Management. It determines who needs to approve the work, how quickly it can move forward, and what safeguards should be in place to reduce the risk of service disruption.
In this article, we'll explain each ITIL change category, when to use it, and how it fits into the overall Change Management process.
What is Change Management in ITIL?
Change Management is the ITIL practice responsible for ensuring that changes to IT services, infrastructure, and applications are introduced in a controlled way. Its purpose is to maximize the value of changes while minimizing the risk of service disruption.
Rather than preventing change, the practice helps organizations make changes safely. Every proposed change is assessed according to its risk, impact, urgency, and business value so the appropriate level of planning, authorization, testing, and communication can be applied.
A well-defined Change Management process helps organizations:
- Reduce service outages caused by poorly planned changes.
- Balance delivery speed with operational stability.
- Improve visibility into planned work.
- Coordinate changes across multiple teams.
- Maintain compliance and auditability.
- Learn from completed changes to improve future implementations.
One of the first decisions in the process is determining which category a change belongs to, since that dictates how it will be evaluated and approved.
Change Categories and their use cases
| Change category | Risk level | Approval | Typical use cases |
| Standard change | Low | Pre-authorized | Routine maintenance, approved software installations, password policy updates, replacing identical hardware |
| Normal change | Low to high (varies) | Risk-based approval | Application upgrades, infrastructure changes, cloud migrations, configuration changes, deploying new business services |
| Emergency change | High urgency | Expedited approval | Security vulnerability remediation, restoring failed production services, urgent fixes for critical incidents |
Standard change
A standard change is low-risk, repeatable, and pre-authorized. It follows a documented procedure that has already been assessed and approved, so each instance runs without a fresh round of sign-off. Many standard changes are fully automated.
The first time a change becomes a standard change, it goes through a complete risk assessment and authorization. From then on, the pre-approved procedure covers every repeat, for as long as nothing about the change is modified.
Who approves it: The change authority approves the change model once. Standard changes never route to the CAB.
How long it takes: Minutes to hours.
Examples: Password resets, antivirus definition updates, creating a user account from an approved template, provisioning a standard laptop build, applying a pre-approved routine patch.
Normal change
A normal change is any planned change that is not standard and not an emergency. It follows the full process: an RFC, a risk and impact assessment, authorization, and scheduling.
The category covers a wide range. A small configuration tweak on a single server sits in it, and so does replacing a core system that hundreds of people depend on. ITIL handles that range through risk assessment rather than extra sub-categories. The change manager works through dependencies and likely impact, then decides whether the change needs the full CAB or can move with lighter sign-off. Anything touching critical services, multiple teams, or regulated systems earns the full review.
A note on the term major change: in ITIL 4, a major change is a high-risk normal change, not a category of its own.
Who approves it: A change manager for low-to-medium-risk changes. The Change Advisory Board (CAB) for high-risk or major ones.
How long it takes: Days to weeks.
Examples: Upgrading a production database, migrating email to a new platform, rolling out a new application, reconfiguring a network segment.
Emergency change
An emergency change is a high-urgency, high-impact change that has to happen as fast as the risk allows, to resolve a major incident or close an active security threat. It uses an expedited path in which assessment, approval, and implementation are compressed.
An Emergency Change Advisory Board (ECAB) or a single senior change authority signs off. Documentation is captured in real time as the work happens: steps taken, commands run, values changed. That record cannot be reconstructed accurately after the fact, and it is what the post-implementation review depends on. The review itself is mandatory once the service is stable.
Who approves it: The ECAB or an emergency change authority, on an expedited basis.
How long it takes: Immediate, within hours.
Examples: Patching an actively exploited vulnerability, restoring a downed critical service, an emergency firewall rule to stop an in-progress attack, recovering from a primary server failure.
How to decide which category a change belongs to
Sort every Request for Change (RFC) with three questions, in order:
- Is there a documented, pre-authorized procedure for this exact change? If yes, it is a standard change. Run it.
- Does it need to happen now to resolve or prevent a major incident or an active security threat? If yes, it is an emergency change. Route it to the ECAB or the emergency change authority.
- Everything else is a normal change. Set the change authority by risk: a change manager for low-to-medium impact, the full CAB for high-impact, multi-team, or regulated work.
The order does the work. Checking for a standard procedure first keeps routine changes off the CAB's plate. Reserving the emergency path for genuine urgency keeps that path credible. Assigning normal-change authority by risk keeps scrutiny proportional to impact.
This sorting happens at intake, and it belongs in the organization's change policy. Writing the rules down means the same request lands in the same category every time, regardless of who logs it.
Common misclassifications and what they cost
Most misclassifications happen for practical reasons: teams want to move faster, established procedures haven't been reviewed in years, or there's uncertainty about how a change should be handled. Although these decisions may seem harmless at the time, they often lead to slower delivery, failed implementations, or compliance issues.
Here are some of the most common mistakes and the consequences they create.
Routing standard changes through the CAB
ITIL 4 identifies sending every standard change to the Change Advisory Board (CAB) as an anti-pattern. Standard changes have already been assessed, documented, and pre-approved, so requiring another review adds little value.
The result is predictable:
- Longer lead times for routine work.
- CAB meetings filled with low-risk requests instead of meaningful discussions.
- Less time spent evaluating complex or high-risk changes.
Instead of improving governance, this approach often slows delivery without reducing risk.
Labeling a normal change as an emergency
Sometimes teams classify a planned change as an emergency simply to avoid waiting for approvals or the next maintenance window. Although this may speed up implementation in the short term, it bypasses the reviews designed to identify technical and business risks.
Organizations typically see:
- More failed or rolled-back changes.
- Missing testing or rollback plans.
- Incomplete documentation.
- Emergency changes becoming the default instead of the exception.
When every change is treated as urgent, the emergency process loses its purpose.
Treating a risky change as standard
A change shouldn't be considered standard simply because it has been performed before. If circumstances have changed—or if the implementation affects production systems, critical dependencies, or regulated environments—it deserves a fresh assessment.
Misclassifying these changes can result in:
- Insufficient risk analysis.
- No formal approval.
- Missing rollback procedures.
- Service disruptions that could have been prevented.
A standard change is one that is repeatable, well documented, proven to be low risk, and formally pre-authorized—not merely familiar.
Under-documenting emergency changes
Emergency changes move quickly, but they should never bypass documentation. Recording what changed, who approved it, and why the emergency process was used is essential for accountability and future improvement.
Poor documentation makes it difficult to:
- Conduct post-implementation reviews.
- Identify recurring problems.
- Demonstrate compliance during audits.
- Improve future emergency response procedures.
The faster a change is implemented, the more valuable its documentation becomes afterward.
The common thread across these examples is that change categories are a way to match governance to risk, not a way to speed up or slow down work. Applying the right category helps organizations deliver routine changes efficiently while giving higher-risk changes the oversight they require.
How InvGate Service Management supports the three change types
Sorting changes correctly is a policy decision. Enforcing that policy consistently is where a platform earns its place. InvGate Service Management supports the three change types through a single Change Enablement workflow:
- A no-code, drag-and-drop Workflow Builder models the path each change type can take: an automated flow for standard changes, a full assessment-and-approval flow for normal changes, and an expedited path for emergencies.
- AI-Assisted Risk Assessment analyzes impact scope, service dependencies, and historical patterns to generate a risk score and recommendations before approval, which helps route each normal change to the right change authority.
- Every request for change can move from logging through assessment, including the CAB where needed, to authorization and release, with the required data visible at each step.
- Approvers don't require a license, so growing a CAB or an approval chain adds no per-seat cost.
- Change, Incident, and Problem Management live in one platform, so an emergency change tied to a major incident carries full context across modules.
- Change Management analytics and audit trails cover governance and change-control needs, and more.
InvGate Service Management is accredited by PeopleCert for the ITIL Change Management practice, so the process follows recognized standards out of the box.
Frequently asked questions
What are the three ITIL change categories? Standard, normal, and emergency. Each is defined by risk, impact, and urgency, and each takes a different approval path.
What is the difference between a standard change and a normal change? A standard change is pre-authorized and follows a documented, repeatable procedure, so it needs no approval per instance. A normal change is planned yet not pre-approved: it needs an RFC, a risk assessment, authorization, and scheduling every time it runs.
Is a major change a separate ITIL category? No. In ITIL 4, a major change is a high-risk normal change, not a category of its own. The older major/minor distinction is handled through risk assessment, which decides whether a normal change goes to the full CAB or a lighter sign-off.
Who approves an emergency change? An Emergency Change Advisory Board (ECAB) or a single senior change authority, on an expedited basis. A post-implementation review follows once the service is stable.
