How segregation of duties works
Segregation of duties is a control principle borrowed from finance: the person who creates a payment should not be the one who approves it, and the developer who writes code should not be the only one who deploys it to production. By requiring at least two people for a sensitive end-to-end process, SoD makes fraud and serious error require collusion rather than a single decision.
In identity terms, SoD is expressed as rules about conflicting entitlements. A policy might state that no user may hold both the vendor-creation role and the payment-approval role in an ERP system, or both database administration and audit-log management rights.
An SoD engine evaluates these rules continuously: it blocks conflicting combinations at request time (preventive control) and scans existing access for violations (detective control).
Why SoD matters
Most large frauds involve one person holding a toxic combination of permissions for too long. SoD is the structural defense against that scenario, which is why external auditors test it directly in financial systems and why frameworks such as SOX, ISO 27001, and SOC 2 expect conflicting duties to be identified and controlled.
SoD violations also accumulate silently. A user who changes roles three times can end up with a combination no policy would ever have approved deliberately. Without automated detection, these toxic combinations surface only during incidents or audits.
Where a conflict cannot be avoided — common in small teams — organizations document the exception and apply compensating controls such as enhanced logging and management review.
Implementing SoD in practice
Implementation starts with identifying the processes where a single actor poses real risk: payments, procurement, payroll, user administration, and production deployment are typical. For each process, teams define the conflicting entitlement pairs and encode them as rules in their IGA platform.
The first violation scan usually returns a long list; triage by business impact rather than trying to fix everything at once. Remove clear-cut violations, document justified exceptions with compensating controls, and wire the rules into the access request workflow so new conflicts are blocked before they exist.
SoD checks work best alongside access reviews, where reviewers see conflict flags in context. Monosync supports defining SoD policies and surfacing violations within its access review and reporting workflows.