The State of CI/CD for Regulated Industries 2026
How teams in finance, health, and the public sector ship under approvals, segregation of duties, and audit evidence, and why most of their lead time is queueing rather than control.
Executive summary
Regulated engineering teams do not get to choose velocity over governance. Every production change must carry an approval trail, separate the person who wrote the change from the person who deploys it, and leave behind evidence an auditor can read months later. The pipeline is not just how code ships, it is the system of record that proves the organization shipped it correctly, with the right people involved at the right steps and nothing skipped along the way.
That governance has a measurable cost in lead time, and the cost is larger than most teams assume because it is mostly invisible. Approval gates, segregation-of-duties checks, and evidence collection add days, not minutes, between a merged change and a production release. But when those days are decomposed, the dominant term is not the control itself; it is waiting for a human approver to be available and waiting for evidence to be assembled by hand. The governance is essential; the queueing around it usually is not.
The opportunity in 2026 is to make compliance automatic rather than manual. Generate the evidence as a pipeline artifact instead of screenshotting approvals at audit time. Enforce the duty separation in the workflow instead of in a policy document people are asked to honor. Codify the routine approval decisions so a human reviewer only spends attention on the genuinely risky minority. Done well, this stops a regulated team from paying the approval tax twice, once in wait time and again in reviewer toil.
This report decomposes regulated lead time into its parts, shows which parts are essential control and which are avoidable queueing, and quantifies how evidence maturity changes the audit experience. It also addresses the uncomfortable truth that regulated teams will never hit the elite delivery bands for every change, and explains why that is fine: the goal is not to eliminate governance but to stop spending days on the changes that a codified policy could clear in minutes.
Three numbers frame the year. Roughly three quarters of professional developers use CI/CD, so the regulated segment is not behind on tooling. A change under formal approval gates takes on the order of four to five days to reach production in our modeling, the large majority of which is wait rather than work. And essentially every production deploy in this segment must retain audit evidence, which is precisely why generating that evidence automatically is the highest-leverage change a regulated team can make.
Modeled median days from merge to production, by approval model. · Source: Latchkey analysis (modeled)
Modeled count of retained evidence artifacts by control maturity. · Source: Latchkey analysis (modeled)
Email me the report
The full report is right here on this page, free. Want the link in your inbox to read later or share, plus new Latchkey reports as they drop? Drop your email and we will send it over.
Sent! Check your inbox for the report link.
No spam. Unsubscribe anytime.
Approval wait time, not pipeline time, is the bottleneck
In regulated pipelines the build and test stages are a small fraction of the elapsed time between merge and release. The compute runs and finishes; the change then sits, waiting. When the lead-time split is decomposed, the single largest slice is waiting for a human approver to be available, followed by evidence collection and sign-off, then the scheduled change window. The pipeline's own build and test time is the smallest term of the four.
This matters because it points every improvement effort in the right direction. A team that responds to slow regulated delivery by buying faster runners is optimizing the smallest slice of the problem. The leverage is in the wait: making approvals asynchronous and well-packaged so an approver can clear them quickly, and generating evidence automatically so the sign-off step reviews a complete artifact rather than assembling one from scratch.
The teams that cut regulated lead time meaningfully attack the queue. They codify the routine approval policy so most changes clear a gate instead of a person, they pre-assemble the evidence package so the approver's job is to review rather than to gather, and they reserve human approval bandwidth for the changes that genuinely warrant it. The control stays; the waiting shrinks.
- Waiting for an available approver is the largest single slice of regulated lead time, ahead of evidence, change windows, and build/test.
- Faster runners optimize the smallest term; the leverage is in the wait around the controls, not the controls themselves.
- Pre-assembled evidence turns the sign-off step from gathering into reviewing, which is the difference between days and minutes.
Modeled split of elapsed time between merge and production release. · Source: Latchkey analysis (modeled)
Segregation of duties belongs in the pipeline, not in a policy document
The control that the author of a change cannot also be its deployer is far stronger when the workflow enforces it than when a wiki asks people to behave. A policy document is an aspiration that depends on every individual remembering and choosing to comply, and on a reviewer catching the cases where they do not. That is exactly the kind of human-in-the-loop control that auditors probe and that occasionally fails in embarrassing ways.
Environment protection rules that require a different identity to approve a production deployment turn segregation of duties into something the pipeline guarantees and records. The separation is no longer a behavior the organization hopes for; it is a property the system enforces, and the enforcement leaves a tamper-evident record of who approved what. That is precisely the artifact an auditor wants to see, and it is generated for free as a side effect of the deploy.
Encoding the control this way also resolves the apparent tension between segregation of duties and speed. The governance-model chart shows segregation of duties sitting around five days of lead time when implemented through manual handoffs, against roughly one day for an automated policy gate. Most of that five-day figure is the manual handoff, not the separation itself. Codify the gate and a team keeps the duty separation while reclaiming most of the days.
Audit evidence is cheapest when it is a pipeline artifact
Manually screenshotting approvals and exporting logs at audit time is slow, error-prone, and resented by everyone involved. It also tends to produce the thinnest possible evidence, because each artifact is gathered under deadline pressure by someone who would rather be doing anything else. The result is an audit that feels like a fire drill and an evidence trail that is exactly as complete as the last frantic export made it.
The mature pattern is to emit the evidence as the pipeline runs: the commit, the test results, the approver identity, the artifact hashes, and the deploy record, all captured as immutable artifacts attached to the run that produced them. Evidence generated continuously turns an audit from a fire drill into a query. The auditor asks for the trail of a change, and the team returns a complete, machine-generated package rather than reconstructing it from memory and screenshots.
The evidence-maturity chart shows the difference is not subtle. Ad hoc and manual approaches retain a couple of artifacts per release; fully automated pipelines retain several times that, and continuous-controls setups retain more still, because each control emits its own record without anyone deciding to capture it. More evidence, captured automatically, at lower effort is the rare combination that makes both the auditor and the engineer happier at once.
- Emit commit, test results, approver identity, artifact hashes, and deploy record as immutable artifacts on every run.
- Continuous capture retains several times the evidence of manual approaches, at lower effort, because each control records itself.
- An audit becomes a query against retained artifacts rather than a deadline-driven reconstruction from screenshots and logs.
Slow lead time is a deliberate trade, but it has a floor
Regulated teams will never hit the DORA elite lead-time band of "Less than one day" for every change, and they should not pretend to. Some changes genuinely warrant a change advisory board, a scheduled window, and multiple human approvals, and pretending otherwise is how regulated organizations get into trouble. The governance on high-risk changes is the point, not an obstacle to route around.
But much of the lead time most regulated teams carry is avoidable queueing rather than essential control. The governance-model chart spans from roughly one day for an automated policy gate to around nine days for a full change advisory board. The expensive end of that range is appropriate for a small minority of changes and ruinous when applied to all of them. Applying CAB-grade governance to a one-line config change is not caution, it is waste dressed as caution.
Separating the small set of high-risk changes that genuinely need a change advisory board from the majority that a codified policy gate can clear lets a regulated team keep the governance where it matters and reclaim days everywhere else. This risk-tiering is the single most effective lever in the segment, because it does not weaken any control; it simply stops applying the heaviest control to changes that never needed it.
Risk-tiering the change is more powerful than speeding any single gate
The instinct when regulated delivery is slow is to make each gate faster: a quicker approval tool, a snappier evidence export, a more responsive CAB. Those help at the margin, but they leave the fundamental structure intact, which is that every change pays the same heavy governance regardless of its actual risk. The bigger win is structural: decide, automatically, how much governance a given change deserves.
A codified policy gate can clear a large class of low-risk changes, dependency bumps, copy edits, config toggles behind a flag, with full evidence and full duty separation, in about a day. The same gate can route a schema migration, a change to an authorization boundary, or a payment-path edit to the heavier human review it genuinely warrants. The pipeline becomes the thing that decides which path a change takes, based on what the change touches.
This is where regulated delivery starts to feel less like a tax. When the majority of changes flow through a fast, fully evidenced, fully separated automated path, the human approval bandwidth that used to be spread thin across everything concentrates on the changes that actually need a human judgment. Governance gets stronger on the risky changes precisely because it stops being diluted across the trivial ones.
Managed runners that self-heal reduce the audit surface
Every manual rerun of a failed pipeline is an event someone may eventually have to explain to an auditor. Why did this build fail and then pass? Who decided to rerun it? Was the failure a real defect that was suppressed, or a transient blip? In a regulated environment, a non-deterministic pipeline is not just an annoyance; it is a stream of small unexplained events that muddy the audit trail.
Self-healing runners retry transient, mechanical failures automatically and record exactly what happened: the failure signal, the retry, and the clean result. That keeps the audit trail deterministic and self-explaining. A network blip during artifact upload becomes a recorded recovery rather than a mysterious red-then-green sequence that a human had to intervene in and that an auditor might later question.
A managed runner at a modeled $0.0025 per minute delivers that recovery and that record at roughly 69% below GitHub-hosted cost, with no self-hosted fleet to separately patch, document, and prove compliant. In a regime where the build infrastructure is itself part of the validated system, removing a long-lived self-hosted fleet in favor of reproducible managed runners shrinks the audit surface as much as it cuts the bill.
The scheduled change window is a control worth re-examining
After approver wait and evidence collection, the scheduled change window is the next largest slice of regulated lead time. Many regulated organizations still batch deployments into fixed windows, a weekly release night, a monthly maintenance slot, on the theory that concentrating change into a known period reduces risk and makes incidents easier to attribute. That theory made sense when deployments were large, manual, and hard to reverse.
It makes far less sense alongside small, automated, individually evidenced changes that can be rolled back in minutes. Batching many small changes into a single window recreates the large-batch risk the rest of the pipeline was designed to avoid, and it adds days of waiting for the window to arrive. The window becomes a queue, and the queue becomes the second-largest avoidable component of lead time after approver availability.
Re-examining the change window does not mean abandoning operational discipline. It means distinguishing the changes that genuinely need a coordinated window, a database migration with downtime, a coordinated multi-service cutover, from the majority that can deploy continuously behind a flag with full evidence and instant rollback. Shrinking the set of changes that must wait for a window reclaims a large fraction of the lead time without touching any safety control that actually reduces risk.
Recommendations
Risk-tier changes so most clear an automated policy gate
Classify changes automatically by what they touch and route only the high-risk minority to a change advisory board. The routine majority clears a codified gate with full evidence and full duty separation in about a day, which concentrates scarce human review on the changes that actually warrant it and reclaims days everywhere else.
Enforce segregation of duties with environment protection rules
Require a different identity to approve a production deployment so the author cannot ship their own change. The separation becomes a property the pipeline guarantees and records, which is both a stronger control and a better audit artifact than a policy document people are asked to honor.
Generate audit evidence continuously, never at audit time
Emit the commit, test results, approver identity, artifact hashes, and deploy record as immutable artifacts on every run. Continuous capture retains several times the evidence of manual approaches at lower effort, and it turns an audit from a deadline-driven reconstruction into a query against artifacts that already exist.
Shrink the set of changes that must wait for a change window
Reserve scheduled windows for changes that genuinely need coordination, and let the rest deploy continuously behind flags with instant rollback. The change window is the second-largest avoidable slice of lead time, and most of what sits in it never needed the window in the first place.
Use self-healing managed runners to keep the audit trail clean
Auto-heal transient, mechanical failures and record the recovery, so a flaky blip never becomes an unexplained red-then-green sequence a human had to intervene in. A managed runner delivers that determinism below hosted cost and removes a self-hosted fleet from the validated surface you must separately prove compliant.
Outlook
Through 2026 the regulated segment will keep separating into two groups. One treats compliance as a property the pipeline produces automatically and risk-tiers its changes so governance lands where it matters; this group ships small, evidenced changes at a cadence that would have seemed impossible for a regulated organization a few years ago. The other treats every change as equally heavy and pays for it in lead time, reviewer fatigue, and audits that feel like emergencies.
Auditor and regulator expectations are themselves shifting toward automation. Continuously generated, tamper-evident evidence is becoming the expected standard rather than an impressive extra, partly because it is simply better evidence than a folder of screenshots assembled under deadline. Teams whose pipelines already emit that evidence will find their audits getting shorter, while teams reconstructing it by hand will find the bar rising faster than their manual process can keep up.
The durable direction is that governance and velocity stop being a straight trade-off in regulated software. The controls that matter, duty separation, retained evidence, approval trails, can all be encoded into the pipeline, which means a regulated team can have strong governance and reasonable speed at the same time. The organizations that internalize this will spend the next two years treating compliance as an automated baseline, while their peers keep treating it as a manual project they restart with every release.
Methodology
This report synthesizes publicly available industry data (developer surveys and the DORA State of DevOps research) with Latchkey's own analysis of regulated-pipeline economics. Lead-time figures, lead-time splits, and evidence-artifact counts are modeled from typical approval, segregation-of-duties, and audit-evidence pipeline shapes, plus published runner pricing, and are labeled as modeled rather than drawn from a primary survey. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.