Your compliance regime requires a documented human approval before every production change, and the team wants to deploy twenty times a day. How would you satisfy both?

## Read the control, not the ritual The conversation goes wrong when "approval" is treated as a fixed artefact — a person, a button, a meeting. Almost every regime's underlying control is some version of: *changes to production are authorized by someone other than the person who made them, and there is durable evidence of that authorization tied to what was actually deployed.* Segregation of duties plus retained evidence. Nothing in that sentence says when the approval happens, how many changes it covers, or that a human must be interrupted at deploy time. So the design question is: where in the delivery path can we place a decision that genuinely satisfies segregation of duties, and how do we make the evidence a by-product rather than a chore? ## Move the approval earlier and bind it to the artifact The strongest available control point in most organisations already exists: peer review of the change before merge. It has the right properties — a different person, a substantive look at the change, a durable record with identity and timestamp — and it happens where the reviewer has the most context and the least time pressure. What is usually missing is the *binding*. A review approves a commit; the auditor cares about what runs. Close that by having the pipeline record the chain — reviewed commit, the artifact built from it identified by content digest, the gates that evaluated it, the environment record of where and when it deployed. Then "who authorized what is running in production" is a query, not an archaeology project. ## Tier the changes Not every change needs the same treatment, and pretending otherwise is what makes teams route around the process. A workable tiering: **Standard changes** — pre-approved as a *class* rather than individually. A defined, narrow blast radius, a well-exercised deployment path, automated verification and automatic rollback on failure. Routine application releases through the normal pipeline are the canonical example. The authorization is the recorded peer review; the class approval is granted once, reviewed periodically, and the pipeline enforces the conditions that make a change eligible. **Elevated changes** — retain an interactive gate. Schema migrations that are not trivially reversible, changes to authentication or payment paths, infrastructure changes affecting data durability, the first traffic onto a large release. The gate is worth its latency here because a human genuinely has information the pipeline lacks. **Emergency changes** — a break-glass path that is always available, loudly recorded, notifies automatically, and is reviewed after the fact. The review afterwards is the control; blocking is not. ## Make evidence a by-product Compliance work becomes cheap exactly when the artefacts are generated by the system doing the work. Deployment records carrying artifact digest, actor, approver, timestamp and gate results; retained pipeline logs; a queryable link from any production version back to its review. Screenshots and spreadsheets assembled quarterly are expensive, contestable and frequently wrong — and preparing them consumes the engineering time that could have improved the controls. ## Bring the counter-argument, with evidence A principal-level answer engages the compliance side rather than routing around it. Two points carry the discussion. First, a gate that everyone approves within seconds is not a control. It produces a record, but no independent judgement occurred, and the record is arguably worse than nothing because it looks like assurance. Ask what the approver is expected to verify; if they cannot answer, the gate is theatre. Second, and more decisively: an approval queue forces batching. If deploying costs a day of waiting, teams ship weekly instead of continuously, and each release now contains twenty changes. When it fails, nobody knows which change did it, the rollback reverts nineteen innocent ones, and mean time to recovery grows. Widely cited industry research into delivery performance (the DORA programme) reports that heavyweight external change-approval processes correlate with slower delivery *without* a corresponding improvement in stability. Frame this as a risk argument in the auditor's own terms: smaller, more frequent, individually attributable, automatically reversible changes are the safer configuration. ## Where to concede Do not oversell. Some obligations really are per-event and non-negotiable — certain regulated financial flows, changes affecting audited data retention, jurisdictional requirements about who may operate a system. Take those seriously, isolate them so the requirement applies to a small, well-defined slice rather than to all deployments, and spend the gate budget there. A control regime that is proportionate is one people keep following; a uniform one gets routed around, and the exception path becomes the real process nobody is measuring.