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.
A representative scenario: 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 that CVE remediation satisfies, what evidence shows the control was in place before deployment, who approved the remediation decision, and where the audit trail is that connects the vulnerability to the regulatory obligation. DevSecOps answered none of those questions. It was never designed to.
The governance gap
See it in action
See how ComplAIbridge fits your stack
Book a 20-minute walkthrough - no deck, no sales cycle, just the product.
Book a DemoThe 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, not assembled retrospectively.
The tools have not caught up. Every major compliance platform, such as Vanta, Drata, or 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.
The current, production-backwards market approach connects to live infrastructure, scans current configuration, and generates evidence at audit time, with no design-stage data, no ability to trace a requirement to a control, manual multi-framework mapping, and evidence that is assembled rather than captured. A lifecycle-first, DevGovOps approach instead instruments from the requirements stage, captures evidence at the moment of decision, builds a cryptographic and provably unaltered chain, treats design artefacts as compliance inputs, traces requirement through control to evidence, lets one control satisfy multiple frameworks, and ensures evidence exists before the audit question is even asked.
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. DevGovOps treats the requirements phase as the first governance checkpoint. Framework obligations are ingested as design inputs, and controls are identified before a line of code is written. Design artefacts, architecture documents, threat models, and 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 captured at the moment of an event and evidence assembled after the fact to describe that event. Regulators and auditors know the difference, and increasingly, legal frameworks 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. The chain runs from requirement through design artefact, build event, test result, and production state, to audit pack, and 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 spans several overlapping frameworks that require different evidence formats but are often satisfied by the same underlying controls. DevGovOps treats multi-framework mapping as a first-class architectural concern, so a single control can be evidenced once and mapped automatically to every applicable framework it satisfies.
Who DevGovOps is for
The DevGovOps audience is not the traditional compliance manager. It is the emerging class of practitioners who think in systems, understand the development lifecycle, and have been handed compliance responsibilities that legacy tools were never designed to support: the security engineer at a DORA-regulated fintech who needs CVE remediation to generate compliance evidence automatically; the platform engineer building an internal developer platform who needs CAF compliance to be an output of good engineering practice; the GRC lead at a scale-up told to achieve ISO 27001, DORA, 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, and 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 it opens, the problem isn't recognised widely enough for a category to exist. After it closes, incumbents have claimed the space and the cost of entry rises dramatically.
The DevGovOps window is open now for three reasons. DORA came into force in January 2025, mandating continuous ICT risk management and cryptographic-quality evidence for roughly 22,000 in-scope financial entities and their technology suppliers, many of whom are discovering that their existing compliance tools cannot satisfy continuous evidence requirements. A compliance scandal in early 2026, involving fabricated evidence and a confirmed data breach with live session tokens exposed, has made compliance-mature buyers acutely aware of the difference between assembled and captured evidence. And a nascent but growing GRC engineering community is already laying the conceptual foundation the category needs.
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, and 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. The same opportunity that built DevSecOps exists in governance today. The question is whether the people who recognise it move fast enough to claim it.
Keep reading
Get Early Access
Ready to make compliance
part of how you build?
Get in touch and we'll show you exactly how ComplAIbridge fits your stack, your team, and your frameworks.
No deck. No sales cycle. Just the product.