8 min read
Why Software Delivery Governance Matters
The modern world runs on mission-critical software. It moves our money, drives our cars, diagnoses our illnesses, and fundamentally improves our lives. But, organizations building this critical software face a paradox: they need to move fast to stay competitive, but they also need rigorous governance to manage risk.
This has created a lot of tension in regulated industries. Engineering teams have spent over a decade investing in DevOps and cloud technologies, automating their way to multiple deployments per day. Meanwhile, governance processes remain stubbornly manual and slow. A single line of code can require dozens of manual steps, multiple approvals, and weeks of waiting - all while providing little actual risk reduction.
Controls Engineering offers a way forward. By applying modern software engineering practices to governance itself, organizations can achieve continuous compliance without sacrificing velocity. This approach replaces manual checkpoints with automated controls, transforms governance from costly theatre to a competitive advantage, and proves compliance through verifiable evidence rather than paperwork and promises.
This guide provides a foundation for understanding Controls Engineering - what it is, why it matters, and how to begin implementing it in your organization.
The Governance Bottleneck
While engineering teams have automated the journey to production, governance processes haven’t kept pace. Legacy models relying on manual documentation, change advisory boards, and human approvals introduce friction and delay that modern software delivery cannot sustain.
Consider the real cost: one engineer at a major financial institution documented 81 individual steps just to create and approve the paperwork needed to deploy a single line of code. Three different tickets. Multiple meetings. All of this happens after the code is written and tested.
This isn’t just a productivity problem - it’s a risk problem. Manual processes at scale create opportunities for human error. When you’re managing millions of changes, relying on humans to catch every compliance gap is unrealistic, and controls meant to reduce risk often increase it.
Discover how much time and money your organization spends on the governance bottleneck. This Compliance Debt Calculator helps you estimate the real cost of manual evidence gathering, audit preparation, and rework, so you can build the business case for compliance automation.
Regulators Have Raised Their Expectations
Regulators also recognize the problem. The UK’s Financial Conduct Authority analyzed over 1 million production changes and found that traditional governance practices correlate with worse outcomes. Their research showed:
- Change Advisory Boards approved over 90% of changes they reviewed, with some firms not rejecting a single change all year, making them ineffective as an assurance mechanism
- Firms’ change management processes are ineffective due to heavily reliance on manual review and actions
- Legacy technology and slow release cycles are indicative of high risk changes
The research is clear: heavyweight approval processes don’t reduce risk. In fact, formal change management that requires external approval makes organizations 2.6 times more likely to be low performers, with no corresponding improvement in change failure rates.
The Three Pillars of Software Governance
Effective governance, whether manual or automated, must address three fundamental pillars:
1. Define: Have a Process for Managing Risks
Every governance framework starts with documented, standardized processes that explicitly address risks in software development and delivery. This typically takes the form of an SDLC Governance Framework that identifies potential risks and prescribes specific controls to mitigate them. [You can take a look at Kosli’s SDLC at sdlc.kosli.com]
Without clear definitions, controls become subject to interpretation, making consistent implementation impossible.
2. Implement: Follow the Process in Daily Work
A framework documented on paper is meaningless unless consistently executed in practice. This pillar focuses on embedding governance activities into the daily workflow of development teams.
Modern engineering practices like DevOps and automation bridge the gap between governance theory and governance practice. When controls are automated they’re followed every time, not only when someone remembers.
3. Evidence: Prove the Process Has Been Followed
The final pillar involves demonstrating compliance through verifiable evidence. Auditors and regulators need proof that controls are actually performed, not just policies stating they should be.
Controls Engineering: Applying Software Practices to Governance
Controls Engineering is the application of modern software engineering practices to the domain of governance, risk, and compliance. Think of it as asking: “What would happen if we applied software engineering to compliance and risk management?”
The Speed Mismatch Problem
Modern software engineering moves fast - teams deploy multiple times per day. Governance moves slowly - frameworks are reviewed annually, policies go through committees.
This speed mismatch creates friction. The traditional response is to slow engineering down, but this approach fails both business needs and risk management goals.
Controls Engineering offers a different path. Like a clutch in a manual transmission, it manages the connection between two systems rotating at different speeds, allowing both to operate effectively.
What do we mean when we say Control?
The term control is a loaded word, especially in highly regulated industries. For example, the Oxford English Dictionary defines control as:
1a. The action or fact of holding in check or restraining; restraint
This is not a bad start. But looking beyond the first entry, the dictionary provides ten alternative definitions! For our needs, we’re required to be more specific. So, throughout this guide, we’ll use this narrower definition scoped specifically to the process of governing software delivery:
Control: a check or restraint on an activity to meet one or more software risk objectives
Note here that we’ve introduced a key concept: controls should only exist to tackle a given risk. If there is no risk to mitigate or eliminate, then it really has no purpose. There is a good reason for this: every control comes with a cost - typically delays and maintenance overheads. If those costs don’t protect against a high-value risk, then why pay the cost?
If we put the diagram above into words, a control must be related to one or more risks, and a risk can be associated with many controls. For example, an unmitigated or uncontrolled risk would be associated with zero controls.
A way to visualize the function of a control is to imagine bounds or tolerance for a property or event. The control embodies the knowledge of acceptable values, and when invoked it evaluates whether or not the requirements are met.
And, finally, a control acts to enforce a decision. The decision could be to allow access, to promote a workload, or simply to continue to the next stage of the process.
Designed correctly, controls are guardrails that keep your software delivery lifecycle (SDLC) on track and aligned with your organization’s policies, standards, and regulatory requirements.
The Parallel to Site Reliability Engineering
Google created SRE by asking what would happen if software engineers did operations work. Controls Engineering asks the equivalent question for governance: what would happen if we applied software engineering to compliance?
Just as SRE gave operations work a new identity and methodology, Controls Engineering does the same for governance.
Controls Engineering is Not “Automating the Tickets”
There is a natural and understandable response when engineering teams encounter the governance bottleneck: automate the paperwork. If filling out change tickets is slow, write a script that fills them out. If uploading evidence to a change management system is tedious, build an integration that does it automatically. If the CAB meeting is a waste of time, auto-generate the documentation so at least the preparation is painless.
This approach feels like progress. It is faster. It removes some toil. But it does not fundamentally change the outcome. You are still doing the same process, with the same assumptions, producing the same artifacts. You’ve just automated the receipts.
The problem is deeper than that. If your existing manual process doesn’t actually improve your risk posture, and in many organizations it doesn’t, then automating that process means you are now doing a risky thing more often. You have increased your throughput without improving your controls. That is strictly worse than the manual version, because at least the manual version had the side effect of slowing you down.
Consider a single change ticket
In a manual process, an engineer fills out a form describing what is changing and why and a reviewer reads it. In theory, this provides a checkpoint. In practice, at scale, the reviewer is rubber-stamping hundreds of tickets a week. The review adds time but not insight.
Now automate the ticket creation. You’ve removed the time cost for the engineer, which is good. But the reviewer is still rubber-stamping, the ticket still doesn’t reflect what’s actually running in production, and you’ve removed the one forcing function that made anyone pause and think about the change at all.
Controls engineering takes a different path. Instead of asking “how do we automate this process?”, it asks “what risk is this process trying to mitigate, and what is the best way to mitigate that risk?” Sometimes the answer involves automating part of the existing process. Often it means redesigning the control entirely.
You have to think about where the control should sit in the value stream, what data it needs, whether that data can be trusted, how the decision should be recorded, and how that record connects to other controls in the system.
This is process re-engineering, not process acceleration. The distinction matters because it determines whether you end up with genuine risk reduction or just faster paperwork.
Designing an automated SDLC control
For anyone shipping software in regulated industries, the word “control” gets thrown around a lot. Compliance frameworks demand controls, auditors verify controls are used, engineering teams implement controls, and there are even Control Owners.
But, how do we design controls that actually serve their intended purpose while enabling rather than hindering delivery velocity?
When it comes to automating a control, the challenge is to understand how an existing collection of manual processes, spreadsheets, and screenshots are actually…..
To read the rest of our guide on Controls Engineering, 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.
