Automating Change Approval and Segregation of Duties in CI/CD
Making the Control the Pipeline Rather Than the Meeting
Most banks can produce a segregation of duties policy in under a minute. Producing evidence that the control worked on a specific deployment last Thursday takes considerably longer, and the answer is often a change record that a human filled in describing what they intended to do, alongside a deployment log showing what actually happened, with nothing connecting the two.
That gap is the whole problem. Segregation of duties CI/CD banking controls only mean something when the pipeline itself refuses to proceed, rather than when a committee has been informed.
What is the control actually trying to prevent?
One person moving a change from their own keyboard into production with nobody else involved.
The risk has two faces. The fraud case is deliberate: someone alters a limit check, a payment beneficiary, an interest rate, or a reporting figure, and deploys it themselves. The error case is far more common: someone deploys the wrong artefact, the wrong configuration, or a change nobody else looked at, and discovers the consequence in production. Both are addressed by the same structural answer, which is that the person who authors a change must not be the person who authorises it or the only person who can release it.
Why does a change advisory board meeting not deliver this?
Because it approves a description, not an artefact.
A change record says "deploy release 4.2 to production on Thursday" and a board approves it. Nothing in that process establishes that the code in release 4.2 was reviewed by someone other than its author, that the artefact deployed is the one that was built from the reviewed code, or that no additional change was slipped in. The board is a governance forum, and it is useful for scheduling and risk conversation, but treating it as the segregation control produces exactly the evidence gap described above. Control has to attach to the artefact and the identity, which is why it belongs in the pipeline.
Which duties genuinely need separating?
Four boundaries, and one of them is usually missed entirely.
| Boundary | What it prevents | Common failure |
|---|---|---|
| Author from approver | Self-reviewed change reaching production | Approval by a colleague with no enforced entitlement |
| Build from deploy | Deploying an artefact that was not built from reviewed source | Rebuilding at deploy time from a mutable branch |
| Deploy rights from production data access | A deployer reading or altering customer data | Deployment identities carrying broad database rights |
| Pipeline administration from pipeline use | Changing the control rather than complying with it | Every engineer holding pipeline admin |
The fourth is the one estates miss. An organisation can enforce two-person review on application code while every engineer can edit the pipeline definition that enforces it, which makes the control advisory. The same applies to the identity and entitlement layer generally, which is why this sits alongside the disciplines in identity and access management for regulated platforms.
How do you enforce approval inside the pipeline?
By making the artefact, the approval, and the identity inseparable.
The pattern that works: protected branches that cannot be written to directly, required review from an identity that platform-enforced rules confirm is not the author, a build that produces an immutable versioned artefact from the reviewed commit, a deployment step that can only take an artefact carrying a valid approval, and a deployment identity that is a machine identity rather than a person's credentials. Each link removes a way for the control to be bypassed without leaving a trace. Where a change record system is mandated, tie the deployment gate to the record's approved state programmatically rather than asking a human to confirm it exists.
Why must the approver be determined by entitlement rather than convention?
Because a convention is unenforceable and unevidenced.
"A colleague reviews it" is not a control. What is a control: the platform knows who authored the change, knows the entitlement group permitted to approve changes to that component, verifies the approver is in that group and is not the author, and records the decision with identity and timestamp. That also handles the awkward cases honestly, such as a two-person team where the only available approver is the author, which the platform should refuse rather than quietly permit. Refusing surfaces a real staffing constraint instead of hiding it behind a signature.
Could one person in your organisation author and deploy a change to a payment limit unobserved?
How do you stop the pipeline becoming the bypass?
Treat pipeline definitions, runners, and secrets as production infrastructure.
Pipeline configuration should live in version control, be subject to the same review requirements as application code, and ideally be reviewed by a group other than the team whose deployments it governs. Build runners need hardened, ephemeral, and isolated execution so one job cannot influence another or reach another team's secrets. Deployment credentials should be short-lived and scoped, issued to the pipeline rather than held by people, with signing material inaccessible to user-defined build steps. Where cryptographic signing is involved the key custody question belongs with the broader design covered in HSM and key management for financial workloads.
Why is pipeline configuration the most privileged code you own?
Because whoever changes the pipeline changes what the pipeline enforces.
An engineer who can edit a deployment workflow can remove a review requirement, add a step that pulls an unreviewed artefact, or exfiltrate a secret, and the change looks like ordinary configuration. Privilege should therefore be inverted from the intuitive arrangement: application code review is routine, pipeline change review is stricter. Also monitor for the specific event of a control being weakened, since a commit that removes an approval requirement should generate an alert rather than merely a merge notification. This is the same reasoning that makes dependency and toolchain integrity a first-order concern, as discussed in software supply chain attacks.
What about emergency change?
A defined path, heavily logged, reviewed afterwards, and counted.
Real emergencies happen and a control set with no emergency path will be bypassed informally, which is worse. Define break-glass explicitly: who can authorise it, what it permits, what logging is automatic, and a hard requirement for retrospective review inside a defined period with the same rigour a planned change would have received. Then measure the rate. If ten per cent of production changes go through the emergency path, the standard path is too slow and the exception has quietly become the process, which is a delivery finding rather than a compliance one.
| Break-glass element | Requirement |
|---|---|
| Authorisation | Named individuals, not a role anyone can claim |
| Scope | Specific system and change, time-bounded |
| Logging | Automatic, immutable, including session activity |
| Retrospective review | Mandatory within a defined period, with sign-off |
| Measurement | Rate reported to engineering and risk leadership |
| Trigger for redesign | A sustained rate above an agreed threshold |
Should anyone hold standing production access?
Almost nobody, and never as a default of employment.
Standing access is the control weakness that most reliably survives a well-designed pipeline, because someone still needs to fix things at three in the morning. Replace it with just-in-time elevation: a request stating purpose, an approval by someone other than the requester, a time-limited grant, automatic revocation, and full session logging. Then reduce the need for elevation by improving observability, since most production access requests are attempts to find out what is happening rather than to change it. The insider dimension is real here and standing broad access is exactly the precondition it needs, which is the subject of insider threat detection in financial institutions.
How do you handle infrastructure and database change?
Same pipeline, same separation, with schema change treated as the sharp end.
Infrastructure defined as code inherits the review and approval model automatically, which is one of the strongest arguments for defining it that way. Database change is harder: a schema migration is code, needs review, and needs a tested rollback or forward-fix path, while direct data manipulation in production should be a break-glass event rather than a routine one. Separate the person who writes a migration from the person who approves it, and separate deployment of a migration from the ability to run arbitrary statements against production. Getting the migration discipline right also matters disproportionately during core replacement work, as covered in core banking data migration.
What about vendors and offshore teams?
Same entitlement model, with location and jurisdiction as additional attributes.
Vendor engineers frequently end up with broader pipeline and environment access than employees because access was granted at contract start and never reviewed. Bring them into the same entitlement structure, include them in access reviews, and record which entitlements permit approval, since an outsourced author approved by another engineer at the same supplier may not satisfy the separation the institution believes it has. Where the change touches regulated data, the location of the person exercising the entitlement can itself be a constraint, which is the terrain of data residency and sovereignty architecture.
How do you avoid strangling delivery?
Put the control in the path of the change, automate the check, and tier by risk.
The controls above add seconds rather than days when they are automated, and weeks when they are administered by people. The corollary is that risk-tiering matters: a configuration change to a marketing banner should not require the same approval chain as a change to interest calculation. Define standard pre-approved change types with automated verification, a normal path with enforced two-person review, and a high-risk path with additional authorisation. Then measure lead time by tier so it is visible when the control set is the constraint. Confidence in automated testing is what makes tiering defensible, which is why this pairs with core banking regression automation.
Supervisory framing supports the automated direction rather than the committee one. The EBA's guidelines on ICT and security risk management, applicable from 20 May 2025 and amended to align with DORA's application from 17 January 2025, set ICT risk management requirements across credit institutions, investment firms, and payment service providers. PCI DSS applies to any entity that stores, processes, or transmits cardholder data or could affect the security of the cardholder data environment, which brings deployment paths into scope wherever they can reach that environment. And NIST's Secure Software Development Framework, version 1.1 published in February 2022, sets out high-level secure development practices aimed at reducing vulnerabilities and addressing their root causes.
Is your emergency change rate above ten per cent of production deployments?
How should implementation be sequenced?
Version control discipline, then artefact integrity, then gates, then access, then the exceptions.
| Phase | Duration | Deliverable |
|---|---|---|
| Repository and branch protection | 1 month | No direct writes, enforced review from a distinct entitlement |
| Immutable artefacts | 1 to 2 months | Versioned build outputs, no rebuild at deploy time |
| Deployment gates | 2 months | Deploy accepts only approved artefacts, machine identities only |
| Pipeline hardening | 2 months | Pipeline as reviewed code, ephemeral runners, scoped secrets |
| Production access replacement | 2 to 3 months | Just-in-time elevation, standing access removed |
| Database and infrastructure change | 2 months | Migration review, no routine direct data manipulation |
| Break-glass formalisation | 1 month | Defined path, logging, retrospective review, rate reporting |
| Risk tiering | 1 to 2 months | Standard, normal, and high-risk paths with differentiated controls |
Evidence generation is deliberately absent from this list because it is a separate discipline with its own design questions, covered in audit-ready CI/CD evidence trails. Enforcement and evidence are related but distinct: this article is about making the control real, that one is about proving it to someone who was not there.
Which metrics matter?
Self-approved change count, standing production access holders, emergency change rate, pipeline admin population, and lead time by risk tier.
Self-approved changes should be zero and any occurrence should be investigated, since it means an enforcement path failed. Standing production access holders should trend to a small named set. Emergency change rate signals whether the standard path is usable. Pipeline administrator population is the privilege concentration measure. And lead time by risk tier shows whether the controls are proportionate, because if a low-risk change takes as long as a high-risk one then tiering exists on paper only.
Segregation of duties is one of the oldest controls in banking and one of the worst served by traditional change management. It works when the pipeline enforces it, records it, and cannot be quietly reconfigured by the people it constrains.
Frequently Asked Questions
What is segregation of duties in a deployment pipeline actually preventing?
One person being able to write a change, approve it, and put it into production unobserved, which is the pattern behind both fraud and uncontrolled error.
Why does a change advisory board meeting not deliver segregation of duties?
Because it approves a description of a change rather than the artefact being deployed, and it does not prevent the deployer from shipping something different.
Which duties genuinely need to be separated?
Author from approver, build from deploy, deployment rights from production data access, and administration of the pipeline from routine use of it.
Why must the approver be determined by entitlement rather than convention?
Because a convention that a teammate reviews the change is unenforceable and unevidenced, while an entitlement check enforced by the platform is both.
Why is pipeline configuration the most privileged code in the estate?
Because whoever can change the pipeline can change what the pipeline enforces, which makes pipeline definitions a higher-privilege artefact than the application code they build.
How should emergency change be handled?
Through a defined break-glass path with named authorisation, full logging, mandatory retrospective review inside a set period, and a measured usage rate.
Should developers have standing production access?
No. Access should be time-limited and requested for a purpose, granted just in time, logged, and revoked automatically when the window closes.
How do you avoid these controls strangling delivery?
By placing the control in the path of the change rather than the path of the person, automating the check, and risk-tiering changes so low-risk work follows a pre-approved route.
