When should teams use segregation of duties instead of relying on audits?

Why Segregation Matters More Than Audit After the Fact

segregation of duties is the control you choose when the business consequence of one identity being able to complete a transaction alone is too high to leave to review. Audits can confirm what happened, but they do not stop a single actor from initiating, approving, and executing the same action. That distinction matters most in payment, procurement, payroll, privileged change, and any workflow with irreversible impact.

The practical test is whether the workflow contains a toxic combination: access that allows one person to create the request, approve it, and carry it through. If that path exists, audit becomes evidence, not prevention. Strong SoD design breaks the path before the transaction can complete, while audit supports oversight and exception handling after the fact.

In mature access governance programs, SoD is often paired with role design, entitlement review, and compensating controls. The point is not to eliminate every conflict in every system, but to decide where prevention is required because downstream review would be too late. NHIMG’s IAM and IGA Basics is a useful reference for how SoD fits into broader access governance and entitlement control.

Where Audit Stops and SoD Starts

Audit answers the question, “Did a violation occur, and can we prove it?” Segregation of duties answers a different question, “Should this actor ever be able to complete the full chain?” When the same identity can both authorize and execute, audit may detect the event, but the organization has already accepted the exposure. That is acceptable for low-impact processes; it is not acceptable where fraud, self-approval, or unauthorized privilege use would be material.

A useful rule is to reserve audit-heavy patterns for activities where review can realistically reverse, contain, or remediate the issue before harm becomes significant. Use SoD when the control objective is preventative, when the action is hard to unwind, or when the transaction itself creates trust in other downstream systems. This is why segregation is common in finance, procurement, and privileged administration, where one person’s unchecked action can become another system’s record of truth.

SoD also becomes more important as access expands across human and non-human actors. Once a workflow is automated, the question changes from “who saw it?” to “what identity can both request and perform it?” NHIMG’s Segregation of Duties (SoD) Guide is helpful for thinking about toxic combinations, compensating controls, and how segregation must extend beyond human users.

Designing for Prevention, Not Just Review

Teams should use SoD whenever they cannot tolerate a single identity holding end-to-end control over a sensitive process. That usually means separating request, approval, execution, and reconciliation into different roles or systems, then validating that no role chain silently recombines those powers. If the process can be completed entirely by one privileged identity, the design is usually too weak for a prevention-first control model.

Audit remains important, but it should support a control that already limits blast radius. For example, audit logs can help prove that a privileged change was made, but they cannot stop the change from being made. SoD changes the architecture of authority, while audit changes the quality of evidence. Good programs use both, with SoD as the control boundary and audit as the assurance layer.

When the process is exception-driven, define who can grant the exception, how long it lasts, and what evidence is required to close it. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is relevant here because audit trails and access governance are only effective when the underlying control model prevents the same identity from owning every step.

Practitioner Guidance

What to prioritise: Start with processes that create direct financial, privilege, or irreversible operational impact. Those are the workflows where audit-only control is weakest and where SoD usually gives the highest reduction in exposure.

What to verify: Check whether any one identity can request, approve, and execute the same sensitive action, even through role inheritance, delegated admin, or privileged fallback paths. Hidden recombination is the most common failure mode.

What good looks like: Sensitive workflows require at least two distinct authorities, and any exception is time-bound, logged, reviewed, and narrow enough that it does not become a permanent shortcut.

Practitioner takeaway: Use SoD when you need the control to stop a bad action from happening at all; use audit when you need proof, trend visibility, and follow-up after a properly bounded action.

Related resources from NHI Mgmt Group

• How should security teams implement Oracle Cloud ERP segregation of duties at entitlement level instead of relying on Job Role labels?
• How should security teams use IAST and RASP in NHI governance?
• When should teams use step-up verification instead of relying on reusable identity?
• How should security teams use autonomous pentesting to validate real exploitability instead of relying on checklist scans?