Regulated organisations face a genuine tension. Regulators expect strong change control, segregation of duties and a clear audit trail, while the business expects software to ship at a competitive pace. Too often this tension is resolved by adding manual approvals and review boards that turn every release into an event. This article sets out how to design CI/CD governance in regulated environments that satisfies auditors and controls risk without reintroducing the bottlenecks that automation was meant to remove.
The false choice between speed and control
The starting belief to challenge is that control requires manual gates. Most regulatory requirements are about evidence and accountability: that changes are reviewed, tested, approved by appropriate people, and traceable. None of that inherently requires a human to click an approval button at the end of a pipeline. In fact, automated pipelines are capable of producing far better evidence than manual processes, because every step is logged, repeatable and tamper resistant.
High performing regulated organisations have shown that strong control and frequent delivery are compatible. The trick is to encode the controls into the pipeline so that compliance is a property of the system rather than a series of human checkpoints. When the path to production enforces the rules automatically and records what it did, you get both the speed of automation and the assurance the regulator needs.
Segregation of duties without manual handoffs
Segregation of duties is a common requirement that teams assume forces a manual approval. The principle is that the person who writes a change should not be the sole person who approves its release to production. This can be satisfied through the pipeline itself. Require that code changes are reviewed and approved by someone other than the author before they can merge, enforce this in the source control system, and record the approval immutably. The deployment to production then flows from that approved, reviewed change without a separate manual gate.
Where higher risk changes genuinely warrant additional human judgement, make that the exception rather than the rule. Classify changes by risk so that routine, low risk releases flow automatically while a small minority requiring explicit sign off are clearly identified. This keeps the friction proportionate and concentrated where it adds real assurance, rather than taxing every release equally.
Building the audit trail into the pipeline
Auditors ask who changed what, when, who approved it, what testing was performed, and how it reached production. A well designed pipeline answers all of these by construction. Every change carries its review and approval record. Every build is reproducible from version controlled source. Every test run and its results are logged. Every deployment records the artefact version, who triggered it, and the controls that passed. The evidence is generated automatically as a side effect of doing the work.
This is a profound improvement over manual processes, where evidence is assembled retrospectively from emails, tickets and spreadsheets that may be incomplete or contradictory. With pipeline generated evidence, an audit becomes a matter of querying records that already exist and are trustworthy because they were produced by the system, not reconstructed by people under time pressure.
Enforcing quality and security gates automatically
Governance in regulated settings extends beyond change control to the quality and security of what is shipped. Build these checks into the pipeline as automated gates: tests that must pass, security scanning of code and dependencies, infrastructure compliance checks, and policy as code that verifies configuration against required standards. A change that fails a mandatory gate does not proceed, and this enforcement is consistent and unbiased because it is automated.
The key design principle is that gates should be fast and deterministic. A gate that is slow or flaky teaches teams to find ways around it, which is exactly the behaviour governance is meant to prevent. Invest in making the automated controls reliable and quick, so that passing them is simply part of normal delivery rather than an obstacle to be resented and circumvented.
Managing the highest risk changes
Some changes carry enough risk that additional governance is justified: major data migrations, changes to systems handling the most sensitive information, or releases during sensitive business periods. For these, a clearly defined heavier path is appropriate, with explicit human review and perhaps a change advisory step. The important thing is that this heavier path is the exception, applied to a defined and limited category, and that the criteria for entering it are clear and agreed in advance.
Defining these categories deliberately prevents the common failure where, out of caution, everything is treated as high risk and the whole estate slows to the pace of its most sensitive change. Risk based differentiation is itself a control, and a defensible one, because it directs scrutiny to where it genuinely reduces exposure.
Designing the governance model
- Map each regulatory requirement to a specific automated control in the pipeline rather than to a manual checkpoint.
- Enforce reviewer separation in source control so segregation of duties is satisfied without a release time gate.
- Classify changes by risk so routine releases flow automatically and only defined high risk changes need human sign off.
- Make the pipeline generate audit evidence automatically: approvals, test results, artefact versions and deployment records.
- Build fast, deterministic quality and security gates, including policy as code, that block non compliant changes.
- Review the controls with audit and compliance colleagues early so the model is accepted before it is relied upon.
Common pitfalls
The most frequent pitfall is layering automated gates on top of all the old manual ones rather than replacing them. The organisation builds a sophisticated pipeline but keeps the change advisory board reviewing every release, so it gets the cost of both and the benefit of neither. Decommissioning manual controls requires the confidence of audit and compliance, which is why engaging them early to agree that the automated controls are sufficient is essential. Without that agreement the manual gates never go away.
A second pitfall is treating governance as purely an engineering exercise. The people who must be satisfied are in risk, audit and compliance functions, and if they do not understand or trust the automated controls they will insist on the manual ones as a safety net. Bring them into the design, show them the evidence the pipeline produces, and let them help define the risk tiers. Governance that the second line helped build is governance the second line will accept.
Striking the right balance for your specific regulatory obligations and risk appetite takes careful design and stakeholder alignment. Need support applying this approach? Email sales@halfteck.com.