The Change Advisory Board exists to catch the change that would cause an outage before it happens, and in most organisations it has drifted into something else: a weekly meeting where a long list of changes is read out, nobody has read the details in advance, and everything is approved because objecting to something you haven't reviewed feels presumptuous. The board exists, the meeting happens, and it prevents almost nothing.
The fix that works is tiering changes by risk rather than reviewing everything at the same level of ceremony. A routine, well-understood change with a known rollback path should be pre-approved and never reach a meeting at all — a standard change, in ITIL's own language. A change with genuine risk, touching a system with no rollback path or affecting many users at once, deserves real scrutiny from people who understand the system, not a rubber stamp from a room of generalists.
Speed matters because a slow CAB is what teaches engineers to route around it. If getting a routine change approved takes a week, people start bundling unrelated changes together to reduce how often they have to ask, which is precisely the pattern that makes an incident harder to diagnose. A CAB that can turn around a standard change same-day, and reserves its real attention for the changes that deserve it, gets used honestly rather than gamed.
The membership matters more than the process. A CAB of people who do not operate the systems being discussed produces polite approval rather than genuine review. The useful reviewer is someone who would be paged if this change went wrong, not the most senior person in the building. Two engaged reviewers who understand the system beat a committee of ten who are skimming the ticket for the first time in the meeting.
