Change Advisory Board

Definition

A Change Advisory Board (CAB) is a governance forum that reviews proposed production changes for risk, timing and business impact. Historically an ITIL construct with heavy meeting cadence, the modern practice separates changes into standard (pre-approved and automated), normal (peer-reviewed by the delivery team) and high-risk (escalated to the CAB). The role has shifted from gatekeeper to risk-focused reviewer.

Why It Still Matters

Fast, autonomous delivery has not eliminated the class of changes that carry cross-cutting or regulatory risk — database migrations, identity provider changes, network cutovers, price engine deployments. For these, some form of pre-change review remains valuable. The failure mode of modern CABs is not existing, it is applying the same review to a config-file typo as to a payment-gateway swap.

Types of Changes

• Standard change: low risk, well understood, pre-approved. Executed by the team without additional review — e.g. certificate renewal via automation.
• Normal change: reviewed by peers within the delivery team, with defined rollback and monitoring. Most day-to-day deploys.
• High-risk change: cross-team impact, regulatory sensitivity, or reversibility concerns. Requires CAB review.
• Emergency change: production incident response. Retrospectively reviewed, not pre-approved.

Real-World Example

A retail bank ran a weekly CAB that approved every production change, from feature flag flips to core banking migrations. Meetings averaged 90 minutes with 60 items on the agenda. Approval was rubber-stamp for most, and the two high-risk items each week received seven minutes of review. After a botched core-banking release caused a four-hour outage, the CAB was restructured: standard changes were codified and removed from the agenda, normal changes moved to team-level peer review, and only high-risk changes came to the board. Meeting time dropped to 45 minutes with 6 items. Each high-risk change now received real review. In the subsequent 12 months, deploy frequency across the org doubled, and change-related incidents fell by 40 %.

What a Good CAB Reviews

• Blast radius — which systems, users, or business processes are affected.
• Reversibility — can the change be rolled back cleanly, and how long does that take?
• Timing — does the change land in a freeze window, a peak business period, or an inconvenient time for the on-call team?
• Testing evidence — what was tested, in what environment, with what data.
• Communication plan — who needs to know before, during and after.
• Runbook and rollback readiness — not "we'll write it later."

How to Run It Well

1. Publish a change taxonomy — which changes need which level of review. Ambiguity forces everything into the CAB.
2. Keep the board small — engineering, operations, security, business representation. Larger boards debate; small boards decide.
3. Time-box each item — five to ten minutes. Anything needing longer needs offline discussion first.
4. Focus on risk, not permission — the CAB is not the delivery team's manager.
5. Feed outcomes back — approved changes that fail should reshape the taxonomy.

Practical Lessons Learned

• CABs that approve everything approve nothing. Volume is the enemy of scrutiny.
• Automation is the alternative to gatekeeping. Automated tests, canary deploys and feature flags remove most of what a CAB used to catch.
• The best CAB question is "how do we know?" — how do we know it was tested, how do we know we can roll back, how do we know the on-call team is ready.
• CAB minutes are audit evidence. For regulated environments, this is often the real reason the board exists.
• Emergency changes need retrospective CAB review, not skip-and-forget.

Expert Tips

• Publish the taxonomy on the intranet — teams stop asking whether they need CAB approval.
• Require every high-risk change to include a link to the rollback plan and the runbook.
• Use the Production Readiness Review as the CAB's evidence base for new services.
• Include a security representative for anything touching identity, encryption or data classification.
• Publish approval-to-incident correlation quarterly — it protects the CAB from becoming ceremony.

Common Mistakes

• Applying CAB review to every change, turning it into a rubber stamp.
• Making CAB decisions in the meeting itself with no advance material.
• No taxonomy, so teams either escalate everything or nothing.
• Board composition heavy on managers, light on people who understand the systems being changed.
• Skipping retrospective review of emergency changes, losing the learning.

Key Takeaways

• Modern CABs review high-risk changes and delegate the rest.
• Change taxonomy is the single most valuable artefact.
• Automation and canary practice do the work old CABs pretended to do.
• The board's real question is "how do we know?" not "may I?"
• Approvals correlate with incidents when volume is high — measure it.

Related Concepts

Pairs with Deployment Freeze Window, Rollback Plan, Production Readiness Review, and Release Notes Discipline.