An organisation's change advisory board is slow and, by its own incident data, is not preventing failures. What should replace it, and what genuinely requires human review?

Why the board does not work

The reviewers lack the context to assess most changes. A weekly board reviewing thirty changes across fifteen systems cannot meaningfully evaluate any of them, so approval is granted by default — and a gate with a hundred-percent approval rate is a delay, not a control.

The delay is not free. It batches changes, and batching makes each release larger, riskier and harder to diagnose — which is the mechanism by which heavyweight change control correlates with worse outcomes rather than better ones, a finding the DORA research programme has reported consistently.

And it displaces the review to the wrong moment. Design-time judgement changes the outcome; release-time judgement can only approve or obstruct.

What should replace it

Automated, deterministic gates in the pipeline, which are fast, specific and never wrong in a way that erodes trust:

• Tests passing, where the suite is trustworthy.
• Provenance verification at admission — the artefact came from the expected source and builder.
• Policy as code: no privileged containers, no public storage, no unencrypted data at rest, required ownership metadata.
• Contract verification against every consumer, which turns "we will find out in production" into "the build fails and names the consumer."
• Destructive schema changes blocked outside expand-contract.
• A segmented, comparative canary gate, which catches more real defects than everything above combined.

Plus progressive delivery with automatic rollback, so that a defect is contained by the deployment mechanism rather than by prediction.

What genuinely requires human review

A small, well-defined set — and naming it precisely is what makes removing the rest defensible:

• Irreversible changes: data deletion, destructive migrations, decommissioning, anything that discards information.
• Changes to components whose failure prevents their own remediation — kernel-level agents, bootloaders, network device configuration, the deployment system itself.
• Changes with an external commitment attached: a public API contract, a partner integration, a regulatory submission.
• Changes during a declared freeze for a known high-risk period.
• Novel changes, where the pipeline has no precedent to check against.

This is a small fraction of changes, which is the point: rigorous review of the few, automated gates for the many.

Making the transition defensible

• Present the incident data. Which past incidents would the board have prevented? The answer is usually "very few", and it is the argument that carries.
• Measure change failure rate before and after, so the claim is testable rather than asserted.
• Automate the checks the board was nominally performing, so nothing is simply dropped.
• Give the risk function visibility rather than approval: every change recorded, attributable, and auditable — which frequently satisfies the underlying control objective better than the approval did, and is the framing that gets it agreed.
• Keep an emergency path, documented, with a named approver and a follow-up review.

The control objective was never "someone approved it"; it was "changes are safe and accountable." Automated gates and progressive delivery serve that objective better, and stating it that way turns a fight about process into a discussion about evidence.