The change advisory board (CAB) is one of the most misunderstood practices in ITSM — too many organisations treat it as a rubber-stamp meeting that slows everything down rather than a structured risk filter that protects service quality. This guide explains what a CAB is, how to structure it, who should attend, and how to run meetings that actually reduce failed changes without creating a bureaucratic bottleneck.
What Is a Change Advisory Board and Why Does It Matter
A change advisory board is a group convened to evaluate, prioritise and authorise significant changes to IT services and infrastructure. The concept comes directly from ITIL v4, where it sits inside the change enablement practice alongside standard and emergency change types.
The CAB exists for one reason: changes are the leading cause of unplanned outages. Without a formal review process, engineers and project teams push changes that conflict with each other, lack rollback plans, or have not been tested in a representative environment. The CAB forces those gaps to the surface before production is touched.
That said, a poorly run CAB creates its own problems. If every change — no matter how minor — goes through a slow weekly meeting, teams learn to work around it. Shadow changes, undocumented deployments and weekend "emergency" work become the norm, which is worse than having no CAB at all.
The goal is a CAB that is fast enough to stay relevant and rigorous enough to catch real risk.
CAB Roles and Who Should Attend
Getting the right people in the room (or on the call) is the single biggest factor in CAB effectiveness. ITIL v4 does not prescribe a fixed membership list, but most well-run CABs include a consistent core with rotating technical representation.
Core CAB members
- Change manager — chairs the meeting, owns the agenda and maintains the change schedule
- Service desk manager — brings visibility of open incidents and known errors that a change might affect
- Infrastructure or platform lead — evaluates technical risk and dependency conflicts
- Security representative — assesses whether the change introduces compliance or vulnerability exposure
- Application owner or business analyst — represents the business service impacted by the change
When to bring in additional reviewers
For changes touching a specific system, add the relevant subject-matter expert on a per-change basis rather than making them a permanent attendee. Permanent over-attendance is one of the fastest ways to kill CAB engagement — people stop preparing because the meeting rarely concerns them directly.
For large organisations, consider a virtual CAB model where reviewers submit written assessments before the meeting. The live session then focuses only on high-risk or contested changes.
The Three Change Types and What Goes to CAB
Not every change needs a CAB review. ITIL v4 defines three change types, and understanding the distinction is essential for keeping the CAB focused.
Standard changes
Standard changes are pre-approved, low-risk, and follow a documented procedure. Examples include adding a new user account, installing an approved software package from a vetted catalogue, or rotating a service account password using a tested runbook. These never go to CAB — they are authorised by the change model itself.
Normal changes
Normal changes carry meaningful risk, affect production services, or have not been done before in this environment. These are the changes CAB exists to review. They arrive with a request for change (RFC) that documents scope, risk assessment, rollback plan, testing evidence, and implementation window.
Emergency changes
Emergency changes are raised to resolve a critical incident or close a severe security vulnerability when waiting for the next CAB cycle would cause unacceptable harm. Most organisations handle these through an emergency CAB (ECAB) — a smaller, faster group (often just the change manager, a technical lead, and a senior stakeholder) that can convene within hours. Emergency changes are reviewed in full at the next standard CAB meeting to close the loop.
Keeping these three lanes clearly separated prevents the most common CAB failure: normal changes being mislabelled as emergencies to skip the queue.
How to Run an Effective CAB Meeting
The mechanics of the meeting matter as much as who attends. A CAB that runs well feels like a focused risk conversation, not a status update or an approval theatre.
Before the meeting
- Publish the RFC template and submission deadline at least 48 to 72 hours before the meeting
- Require change owners to complete all RFC fields before submission — incomplete RFCs should be returned, not reviewed
- Circulate the agenda and RFC pack to all attendees in advance so they arrive prepared
- Score each RFC against a consistent risk matrix before the meeting so discussion time is allocated to genuinely complex changes
During the meeting
- Start with a review of the forward schedule of change to identify conflicts and freeze periods
- Work through RFCs in risk order — highest risk first while attention is sharpest
- For each change, ask three questions: what is the blast radius if this fails, is the rollback plan credible, and has this been tested in a non-production environment
- Timebox each RFC to keep the meeting under 60 minutes wherever possible
- Record decisions and conditions clearly — "approved subject to completing load testing by Friday" is a real decision; "approved in principle" is not
After the meeting
- Update the change schedule and notify change owners of outcomes within hours, not days
- Track changes through to completion and record whether they succeeded, failed, or required rollback
- Review failed or rolled-back changes at the next CAB as part of a brief post-implementation review
Building a CAB Metrics and Continuous Improvement Loop
A CAB without metrics is a meeting without accountability. Measuring CAB performance helps you identify whether the process is working and where it needs to be tuned.
Metrics worth tracking
- Change success rate — the percentage of changes implemented without incident or unplanned rollback
- Emergency change ratio — a rising proportion of emergency changes signals that teams are bypassing normal process
- CAB cycle time — how long from RFC submission to authorisation decision; long cycle times drive shadow changes
- Change-related incident rate — incidents caused by changes as a percentage of total incidents, often tracked as change-induced outage time
- RFC rejection rate — high rejection rates may indicate poor RFC quality or a template that needs clarification
Using metrics to improve the CAB
Review these metrics quarterly with the change manager and service desk leadership. If the emergency change ratio is climbing, investigate root causes — it usually points to inadequate capacity in the normal change pipeline or a culture where teams feel the CAB adds no value. If cycle time is high, look at whether the RFC template is too burdensome or whether the meeting cadence needs to increase.
Most experts recommend moving toward a risk-tiered model over time, where low-risk normal changes are approved by the change manager alone without a full CAB session, reserving the group review for high-risk and complex changes. This keeps the CAB fast and credible.
Common CAB Pitfalls and How to Avoid Them
Even well-intentioned CABs fall into predictable traps. Recognising them early saves significant pain.
- Approving changes without a rollback plan — the CAB should not authorise any change that cannot be reversed within an acceptable timeframe
- Treating the CAB as a formality — if the change manager pre-approves everything before the meeting, attendees disengage and the process loses its value
- No connection to the CMDB — reviewing a change without knowing which configuration items it touches is guesswork; the RFC should always reference affected CIs
- Ignoring the forward schedule — approving a database change during a peak trading window because no one checked the calendar is an avoidable failure
- Never updating standard change models — if a change that used to be risky has been done successfully dozens of times, promote it to standard and remove it from the CAB queue
The TIKTING service management platform includes a built-in change management workflow with RFC templates, approval routing, and a forward schedule of change view, so CAB chairs can see the full change landscape without manually assembling spreadsheets. Odysseus asset discovery keeps the underlying CMDB current, which means change impact assessments are based on real configuration data rather than outdated records.
Key Takeaways
- A change advisory board is a risk filter, not an approval bottleneck — its value depends entirely on how it is run
- Separate standard, normal and emergency changes clearly so the CAB focuses only on changes that genuinely need group review
- Core CAB membership should be small and consistent; bring in subject-matter experts per change rather than packing every meeting
- Require complete RFCs before the meeting, timebox discussions, and publish decisions the same day
- Track change success rate, emergency change ratio and CAB cycle time to identify where the process needs tuning
- A live, accurate CMDB is a prerequisite for meaningful change impact assessment — without it, CAB decisions are made on incomplete information
