Engineering teams tend to see the deployment pipeline as a productivity tool and the control framework as a tax imposed on it. That framing is a missed opportunity, because the pipeline is already doing most of what the control framework asks for — it is simply not recording it in a form anybody outside engineering can read.
The four questions
Strip away the vocabulary and change control asks four things. Who authorised this change? What evidence exists that it was tested? Could one person have made it alone? And can you put it back?
A pipeline with enforced review, immutable artefacts, recorded test results and a rehearsed rollback answers all four continuously, for every change, without anybody assembling a pack. The work is in making the answers legible, not in producing them.
Segregation of duties without a ticket queue
The control objective is that no individual can unilaterally move code into production. The traditional implementation is a separate release team and a change advisory board, which adds days and, in practice, reduces safety by encouraging large batched releases.
The same objective is met by branch protection requiring an approving review from someone other than the author, plus deployment credentials held only by the pipeline. The author cannot approve their own change and cannot deploy by hand. That is segregation of duties, enforced by configuration rather than by process, and it is both stronger and faster.
Make the evidence a by-product
For each deployment, retain the commit, the approver, the test and replay results, the artefact hash, the configuration version, and the timestamp. Emit it as a signed record when the deploy runs. An auditor’s request then becomes a query rather than a project, and the engineering team never spends a week reconstructing history from chat logs.
The test that this is working: someone outside engineering should be able to answer "what changed in production last Thursday and who approved it" without asking an engineer. If they cannot, the evidence exists but is not a control.
Configuration is code
The most common gap we find is a rigorous pipeline for source and an unmanaged path for configuration — risk limits, instrument parameters, venue settings, kill-switch thresholds — edited directly in production by someone with the right access.
From a risk perspective a limit change is at least as consequential as a code change, and frequently more so. It belongs in version control, under review, deployed by the same pipeline, with the same evidence trail. Closing that gap is usually a fortnight of work and it removes an entire category of incident.