The Change Advisory Board is the meeting engineers complain about most and prepare for least. That's the whole story. Every enterprise migration I've delivered went through CAB. The ones that sailed through and the ones that got sent back for a second round differed in maybe five specific things.
What CAB is actually for
CAB exists to answer three questions on behalf of the business:
- Do we understand what's changing?
- Do we understand what happens if it goes wrong?
- Do we understand what happens if we don't change?
Most CAB submissions try to answer question 1 in a lot of detail and skip 2 and 3. The failure mode is predictable — the reviewers ask the questions the submission didn't answer, the meeting runs out of time, the change goes to next cycle.
The five things that get changes approved
1. A one-page executive summary. Not the change ticket. A separate one-page document that a business person can read in two minutes. What we're changing. What business capability it affects. Why now. Risk band. Time window.
2. A rollback plan with a specific decision point. Not "we will roll back if issues arise." Specifically: "if X metric is above Y for Z minutes at the T checkpoint, we will initiate rollback." The specificity is what CAB reviewers are looking for. Vague rollback plans read as "we haven't thought about this."
3. A tested rollback plan. If the CAB submission says "rollback has been tested on 2026-07-15 with these results," you've pre-answered the question they were about to ask.
4. A communication plan. Who gets notified before, during, after. The reviewers know that half of production incidents are made worse by uncoordinated communication. A CAB submission with a communication section reads as mature.
5. A dependency map. What upstream systems does this depend on. What downstream systems depend on it. Reviewers who have been burned by dependency surprises appreciate this section.
If you have these five things, most CABs approve in one cycle. If you're missing three or more, expect two cycles minimum.
The traps
Emergency changes. Every organisation has an emergency-change process. Every engineer eventually tries to use it for a change that is not actually an emergency. This burns credibility fast. Reserve the emergency lane for actual emergencies, and use standard change for everything else.
Bundling changes. "While we're changing X, let's also fix Y and Z." This kills approval. Each change should be its own submission. Bundling triples the review scope.
Missing the CAB cadence. Most CABs meet weekly or biweekly. Missing a submission deadline pushes you by a full cycle. Track the deadlines, submit early, don't rely on emergency lanes to bail you out.
Ambiguous scope. "Deploy Bedrock configuration updates" is ambiguous. "Update Bedrock KnowledgeBase ID from KB-a1b2c3 to KB-d4e5f6 in prod-us-east-1" is specific. Ambiguous scope gets sent back for clarification.
The escalation dynamic
CAB reviewers are usually a mix of infrastructure, security, and business representatives. Different concerns:
- Infrastructure cares about capacity, dependencies, and network changes.
- Security cares about IAM changes, data flows, and audit trails.
- Business cares about downtime windows and customer impact.
A good CAB submission speaks to each concern in a dedicated section. It shows the submitter has thought about who the audience is. Reviewers who see their concerns explicitly addressed rarely raise them again — they raise them when they feel ignored.
The "standard" change type
Most CABs have a category for "standard" or "pre-approved" changes — things done frequently, low risk, well-understood. Getting a change classified as standard is worth a lot. It skips the queue.
To qualify, you usually need:
- Documented runbook.
- Automated rollback.
- Historical evidence of >5 successful executions.
- Change occurs frequently (weekly+).
Building the case to reclassify a change as standard is a one-time investment. The payoff is dozens of skipped queue days over the year.
The bank engagements
Banks I've delivered for had the strictest CAB processes I've seen — Rogers, DNB, Länsförsäkringar. In every case, the projects that moved fastest weren't the ones that fought the CAB. They were the ones that gave the CAB reviewers exactly the artefacts they needed and no more. Reviewer time is finite. If reading your change ticket costs them 10 minutes and reading a competitor's costs 30, yours gets approved first.
The relationship dimension
CAB reviewers are people. They approve more readily for submitters they trust. Trust is built by:
- Never surprising them.
- Following through on stated plans.
- Being transparent about failures (a change you had to roll back, honestly explained, builds more trust than a change you didn't).
- Attending CAB meetings even when your change isn't up. This one is unpopular and useful.
The engineers who consistently got their changes waved through were also the ones the CAB reviewers had built confidence in over time. Newer engineers benefit from having their submissions vouched for by trusted colleagues on the first few tries.
Bottom line
CAB is not a bureaucratic obstacle. It is the interface between "what we want to do" and "what the business can safely absorb." Treat it as an interface with a well-defined API — the five artefacts above — and it becomes a routine part of shipping rather than a fight. Fight it, and it fights back, slowly.
Every project I've delivered on time had a strong CAB relationship. Every project that slipped had one of two problems in CAB — either they didn't know how to submit, or they didn't respect the process. Fix one; the other usually follows.