Notifications
Clear all
Topic starter
25/06/2026 2:53 pm
TL;DR: SOX separation of duties works by splitting initiate, approve, and review rights so no single user can both create and conceal a risky transaction, according to SafePaaS. That makes SoD an identity governance control as much as an audit requirement, because role design, provisioning, and change evidence determine whether conflicts are prevented or merely discovered later.
NHIMG editorial — based on content published by SafePaaS: SOX separation of duties, ITGC controls, and audit readiness
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.
Questions worth separating out
Q: How should security teams enforce separation of duties in modern enterprise systems?
A: Enforce separation of duties at the point where access is requested or changed, not after the fact.
Q: Why do access reviews alone fail to manage SoD risk?
A: Access reviews are too late to stop a toxic entitlement from being used.
Q: What do security teams get wrong about separation of duties?
A: They often treat SoD as a compliance checklist instead of a live governance rule.
Practitioner guidance
- Embed SoD checks at access request time Block or escalate conflicting entitlements before provisioning, and route every exception to an independent control owner for review.
- Tie identity-sensitive changes to auditable tickets Link master data, approval matrix, and security model changes to a ticket, reviewer, and deployment record so audit evidence can be reconstructed quickly.
- Harmonise toxic-role rules across applications Maintain one policy matrix for ERP, SaaS, identity provider, and PAM entitlements so the same toxic combination cannot slip through a different platform.
What's in the full article
SafePaaS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of SoD rules in ERP, inventory, payroll, and payment workflows.
- Workflow automation details for access request escalation, approval routing, and audit evidence capture.
- Change Tracker usage patterns for master data and application security model changes.
- Integration detail for SAML and API connectors across identity, PAM, and monitoring tools.
👉 Read SafePaaS's analysis of SOX separation of duties and ITGC controls →
SOX SoD and identity governance: where audit controls fail?
Explore further
25/06/2026 4:06 pm
SOX separation of duties is an identity governance control, not just an audit control. The article is right to frame SoD as a way to prevent one user from both perpetrating and concealing a transaction. That is the same governance logic identity teams use when they look for privilege combinations that collapse oversight. The field takeaway is that SoD belongs inside IAM, IGA, and application access design, not only in audit workpapers.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: How do organisations prove SoD is working during audit preparation?
A: They should be able to show real-time conflict dashboards, change logs for identity-sensitive configuration, and a complete approval trail for access grants and exceptions. The strongest evidence is not a policy statement but a reconstructed control path that shows who approved what, when it changed, and whether the conflict was blocked or remediated.
👉 Read our full editorial: SOX segregation of duties is becoming an identity control problem
