Agile In Regulated Environments

The received wisdom in regulated industries is that iterative delivery is something other people do. Banks, insurers, pharmaceutical manufacturers, clinical systems, critical national infrastructure — these are held to be domains where the regulator requires a documented specification, a signed design, a controlled test phase and a formal release approval, in that order. Teams working under those constraints are told they can have the ceremonies of agility as long as the underlying gates stay where they are.

This account is almost entirely wrong, and it is worth being precise about where it goes wrong. Regulators, supervisors and auditors are overwhelmingly concerned with two things: that a control objective is met, and that you can demonstrate it was met with evidence that a third party can verify. They are, with rare and specific exceptions, indifferent to the mechanism. Almost nothing in the major regimes prescribes a waterfall lifecycle. What prescribes it is internal policy, written by people who chose one implementation of a control, and then hardened by twenty years of nobody wanting to be the person who changed it.

That distinction — objective versus implementation — is where all the available movement lives. Once you can separate them, the interesting observation is that a well-built continuous delivery pipeline is a substantially better control environment than a manual one. It produces evidence automatically, applies controls uniformly, cannot be persuaded to make an exception at eleven at night before a deadline, and leaves an immutable record. The manual process it replaces relies on a human remembering to attach a document.

What the regulator is actually asking for

Strip the language of any major regime down and a consistent set of questions emerges. Who authorised this change, and were they entitled to? Can one person push a change to a production system unilaterally? What testing established that it works, and where is the record? How do you know production matches what was approved? Can you reverse it? Is the record complete, accurate and protected from retrospective alteration?

Financial reporting controls under a regime like the Sarbanes-Oxley Act are, in the IT general controls domain, largely about access, change management and the integrity of the records feeding the accounts. PCI DSS concerns the security of the cardholder environment and the discipline with which changes to it are made. Data protection regimes like GDPR ask about lawful processing and the ability to demonstrate accountability. The EU's Digital Operational Resilience Act — confusingly sharing an acronym with the DORA delivery research, and unrelated to it — concerns operational resilience, testing and third-party risk. Validated systems regimes in life sciences ask you to show that a system does what it is specified to do and continues to do so.

None of these asks for a phase. They ask for a property, and for proof.

The rhetorical move that unlocks most conversations is therefore not "let us be more agile". It is: show me the control objective, and let me propose a different implementation that meets it with better evidence. That framing puts you on the same side of the table as the risk function, which is generally staffed by people who would rather have a strong control than a familiar one, and who are used to being handed the opposite request.

Segregation of duties without a handoff

Segregation of duties is the control most often cited as incompatible with modern delivery, usually in the form of a rule that the person who writes code may not deploy it. That rule is an implementation. The objective behind it is that no single individual can unilaterally introduce a change into a production system without independent scrutiny.

A pipeline satisfies that objective more strictly than a separate deployment team does.

Peer review as the independent scrutiny. Enforce, in the version control system rather than in a policy document, that every change to the mainline requires approval by someone other than the author. The system records who approved, when, and against which exact revision. That record is cryptographically anchored and cannot be adjusted afterwards, which is more than can be said for an approval captured in a spreadsheet.

The pipeline as the only path to production. Remove interactive human access to deploy into the production environment. If the pipeline is the sole route, and the pipeline only accepts artefacts built from reviewed trunk commits, then no individual can deploy unreviewed code — not because they are forbidden, but because there is no mechanism by which they could.

Separation of privilege rather than separation of people. The engineer can trigger a deployment; the engineer cannot alter the pipeline definition, the approval rules or the audit log without a separately controlled change that is itself reviewed. This is the meaningful separation, and it is stronger than putting a different human at the end of the process — because that human, in practice, almost never has the context to provide real scrutiny and approves because the ticket says to.

The last point is worth pressing in the conversation with risk. A separate operations team clicking deploy is a control on paper that provides little assurance in practice. Enforced peer review by someone who understands the change provides considerably more. The question to ask is not whether the new arrangement looks like the old one, but which arrangement would more reliably prevent the specific failure the control exists to prevent.

Traceability as a by-product

Traceability requirements — the ability to link a business requirement to a design, to code, to tests, to an approval, to a deployment — are usually met by maintaining a document that asserts these links. The document is assembled by hand, generally shortly before an audit, by people reconstructing what happened from memory and email.

That is the worst possible implementation, because it is expensive, it is late, and it is unreliable exactly where it matters. The alternative is to generate the same linkage as a by-product of doing the work.

Require a work item identifier in every commit message, enforced by a hook rather than by convention. Have the pipeline record, for every build, the source revision, the dependency versions, the test results, the approvals and the artefact fingerprint. Have deployment record which exact artefact went to which environment at what time, triggered by whom. Do not let anything reach production except through that path.

The result is a trace from requirement to running system, produced automatically and without anyone deciding what to include. When the auditor asks what testing was performed on the change that went live on a particular date, the answer is a query, not a project.

Contemporaneous evidence is also stronger evidence. A record assembled at the time, by a system with no interest in the outcome, is more credible than a reconstruction assembled by the people being examined. Auditors know this, and most would far rather have the former.

What the change advisory board is actually protecting

The ITIL change advisory board is the most visible ritual in regulated delivery and the most misunderstood. It is generally justified as risk management. Watch one for a few weeks and its real functions become clearer, and they are mostly legitimate needs being served by the wrong mechanism.

Coordination. Knowing that the network team's maintenance window collides with the payments release. A genuine need in a coupled estate, and one that a shared deployment calendar with automated conflict detection serves better than a weekly meeting.

Awareness. Ensuring that the service desk and operations know something is changing. Solvable by automated notification derived from the deployment record, which is also more timely.

Accountability transfer. The unstated function. Once the board has approved, the engineer is no longer solely accountable if it fails. This is a real psychological need in a blame-oriented culture, and no amount of automation addresses it — the remedy is cultural, not procedural.

A last line of defence against a weak process. When the upstream process cannot be trusted, a committee reading a form is the only inspection left. This is the honest justification in some organisations, and the response is to strengthen the upstream process rather than to defend the committee.

The practical route is not to abolish the board. It is to introduce a standard change category: pre-approved classes of change that follow a defined, automated, evidenced path and do not require individual review, with the board retaining oversight of the category and reviewing exceptions and outcomes. This is entirely consistent with ITIL's own framing, and it is usually less contentious than practitioners expect, because it gives the board a more meaningful role than rubber-stamping items it cannot assess.

Validated environments and the qualification burden

In life sciences and some safety-critical domains the constraint is sharper: the environment itself is qualified, and a change to it may require re-qualification. This is a genuine cost and it does move the economics — it is one of the places where a larger batch can be rational, because the fixed cost of the qualification event is high and real.

Even here the fixed cost is partly a design choice. Infrastructure defined as code converts qualification of a hand-built environment into qualification of a repeatable process. Immutable infrastructure means the deployed state cannot drift from the qualified state between audits, which removes an entire class of finding. Automated evidence collection reduces the effort per qualification event, which brings the optimum batch size down over time.

The general principle holds: attack the transaction cost and let the batch size follow it down, rather than negotiating forever about the release calendar. That argument is set out in full in batch size and the cost of big releases.

Mapping control objectives to pipeline implementations

The following is a starting point for the conversation with risk and internal audit, not a compliance template. The right-hand column is what to propose; the middle column is what you are replacing, and naming it explicitly is what keeps the discussion on objectives rather than on habits.

Control objective	Common manual implementation	Pipeline implementation and evidence
No unilateral change to production	Separate deployment team executes releases	Enforced peer approval in version control plus pipeline as sole deployment path; approval and actor recorded immutably
Changes are authorised	Change request form approved in a board meeting	Work item linked to every commit; standard-change category pre-approved with documented criteria
Adequate testing performed	Test phase sign-off document	Automated test results attached to every build artefact, with the exact revision tested
Production matches what was approved	Periodic manual reconciliation	Immutable artefacts deployed by fingerprint; infrastructure as code with drift detection
Ability to reverse a change	Documented rollback plan per release	Demonstrated automated rollback, exercised regularly, with recovery time recorded
Access is appropriate and least-privilege	Periodic access review spreadsheet	Role definitions in code, reviewed like any change; access grants logged and time-bounded
Records are complete and tamper-resistant	Controlled document repository	Append-only pipeline and version control history with retention controls
Data protection by design	Design review checkpoint	Automated checks in the pipeline for data handling rules, plus recorded design decisions in the work item trail
Operational resilience is tested	Annual disaster recovery exercise	Continuous verification in the pipeline plus regular, recorded resilience testing

Two cautions. Every row of this needs to be agreed with the people accountable for the control, not asserted by engineering; and the evidence has to be genuinely retrievable, because a control that produces evidence nobody can query is not an improvement on a form.

Audit as a design input

The organisations that do this well share one structural habit: they involve risk, compliance and internal audit while the delivery approach is being designed, rather than presenting it for approval afterwards.

The reason is not diplomacy. Compliance functions hold information the delivery team does not have — which objectives are hard requirements, which are internal policy choices, which interpretations the external auditor has accepted before, and which findings the organisation is already carrying. A delivery design built without that information will be rebuilt later at greater cost.

It also changes the relationship. A compliance function shown a pipeline producing continuous, verifiable evidence usually becomes an advocate, because their assurance becomes stronger. One that first encounters the pipeline as a fait accompli, in a meeting where they are asked to approve something they have not been taught, will do the only responsible thing available and say no.

What to do on Monday

Take your current release process and write down, for each step, the control objective it exists to satisfy and the source of that objective — external regulation, external auditor expectation, internal policy, or nobody-remembers. Do this with someone from risk in the room rather than as an engineering exercise. The fourth category is usually larger than anyone expects, and it is free ground.

Pick one control where the objective is clearly met better by automation, and propose the substitution as a formal control redesign with named evidence. Enforced peer review replacing a separate deployment handoff is the usual first candidate, because the evidence is stronger and the change is contained.

Then run a standard-change proposal past your change advisory board: one low-risk, high-frequency class of change, with defined criteria and automated evidence, pre-approved as a category with outcomes reported back to the board. Deliver it for a quarter and bring the record. A demonstrated control with an unbroken evidence trail is a far better argument than a presentation about agility, and it is the only kind of argument that travels to an auditor.