Every regulated delivery team I've worked with believes its release process exists to satisfy the auditor. The change record filled in by hand. The sign-off email. The person running deployment steps from a runbook at 11pm on a Saturday, with a second person watching over their shoulder to make it official. All of it performed in the name of control.
Here's the uncomfortable part. An auditor is asking two questions, and neither of them is "did you hold a meeting":
- Who approved this change, and can you prove it?
- Is what is running in production the thing that was approved, and can you prove that too?
Manual handling is the worst available way to answer either one. Every human step between the approved artefact and the running system is a step you cannot evidence, cannot repeat, and cannot prove wasn't something else. The ceremony that exists to demonstrate control is the thing destroying your ability to prove you have any. Teams think they're speaking to the auditor. They're compromising themselves at the gate.
So whenever you hear someone utter the words "CI/CD", you should become instantly skeptical of every tech-adjacent word that follows. For years I've watched enterprise "DevOps" teams use these words with scant regard for the discipline that these genuinely valuable practices demand. In a regulated environment, the gap between the words and the practice isn't a productivity problem. It's a control problem.
Let's break it down a little.
What CD means when you can't deploy on merge
First, a concession, because most writing on this subject refuses to make it and is useless as a result.
Continuous Deployment - a merge to the main branch goes to production, no human decides - is not available to you, and it isn't coming. Stop measuring yourself against the companies that do it, and be suspicious of anyone who tells you it's the goal. Your organisation has decided that a human being will make a release decision for the environments that matter. That decision is usually correct, frequently a legal obligation, and not yours to overturn.
Continuous Delivery is available to you, completely. Every build provably releasable, at all times, with a human choosing when. Nothing about a gated approval prevents this. Most enterprises claiming "CD" mean Delivery, which is fine - and then don't achieve Delivery either, which is not, because provably releasable is doing an enormous amount of work in that sentence. Part three sets out what has to happen before those words are earned.
So the gate stays. What changes is what happens at it:
- The approver makes a decision. Legitimate, permanent, keep it.
- The approver does work. That's the smell.
If your approval step involves a human assembling evidence, re-running a build, editing configuration, or executing deployment steps, you don't have a gate. You have a manual deployment with a signature attached.
Build once, promote many
This is the invariant that everything else rests on, and it's the seam where CI hands over to CD.
The artefact is built once, by CI, from a known commit. The same bytes are promoted through every environment. Nothing is rebuilt per environment. Ever.
If you rebuild for UAT and rebuild again for production, you tested one thing and shipped another. That's a CD failure and an audit failure at the same time, and the audit failure is the one that will hurt you - because you have just lost the ability to claim that what was tested is what shipped. Configuration varies by environment. The artefact does not.
The practical test: point at what's running in production, take its digest, and trace it back to the commit, the test results, the scans, and the approval. If there's a rebuild anywhere in that chain, you can't. Neither can your auditor.
Segregation of duties is a pipeline feature
The standard objection to automating deployment in a regulated environment is segregation of duties. If the pipeline deploys, who exactly is separated from whom?
Turn it around and look at what the manual process actually gives you. In most of them, the same engineer writes the code, builds it, and runs the deployment - separated from themselves only by an approval email from somebody who wasn't watching and couldn't have verified it if they were.
Now the automated version:
- The developer authors code, and holds no credentials that can deploy
- The pipeline builds, and its identity is the only thing that can produce a promotable artefact
- The approver approves, and can neither author nor build
- The pipeline deploys, using credentials no human holds at all
No single identity holds both "can change the code" and "can touch production". That is stronger separation than the manual process, it is enforced rather than agreed, and it's evidenced by default rather than reconstructed from memory six months later.
A second-order benefit worth naming: an approval recorded against an artefact digest is evidence. An email saying "approved" is a claim. Only one of those survives contact with an auditor.
Build time is not delivery time
Ask an organisation how long a piece of work will take and what you get back is build time. Two weeks means two weeks of writing code. Almost nothing in that number accounts for getting the change into production - the approvals, the evidence, the change record, the window, the notice period, the coordination, the second person who has to be awake for it.
That work is real, it's substantial, and in a regulated organisation it is frequently larger than the build it accompanies. Rarely does a delivery deadline take into account the compliance of the organisation that has to let the delivery occur. It isn't in the estimate, it isn't on the plan, and it appears in no report. It lands on people instead, as the overtime at the end of a release.
Worse, it gets lumped in with "technical work". So when a release is late, the conclusion available to everybody is that engineering was slow. That conclusion is wrong, and it's unfixable, because it points at the wrong system entirely. What was actually slow was organisational complexity that went unpriced.
And you cannot improve what you are not measuring. That's why this work costs roughly what it cost five years ago while everything around it got faster. Not for want of trying. For want of a number.
Look at what's inside it. Somewhere in most regulated organisations, somebody spends the last two days of every release assembling an evidence pack - exporting test results, screenshotting scan dashboards, pasting them into a document, uploading it to SharePoint so the approver has something to read. That work appears on no org chart and in no estimate.
That job is an integration. It moves data from one system to another on a schedule. We'd never accept a person doing that by hand between two production systems, and there's no reason to accept it here.
The cost isn't only the two days. Toil in the evidence chain is a control weakness. A human who assembles the pack is a human who could assemble it incompletely - through time pressure, inattention, or, once in a career, intent. The difference is undetectable afterwards. A pipeline that emits the same evidence, the same way, every time, removes the possibility rather than managing it. Auditors tend to understand this faster than the organisations being audited.
So automate the evidence, all the way to wherever it has to land. Proving compliance should cost a team nothing.
The interesting part is what you do when the destination is silly. If the governance function insists the pack lives in SharePoint, don't spend your credibility arguing that SharePoint is the wrong home for release evidence. That's an argument you'll lose, and losing it costs you the arguments that matter. Concede the destination completely - and automate the upload.
What you've built at that point is a seam: a boundary between your delivery system and somebody else's system of record. Seams are fine. Undeclared seams are not. So declare it. Tell the architecture and governance functions plainly - this is the boundary, this is what crosses it, this is the format, this is what happens when it fails, and this is who owns it.
Same code either way, completely different governance posture. Undeclared automation is a finding waiting to happen. A declared, owned, monitored interface is architecture - and when the organisation eventually retires SharePoint, there's exactly one place to change.
The tell: what happens either side of the approval
So why do development teams still coordinate the deployment to QA, UAT and Production? When I see this behaviour I am very skeptical - but not about the approval. About what's happening on either side of it.
Some of this coordination is entirely legitimate, and permanent:
- Change windows and legacy freeze periods
- An approver who sits outside the delivery team
- Independent sign-off on UAT, sometimes contractual
- Retention and archival obligations that outlive your pipeline's own retention
And some of it is the tell:
- A person assembling evidence so the approver has something to read
- A rebuild between the approval and the deployment
- Steps executed by hand from a runbook
- A bridge call
- The deployment behaving differently in production because somebody "knows the trick" for prod
Look at the difference. The first list constrains when you release and who decides. Not one item on it constrains whether the release is automated, evidenced and repeatable. The second list means a human is performing the deployment - which is the thing that was supposed to be automated, and also the thing your auditor cannot verify.
When I see the second list, it says to me that the automation isn't trusted, that we've skipped critical steps, that we haven't practised the release in the other environments. But mostly it says "we have rebadged our old deployment approach with the trendy label of CD". What I often see is teams doing old-world scripting using modern engineering tooling - ClickOps, if you will, with better syntax highlighting. Just because you wrote the script in GitLab, Jenkins or GitHub does not mean you are doing CD.
The test you can run on Monday
Opinion is cheap. These are measurable - and in a gated environment the first one has to be split in two, which turns out to be the most useful thing in this article.
- Lead time to releasable - commit to an approved-and-evidenced, promotable artefact. Entirely within your control. Should be under an hour
- Time in gate - releasable to running. Governed by your organisation, not your team
- Deployment frequency - on demand, per merge, into non-production. No change window applies to your test environments
- Change failure rate - known, measured and boring, because the releases are small
- Time to restore - roll forward or back on a pre-approved path, without a bridge call
Splitting lead time is the point - it's how the unpriced work earlier in this article finally gets a number. Reported as one figure, engineering slowness hides behind "the CAB" and governance slowness hides behind "the engineers", and neither conversation can happen. Split them and both become possible - and you'll usually find the second number is the larger one, which is a far better argument for changing the process than any amount of advocacy.
If lead time to releasable isn't moving, the practice isn't real - whatever the workflow file says. If time in gate isn't moving, that's a governance conversation, and now you're holding data instead of an opinion.
Where this goes next
Those two numbers belong to two different disciplines, and they fail in different ways.
- Continuous Integration owns lead time to releasable - branch discipline, merging unfinished work safely, and what a build must guarantee before anything is allowed to leave it.
- Continuous Delivery owns time in gate - promoting one artefact through environments, what a good gate looks like, freezes, and rollback as a pre-approved path.
The regulated version of "boring" was never the absence of a gate. It's a gate that takes four minutes, because the evidence was already sitting there when the approver opened it. If you're doing it correctly, releases should not be celebrated with fanfare - the office would be too noisy.
References & further reading
- Continuous Delivery - Humble & Farley (2010)
- Accelerate - Forsgren, Humble & Kim (2018)
- The DevOps Handbook - Kim, Humble, Debois & Willis (2016)
- Investments Unlimited - Yates, Willis, Wilkinson, Byard et al. (2022)