Your change advisory board is making releases riskier

Probably, yes. The largest running study of software delivery finds that formal external change approval — a change advisory board, or a senior-manager sign-off — correlates with slower delivery and worse stability, and does nothing measurable for your change failure rate. A CAB feels like a control. Statistically it behaves like a tax. The control that actually works is peer review plus automated gates in the deployment pipeline. Here is the evidence, and the swap.

What does the delivery research actually find?

The 2019 State of DevOps research, run across tens of thousands of respondents, put change approval processes on the measurement table and got an unambiguous answer. Organizations that relied on an external body — a change advisory board or a senior manager — to approve changes were, per the State of DevOps 2019 report, 2.6 times more likely to be low performers. The report's own summary is blunt:

Heavyweight change approval processes, such as change approval boards, negatively impact speed and stability.

The book that preceded it, Accelerate, is where this gets uncomfortable. As Octopus Deploy's analysis of the research summarizes, external change approval was negatively correlated with lead time, deployment frequency, and restore time — and had no correlation with change fail rate. Read that axis by axis. The CAB slows how fast you ship (lead time, deployment frequency). It slows how fast you recover when something breaks (restore time). And it does not move the one number it exists to protect — whether your changes fail. Every dimension it touches, it either degrades or leaves untouched.

If it doesn't catch failures, what is the CAB doing?

Watch one in operation and the mechanism is obvious. Reviews of change boards found they approved more than 90% of major changes, and some organizations' boards rejected zero changes across an entire year. A body that approves everything is not a filter. It is a queue with a meeting attached.

It shapes behaviour in two ways, both bad for stability:

• It batches. Changes wait for the weekly or fortnightly slot, so they pile up and ship together. Bigger batches mean more coupling, more moving parts per release, and harder rollback — the exact opposite of what stability wants. It is the same failure mode as the quarterly release train that guarantees quarterly features: the cadence of the control becomes the cadence of the work.
• It is optional under pressure. Every CAB has an emergency-change path that bypasses the board. So the changes most likely to break production — the urgent ones, made fast, under stress — are precisely the ones that skip review. A control that is waived exactly when risk peaks is not a risk control. It is a formality that yields the moment it would cost anything.

A concrete one from our own work: a small configuration change to a promotional pricing engine — adjusting a returnable-deposit promo before a trade window opened — sat behind a weekly board while the retail calendar kept moving. The change was three lines and fully tested. The wait was five days. Nothing about the board made those three lines safer; it only made them late.

But doesn't the auditor require it?

This is the real reason CABs survive, and it deserves a straight answer rather than a shrug. Nobody keeps a change board because they think the DORA numbers are wrong. They keep it because it produces an artifact an IT general controls (ITGC) auditor will accept: evidence that a change was authorized, reviewed, tested, and that no single person could push code to production unchecked. The CAB is a manual, expensive, slow way to generate that evidence — but it does generate it, and swapping it out means the replacement has to satisfy the same auditor. Skip that step and you get the kind of governance gap that turns a go-live into litigation, as in the payroll go-live that ended up suing its integrator.

The good news is that a deployment pipeline produces stronger control evidence than a meeting does, and produces it automatically.

How to fix it without failing the audit

Replace the board with controls that are faster and better documented. In order:

1. Make peer review the authorization gate. Every change goes through pull-request review by someone who did not write it. That is your segregation of duties, recorded with author, reviewer, timestamp, and the exact diff. It is harder evidence than a line in a meeting's minutes, and it happens at the moment of change instead of days later.
2. Turn the checks into blocking pipeline stages. Automated tests, security and dependency scans, database-migration checks, and policy-as-code run as mandatory gates. A change that fails any of them does not deploy — no human bottleneck, no discretion to wave it through.
3. Pre-approve standard changes. The overwhelming majority of changes are low-risk and repetitive. Classify those as standard changes whose standing control is the pipeline. Reserve real human discussion for the rare change with genuine blast radius — a schema migration, a new integration boundary — not the daily config edit.
4. Emit the audit trail from the pipeline itself. Deployment records, review approvals, test results, and artifact provenance become the ITGC evidence — queryable, complete, and tamper-evident by construction. This is how we wire it into our event bus and delivery pipeline: every deploy writes its own control record, so an audit is a query rather than an archaeology project.
5. Keep a forum, drop the gate. If the board gave you useful cross-team visibility, keep a lightweight review that runs asynchronously or after deploy — informing people, not blocking them.

The tell that it worked: emergency changes stop being special. When the normal path is peer review plus automated gates that clear in minutes, there is nothing for an emergency path to skip, because the standard path is already fast. You have replaced a process that was bypassed under pressure with one that holds under pressure.

None of this is exotic; it is table stakes for teams that ship daily, and it is well within reach for the enterprises still buying delivery capability the slow way — the same organizations that spend a year procuring what takes six weeks to build. As auditors grow more fluent in reading pipeline evidence, the change board's last justification is quietly expiring. The brewers who notice first will spend the coming year turning approval meetings into dashboards and watching their lead times fall; the rest will keep the meeting on the calendar, and keep wondering why the emergency path is the only one anyone trusts.