What is ITIL 4 change enablement? Change management process and CAB

Definition

In IT service management, change enablement is the ITIL 4 practice that assesses, authorizes and schedules changes to IT services. Its purpose is to maximize successful service and product changes while keeping risk controlled. It is one of the 17 service management practices among ITIL 4’s 34, alongside 14 general management and 3 technical management practices. ITIL v3 called it change management.

What are the key differences between ITIL change management and ITSM change management in practice?

IT service management (ITSM) change management and the ITIL 4 practice differ in where authority sits, not in what they govern.

Both phrases cover change to IT services. Change to people is a different subject: Kotter, Prosci and ADKAR belong to organizational change management, a separate ITIL 4 general management practice outside this article’s scope.

Shaped by the tool ITSM change management is whatever request, approval and implementation workflow your platform ships.
Shaped by authority ITIL 4 change enablement specifies who may authorize a change at a given level of risk and leaves the workflow open.

The difference shows up in an audit. An auditor asks who authorized this change and under which rule, and a workflow-driven process can only answer with a status.

What percentage of IT outages are caused by changes?

Roughly 70%, and the figure does not come from an analyst house.

Google’s Site Reliability Engineering book reports that SRE has found roughly 70% of outages are due to changes in a live system. The number circulating as “Gartner says 80% of outages are caused by change” has no retrievable primary document. The SRE figure is the origin of that repetition, rounded upward in retelling.

Uptime Institute’s 2025 outage analysis adds a narrower observation: IT and networking issues totaled 23% of impactful outages in 2024, a rise Uptime attributes to complexity producing change management problems and misconfigurations. That 23% is a category total, not a change-caused share.

The cost of those outages is better quantified. In Uptime’s 2026 analysis, 57% of respondents said their most recent major outage cost more than $100,000, and for the second consecutive year 1 in 5 reported costs above $1 million.

70%

of outages are due to changes in a live system, per Google’s SRE book

23%

of impactful outages in 2024 came from IT and networking issues

57%

said their most recent major outage cost more than $100,000

Source: Google, Site Reliability Engineering; Uptime Institute, Annual Outage Analysis 2025 and 2026

Failures to follow established procedures remain the leading driver of human-error outages in Uptime’s 2026 analysis, ahead of inconsistent processes and installation errors.

How do ITIL v3 and ITIL 4 change management practices differ in real-world use?

In most migrations, barely at all, because the rename is the only part that gets implemented.

The IT Process Wiki, whose own published process still follows ITIL v3, notes that the v3 process was never invalidated and can still serve as a template. Teams relabel the workflow and keep the weekly board, and the authorization route stays where it was.

The real difference is where authorization sits. ITIL 4 Foundation shipped the practice as change control in February 2019. The practice guides renamed it change enablement after industry feedback that the word control described gatekeeping, when the purpose is to let changes proceed at a controlled level of risk. ITIL v3 assumed a board by default.

ITIL 4 scales the authorization to the risk of the change, so a routine update does not wait on the same decision as a high-risk one.

What are the essential steps in an ITIL change management process for a mid-to-large organization?

Registration, assessment, authorization, execution and closure. ITIL 4 calls that the change lifecycle management process.

A second process plans and optimizes the practice, and change reviews trigger it. A Request for Change (RFC), a description of a proposed change, initiates the lifecycle.

What trips mid-to-large organizations is that this is not one pipeline. A change model is a repeatable approach to managing one type of change, and three of them run in parallel with different numbers of gates. Route standard and emergency changes down the normal path and lead time inflates until teams stop logging work.

A risk assessment is only as good as the dependency data behind it. Without an accurate map of what a change touches, nobody can say which services the change actually puts at risk.

That is why the Configuration Management Database (CMDB) kept by the service configuration management practice decides the quality of the answer, and why test evidence comes from service validation and testing.

What is a Change Advisory Board (CAB) in ITIL change management?

A Change Advisory Board (CAB) is a group convened to advise on and authorize proposed changes. In ITIL 4 it is one possible form of the change authority, not a required body.

The practice guide names only change manager, change coordinator and change authority among its roles, and states that authorization does not need to be a bureaucratic procedure. Change models should delegate the change authority to the appropriate level: development teams, technical experts or service and product owners. In the guide’s words, the closer the change authority is to the work performed, the more effective the practice.

The DevOps Research and Assessment (DORA) program’s 2019 Accelerate State of DevOps research found that formal approval by an external body, such as a CAB or a senior manager, has a negative impact on software delivery performance. Respondents were 2.6 times more likely to be low performers where such a process was in place. DORA also investigated whether a more formal approval process was associated with lower change fail rates and found no evidence.

DORA recommends shifting left to peer review during development, with reviews, comments and approvals captured in the development platform to meet segregation-of-duties goals. In Europe that evidence trail is a legal requirement for some organizations: the NIS2 implementing regulation (EU) 2024/2690 obliges cloud, data center, CDN and managed service providers to document their change procedures and keep the approval records.

Dimension	Standard change	Normal change	Emergency change
Authorization route	Pre-authorized by its change model, no board decision	Change authority, which may be a Change Advisory Board (CAB) for high-risk changes	Emergency Change Advisory Board (ECAB) or an on-call change authority
Typical trigger	A known, repeatable request already assessed once	A new or higher-risk change to a live service	Restoring service during a major incident or closing an urgent vulnerability
Risk assessment	Done once when the model was approved	Done per change against the services and assets it touches	Compressed, with the accepted risk recorded explicitly
Record created	Logged automatically, often by the fulfilling tool	Full change record with impact assessment and test evidence	Change record completed retrospectively, review mandatory
Effect on lead time	Shortest; the main lever for reducing change lead time	Longest; where queues form if everything is routed here	Short by design, which is why its share should be monitored

A major change is not a fourth type. It is a high-risk normal change whose change authority escalates.

The board still has a defensible job. DORA describes the shift as one from gatekeeper to process architect and information beacon. That means schedule and collision review, plus expanding the standard-change catalogue so fewer changes need a decision at all.

Is a change approval board the same as a change advisory board?

Yes, in everyday use. Change approval board is informal usage for the same meeting. The ITIL term is Change Advisory Board (CAB), and the word advisory is deliberate: accountability for the decision rests with the change authority.

How do you measure the success of a change management process within ITIL/ITSM frameworks?

ITIL 4 answers with four Practice Success Factors (PSFs), and the practice guide states that key metrics map to them.

Two cover delivery Ensuring that changes are realized in a timely and effective manner, and minimizing the negative impacts of changes.
Two cover accountability Ensuring stakeholder satisfaction, and meeting change-related governance and compliance requirements.

Read against those, change success rate on its own is gameable. A high volume of pre-authorized standard changes dilutes the denominator and hides failures among normal changes, so segment the rate by change model. Change failure rate and change lead time have to be read as a pair: optimizing either alone degrades the other. DORA’s 2023 report puts change failure rate at 5% for elite performers, 10% for high, 15% for medium and 64% for low.

change failure rate for elite performers

15%

change failure rate for medium performers

64%

change failure rate for low performers

Source: DORA, Accelerate State of DevOps 2023

The count of unauthorized changes and the share of emergency changes are more useful as leading indicators, because both rise when people start routing around the practice.

Segmentation belongs to measurement and reporting; a change that keeps failing is a case for problem management.

What features should I look for in change management software for a mid-size company?

The feature that decides outcomes is the link between the change record and the configuration and asset records it touches, because impact assessment without a dependency map is guesswork.

After that: configurable change models per risk class, pre-authorization of standard changes, a visible change calendar for collision detection, and an audit trail of who authorized what.

Two pitfalls follow from getting that order wrong.

Buying a workflow engine Modeling one normal-change path reproduces the approval queue in software, faster but no safer.
Mistaking it for a project tool Project tools track a plan to completion. Change management software holds an authorization decision, its risk basis and its reversal route against live service records.

Matrix42 Change Management is one of 11 PinkVERIFY-certified processes for Matrix42 Enterprise 25.4, and the platform documents approvals and changes with built-in compliance checks and audit-trail reporting.

Key takeaways

What the practice defines is authority ITSM change management is whatever workflow your tool ships. ITIL 4 change enablement specifies who may authorize a change at a given risk level, which is the part auditors test.
The 70% figure is Google’s, not Gartner’s Google’s SRE book reports that roughly 70% of outages are due to changes in a live system. The widely repeated 80% attribution to an analyst house has no primary document.
AXELOS argues against central gatekeeping The practice guide delegates change authority to development teams, technical experts or service and product owners, because the closer the authority is to the work, the more effective the practice.
The CAB bottleneck shows up in the data DORA found formal external approval has a negative impact on delivery performance, with low performance 2.6 times more likely, and no evidence that it lowers change fail rates.
Standard, normal and emergency Standard, normal and emergency are the ITIL 4 change types. A major change is a high-risk normal change whose authority escalates.

Every change authorized against the services and assets it actually touches

Unauthorized changes are usually a routing problem. They rise when the authorization route is slower than the work it governs.

Changes cause incidents when approvals, impact analysis and communication are manual. Matrix42 Change Management runs structured change request, assessment and approval workflows with a change calendar and impact analysis. The change record sits on the same data model as the integrated CMDB, where automated discovery and dependency mapping run impact assessment against the connections that exist now. Cora, a retailer of around 17,000 employees, handles approximately 3,600 change requests a year on six Matrix42 processes.

One boundary: Change Management and Deployment Management are Matrix42 Core processes, while Release Management sits in Professional. There is no CAB voting or quorum tooling, and AI-driven change impact analysis is on the roadmap, not shipped. See how change, asset and ticket records share one model in Matrix42 incident management.

FAQs

Yes. ITIL 4 renamed the practice to change enablement to separate it from organizational change management and to signal that the job is enabling changes to flow safely rather than restricting them. The older name survives everywhere in the field: job titles, tool modules, audit checklists and most search traffic still say change management, and ITIL 4 itself still calls the thing being managed a change.

A change model is a repeatable, predefined route for handling a particular kind of change: who assesses it, who authorizes it, what testing is required and how it is reversed. Models are what make authorization scale, because the decision is made once for a class of change instead of once per request. Most organizations run at least three, matching the standard, normal and emergency change types.

A change schedule is the forward-looking record of authorized and proposed changes with their planned implementation windows. Its practical value is collision detection: it shows when two changes will touch the same service, supplier or maintenance window. It also feeds service desk and user communication, so the people answering calls know what moved and when.

No. Pre-authorized standard changes proceed under their change model without a board decision, and emergency changes are usually authorized by a small Emergency Change Advisory Board or an on-call change authority. Sending everything to a full board is the most common cause of change queues, and research from DORA found no evidence that formal external review lowers change failure rates.

An unauthorized change is a change implemented without the authorization its change model requires, including work done correctly but recorded afterwards. The count is worth tracking: a rising number usually means the authorization route is slower than the work it governs, so teams route around it. The usual fix is to widen the standard-change catalogue so that fewer changes need a decision at all.

A post-implementation review checks whether the change delivered its intended outcome, whether it caused incidents or required rollback, and whether the effort and duration matched the estimate in the request. The reusable output is the correction it produces to the change model, such as a risk category that was set too low or a test step that caught nothing.

Yes. PeopleCert offers ITIL 4 Practitioner: Change Enablement as a standalone module, alongside separate Practitioner modules for release management and deployment management. Candidates need a prior ITIL qualification such as ITIL 4 Foundation. Practitioner modules are aimed at people who run the practice day to day rather than at those designing a whole service management system.

Change enablement decides whether a change is authorized and at what level of risk. Release management decides what is bundled together and when it becomes available to users, and deployment management moves the components into the live environment. One authorized change can span several releases, and one release can carry many authorized changes, which is why ITIL 4 keeps them as separate practices: release management is a service management practice and deployment management is one of the three technical management practices.

Sources

1 ITSM Academy, under licence from PeopleCert, “What is Change Enablement? (derived from the ITIL 4 Change Enablement Practice Guide),” 2024.itsmacademy.com/content/WHATIS_Change_Enablement.pdf
2 DORA (DevOps Research and Assessment), Google Cloud, “Capabilities: Streamlining change approval,” research attributed to the 2019 State of DevOps Report.dora.dev/capabilities/streamlining-change-approval
3 DORA (DevOps Research and Assessment), Google Cloud, “Accelerate: State of DevOps 2019,” 2019.services.google.com/fh/files/misc/state-of-devops-2019.pdf
4 DORA (DevOps Research and Assessment), Google Cloud, “Accelerate State of DevOps 2023,” 2023.dora.dev/research/2023/dora-report/2023-dora-accelerate-state-of-devops-report.pdf
5 Google, “Site Reliability Engineering: How Google Runs Production Systems, Chapter 1, Introduction, section “Change Management”,” 2016 book, 2017 web edition.sre.google/sre-book/introduction
6 Uptime Institute, “Uptime Announces Annual Outage Analysis Report 2026,” 2026.uptimeinstitute.com/about-ui/press-releases/uptime-announces-annual-outage-analysis-report-2026
7 Uptime Institute, “Uptime Announces Annual Outage Analysis Report 2025,” 2025.uptimeinstitute.com/about-ui/press-releases/uptime-announces-annual-outage-analysis-report-2025
8 Atlassian, “IT Change Management: ITIL Framework & Best Practices,” accessed 2026.atlassian.com/itsm/change-management
9 IT Process Wiki (IT Process Maps), “Change Management,” accessed 2026.wiki.en.it-processmaps.com/index.php/Change_Management
10 Official Journal of the European Union, “Commission Implementing Regulation (EU) 2024/2690, Annex section 6.4, Change management, repairs and maintenance,” 2024.eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402690
11 PeopleCert, “ITIL 4 Practitioner: Change Enablement,” accessed 2026.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-change-enablement-3794

Products

Marketplace

Solutions

Industries

Services

Partners program

User resources

Learn more

M42 careers

About Matrix42

Contact