A Change Advisory Board sounds like the kind of thing only large enterprises bother with. In practice, any IT team making changes to production systems needs some version of one — even if it's just two people approving each other's work before anything goes live.
This guide explains what a CAB is, why it matters, and how to set one up that's proportionate to your team's size.
What is a Change Advisory Board?
A Change Advisory Board is a group of people responsible for reviewing, approving and scheduling changes to IT systems. Its job is to make sure that changes are assessed for risk and impact before they happen, rather than discovered to be a problem after they've caused an outage.
The CAB doesn't have to be a committee meeting. For a small team, it might be an asynchronous approval process where the change requester and one other person sign off before a deployment happens. What matters is that the process is documented and followed consistently.
Why bother with a CAB?
Most IT outages are caused by changes. Not by hardware failures, not by external attacks, not by random Acts of God — by someone pushing something to production without fully understanding the dependencies.
The CAB exists to catch those moments. A second pair of eyes on a change request will spot things the person who wrote it missed. "Have you considered what happens if the database connection times out during this migration?" is the kind of question that prevents a 3am incident call.
Beyond risk reduction, a formal change process also gives you an audit trail. When something does go wrong, you can trace exactly what changed, when, who approved it, and what the rollback plan was.
Types of changes
Not every change needs the same level of scrutiny. A well-run CAB process classifies changes into categories:
- Standard changes — pre-approved, low-risk, routine. Password resets, patch deployments to a tested schedule, adding a user to a group. These should have a template and be logged but not require approval each time.
- Normal changes — require review and approval before implementation. New system deployments, significant configuration changes, infrastructure modifications. These go through the full CAB process.
- Emergency changes — need to happen quickly, often to fix a production incident. These get expedited approval (sometimes just the Change Manager and one other), with full documentation completed after the fact.
What a change request should contain
A useful change request isn't a one-liner. It should give reviewers enough context to make a proper risk assessment without having to go and find the requester. At minimum it should cover:
- What is changing — a clear description of the technical change being made
- Why it is changing — the business justification or the problem being solved
- Risk assessment — what could go wrong, how likely, what the impact would be
- Implementation plan — step-by-step what will happen and in what order
- Rollback plan — exactly how to reverse the change if something goes wrong
- Testing evidence — how has this been tested before going to production
- Scheduled window — when the change will happen, ideally outside business hours
Who should be on the CAB?
The classic answer is "anyone whose systems could be affected by the change." In practice for a small IT team, that usually means:
- The Change Manager (whoever runs the process)
- The technical lead or architect
- A representative from operations or service management
- For significant changes, a representative from the affected business area
Keep it small. A CAB with twelve people gets nothing approved. A CAB with two or three focused people is genuinely useful.
The CAB meeting
For normal changes, a weekly CAB meeting to review the upcoming change schedule works well. Each change is presented by the requester, questions are asked, and approval or rejection is recorded. Changes scheduled for the coming week get approved or deferred.
The output of the meeting should be a change calendar — a clear view of what's happening, when, and who approved it. This helps with scheduling conflicts (two major changes on the same night is rarely a good idea) and gives the wider team visibility.
Keeping it proportionate
The goal is to reduce risk, not create bureaucracy. A CAB process that takes two weeks to approve adding a firewall rule is as dangerous as having no process at all — people will work around it.
Design your CAB process to be as lightweight as possible while still providing genuine oversight. For a team of five, that might mean a simple shared change log and a rule that anything touching production needs one other approval before it happens. Scale the formality to match your risk profile.