Executive Summary
Overcoming The Final Roadblock in Regulated Software Delivery
This report addresses the software delivery governance bottleneck faced by large banks. Despite heavy investments in DevOps and CI/CD automation, manual processes and audits remain a roadblock, slowing releases, increasing costs, and creating compliance risks.
We will explore the problems caused by manual governance and the shortcomings of traditional solutions. We will introduce Kosli Enterprise - a SaaS platform that automates governance by integrating automated controls into DevOps workflows, eliminating delays while increasing security.
The Status Quo Isn’t Working
Legacy approaches to software delivery governance rely on filling out forms, manually gathering evidence, and long waiting times for external approvals. While these approaches were effective when we had annual releases, they don’t work in the world of rapid changes that happen across a large technology landscape.
The speed and complexity of modern software delivery means that existing solutions, DIY efforts, and fragmented tooling fail. Without a holistic approach, banks struggle to balance compliance needs with velocity. Unleashing the full potential in regulated software delivery means rethinking governance from first principles.
A New Approach: Kosli Enterprise
Kosli Enterprise solves the governance challenge with a dual approach: a SaaS platform that continuously controls every change in your software delivery processes, and Controls Engineering expertise that builds governance directly into DevOps pipelines. This combination eliminates manual bottlenecks, ensures provable compliance, and accelerates secure software delivery.
Kosli addresses the specific needs of software development teams that operate in highly regulated industries. We are delighted to partner and collaborate with Kosli to drive our vision of a highly efficient, transparent, and secure software development lifecycle that empowers our engineers to focus on developing solutions for the bank’s clients.
1 The Governance Wall: The Slowdown Felt By Everyone
The banking and financial services industries have spent years investing in software delivery pipelines and cutting-edge DevOps tools to automate every technical step from code to deployment.
From the technical perspective, everything is in place for you to deliver software at the same speed as the leading Silicon Valley technology companies. Right now, teams in every bank have access to the tools needed to deploy hundreds of thousands, maybe even millions, of changes per month.
But outdated governance approaches mean you’re still running into the same bottleneck. At the final step the software delivery process grinds to a halt because every change to production goes through a change management process that is closer to pen and paper exercises than technological controls.
This takes a toll on the whole team. Developers are delayed by evidence gathering tasks and raising manual requests in strange tools. Approvers have to manually verify the work of their colleagues based on information that is not verifiable.
When Morgan Stanley looked at automating their change management process they tried to quantify the extent of governance slowdown with an internal developer survey.
One engineer documented all of the things they had to do to get a single line of code into production. It required 3 different Jiras, a change ticket, and 81 individual steps just to get the paperwork created and approved.
Across the bank, they estimated that 200,000 hours were spent every year on preparing and approving change tickets.
The Faster You Go the More it Hurts
The big frustration is that all the gains you make in CI/CD are lost to manually enforced controls in the change management process. Engineers have to pull the handbrake while they copy and paste test evidence, chase down sign-offs, and navigate an outdated ITSM that was never designed for the speed of your DevOps teams.
Over time, the change tickets pile up, approvals sit in inboxes, and audits stretch into days or even weeks and months. You know that governance is your biggest bottleneck, but the faster you go the more it hurts.
Metrics like deployment frequency have become proprietary knowledge because of how closely they correlate to competitive advantage, but when this data was still publicly available Amazon was shipping 50 million changes every year, with Netflix shipping 4,000 changes every day. And these numbers are nearly a decade old.
Cloud native giants are able to ship with incredibly high velocity due to large and highly capable engineering teams. They also do not carry the same technical debt and legacy systems as traditional banks. Smaller, more agile fintechs carry many of the same advantages.
This sort of unrestrained deployment frequency is the end goal for technology leaders in financial services and it’s surely what Richard Fairbank, Capital One CEO, had in mind when he said “Ultimately the winners in banking will have the capabilities of a world-class software company.”
The Illusion of Safety With Manual Controls
Even when you’re doing everything by the book, bad changes can still slip through. Manual approvals feel like control, but they only provide the illusion of control. People rush, they rubber-stamp, they miss things.
Without a real-time, zero-trust view of what’s happening in your software supply chain, you’re carrying a lot of unseen risk. How confident can you be that every change is safe and fully reflects reality? The irony is hard to ignore because the governance processes meant to reduce risk are actually introducing it. Every manual approval, compliance gate, and audit presents another opportunity for human error.
This conflict between “speed” and “control” is framed as “throughput” and “stability” in Google’s annual State of DevOps Report. And what they find is that this isn’t really a conflict at all. In fact, as deployment frequency increases, so does stability. It is necessarily so - you can’t go faster without a better handle on risks.
The latest 2024 DORA report found that elite performers deploy 182x more, with 8x lower change failure rates. Their change lead times are 127x faster, and they can recover from a failed deployment 2,293x faster.
The Consequences of Inaction are Mounting Up
Banks are aware that legacy governance is unsustainable. In the context of billion dollar IT budgets, this amount of waste becomes a board level priority. The stark performance gap between internal development and vc-backed technology companies is no longer possible to ignore.
In many ways, poor performance becomes a self-fulfilling prophecy. Engineers become frustrated and the best leave for greener pastures, performance declines, security risks grow, and ultimately competitors with more agility win the market.
2 Competitive Pressure and Regulatory High Stakes
The impact of bolting a manual governance process onto the end of your DevOps harms your software delivery organization in two significant ways - long lead times for changes, and a growing risk that everything blows up. However, banks who are solving this problem are not only moving faster, but with greater security. They’re delivering with higher throughput by continuously automating new controls to ship compliant software with confidence.
Manual Governance Destroys Competitiveness
Manual governance isn’t just an inconvenience, it undermines your ability to compete. Every delayed release is a missed opportunity. Bundled up, they become valuable features stuck in engineering instead of delivering value to your customers.
- Time-to-market delays hurt your bottom line. Whether it’s a new product, a customer-facing feature, a critical security update, or an internal efficiency improvement, the longer it takes to deploy, the less value it delivers.
- Compliance overhead drains resources. Instead of focusing on innovation, your engineers and operations teams are stuck in an endless cycle of documentation, approvals, and rework.
- Top talent doesn’t wait around. The best engineers want to work in environments where they can move fast, innovate, and see their work in production. If your organization can’t offer that, they’ll find one that does.
- The competition is already ahead. Banks that have solved—or even partially solved—this issue are winning. They’re delivering software faster, reducing risk, and attracting top-tier developers. The longer you take to catch up, the harder it will be.
Hidden Risks Bring Regulatory Consequences
The cost of governance is a huge overhead that delivers zero ROI because it isn’t doing anything meaningful to protect you against risk. Engineers spend countless hours gathering evidence, filling out forms, and sitting in approval meetings to provide the illusion of safety. Even financial regulators see through the risk theatre that is central to legacy change management.
One of the key assurance controls firms used when implementing major changes was the Change Advisory Board (CAB). However, we found that CABs approved over 90% of the major changes they reviewed, and in some firms the CAB had not rejected a single change. This raises questions over the effectiveness of CABs as an assurance mechanism.
3 Half-Measures Don’t Measure Up
Banks have been spending money on tools and people to solve governance for years, yet this software delivery bottleneck remains. You’ve probably seen some of the attempts - bloated ITSM tools that are divorced from the software lifecycle, automated tickets, and insecure audit trails. And you’ve probably seen where they fall short.
Typical Solutions are Inadequate
There’s no shortage of “solutions,” but none of them automate governance for large banks that deliver software at scale.
- Automate the Tickets - Every bank has an IT Service Management system that is used by IT to track requests and standardize workflows. These systems are designed around tickets and workflows, and were, historically, the way to action IT to deploy a software change from engineering. Over time, this became the natural home for the change management process. However, these tools are not designed to track your SDLC or even actual software deployments, so when you start to increase deployment speed, the inadequacies become glaringly apparent.
- Point Solutions - Plenty of tools claim to automate parts of SDLC compliance, but only tackle small pieces of the overall lifecycle. Tools for securing supply chain, governing deployments, and automating attestations are only pieces of a much larger puzzle. When it comes to governance (and audits) you need to evaluate across the whole value chain.
- DIY Compliance Database - Some banks try to build their own governance automation. It starts with a few scripts, then records in a database, then a custom dashboard. But what started as a quick fix turns into a sprawling internal tool that becomes a project of its own. Before long, you’ve spent millions, roped in entire teams to maintain it, and still haven’t removed all of the manual steps that slow everything down.
The Need for Full Lifecycle Thinking
When you deliver software at scale using very large teams, sprawling tool stacks, and high change volumes, and then combine those highly automated DevOps teams with manual governance requirements - you have a multi sided engineering problem, and a cultural problem involving competing stakeholder priorities. This is why it is difficult to imagine what a solution even looks like, never mind build it.
- A Siloed View of Compliance - Governance isn’t about security, risk, or engineering in isolation - it’s all of them together. But, most organizations treat them separately, leading to disconnected processes that don’t align. Compliance requires a holistic approach, not just another tool bolted onto the pipeline.
- Trading Speed for Control - Related to this is the idea that good governance is based on slowing down and being careful. This is a fundamental mistake. By guaranteeing controls with automation it is possible to achieve far greater speed, compliance, and security by removing the possibility of human error.
- Fragmented Tooling, Fragmented Data - Every tool in your stack collects a piece of the compliance puzzle, but they don’t talk to each other. Security scans live in one system, approvals in another, deployment logs in yet another. Without a centralized system of record the manual oversight and audit burden only grows.
To read the rest of Unbricking the Wall, hit the button below and share your email address. We’re building a community around Controls Engineering and SDLC Governance and this is one of the ways we’re bringing like minds together. No spam, just great content and community.