Why change control slows delivery in regulated firms
DevOps is a way of organising software delivery so that the team that builds an application also releases and operates it, supported by automation. In a bank or insurer it has to work inside a change control framework, because risk and compliance need evidence that every change to a system supporting customers or markets was authorised, tested and reversible.
The usual answer is batching. Changes accumulate into a release, the release goes to a CAB that meets weekly or fortnightly, and deployment happens in a weekend window. Large, infrequent releases are riskier, which justifies more process. Lead time from a finished feature to a customer using it stretches to weeks, most of it spent queueing.
DevOps breaks that loop by shipping small changes often. Each change carries less risk, which is what allows approval to become lighter without the firm accepting more risk.
What does the research say about speed and stability?
Much of the evidence comes from DevOps Research and Assessment (DORA), a programme now run by Google Cloud that has measured software delivery performance since 2014. It is unrelated to the EU Digital Operational Resilience Act, which this article always writes out in full.
Its central finding is that speed and stability are not trade-offs: teams that deploy more often also have lower change failure rates and recover faster. Its finding on change approval matters most here. Approval by a CAB or a senior manager outside the team had a negative effect on delivery performance, and there was no evidence that it lowered change failure rates. Heavyweight approval pushes teams towards larger batches, and larger batches fail more often.
How do peer review and automation meet segregation of duties?
Segregation of duties requires that a change is approved by someone other than its author. DORA’s research found that peer review meets this requirement when the review and approval are captured in the team’s development platform as part of the change itself.
Automation does the rest. A pipeline that will not deploy until a change has passed automated tests, security scans and a recorded peer approval enforces the control on every change, not only the ones a board has time to look at. The resulting evidence trail is generated by the process rather than reconstructed for an audit.
The supporting practices are version control for code, infrastructure and configuration, automated testing, continuous delivery and monitoring. Infrastructure as code extends the same controls to environments. DORA’s 2025 report found that AI-assisted development raised both throughput and instability, with the instability concentrated in teams that lacked these controls.
How do you move away from a CAB without dismantling a control?
In a bank or insurer the CAB is often a control that regulators, auditors and the firm’s risk function expect to see. Replacing CAB review of individual changes with peer review changes the control framework, so it has to be agreed with risk and compliance, mapped to the controls it replaces and documented for audit.
The usual bridge is to stop treating all changes equally, which DORA lists as a common pitfall. IT service management frameworks such as ITIL already recognise standard changes: low-risk, repeatable changes that are pre-approved. Defining which pipeline-delivered changes qualify, and what evidence each must carry, takes routine changes off the CAB agenda without removing a control.
The CAB keeps a role in coordinating across teams, improving the change process and approving high-risk changes, including changes to important business services.
How does DevOps support operational resilience obligations?
Since 31 March 2025, UK banks, insurers and other in-scope firms have had to be able to keep their important business services within set impact tolerances under the Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA) operational resilience rules. A software change is one of the ways an important business service can be disrupted, so how a firm releases software is part of how it stays within tolerance.
Small, tested changes affect less when they fail, are detected sooner through monitoring and are reversed faster through the pipeline. Firms with EU-regulated entities are also subject to the EU Digital Operational Resilience Act, which has applied since 17 January 2025 and includes requirements for managing changes to information and communication technology (ICT) systems; Northdoor’s Digital Operational Resilience Act page covers its scope. DevOps does not satisfy either regime on its own, but a well-run pipeline produces much of the evidence both expect.
How does DevOps work when a managed service provider runs operations?
Many regulated firms build some of their own software but outsource infrastructure and operations. The pipeline then becomes the shared boundary. The firm’s developers own the code, tests and peer review; the provider owns the platform, monitoring and incident response. Both agree in writing which change types the pipeline may deploy without further approval, what evidence each must carry and who can roll back. Where the arrangement is a material outsourcing, those terms belong in the contract too.
Northdoor works on both sides of that boundary, delivering DevOps services and managed services for clients in banking and finance and insurance. Our IT automation work is built on Red Hat Ansible Automation Platform.
Where should a regulated firm start?
- Agree with risk and compliance which control objectives the current change process meets, and how a pipeline will evidence each.
- Pick one application that changes reasonably often and does not support an important business service.
- Put its code, infrastructure and configuration under version control, and write automated tests around the highest-risk paths.
- Automate build and deployment to test, with peer approval recorded in the platform.
- Define the first standard change category and measure lead time and change failure rate from the start.
What this means for your organisation
If releases are quarterly and approved by a board that sees each change for a few minutes, the firm may be paying for control it is not getting. Small releases, recorded peer review and automated testing can give risk and compliance better evidence and get changes to customers sooner. The first step is a conversation with the people who own the control framework, about one application.