Separation of duties
Separation of duties policy detects and prevents toxic combinations of access that would let one person commit fraud or error.
Separation of duties (SoD) is a policy that flags or blocks conflicting access, for example the same person who can create a vendor also being able to approve payments to it. IdentityIQ evaluates SoD policies during requests and identity refresh, and surfaces violations for remediation.
- SoD prevents one person holding conflicting access
- Policies define pairs or sets of conflicting entitlements/roles
- Evaluated at request time and during identity refresh
- Violations are remediated or granted a documented exception
- A core control for SOX and financial compliance
Separation of duties (SoD) is the control that prevents any single person from holding a combination of access that would let them commit and conceal fraud or error, for example both creating a vendor and paying it. It is the control auditors scrutinise most, especially under SOX, and one of the highest-value things SailPoint enforces.
What SoD prevents
Certain pairs of capabilities are dangerous in one pair of hands. SoD policies define these toxic combinations so that no identity can hold both sides, breaking the chain that makes undetected fraud possible.
How SailPoint enforces SoD
- Policies define conflicting sets of entitlements or roles.
- At request time, a conflicting request is prevented or requires an explicit, documented exception.
- During identity refresh, existing violations are detected and raised for remediation.
- Certifications surface violations for review.
Prevention versus detection
The strongest posture prevents conflicts at request time rather than only detecting them afterward. Where prevention is not possible, violations must be remediated or granted a time-bound, approved exception, and that exception trail is itself audit evidence.
Getting SoD right
SoD quality depends on a well-modelled entitlement set and a ruleset that captures the conflicts that actually matter in your business, particularly in finance systems like SAP. Invest there; vague rules produce noise, precise ones produce control.
Common pitfalls
- Detect-only SoD with no remediation.
- Rules over poorly-modelled entitlements, producing noise.
- No exception process, forcing all-or-nothing outcomes.