Here's the statistic that justifies this entire practice: a large share of major IT outages — by many practitioner estimates, most of them — are self-inflicted, caused not by attackers or hardware but by changes someone made. The upgrade that conflicted, the firewall rule that blocked more than intended, the quick fix at 4:55pm on Friday. Change enablement exists to manage that risk — and its history is a cautionary tale about cures becoming diseases.
Three species of change
ITIL's central insight is that changes deserve proportionate control, so it defines three types:
- Standard changes — low-risk, routine, well-understood, pre-authorised. Password resets, standard laptop builds, adding a user to a group. Assessed once as a category, then executed freely forever. Every change your organisation can honestly move into this bucket is bureaucracy deleted.
- Normal changes — everything that needs individual assessment: risk, impact, scheduling, rollback plan, authorisation. The server upgrade, the network reconfiguration.
- Emergency changes — the building is on fire and the fix can't wait for a committee. Assessed and authorised, but fast, by a smaller authority, with paperwork sometimes completed after. Note the discipline hiding here: emergency changes are still changes — recorded and reviewed — not exemptions from reality.
The rise and fall of the CAB
Older ITIL centred on the Change Advisory Board — a weekly committee reviewing changes. Sensible intent; in practice it often calcified into the worst version of itself: every change queuing a week for a meeting where people with no context rubber-stamped things they didn't understand. Slow and unsafe — the double failure. ITIL 4's rename from change management to change enablement was a deliberate philosophical correction, and its key concept is the change authority: the right decision-maker for that change type, which might be a board for a datacentre migration, a team lead for a config tweak, or an automated pipeline's test suite for a code deployment. Authority proportionate to risk, not one committee for everything.
The modern synthesis worth quoting in interviews: high-performing organisations don't choose between speed and safety — they get both by shrinking change size. Small, frequent, well-tested, easily-reversed changes beat huge quarterly big-bangs on both risk and pace (a big bang is a hundred untested changes detonating simultaneously). Ring-based rollouts — pilot small, observe, expand — are this philosophy in action, and they echo the guiding principle from earlier on this trail: progress iteratively, with feedback.
Whatever the process flavour, three questions define a competent change request, and they're the ones to internalise now: What exactly will be different afterwards? What could go wrong, and who's affected if it does? How do we get back if it goes badly? A change without a rollback plan isn't a plan — it's a hope with a start time. Answer those three well and most change processes, however baroque, will wave you through.