The Difference Between Standard, Normal, and Emergency Changes
- Contributor
- May 8
- 5 min read
Process applied uniformly is process applied badly. A two-line config change and a database migration shouldn't go through the same approval flow — one needs to ship in five minutes, the other deserves a serious conversation. The most useful concept ITIL contributed is the simple classification of changes into three types: standard, normal, and emergency. Match the process to the type, and your team stops fighting the process.
This guide is the practical version of the distinction.
Standard Changes
A standard change is a low-risk pattern you've done many times. It's pre-approved as a category, not per instance. Engineers can execute it without waiting for a meeting or signature, and they log that they did one.
Examples:
Adding a user to a team via the standard provisioning script
Deploying a normal code change through the established pipeline to a service running under capacity
Scaling a service within pre-approved bounds
Rotating a credential using the rotation tool
Restarting a stateless service
The defining property: the pattern has been evaluated and approved. Each execution doesn't need re-evaluation.
The benefit: speed. Most engineering work fits this category once you've defined the right patterns, and unblocking it from approval ceremonies is the single biggest delivery improvement most teams can make.
The danger: scope creep. A category that started as "deploy a code change to service X" becomes "any deploy to any service." Stop the creep by being specific about what's in scope for each standard change, and by requiring that any deviation graduate to a normal change.
Normal Changes
A normal change is anything that's not pre-approved as standard and isn't an emergency. The bulk of non-routine work fits here.
Examples:
Introducing a new service or component
Changing the data model in a non-trivial way
Modifying a third-party integration
Updating the deployment pipeline itself
Anything cross-team
Normal changes go through your team's standard review process: written request, peer review, approval, scheduled execution, verification. The depth of the review matches the risk — a small normal change might get a 10-minute async review; a major normal change might get a full CAB conversation.
The benefit: appropriate scrutiny without paralyzing every change.
The danger: normal changes become a one-size-fits-all bucket, with the same heavyweight process applied to everything. Sub-classify if you need to — small/medium/large normal changes — and right-size the review.
Emergency Changes
An emergency change is a fix for an active problem that can't wait for the normal process. Usually a production incident.
Examples:
Rolling back a deploy that's causing customer-facing errors
Patching a security vulnerability with active exploitation
Restoring service after an outage
Disabling a feature that's causing data corruption
Emergency changes bypass approval and ship as fast as possible. The discipline isn't "ask first" — it's "log immediately and review afterward."
The benefit: the team can actually respond to incidents.
The danger: emergency creep. The team learns that emergency changes skip the meeting, and "emergency" becomes the label for anything someone wants to ship quickly. The ratio of emergency to normal changes is the key health metric.
Authority and Accountability
Each change type has different authority structures.
Standard: the executing engineer has authority. Pre-approval covers it.
Normal: the designated approver(s) for the affected area have authority. Specifics depend on team structure.
Emergency: the on-call lead or incident commander has authority. Single-person decision, fast.
Accountability follows authority. The person who shipped the change is on the hook for verifying it landed and for the retrospective if it didn't.
How to Classify a Change
Three quick questions:
Have we done this exact pattern many times, with a runbook, low incident rate? → Standard.
Is there an active problem in production right now that this is fixing? → Emergency.
Anything else? → Normal.
If you're trying to talk yourself into "standard" for something that isn't really a standard pattern, classify it as normal. If you're trying to talk yourself into "emergency" because you want to skip review, you're probably gaming the system. Stop.
Building the Standard Change Catalog
The single best investment in change management is growing the standard change catalog. Each new entry compounds: every future execution of that pattern bypasses the meeting.
The pattern for promoting a change to standard:
Propose the candidate pattern, with a clear scope definition.
Document the runbook — exact steps, expected outcomes, failure modes.
Execute the pattern as a normal change three or more times, with no incidents.
Promote with a one-time approval from whatever authority normally approves the underlying work.
Each standard change in the catalog has an owner who keeps the runbook current. When the pattern changes (a new tool, a new constraint), the owner updates the entry. If no one owns it, it goes stale and gets removed.
A team's standard change catalog after a few years should cover most of its routine work. If it's still a handful of items after three years, the team is either not investing in the catalog or is doing genuinely novel work every time (rare).
The Emergency Change Retrospective
Emergency changes are the exception, and each one deserves a quick look.
After every emergency change, within one week:
Was it really an emergency? Or did we call it one to skip the meeting?
Could the underlying issue have been caught earlier? What signal did we miss?
Is there a pattern? Multiple emergencies on the same component point to a deeper problem.
Did the emergency response work? Did we have the right runbook, the right people, the right tools?
The retrospective is not blame. It's data. Patterns emerge when you look at emergency changes in aggregate — usually pointing at one or two systems that need investment.
Anti-Patterns by Type
Standard: the catalog has grown to include patterns that aren't actually standard. Engineers using "standard" as a label for "I don't want to write a request." Fix: audit the catalog annually, demote entries that no longer fit the criteria.
Normal: the same heavyweight process applied to a five-line config change and a multi-team migration. Fix: sub-classify, right-size the review depth.
Emergency: more than 15% of changes are emergencies. Fix: investigate which systems are causing them. Usually a few specific components.
What Each Type Needs to Document
Even fast-moving teams benefit from minimum documentation per type.
Standard: the runbook (once), and a one-line execution log per instance.
Normal: the request, the approval, the verification — typical fields covered in the change request template.
Emergency: what happened, what was changed, when, and why — written within 24h.
The discipline isn't about volume. A standard change might be one line in a log. A major emergency might warrant a multi-page postmortem. The minimum is "we know what happened and could explain it later."
Worked Example
Imagine three changes hitting your team this week.
Adding a new IAM user to your provisioning system. You have a script for this; you've done it 500 times. → Standard. Log it. Done.
Switching a service from in-memory cache to Redis. First time you've done this for this service. Touches operational behavior, possibly customer-facing latency. → Normal. Request, peer review, scheduled deploy with verification plan.
A bad deploy is causing 5xx errors. Customer impact is happening now. → Emergency. Roll back. Log. Retrospective next week.
Three different changes, three different processes, all sensible.
Key Takeaway
Standard, normal, and emergency are three change types with different processes for different risk profiles. Standard changes are pre-approved patterns and ship without per-instance review. Normal changes get scaled review based on risk. Emergency changes bypass approval to fix active problems and get retrospected after. The biggest leverage in change management is growing the standard change catalog — codifying patterns the team has confidence in. The biggest danger is emergency creep — labeling things as urgent to skip review. Classify deliberately, build the standard catalog over time, and right-size the process to the change.
Related reading
Keep learning. This article is part of the Project Delivery & Change Management path in the ShiftQuality Learning Center. Ship change without breaking trust or production.
