Notifications
Clear all
Topic starter
17/08/2026 4:41 pm
TL;DR: Separation of duties remains a core internal control because conflicting access can let one person create and approve transactions, issue funds, or bypass review, according to Saviynt. The practical challenge is not defining SOD but enforcing it consistently across applications, users, and service accounts before violations become fraud or audit findings.
NHIMG editorial — based on content published by Saviynt: Separation of Duties and application access governance
Questions worth separating out
Q: How should security teams implement segregation of duties across multiple business applications?
A: Start by mapping the business actions that must never sit in the same identity across ERP, finance, HR, CRM, and workflow systems.
Q: Why do conflicting entitlements create so much fraud risk?
A: Because they remove the independent check that prevents one identity from completing both sides of a sensitive transaction.
Q: How do organisations know if SOD controls are actually working?
A: Look for two signals: risky requests being blocked before access is granted, and existing violations being found and remediated on a recurring schedule.
Practitioner guidance
- Inventory toxic entitlement combinations Build a business-process view of incompatible actions such as create and approve, request and approve, or submit and release across finance and IT workflows.
- Enforce request-time SOD checks Block or route access requests when the requested entitlement would create a conflicting duty with the user's existing access across connected applications.
- Run recurring detective reviews Schedule periodic analysis to uncover previously unknown violations, then route each case to remediation, mitigating controls, or access revocation.
What's in the full article
Saviynt's full blog covers the operational detail this post intentionally leaves for the source:
- Rule logic for detecting conflicting duties across ERP and finance applications
- Workflow examples for preventive rejection versus detective remediation
- Workbench filtering and review flow details for auditors and SOD administrators
- Integration points for application access governance across common enterprise systems
👉 Read Saviynt's analysis of separation of duties controls and application access governance →
Separation of duties risk: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:46 pm
SOD is a lifecycle governance problem, not just a policy rule. The article treats separation of duties as an access control question, but the real issue is whether identity governance can prevent incompatible rights from persisting across joiner, mover, and leaver events. That means the same identity can drift into conflict through role changes, exception handling, or manual remediation. Practitioners should treat SOD as an entitlement lifecycle control, not a static audit checkbox.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who should be accountable when SOD violations involve service accounts?
A: The same identity governance owners who manage human access should own the policy outcome, but operational accountability may sit with application, finance, or platform teams depending on the workflow. If a service account can trigger a critical business step, it belongs in the SOD model and must be reviewed, approved, and remediated like any other identity.
👉 Read our full editorial: Separation of duties gaps still drive fraud and compliance risk
