A regulated organisation's change management process requires approval for every production change, and the team wants continuous delivery. Are they compatible?

They are compatible, and the reconciliation is specific

The regulatory requirement is almost never "a human must approve each change". It is that changes are authorised, tested, traceable, and reversible, with evidence.

Automated gates satisfy all four better than manual approval does:

• Authorised: the change follows a defined process, enforced rather than attested.
• Tested: the evidence is a test run, timestamped and attributable, rather than an assertion.
• Traceable: every change links to its commit, its author, its review, its build and its deployment.
• Reversible: progressive rollout with automated halt and an exercised rollback is stronger evidence of control than an approval signature.

And evidence arrives as a by-product — every gate execution is a logged, timestamped, attributable record, which is precisely what an auditor asks for and what teams otherwise spend weeks assembling.

What to keep manual

A defined significant minority, with the trigger stated in advance: changes to a regulated calculation, to a security boundary, to a data migration touching customer records, or to anything with a stated approval requirement.

The trigger must be a rule rather than a judgement made under time pressure, or the reservation collapses in both directions — everything approved, or nothing.

The argument to make to the risk function

A review board has fixed capacity against unbounded demand. It becomes the throughput ceiling, teams find routes around it, and the predictable result is worse assurance than none — because the control exists on paper and not in the system.

Automated controls prevent rather than detect, operate identically on every change (which is the property manual review cannot claim and which sampling exists to test for), and run in seconds so no queue forms.

The evidence that supports it

Higher deployment frequency with smaller changes correlates with lower change failure rates and faster recovery. A process that reduces deployment frequency in the name of safety is, on the evidence, reducing safety — and in a regulated business that is an argument worth making with the data rather than as an assertion.