I recently watched an infrastructure engineer submit a change request to add a DNS record. It took eleven days to get approved. Eleven days for a change that takes thirty seconds to execute and carries virtually zero risk. The change went through three approval stages, a CAB review, and two documentation checkpoints.

This is what ITIL looks like at most organisations in 2026. Not the thoughtful, risk-based service management framework it was designed to be---but a bloated bureaucratic machine that treats every change as if it might take down production.

How We Got Here

ITIL was created in the 1980s to standardise IT service management. The core ideas were sound: define your services, manage changes carefully, handle incidents systematically. For its era---large mainframe environments with infrequent, high-impact changes---this made perfect sense.

The problem is that most organisations implemented ITIL’s processes without adopting its principles. They built rigid approval workflows and mandatory CAB meetings because that’s what the framework described. But they missed the underlying intent: managing risk proportionate to impact.

According to Gartner’s 2025 IT Service Management survey, 67% of organisations using ITIL-based processes reported that change management “significantly slows down” delivery. Only 23% said their processes had prevented a significant incident in the past year. That’s a staggering cost-benefit imbalance.

What’s Still Valuable

Incident management. A structured approach to triaging, escalating, and resolving incidents is essential. The key word is “sensibly”---you don’t need a 47-field form for every issue.

Problem management. The distinction between incidents (restore service quickly) and problems (find root cause) is genuinely useful. Most organisations are decent at incidents but terrible at problems.

Service catalogue. Knowing what IT provides, who owns it, and what the expected service levels are---that’s basic good practice.

What Needs to Go

Heavyweight change management for low-risk changes. Treating a DNS record change the same as a core database migration is absurd. The fix is a tiered model. Standard changes---pre-approved patterns done dozens of times---should proceed without CAB review.

Mandatory CAB meetings. Most attendees rubber-stamp changes they don’t understand. Replace the standing meeting with asynchronous review for standard changes. Convene focused reviews only for changes that genuinely require cross-team discussion.

Excessive documentation for routine operations. I’ve seen engineers spend more time writing change documentation than making the change. If your system requires 45 minutes of form-filling for a 5-minute change, your process is the bottleneck.

The DevOps Tension

ITIL and DevOps are often presented as opposing philosophies. That’s an oversimplification, but the tension is real. DevOps achieves reliability through small, frequent, well-tested changes with fast rollback. Traditional ITIL achieves reliability through careful planning and approval before changes are made.

The resolution is blending both. Use automated pipelines with built-in testing for standard, well-understood changes. Reserve human review for changes that are novel, complex, or high-impact. Invest in observability so you can detect and respond to problems quickly rather than trying to prevent them entirely through process.

Modernising Your Implementation

Audit your change records. Look at every change from the last quarter. Categorise by actual risk level. I guarantee 70-80% are low-risk and could have been pre-approved.

Create a standard change catalogue. DNS changes, firewall rule additions for known patterns, certificate renewals, parameter changes within defined ranges---these should not require individual approval.

Automate compliance evidence. Instead of manual documentation, instrument your deployment pipelines to generate audit trails automatically. Who, what, when, which tests passed---captured without requiring engineers to fill in forms.

Measure lead time. Track how long from “change requested” to “change deployed.” If standard changes take more than 24 hours, your process is broken.

Kill bad metrics. If you’re measuring “percentage of changes through formal CAB,” you’re incentivising teams to put everything through CAB regardless of risk. Measure change failure rate and deployment frequency instead.

The Cultural Conversation

Modernising ITIL requires buy-in from people who built their careers around the current processes. Change managers and ITSM administrators may see simplification as a threat. Address this directly. The goal isn’t to eliminate process---it’s to make process proportionate to risk.

ITIL isn’t dead. But the way most organisations implement it needs to evolve. Keep the principles. Modernise the practices. And for the love of all that is holy, stop making people wait eleven days to add a DNS record.