Risk-based assessment
Evaluate impact, dependencies, and rollback readiness so each change receives governance proportional to its risk — not a one-size-fits-all process.
Change Management
Change management balances delivery speed with risk control, helping teams introduce change safely without slowing down the business.
Alexa Young
Change Manager
I make sure changes are understood, assessed, and approved with the right level of rigour for the risk involved. I work with delivery teams, service owners, and governance forums so pace is protected while failed changes and unplanned downtime are minimised.
Change enablement in ITIL 4 is about maximising successful service and product changes by assessing risk, securing authorization, and managing the change schedule effectively. The practice is not bureaucracy for bureaucracy’s sake — it is how organisations introduce beneficial change without gambling on production stability.
Core capabilities
Effective change management depends on judgement and coordination as much as process. These are the capabilities Alexa brings to delivery.
Clear authorization
Route changes through CAB, delegated authority, or pre-approved standard paths so decisions are defensible and delivery teams know what approval they need.
Schedule coordination
Maintain a visible change calendar, avoid conflicting work on shared platforms, and align implementation with business tolerance for disruption.
Emergency discipline
Enable urgent fixes without bypassing accountability — expedited implementation with mandatory retrospective review and documentation.
Accurate records
Keep change records complete and auditable: what was planned, what was approved, what was implemented, and what happened afterwards.
Learning loops
Use post-implementation review to capture what worked, what failed, and what to improve — feeding problem management and future change design.
What good looks like
The goal of change management is to:
- enable beneficial change with acceptable risk
- reduce failed changes and service disruption
- maintain an accurate, visible change schedule
- support auditability and continuous improvement
Change management connects directly to incident and problem management, release management, and service configuration. Done well, it gives delivery teams confidence to move fast on low-risk work and gives the organisation confidence that high-risk work is controlled.
In practice
Change governance in practice
Good change governance is proportionate: standard changes flow quickly through pre-approved paths, normal changes receive risk-based scrutiny, and emergency changes are possible when the business cannot wait — without losing accountability afterwards.
These real-world examples show how structured change management makes a positive difference — not by slowing delivery, but by reducing surprise, protecting users, and building confidence in what goes into production.
Zero-downtime platform migration
A retail organisation moved its order-processing platform to a new data centre using phased cutover, rehearsed rollback, and coordinated change windows. Planned governance meant no unplanned outage during migration — and customer orders continued throughout.
Coordinated security patching
Instead of ad-hoc patching that caused surprise restarts, a finance team introduced a monthly patch cycle with risk-ranked batches, CAB-approved windows, and automated verification. Critical vulnerabilities were closed faster while weekend disruption dropped noticeably.
Pre-approved standard changes
An internal IT team defined standard changes for routine user access provisioning and certificate renewals. Delivery teams implemented without waiting for individual CAB slots, while audit records stayed complete. CAB time shifted to complex, high-risk work.
Emergency change with clean closure
When a payment gateway failure threatened transaction loss, an emergency change restored service within hours. Retrospective CAB review confirmed the urgency was justified, documented the fix, and triggered a problem record to prevent recurrence.
Process overview
Change model overview
This model follows ITIL 4 change enablement guidance: classify the change, apply governance proportional to risk, implement with a plan, and close the loop with review. It works alongside CAB or delegated decision paths rather than replacing them.
Change types
ITIL change enablement distinguishes three change types. Classification determines how much governance each change needs — not every change should go through the same approval path.
Standard change
Low-risk, pre-authorized, and well understood. Follows a documented procedure without individual CAB approval for each occurrence.
Normal change
Requires assessment and authorization proportional to risk. Most production changes follow this path through CAB or delegated authority.
Emergency change
Expedited when delay would cause significant harm. Implemented quickly with retrospective review and documentation.
Change lifecycle
Every normal change moves through assessment, authorization, implementation, and review. Standard changes skip full authorization when pre-approved; emergency changes compress the timeline but still require retrospective review.
Phase 1
Request & assess
Capture the change, classify it, and assess risk, impact, and dependencies before commitment.
- Logging
- Classification
- Risk & impact assessment
- Scheduling
Phase 2
Authorize & plan
Obtain the right level of approval and prepare implementation, rollback, and communication plans.
- Authorization
- CAB or delegated approval
- Implementation planning
- Rollback planning
Phase 3
Implement & review
Execute the change within the agreed window, then review outcomes and feed learning back into the practice.
- Implementation
- Verification
- Post-implementation review
- Closure
Policy example
Example change management policy
A representative policy outline covering scope, roles, change classification, authorization, and compliance. Use it as a starting point when defining how your organisation governs production change.
View example policy
