Change Advisory Board (CAB): Purpose, Members and Meetings

A change advisory board, usually abbreviated CAB, is a group that reviews proposed changes, assesses their risk and advises on whether and when they should go ahead. In ITIL, standard changes are pre-approved and skip it, normal changes go to it according to their risk, and emergency changes go to a smaller group, often called an emergency CAB, drawn from the same body.

What the board is for

• To see the changes together, and spot conflicts that no single team can see.
• To challenge the plan, the test evidence and the way back.
• To make a decision on high-risk changes with the right people present.
• To keep the change calendar accurate.

What it is not for

It is not a place to approve routine work. If most items are low risk, the catalogue of standard changes is too small. It is not a substitute for technical review, which should have happened before the change arrives. And it is not a rubber stamp. A board that approves everything adds delay without value.

Who should sit on it

• A chair who runs the meeting and owns the calendar.
• The change owner or requester for each item, present for their change only.
• Representatives of operations, engineering and the service owners affected.
• Security, where the changes touch access or data.
• Support, to speak for customers and to plan communication.
• A scribe to record decisions.

Run a short meeting

• Circulate the list and the change records before the meeting so that people arrive informed.
• Spend time in proportion to risk. Take high-risk changes first.
• For each change, ask: what is the worst outcome, how do we know it worked, how do we undo it, and what else is happening then?
• Record one of four outcomes: approved, approved with conditions, deferred or rejected, with the reason.
• Keep the meeting to thirty minutes or fewer. If it regularly overruns, move low-risk items out of it.

Avoid the bottleneck

Boards become bottlenecks when they meet rarely and review everything. Meet at least weekly, or use asynchronous approval for moderate risk with a defined response time. Grow the standard change catalogue so that proven routine changes need no review. Measure lead time from request to approval, and treat a rising number as a defect in the process.

In Atlas, the sign-off on a release can serve the asynchronous route: a named group is asked to approve or reject, each with a comment, and only the person asked can decide. A rejected or pending sign-off is listed as a blocker. Atlas does not provide a scheduled board meeting or an agenda, so the meeting itself is run in your usual way, with the release record as the shared document.