ITIL Types of Changes: Standard, Normal, Major, and Emergency

On February 20, 2026, Cloudflare’s Bring Your Own IP service went down for six hours and seven minutes. The cause was not a cyberattack. It was a change, a routine automation of a task Cloudflare customers had always been able to do safely themselves: removing an IP prefix they no longer needed. 

Cloudflare’s postmortem is direct about it: the change caused the network to unintentionally withdraw customer prefixes, and testing had covered the customer-facing path completely while never covering the scenario where the automation ran unattended.

This is the case worth sitting with before reading another guide to ITIL’s four change types. Classifying a change correctly, standard, normal, major, or emergency, answers one question: how much process should this go through, and who needs to sign off. 

It does not answer a second, separate question: what does this change actually touch, and what else is running on the same path. Cloudflare’s change was, by every reasonable definition, a standard change. It was still catastrophic. This guide covers the four ITIL change types in full, and demonstrates why classification alone was never designed to catch everything that can go wrong.

What Is ITIL Change Management (Change Enablement in ITIL 4)

ITIL change management, called Change Enablement in ITIL 4, governs how IT teams plan, approve, execute, and review changes to the IT environment. The mandate is narrow and specific: protect service continuity without slowing the business down more than the risk actually justifies.

Every change starts as a Request for Change (RFC). From there, the team assesses risk, maps dependencies, works out a rollback plan, and routes the request to whichever authority the risk level calls for. None of that happens by feel. It happens because the change was sorted into one of four categories first, and that sorting decision shapes every step that follows.

Poor change control is one of the most common causes behind major outages, not because teams skip process, but because the process they run does not match the risk in front of them. A password reset and an ERP migration cannot survive the same approval chain. That mismatch, one process applied to everything, is the exact problem ITIL’s four change types were built to solve.

Why ITIL Change Types Matter

Run every change through the same approval process, and two things go wrong at the same ends of the spectrum. Routine, low-risk work gets stuck behind review it never needed, and the team learns to resent the process. High-risk work moves through that same lightweight process too fast, because nothing in a one-size-fits-all system forces it to slow down. ITIL’s four categories exist to stop both failures from happening in the same organization at the same time.

Getting the classification right is not a formality before the real work starts. It decides which approvals are required, how much lead time the change needs, and what has to be checked against the current environment before anyone runs it. Skip that decision, or make it carelessly, and the failure shows up mid-rollout: a change lands on the wrong system, breaks a dependency nobody had documented, or trips a compliance control nobody flagged. None of that is a coincidence. It is what happens when a change moves through a process that was never built for its actual risk.

Standard Changes: Definition, Criteria, and Examples

A standard change is pre-approved, low-risk, and follows a procedure that is already documented down to the step. Because the outcome is known before anyone runs it, standard changes skip the RFC and Change Advisory Board (CAB) review that every other category requires.

Three things have to be true before a change earns that status: the procedure is fully written down, the risk has already been signed off, and prior runs have proven the outcome is predictable. A Change Manager or governance body pre-approves the template itself, not each individual run. An ad hoc task that happens to be low-risk does not qualify just because nothing went wrong last time.

Common examples of standard changes include:

• Resetting a user’s password through a self-service portal
• Patching antivirus definitions on workstations during a scheduled maintenance window
• Provisioning a standard user account from an approved template
• Adding a printer to an existing, documented print server

Standard changes are the easiest category to automate. The procedure is documented, the risk is already accepted, and the outcome has a track record. Automating one strips out per-instance review and the human error that comes with repetitive manual work. But automation changes something the classification never accounts for: who, or what, is actually running the change once it is live. That distinction matters. It is why an automated, correctly classified standard change was still able to take down a global network, a case covered later in this piece.

Normal Changes: Definition, RFC Process, and Risk-Based Review

Normal changes are everything planned and non-urgent that does not qualify as standard. The category covers an enormous range: a minor configuration tweak on one server sits here, and so does swapping out a core database component five hundred people depend on. ITIL does not split that range into finer categories. It handles the spread through risk assessment instead.

Every normal change needs an RFC. The Change Manager works through dependencies and likely impact, then decides whether the change needs to go in front of the full CAB or can move with lighter sign-off. Anything touching critical services, multiple teams, or regulated systems earns the full review.

Where normal changes actually go wrong is dependency mapping that never gets finished. A team updates a middleware component, and three layers away an application breaks that nobody thought to check. That is not a classification failure, the change was correctly labeled normal and correctly routed for review. It is a visibility failure, and it shows up again later in a much bigger form.

Major Changes: Definition, Governance, and Planning Requirements

Major changes sit at the top of the risk ladder: business-critical systems, planning horizons measured in months, multiple stakeholders, often an external vendor in the mix. Migrating an Enterprise Resource Planning (ERP) system that every department runs on, replacing a core database engine, moving a regulated workload off-premises, these are the changes that qualify.

The process starts with a formal business case and impact assessment, not a ticket. Planning has to cover resource allocation, testing environments, communication strategy, a phased rollout, and a rollback plan that actually works. Executive sign-off is required, and the CAB reviews the change at multiple gates rather than clearing it once and walking away.

No single factor makes a change major. It is the combination: how long the planning runs, and how many people are exposed if it goes wrong. A change that touches one team for one afternoon rarely qualifies, no matter how important the system underneath it. A change that touches every department for six months, with an outside vendor involved, almost always does.

Emergency Changes: Definition, ECAB, and Post-Implementation Review

Emergency changes exist for one situation: something critical is actively failing or under attack, and the response has to be measured in minutes, not the weeks a normal change takes. A banking system down during peak hours, a patient management system crashed, a zero-day being exploited right now, all of it lands here.

Speed does not mean the process disappears. An Emergency Change Advisory Board (ECAB), a stripped-down, fast-moving version of the full CAB, authorizes the change on a compressed timeline. Teams still document what they are doing and keep stakeholders informed as it happens. The post-implementation review is not optional either. Skip it, and the same emergency tends to come back.

The reason the ECAB exists at all comes down to a number: unplanned downtime routinely runs enterprises more than $300,000 an hour. That is the math behind moving fast without giving up the documentation and review that keeps the emergency from repeating.

How to Classify a Change: A Decision Framework

Four questions, asked in this order, narrow the classification quickly:

• Is the procedure already pre-approved and documented? If yes, it is a standard change.
• Is there an active service failure or imminent threat? If yes, it is an emergency change.
• Does it affect business-critical systems with a long planning horizon? If yes, it is a major change.
• If none of the above apply, it is a normal change.

This framework answers one question completely: which governance path applies. It was never designed to answer a second question, one that Cloudflare’s own postmortem makes concrete: what does this change actually touch, once it starts running.

The Cloudflare Case: When the Category Was Right and the Outage Happened Anyway

Cloudflare’s own postmortem describes exactly what this change was meant to be: a low-risk automation of an existing, well-understood process, the textbook definition of a standard change.

The change shipped with a single bug. An API call meant to query for prefixes pending deletion passed a flag with no value attached. The server read that empty value as a request for every prefix on the network, not just the ones actually scheduled for removal, and the new automated task began systematically deleting all of them. Roughly 1,100 BYOIP prefixes were withdrawn before an engineer identified and stopped the process. Cloudflare’s postmortem states plainly that initial testing and code review focused on the customer-facing self-service path and were completed successfully, but that testing never covered a scenario where the task-runner would execute changes to user data without a human providing explicit input.

Nobody misjudged this change’s severity. The classification logic did exactly what it was built to do: it looked at what the change was supposed to accomplish, found it low-risk and well-precedented, and cleared it for a lightweight approval path. What the classification never asked, because no category is built to ask it, was who or what would actually be running the change once it was live. A human clicking a button one prefix at a time and an unattended process looping through every prefix on the network carry very different real-world risk, even when the documented procedure is identical.

Cloudflare’s own impact table in the postmortem, listing Core CDN and Security Services, Spectrum, Dedicated Egress, and Magic Transit as affected products, is dependency information the company had to reconstruct after the outage. It was not something a single service map showed them before the change ran. The category was correct, and the outage happened anyway, because classification and dependency visibility are two different questions, and only one of them was being asked.

Why Classification Alone Isn’t Risk Management: Dependency Visibility as the Second Check

The Cloudflare case demonstrates the gap on one axis: a correctly classified change with an invisible blast radius. The AWS DynamoDB outage on October 19 and 20, 2025 demonstrates a related but distinct version of the same underlying problem. According to AWS’s own post-event summary, the failure traced back to a race condition between two independent DNS automation components, a Planner and an Enactor, each of which was individually correct. 

One Enactor experienced unusual delays retrying an update. While it was stuck, the Planner generated newer plans, and a second Enactor applied one of them. When the delayed Enactor finally applied its now-outdated plan, its own one-time freshness check had also gone stale, so it overwrote the newer plan anyway, and a cleanup process then deleted it, wiping the DNS records for the regional endpoint.

Neither AWS component was misclassified or poorly reviewed. The failure existed only in the timing overlap between two automated processes that never checked what the other was doing at the same moment. Classification asks whether a single change is risky. Neither the Cloudflare nor the AWS case was caught by that question, because the risk in both cases lived in what the change touched or overlapped with, not in what the change itself was documented to do.

This is precisely what a service map, built from accurate, discovery-sourced Configuration Management Database (CMDB) data, is designed to surface before a change runs rather than after an outage forces it into view. An application dependency map shows which services, applications, and infrastructure components sit downstream of the asset being changed, so a change manager can see the blast radius before approving a change, not reconstruct it afterward in a postmortem. This is a separate discipline from classification, not a replacement for it, and both checks belong in front of every change, regardless of which of the four categories it falls into.

Common Change Management Mistakes (and Which Failure Mode They Map To)

Two mistakes come from getting the category wrong, treating a major change as normal compresses planning time and skips the CAB review a business-critical, long-horizon change needs, and treating a standard change as normal creates queue backlogs without reducing risk. Both are solved by better classification discipline. A third mistake sits outside classification entirely.

• Classifying a change correctly, but missing what it touches. This is the Cloudflare and AWS failure mode: the category was right, the approval path was appropriate, and the outage happened because nobody asked what else was connected to the same path or running at the same time.

Better classification does not create the dependency visibility it never claimed to provide. Solving this third failure mode requires a second, separate check: an accurate, current service map reviewed alongside every RFC, not just the highest-risk ones.

Making Change a Controlled Advantage

ITIL’s four change types exist because risk is not uniform across an IT environment, and treating every change identically wastes effort at both ends of the risk spectrum. Getting the category right is the first governance decision in every change cycle, and it remains necessary. The Cloudflare and AWS cases show it was never sufficient. A category tells a team how fast a change can move and who has to approve it. A dependency map tells the same team what happens if that change goes wrong. Both checks, run together on every change, are what keep a correctly classified change from becoming an outage anyway.

Frequently Asked Questions

What makes a change a ‘standard’ change under ITIL 4?

Three conditions, all required: the procedure is fully documented, the risk has been formally accepted in advance, and prior runs have proven the outcome is predictable. The Change Manager or a governance body pre-approves the template itself, before any individual instance runs. A task being low-risk is not enough on its own, it still needs that pre-approval step, or it is not a standard change yet.

Who approves emergency changes in ITIL?

The Emergency Change Advisory Board (ECAB), a small, on-call subset of the full CAB built to convene fast during an incident. It usually includes the Change Manager, the relevant technical leads, and a service owner. When time is the overriding constraint, some organizations let a single senior change authority approve the most critical emergency changes alone. Either way, post-implementation review still happens.

Can standard changes be fully automated?

Yes, and they are the best candidate for it. The procedure is documented, the risk is pre-accepted, the outcome has a track record. Automating one strips out per-instance review and the human error that comes with repetitive tasks like patching, provisioning, and certificate renewal. What automation does change is who is actually running the task, a human clicking through steps versus an unattended process looping on its own. Cloudflare’s case is the proof: the category stayed the same, but the risk profile underneath it did not, because testing only covered the human-driven path and never touched what happens when the same action runs unattended.

Does correct change classification guarantee a change is safe?

No, and that gap is worth taking seriously. Classification decides the approval path, how fast a change can move and who signs off. Dependency visibility, built from an accurate service map, decides something else entirely: what the change actually touches, and what breaks if it goes wrong. Get the category right and skip the second check, and a change can still cause a major outage, which is exactly what happened in Cloudflare’s February 2026 incident.

How does CMDB accuracy affect change management outcomes?

It is the input quality that everything else depends on. A change manager working off a stale CMDB cannot reliably tell which services will be hit, which teams need a heads-up, or whether the rollback plan will actually work. High-frequency IT discovery keeps those records current, so the risk assessment reflects what is actually running, not a snapshot from months ago. For more on keeping that data trustworthy at scale, see ServiceNow CMDB best practices and ServiceNow implementation best practices.