ITIL 4 Change Enablement: Change Types, Authority & ECAB

Q: What is the ITIL 4 definition of an emergency change?

The ITIL 4 glossary defines an emergency change as "a change that must be introduced as soon as possible." The Foundation text gives examples: resolving an incident or implementing a security patch.

Updated November 13, 2026: corrected the history of the practice name, replaced secondary citations with ITIL 4 Foundation and practice guide text quoted in PeopleCert’s official sample papers, added a change model and authority mapping table, clarified how emergency change authority relates to the ITIL v3 ECAB, and added a note on ITIL (Version 5).

The short version

Question	Answer from the ITIL 4 texts
What is it?	One of the ITIL 4 management practices. Its purpose is “to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule” (ITIL 4 Foundation sample paper rationale, AXELOS).
What counts as a change?	”The addition, modification, or removal of anything that could have a direct or indirect effect on services” (ITIL 4 Foundation glossary, AXELOS).
How many change types?	Three: standard, normal and emergency (ITSM.tools, quoting the ITIL 4 Foundation book).
Who approves?	A change authority, “a person or group responsible for authorizing a change,” assigned per type of change (ITIL 4 Foundation glossary).
Is a CAB required?	No. Authority is set per change model, and the practice guide says a CAB-style advisory body adds little where teams work autonomously (PeopleCert PIC sample paper rationale).
Is it the same as organizational change management?	No. ITIL 4 treats organizational change management as a separate practice (Joe The IT Guy).

Why this matters right now

Plenty of change policies still say “requires CAB approval” as a blanket rule while claiming ITIL 4 alignment. That rule doesn’t come from ITIL 4. ITSM.tools calls the idea that every change had to go to the CAB “one of the most common misconceptions in ITIL v3 2011 Edition” (ITSM.tools), and the ITIL 4 Change Enablement Practice Guide says regular CABs “often become bottlenecks for the organization’s value streams” (PeopleCert PIC sample paper rationale, quoting the practice guide). A process that sends routine work to a weekly board is running the old model under the new name.

From change management to change control to change enablement

ITIL v3 2011 placed change management inside the Service Transition stage of the lifecycle (ITSM.tools). ITIL 4 Foundation, released in early 2019, replaced lifecycle processes with management practices and first named this one “change control” (Joe The IT Guy).

The name didn’t last. On October 31, 2019, AXELOS announced the switch to “change enablement,” explaining that the practice “was being misinterpreted or misunderstood as focused on ‘controlling changes’ or ‘controlling teams’, rather than ‘controlling the rate of changes’.” AXELOS said it “tested options, including reverting back to ‘change management’” before settling on the new name (AXELOS, Akshay Anand). Some study material written in 2019 still uses “change control,” so both names turn up in search results.

What did change between ITIL v3 and ITIL 4:

A practice, not a lifecycle stage. Change enablement is one of the ITIL 4 management practices, which PeopleCert revised in 2023. It applies wherever change happens, not only at deployment.
Posture. Kaimar Karu, writing for AXELOS, describes change enablement as “focused more on enabling and supporting than preventing things from happening” (AXELOS).
Decentralized authority. The practice guide says the structure of change authorities should be reviewed “to ensure a decentralized approach to change approvals. The closer the authority sits to the work being done and decisions made, the better” (PeopleCert PIC sample paper rationale).
A separate people-side practice. Organizational change management is its own ITIL 4 practice, so change enablement covers changes to services and their components, not how staff adopt them (Joe The IT Guy).

The three change types, with examples

ITIL 4 Foundation defines three types of change. The definitions below are quoted from the Foundation book as reproduced in ITSM.tools and AXELOS’s Foundation sample paper rationale; the examples are ours.

Change type	ITIL 4 Foundation definition	Example	Authorization
Standard	”Low-risk, pre-authorized changes that are well understood and fully documented, and can be implemented without needing additional authorization.” Often initiated as service requests.	Rotating a TLS certificate with a documented runbook; adding RAM to a VM in a pre-approved tier	Full risk assessment and authorization when the procedure is created or modified; none per instance
Normal	”Changes that need to be scheduled, assessed, and authorized following a process.”	Migrating a production database to a new instance type; switching identity providers	”Change models based on the type of change determine the roles for assessment and authorization”
Emergency	”Changes that must be implemented as soon as possible; for example, to resolve an incident or implement a security patch.”	Patching an actively exploited CVE ahead of the patch cycle; rolling back a deployment causing a Sev-1	Expedited assessment and authorization, possibly by a separate emergency change authority

Two details from the Foundation text are easy to miss. For standard changes, the risk assessment “does not need to be repeated each time the standard change is implemented; it only needs to be done if there is a modification to the way it is carried out.” And emergency changes “are not typically included in a change schedule,” which the glossary defines as “a calendar that shows planned and historical changes” (ITSM.tools; ITIL 4 Foundation glossary).

The failure we see most often at mid-market shops: everything runs as “normal” because nobody built a standard-change catalog, so adding disk to a known-good VM template waits in the same queue as a database migration. Our guide on running a CAB meeting in 2026 covers triaging that backlog.

Change models and change authority: a mapping table

A change model is “a repeatable approach to the management of a particular type of change” (ITIL 4 Foundation glossary). The Foundation text says “it is essential that the correct change authority is assigned to each type of change to ensure that change enablement is both efficient and effective” (Foundation sample paper rationale). Most organizations end up with more models than types, because “normal” and “emergency” each cover a wide risk range.

The table maps the models we see most often to what the ITIL 4 texts say about authority. The first three columns trace to the quoted sources; the last column is our recommendation for the audit trail, not ITIL text.

Change model	What ITIL 4 says	Who typically holds authority	What can be skipped or deferred	Evidence to keep (our recommendation)
Standard, pre-authorized	Risk assessment and authorization happen when the procedure is created or modified, not per instance (ITSM.tools)	The named owner who approved the model	Per-instance authorization	Model approval record, execution logs, next re-certification date
Normal, low risk	”The change authority for these is usually someone who can make rapid decisions, often using automation to speed up the change” (ITSM.tools)	Peer reviewer, team lead, or an automated pipeline gate	A board meeting	Approval record, test results, rollback plan
Normal, high risk or cross-team	”The change authority could be as high as the management board (or equivalent)” (ITSM.tools); an advisory body adds most value where teams depend on each other, and where they work autonomously “the need for such an advisory body is minimal” (PIC sample paper)	Senior technical or business owner, optionally advised by a CAB	Nothing by default	Risk assessment, stakeholder sign-off, change schedule entry
Emergency, pre-planned	“‘Emergency’ does not mean ‘no rules or control’. Emergency changes can be standardized and automated” (PIC sample paper)	Owner of the pre-agreed emergency model, such as an automated rollback	Change request registration or schedule updates can be “bypassed or delayed” (PIC sample paper)	Automatic record of what ran, when, and why it triggered
Emergency, novel	”There may also be a separate change authority for emergency changes, typically including a small number of senior managers who understand the business risks involved” (ITSM.tools); change models may set “a dedicated change authority of high power and availability” (PIC sample paper)	A named, on-call emergency change authority	”Some documentation” until after implementation; sometimes less testing “due to time constraints” (ITSM.tools)	Retrospective documentation and an after-the-fact review

Two rules hold across every row. Each model needs a named owner who is accountable for the authorization, even when a pipeline executes it. And each model needs a re-certification date, because a change that was low-risk two migrations ago may not be today.

Emergency changes: who authorizes them, and where ECAB fits

A common question from teams moving off ITIL v3: who holds emergency change authority in ITIL 4, and is that the ECAB?

The ECAB is an ITIL v3 concept: “a sub-set of the Change Advisory Board who makes decisions about high impact Emergency Changes,” with membership that “may be decided at the time a meeting is called” (IT Process Wiki, based on the AXELOS ITIL glossary). ITIL v3 tied emergency authority to the CAB.

The ITIL 4 Foundation text on emergency changes does not mention an ECAB. It says emergency changes get expedited assessment and authorization, should “as far as possible” receive “the same testing, assessment, and authorization as normal changes,” and may have a separate change authority made up of “a small number of senior managers who understand the business risks involved” (ITSM.tools). The practice guide adds that the emergency authority should have “high power and availability” (PIC sample paper). Availability matters: an authority you can’t reach at 3 a.m. doesn’t speed anything up.

In practice:

Keeping the ECAB name is fine if your tool or policy uses it. What matters is that the emergency authority is named in advance, reachable, and empowered to decide alone. It does not have to be a subset of a standing CAB.
Emergency changes still get authorized. An exam rationale puts it directly: “all emergency changes will be authorized by a change authority” (Foundation sample paper rationale).
Review happens afterward. ITIL 4 allows some documentation to be deferred, and ITSM.tools notes emergency changes “typically require a post-implementation review” (ITSM.tools). Set the review deadline in the model so it isn’t skipped.

For an example of pre-wiring an emergency model against a regulatory deadline, see our BOD 26-04 emergency change decision matrix.

How change enablement fits the service value system

ITIL 4’s service value system describes how an organization’s components work together to create value, with the service value chain at its center. Change enablement isn’t tied to one stage; it operates wherever change happens across the value chain activities: plan, improve, engage, design and transition, obtain/build, and deliver and support (Joe The IT Guy; ITSM.tools). The practice guide makes the same point for automated delivery: in CI/CD value streams, the role of change enablement “is mostly to support the automation aspects” (PIC sample paper).

A change process that only switches on at deployment time is ITIL v3’s model with ITIL 4 vocabulary.

CAB’s role under ITIL 4, and why it’s smaller

ITIL 4 does not abolish the CAB. The practice guide describes CABs as “formal committees that meet regularly to overview and authorize changes accumulated over the period,” which “introduce delays and limit the throughput of the change enablement practice” (PIC sample paper rationale). It also says that where teams work autonomously, “the need for such an advisory body is minimal.” The CAB becomes the advisory route for changes that need multi-team judgment.

Concretely: standard changes are pre-authorized at the model level, low-risk normal changes go to a peer reviewer, team lead or pipeline gate, high-risk or cross-team normal changes are where a CAB still earns its time, and emergency changes go to the designated emergency authority, with review after the fix.

Practitioners report the same pattern. Stuart Rance, quoted by InvGate, says many of his customers “keep a CAB for discussing major changes that affect multiple groups, but they delegate authority for most changes to the people doing the work” (InvGate). Our CAB meeting guide covers the mechanics, and the CAB agenda generator builds a scoped agenda.

How ServiceNow, Jira Service Management, and BMC Helix implement this

Vendor tooling follows the three-type model, though terminology and defaults differ enough to trip up teams migrating between platforms. If you are still choosing a platform and work under SOX, DORA or FedRAMP, our comparison of change management software for regulated industries rates 10 vendors on segregation of duties, CAB features and FedRAMP status.

ServiceNow uses a distinct state model for each type. Normal changes progress New → Assess → Authorize → Scheduled → Implement → Review → Closed; standard changes skip Assess and Authorize (New → Scheduled → Implement → Review → Closed); emergency changes compress the front end (New → Authorize → Scheduled → Implement → Review → Closed) (ServiceNow: state progression for normal, standard, and emergency changes). The missing authorize step on standard changes is pre-authorization expressed as workflow.

Jira Service Management documents the same three types and ships an automation rule, “Auto-approve standard change requests,” that fires when Change type is set to Standard (Atlassian: change management in Jira Service Management). Its workflow includes a CAB review stage for normal changes, which Atlassian presents as one option rather than a required gate (Atlassian Support: what are changes?). Our ServiceNow vs. Jira Service Management comparison breaks down both workflows.

BMC Helix ITSM ships six change classes: Standard, Normal, Emergency, Expedited, Latent, and No Impact. Standard changes are approved only by the change coordinator and change manager, while Normal and Expedited route through CAB and technical approvers as well (BMC Documentation: change control process flows). BMC describes a pre-approved change as “recurrent, well known,” executable via “a predefined and relatively risk-free path,” and “preapproved by the CAB” (BMC Documentation: normal, standard, and emergency changes). That last phrase is a v3-era habit: under ITIL 4 the model’s authority doesn’t have to be a CAB.

Across all three, approval overhead should scale with risk, and pre-authorization should be a workflow state, not an exception someone has to remember to grant.

ITIL 4 and ITIL (Version 5)

ITIL (Version 5) launched in January 2026 (ILX Group). PeopleCert is introducing it “through a gradual, phased release, with new modules and learning options introduced over time,” and says ITIL 4 “remains available for those who wish to continue their current certification journey” (PeopleCert), and ITIL 4 Foundation is a prerequisite for the advanced Version 5 certifications (ITIL.com).

ITIL.com describes Version 5 as “evolution rather than revolution,” built on ITIL 4’s guiding principles, service value system and practices, with full practice guidance in the official ITIL Practice Guides (ITIL.com). We have not yet reviewed a Version 5 change practice guide, so everything on this page reflects the ITIL 4 texts. Most change policies, audit findings and tool configurations in use today still cite ITIL 4 terminology.

Common misconceptions about ITIL 4 change enablement

“We don’t need a CAB anymore.” ITIL 4 makes the CAB optional as a default gate, not obsolete. High-risk or cross-team changes still benefit from multi-team review.

“Standard changes don’t need documentation.” They need more up front, not less. The Foundation definition requires them to be “well understood and fully documented,” because no one reviews the individual instance.

“Emergency changes skip governance.” They compress it. Emergency changes are still authorized by a change authority and should get the same testing and assessment “as far as possible”; what can slip is some documentation and, when time forces it, some testing.

“The ECAB is an ITIL 4 requirement.” The ECAB is ITIL v3 terminology. ITIL 4 asks for an emergency change authority suited to the job, which may or may not be a CAB subset.

“Change enablement and organizational change management are the same thing.” They are separate ITIL 4 practices. Mixing them in a RACI chart causes audit-scope arguments.

“Automation replaces the change authority.” Automation can execute a model, but a person or group remains accountable for having authorized it.

What to do about it

Audit your change type mix. Tag last quarter’s changes as standard, normal or emergency. Any normal change that ran the same scripted procedure several times without incident is a candidate standard change.
Build a standard-change catalog. Start with scripted procedures that have no linked incidents. Certify each model once, in writing, with a named approver.
Replace “requires CAB” with risk-tiered routing. Define thresholds (blast radius, rollback complexity, regulatory scope) that route to a peer reviewer, a technical approver, or the CAB.
Name the emergency change authority before you need it. Record who holds it, how to reach them out of hours, and the deadline for the after-the-fact review.
Re-certify change models on a schedule. Put the next review date in the model record.
Check your tool’s defaults against the three-type model before go-live. ServiceNow, Jira Service Management and BMC Helix place CAB approval differently.
Measure outcomes, not meetings. Track change failure rate and lead time by change type. A shrinking CAB agenda alongside a stable failure rate means the catalog is working. The change risk score tool can help standardize the risk input.
Write the change enablement and organizational change management boundary into policy.

For the wider set of change management guides on this site, see the change management hub.

Frequently asked questions

What is ITIL 4 change enablement?

The ITIL 4 practice, formerly ITIL v3 change management, whose purpose is to maximize successful service and product changes by ensuring risks are properly assessed, authorizing changes to proceed, and managing the change schedule (Foundation sample paper rationale).

How many types of change does ITIL 4 change enablement define?

Three: standard (low-risk and pre-authorized), normal (scheduled, assessed and authorized following a process), and emergency (implemented as soon as possible, with expedited authorization) (ITSM.tools).

Why did ITIL rename “change control” to “change enablement”?

ITIL 4 Foundation first called the practice “change control.” AXELOS renamed it in October 2019 after feedback that the name was read as “controlling changes” or “controlling teams” rather than “controlling the rate of changes” (AXELOS).

What is the ITIL 4 definition of an emergency change?

The glossary defines it as “a change that must be introduced as soon as possible” (ITIL 4 Foundation glossary). The Foundation text gives examples: resolving an incident or implementing a security patch.

Who has emergency change authority in ITIL 4? Is it the ECAB?

ITIL 4 says there may be a separate emergency change authority, “typically including a small number of senior managers who understand the business risks involved” (ITSM.tools). The ECAB, a subset of the CAB, is ITIL v3 terminology; an organization can keep the name, but ITIL 4 does not require the emergency authority to come from the CAB.

Does ITIL 4 still require a Change Advisory Board?

No. A change authority can be a CAB, a peer reviewer, a delegated technical approver, or an automated pipeline gate, depending on the change model. The practice guide calls for a decentralized approach to change approvals (PIC sample paper rationale).

What is a change model in ITIL 4?

“A repeatable approach to the management of a particular type of change” (ITIL 4 Foundation glossary). It defines the steps, the change authority, and what can be skipped. Standard changes are the most common example.

How does change enablement differ from organizational change management?

Change enablement governs changes to services and their components. Organizational change management covers the people side of change. ITIL 4 treats them as separate practices (Joe The IT Guy).

Is ITIL 4 change enablement still current now that ITIL (Version 5) exists?

Yes. PeopleCert is releasing Version 5 in phases, ITIL 4 remains available, and ITIL 4 Foundation is a prerequisite for advanced Version 5 certifications (PeopleCert; ITIL.com).

Sources

#itil #itil-4 #change-enablement #change-management

Published July 21, 2026. Last updated November 13, 2026.