DevGovOps: The Missing Layer in Modern Software Delivery
DevSecOps brought security into the development lifecycle. It took a decade and it changed everything. Governance is next, and the window to define that category is open right now.
P. Revoor, Founder, ComplAIbridge, April 2026
In 2008, a security researcher named John Viega published a paper arguing that the only way to build secure software was to build security into every phase of development and not test it at the end. Nobody listened. For another decade, security was still something you bolted before shipping: a penetration test, a vulnerability scan, a checkbox before deployment.
Then DevSecOps happened. Slowly at first, then everywhere at once. Security shifted left. It moved from the perimeter into the pipeline, from the firewall into the pull request. Today, no serious engineering organisation treats security as a post-production concern. It lives in the code review, the CI/CD gate, and the threat model at design time.
That transformation took roughly fifteen years, a generation of security engineers who thought like developers, and a series of catastrophic breaches that made the old approach untenable.
Governance is exactly where security was in 2008. And the same transformation is coming faster this time, because the regulatory pressure is already here.
The Compliance Fire Drill
Every organisation that builds software in a regulated environment knows the compliance fire drill. An audit is announced. A team scrambles. Evidence is assembled from emails, Jira tickets, Confluence pages, and spreadsheets. Screenshots are taken of systems that no longer look the way they did when the control was supposedly in place. A narrative is constructed, after the fact, to describe a process that was never formally documented.
This is not a resource problem. It is not a tooling problem. It is a structural problem, and it has a name.
“Compliance assembled at audit time is not compliance. It is reconstruction. And the difference matters enormously to a regulator.”
The problem is that compliance has always been treated as a production concern. You build the system, deploy it, and then map what you built to the relevant controls. The evidence you generate is a backward-looking account of what happened. It’s written after the fact, assembled by people who were not present when the decisions were made, and verified against systems that may have drifted significantly since those decisions.
This works, barely, when audits are annual and frameworks are stable. It is already breaking under DORA’s continuous monitoring obligations. It will break completely when the next regulatory cycle arrives.
What DevSecOps Got Right, And Left Behind
DevSecOps solved a specific problem: how do you prevent vulnerable code from reaching production? The answer was instrumentation. To embed security tooling into the development pipeline, scan dependencies at build time, gate deployments on security checks, and surface CVEs before they become production incidents.
It was the right answer to the right question. And it changed the relationship between engineering and security permanently.
But DevSecOps never addressed governance. It addressed security controls, the technical mechanisms that prevent specific classes of attack. It did not address the compliance evidence that proves those controls were designed in, the traceability that connects a regulatory obligation to a design decision to a deployment artefact, or the framework mapping that shows a DORA Article 9 requirement is satisfied by the same control that satisfies ISO 27001 A.12.6.1.
Those gaps are not edge cases. They are the core of what regulators actually ask for.
The DevSecOps gap in practice
A security engineer runs SAST on every pull request. A CVE is detected in a dependency. The dependency is patched, and the build passes. The security engineer closes the ticket.
Three months later, an auditor asks: which DORA control does that CVE remediation satisfy? What is the evidence that the control was in place before the deployment? Who approved the remediation decision? Where is the audit trail connecting the vulnerability to the regulatory obligation?
DevSecOps answered none of those questions. It was never designed to.
The Governance Gap
The governance gap is structural, not cosmetic. It exists because governance tools were built for a world where compliance was a periodic activity. Something you did once a year, with consultants, against a static framework, producing a report that sat on a shelf until the next cycle.
That world is gone. DORA mandates continuous ICT risk management. The CAF requires demonstrable control effectiveness, not point-in-time assertions. ISO 42001 for AI systems demands evidence that risk was considered at design time. The regulatory direction is unanimous: compliance must be continuous, evidenced, and traceable and not assembled retrospectively.
The tools have not caught up. Every major compliance platform like Vanta, Drata, ServiceNow GRC, starts at production and works backwards. They connect to your cloud infrastructure, scan your configuration, and check whether your controls are in place today. They generate evidence of your current state. They cannot tell you what the state was when the design decision was made, because they were not present when the design decision was made.
Production-backwards (current market)
- Connects to live infrastructure
- Scans current configuration
- Evidence generated at audit time
- No design-stage data
- Cannot trace requirement → control
- Multi-framework mapping is manual
- Evidence assembled, not captured
Lifecycle-first (DevGovOps)
- Instruments from requirements stage
- Evidence captured at moment of decision
- Cryptographic chain, provably unaltered
- Design artefacts as compliance inputs
- Requirement → control → evidence traced
- One control satisfies multiple frameworks
- Evidence exists before the audit question
Defining DevGovOps
DevGovOps is the discipline of embedding governance into the software development lifecycle, not alongside it, not after it, but within it. The same way DevSecOps made security a property of the pipeline, DevGovOps makes governance a property of delivery.
It rests on three principles.
Principle 1: Governance at design time, not audit time
A compliance control that was not considered at design time cannot be credibly evidenced at audit time. The question a regulator asks: “was this control in place when the system was built?” has only one honest answer if the control was mapped retroactively: no.
DevGovOps treats the requirements phase as the first governance checkpoint. Framework obligations are ingested as design inputs. Controls are identified before a line of code is written. Design artefacts, architecture documents, threat models, infrastructure specifications, become compliance evidence at the moment they are produced, not months later.
Principle 2: Evidence captured, not assembled
There is a fundamental difference between evidence that was captured at the moment of an event and evidence that was assembled after the fact to describe that event. Regulators know the difference. Auditors know the difference. And increasingly, the legal frameworks know the difference such as DORA’s incident reporting requirements specifically address the timeliness and integrity of evidence.
DevGovOps requires cryptographic evidence capture. Every artefact timestamped and hashed at the moment it is produced, creating a chain that can be independently verified and cannot be altered without detection.
Requirement → Design artefact → Build event → Test result → Production state → Audit pack
Each node in that chain is a timestamped, cryptographically anchored artefact. The chain itself is the evidence. It does not need to be reconstructed at audit time because it was built continuously throughout delivery.
Principle 3: One control, multiple frameworks
The compliance estate of a typical regulated organisation is not one framework. It is four, or six, or eight, overlapping, partially redundant, requiring different evidence formats but often satisfied by the same underlying controls. The current approach manages each framework separately, creating duplicated effort, duplicated evidence, and duplicated cost.
DevGovOps treats multi-framework mapping as a first-class architectural concern. A network segmentation control designed to satisfy CAF ICT-B2 simultaneously satisfies ISO 27001 A.13.1.1 and DORA Article 9. That overlap is not an accident; it is an efficiency that should be systematically identified, evidenced once, and mapped to all applicable frameworks automatically.
Who DevGovOps Is For
The DevGovOps audience is not the traditional compliance manager. It is the emerging class of practitioners, someone who thinks in systems, understands the development lifecycle, and has been handed compliance responsibilities that legacy tools were never designed to support.
It is the security engineer at a DORA-regulated fintech who needs CVE remediation to generate compliance evidence automatically, not require a separate compliance exercise.
It is the platform engineer building the internal developer platform at a public sector organisation who needs CAF compliance to be an output of good engineering practice, not an additional workstream.
It is the GRC lead at a scale-up who has been told by the board to achieve ISO 27001, DORA compliance, and SOC 2 simultaneously without doubling the compliance team.
These practitioners exist. They are numerous. And they have no category that names what they need.
“DevSecOps gave engineers the tools to own security. DevGovOps gives them the tools to own governance. The engineer who can do both is the most valuable person in a regulated organisation.”
The Window Is Open
Category creation has a window. Before the window opens, the problem is not recognised widely enough for a category to exist. After the window closes, incumbents have claimed the space, and the cost of entry rises dramatically.
The DevGovOps window is open right now, for three specific reasons.
DORA came into force in January 2025. It mandates continuous ICT risk management and cryptographic-quality evidence for every in-scope financial entity in the EU, and every organisation that supplies technology to those entities, regardless of where it is based. That is approximately 22,000 organisations who are discovering, right now, that their existing compliance tools cannot satisfy the continuous evidence requirements. They need something they do not yet have a name for.
The compliance scandal of early 2026: fabricated evidence, confirmed data breach, live session tokens exposed, has made compliance-mature buyers acutely aware of the difference between assembled evidence and captured evidence. The question “can you prove this control existed before the audit?” is being asked in boardrooms that never asked it before.
And the GRC engineering community is nascent but growing. Practitioners are already building audiences around the intersection of engineering practice and governance obligation. The conceptual foundation is being laid. The category needs a name.
What Comes Next
DevGovOps is not a product. It is a discipline. The same way DevSecOps is not a product. Products implement it. Teams practice it. Organisations adopt it. Standards bodies eventually formalise it.
The practitioners who define DevGovOps now, who write its principles, build its tools, and educate its early adopters, will shape the discipline for the decade that follows. That is how DevSecOps was built. The engineers who wrote the early papers, built the early tools, and ran the early workshops are now the architects of the security cultures at the organisations that matter.
The same opportunity exists in governance. The question is whether the people who recognise it move fast enough to claim it.
