Segregation of Duty Without Silos

How automation enables compliant, high-velocity teams in regulated environments

In Australia’s regulated sectors, the phrase Segregation of Duties (SoD) is a cornerstone of compliance. For CIOs and CTOs, upholding standards like ISO 27001, PCI DSS often leads to a default solution: organisational silos. We create separate teams for development, platform operations, and QA, citing SoD as the reason.

The intention is sound, but the outcome is frequently a drag on performance. This traditional model introduces friction through endless ticket handoffs, context switching, and delays. For lean organisations or leaders championing agile, “two-pizza teams,” building an entire org chart just to tick a compliance box is inefficient and costly.

This post explores a modern, automation-centric approach. We’ll show you how to embed robust, auditable SoD directly into your tooling, enabling a small, high-performing team to maintain compliance without cumbersome bureaucracy or weak “compensating controls.”

The Intent Behind the Control

The principle behind SoD is simple and necessary. As defined in ISO 27001 (Control 5.3), its purpose is clear:

"Conflicting duties and conflicting areas of responsibility should be segregated."

This is meant to prevent a single individual from having the unchecked ability to introduce risk, whether through error, fraud, or bypassing security controls. The common interpretation is that the duties must be segregated between different people or teams.

This leads to the classic workflow:

A developer, Sam, finishes a feature and creates a ticket for the Platform team.

The Platform team deploys it to a staging environment and assigns a ticket to QA.

The QA team validates the change and re-assigns the ticket back to the Platform team for production deployment.

This process certainly looks good on an audit report. But it’s slow and expensive, and diffuses ownership.

The real problem is our interpretation of the word duty. The standard doesn’t mandate segregated teams; it mandates segregated conflicting actions. In 2025, we have a far more effective tool for this than the org chart: automation.

The Blueprint for Automated SoD

By shifting the burden of segregation from people to systems, we can redesign the landscape. Instead of relying on human handoffs, we build a framework where automated guardrails enforce compliance. This allows Sam, the developer who holds all the context, to drive the process from end-to-end without ever holding conflicting powers at the same time.

Imagine a workflow built on these modern, accessible components:

GitOps & Infrastructure as Code (IaC): All changes to applications and infrastructure are defined as code in version control. The deployment pipeline is the only mechanism for change.

Automated Testing & QA Gates: Unit, integration, and security tests run automatically within the deployment pipeline, acting as an impartial check on quality and security.

ChatOps for Auditable Approvals: A required approval step is built into the pipeline. A peer or manager can review the proposed change (the merge request) and approve it with a command in a tool like Slack or Teams, creating an immutable, timestamped audit record.

Centralised Secrets Management: Tools like HashiCorp Vault or AWS Secrets Manager ensure that developers and pipelines never handle credentials directly. Access is granted ephemerally and on a least-privilege basis.

Immutable Audit Logs: Every action—from the initial code commit to the final approval and deployment—is automatically and permanently logged.

A Better Way: From Handoffs to Guardrails

Let’s revisit our scenario with this automated framework in place.

Sam, our developer, finishes her feature. Instead of creating a ticket for another team, she submits a merge request containing her application and infrastructure changes.

This single action triggers a new, streamlined workflow:

Automated Checks: The pipeline automatically runs a suite of tests to check for bugs, regressions, and security vulnerabilities.

Forced Peer Review: The pipeline halts and requires a formal review. A colleague reviews the proposed changes for risk and intent.

Auditable Approval: The colleague approves the change directly within the code repository or via a ChatOps command. This approval is logged and acts as the crucial SoD gate.

Automated Deployment: With approval granted, the pipeline takes over, deploying the change through each environment and into production without any further human intervention.

Notice the shift?

We have successfully segregated the conflicting duties:

• Initiating a change (Sam’s merge request) is separate from…

• Approving the change (the peer review) is separate from…

• Executing the change (the automated pipeline).

We’ve met the intent of SoD with greater precision and efficiency. Sam keeps the context, the workflow is fast, and the entire process generates a perfect, immutable audit trail.

Shift Complexity, Gain Velocity

As Amazon’s Werner Vogels famously said, “Complexity can neither be created nor destroyed—only moved somewhere else.”

This approach doesn’t eliminate complexity; it strategically shifts it from slow, error-prone human processes into reliable, industry-standard automation. The upfront investment in building these automated guardrails pays dividends in velocity, operational resilience, and—most importantly for a regulated business—effortless auditability.

You can empower your teams to deliver value faster while building a more robust and demonstrable compliance posture than any silo-based structure could ever offer.

In a follow-up article, we’ll demonstrate a practical implementation of this framework for a safety-focused Australian startup.