Approval as Policy: Why Your CAB Rules Should Live on the Path, Not in the Runbook

Every enterprise has approval rules. Few can say with confidence that those rules were enforced on the last hundred changes that reached production.

The cause is architectural. In most organisations the approval rule lives in one place, such as a change policy document, a CAB charter or a runbook. Enforcement lives somewhere else: a ticket workflow, an if statement in a pipeline, a wait step pasted into forty automation scripts. Every copy is an opportunity to drift, and drift stays invisible until an auditor or an incident finds it.

The copy-paste approval problem

When approval logic is written into the automation itself, three things follow.

• Every workflow carries its own version of the rule. One team requires two approvers and another requires one. One checks the change window and another does not. The policy document says one thing and the estate does another.
• Changing the rule means changing the automation. Raising quorum from one approver to two becomes an engineering project across every pipeline and runbook that embedded the old rule. The work is deferred, and the gap between policy and practice widens.
• The evidence is scattered. When someone asks who approved a change and under which rule, the answer sits in tickets, chat threads and pipeline logs. It is assembled by hand, after the fact.

The CAB did its job. The rule existed. It was not enforced at the point of execution. That gap is what frameworks such as CPS 230 and the SOCI risk-management obligations examine. They do not ask whether you have a change policy. They ask whether you can show that it held.

Policy on the path

OpsChain takes a different position. Approval policy is bound to the estate path. It is not written into the workflow.

Your estate in OpsChain is a tree of projects, environments and assets, and every change runs against a node on that tree. An approval policy attached to a path governs everything that runs beneath it. The production path can require a two-person quorum. A sandbox path can require none. The workflow itself holds only operational logic: steps, conditions, retries and fan-out. It contains no approval code.

When a change reaches a governed path, the platform holds the gate.

• Quorum is enforced. The change does not proceed until the required number of authorised approvers have acted.
• Self-approval is excluded by the platform. The person who raised the change cannot be one of its approvers. The system refuses to break this rule.
• Change windows apply. Changes run in the windows you define. Running outside a window requires an override that is explicit, permission-checked and recorded in full.
• Every decision lands in the audit lane. The approval is recorded in the same hash-chained, tamper-evident history as the change it governed.

One consequence deserves emphasis. Changing your approval rules never means changing your automation. When the CAB raises quorum for a class of systems, that is one policy change on one path. It takes effect immediately for every workflow that touches the path, with no engineering backlog in between.

What your CAB gets out of it

This does not replace your CAB. It gives the CAB enforcement and evidence it currently has to assemble by hand.

• Fingerprinted submission exports. Each governed change produces a verifiable record of what was submitted and approved: the content, the approvers and the policy that applied. This is the artefact your CAB minutes and your auditors want, and it is generated as a by-product of running the change.
• One register of what is governed. Policy lives on the path, so the question of which systems require approval, and under what rule, has a single answer that anyone can inspect. There is no need to survey forty pipelines.
• Risk-proportionate control. Low-risk paths can run with few controls. Critical paths carry quorum and windows. The proportionality your change policy promises on paper becomes part of the structure.

Where to start

Teams that adopt this pattern usually start small: one production environment path, one policy with quorum and a window, and the existing workflows left untouched. The first governed change produces its own evidence pack. The conversation with risk and audit moves from "show us your process" to "here is the record".

OpsChain does not make you compliant. No platform does. It enforces the controls and produces the governed history your own compliance evidence is built from. For the wider picture, covering identity, audit and AI operators under the same fabric, see the Governance overview, or go straight to change governance.

---

Key takeaway

An approval rule enforced in one place is a control. The same rule copied into forty runbooks cannot be relied on. Bind approval policy to the estate path and your CAB's rules hold wherever the change runs, with the evidence generated automatically.

Want to see an approval policy enforced live, including quorum? Book a demo.