All writing
Segregation of Duties

Separation of Duties at Scale: Catching Toxic Combinations Before Auditors Do

SoD is easy to state and brutally hard to enforce across hundreds of applications. The trick is detecting toxic entitlement combinations continuously, not at audit time.

5 May 2026·3 min read·Aditi Shah

Separation of duties is one of the oldest controls in existence — don't let the person who creates a vendor also approve payments to it — and one of the hardest to enforce in a modern entitlement landscape. The principle is trivial. The reality is that the conflicting capabilities are scattered across dozens of systems, expressed as cryptic entitlement codes, and accumulate silently as people change roles. By the time an auditor finds a toxic combination, it has usually existed for months.

SoD is a graph problem, not a list problem

The mistake is treating SoD as a list of forbidden roles. Real conflicts are combinations: capability A in one system plus capability B in another equals a toxic pair, regardless of the roles that delivered them. You are looking for the union of someone's effective access against a defined set of conflict rules. This is fundamentally a relationship problem — which is why it needs a system that can evaluate a person's entire entitlement footprint, not one application at a time.

Build the conflict matrix with the business, not in a vacuum

The hardest part of SoD is not the technology — it is defining what actually constitutes a conflict. That knowledge lives with process owners in finance, operations, and risk, not in IT. Sit with them, map the real business processes, and identify the steps that must never be controlled by one person. Document each rule with its business rationale, because every rule will eventually be challenged, and "the matrix says so" is not a defence an auditor or an aggrieved manager will accept.

Reality check

You will never get the conflict matrix perfect, and you should not wait until you do. Start with the highest-impact financial and privileged conflicts — the ones that would make headlines — and expand. A partial matrix enforced continuously beats a perfect one that ships next year.

Detective and preventive, in that order

There are two enforcement modes. Preventive SoD blocks a request that would create a conflict at the moment of provisioning — ideal, but only possible where access flows through your governed request process. Detective SoD scans existing access continuously and raises violations after the fact. You need both, because access arrives through ungoverned paths no matter how good your front door is. I start with detective — it gives you immediate visibility of the existing mess — then layer preventive controls onto the request workflow.

Mitigating controls: the pragmatic exit

Sometimes a conflict is unavoidable — a small team where one person genuinely must hold both capabilities. The answer is not to pretend the conflict doesn't exist; it is a documented mitigating control: compensating oversight, such as an independent review of that person's transactions, with the residual risk formally accepted by someone accountable. Auditors respect a known, mitigated, accepted conflict far more than one you didn't know about.

SoD at scale is won by making toxic combinations visible continuously and resolved in context — not by a heroic clean-up before each audit. When violations surface the day they arise, with a clear owner and a defined disposition, SoD stops being an audit fire drill and becomes a quiet, always-on control.

Segregation of DutiesSoDRiskIGA
Aditi Shah
Aditi Shah
Cybersecurity & IAM Specialist, Melbourne — 12+ years across regulated finance, government & telecom. About →

Looking for an IAM lead who thinks this way?

I help regulated enterprises govern identity at scale — from SailPoint to PAM to audit.

Get in touch