Overview
Separation of Duties (SoD) is a fundamental internal control intended to prevent fraud and error. Ideally, no single person should be responsible for completing a critical business process from end to end. For example, the person who creates a vendor in the system should not be able to pay that vendor.
In the context of IGA, SoD involves defining "Toxic Combinations" of access and enforcing rules to prevent users from acquiring them (Preventive) or detecting when they do (Detective).
Architecture
Reference Pattern: SoD Policy Enforcement
SoD checks must occur at multiple stages: Role Definition, Access Request, and Periodic Review.
Diagram
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| Enforcement Mode | Preventive (Block), Detective (Report) | Hybrid | Prevent high-risk (e.g., Pay + Approve). Detect/Report lower risk. |
| Scope | ERP only, Cross-application | Cross-application | Fraud often jumps systems (Create user in AD, Pay in SAP). |
| Exception Handling | Not Allowed, Allowed w/ Expiry | Allowed w/ Controls | Business needs might override security. Require "Compensating Controls" and expiration. |
| Rule Granularity | Role-level, Entitlement-level | Entitlement-level | Role names lie. Check the underlying permissions (T-Codes, Objects). |
| Rule Ownership | IT Security, Audit/Compliance | Audit/Compliance | IT implements the rule; Audit defines the risk. |
Implementation
Phase 1: Definition & Baseline
- Work with Internal Audit to define the "Top 20" toxic combinations.
- Scan the current user base for existing violations.
- Goal: Quantify the risk exposure.
Phase 2: Cleanup & Detective Controls
- Remediate existing violations (remove access or grant exception).
- Establish a quarterly report of new violations.
- Goal: Clean slate for critical systems (e.g., SAP, Oracle).
Phase 3: Preventive Enforcement
- Integrate SoD checks into the Access Request workflow.
- Block requests that create violations unless an exception is pre-approved.
- Check new Role definitions for internal conflicts.
- Goal: Stop the bleeding. No new violations created.
Risks
- False Positives: Rules are too broad, flagging innocent users. Leads to alert fatigue.
- Exception Hoarding: Managers approving exceptions for everyone "just in case." Exceptions become the rule.
- Cross-System Blindness: Failing to see that "Admin" in App A and "User" in App B creates a conflict.
- Compensating Control Failure: Approving an exception based on a control (e.g., "Manager reviews logs") that nobody actually performs.
KPIs
- Active Violations: Total number of unmitigated SoD violations in the environment.
- Exception Ratio: Percentage of violations covered by an approved exception vs. open risks.
- Remediation Rate: Speed at which new violations are resolved.
- Preventive Block Count: Number of access requests stopped by SoD rules (shows the value of the tool).