Key points
- Core control for SOX, PCI-DSS, and financial audits
- Expressed as conflicting-role rules (e.g. 'cannot have AP create + AP approve')
- Detected and enforced by IGA tools
- Critical in ERPs (SAP, Oracle, NetSuite, Workday)
- Violations require either role change or compensating control
What it is
Segregation of duties (SoD) ensures that risky business processes require collaboration between multiple people. No one user can both initiate and approve the same sensitive action.
Classic example: in accounts payable, the person who can create a new vendor must not also be able to approve payments to that vendor — otherwise they can pay a fake vendor they created.
How it works
The IGA platform maintains a rule library of conflicting roles or fine-grained permissions. When new access is requested or during access reviews, the tool flags conflicts. Resolution is either:
- Deny the request
- Remove conflicting existing access
- Document a compensating control (e.g. monthly transaction review by an independent party)
When buyers care
- SOX and other financial-controls audits
- ERP deployments (SAP and Oracle GRC are entire product categories)
- Healthcare, government, and defense compliance regimes
- Detecting toxic combinations across multiple systems (not just within one app)
Common misconceptions
- SoD is not only about money. Production-deploy + prod-data-access is a similar toxic combination in engineering.
- Role-based access alone doesn't enforce SoD. You need explicit conflict rules across roles.
FAQ
Who owns SoD rules?
Usually a partnership between Internal Audit, Finance, and Security/IAM. Rules are reviewed annually.
Best tools for SoD?
SAP GRC and Oracle Risk Management for ERP-heavy shops. SailPoint, Saviynt, and Pathlock for cross-app SoD.