Notifications
Clear all
Topic starter
08/06/2026 4:15 pm
TL;DR: Segregation of duties is described as a structural control that prevents one role from approving, executing, and recording the same action, and the article connects that model to finance, IT, HR, and automated access workflows, according to SecurEnds. The governance issue is now identity-centric: when access, approvals, and logging overlap, SoD becomes a detection problem rather than a control.
NHIMG editorial — based on content published by SecurEnds: Segregation of Duties explained for modern enterprises
Questions worth separating out
Q: How should security teams implement segregation of duties in cloud and IAM environments?
A: Start by identifying the actions that should never sit with one identity, such as approving access, using elevated access, and certifying the outcome.
Q: Why do service accounts and automation identities make segregation of duties harder?
A: Because service accounts can operate at machine speed and often bypass the informal controls used around human work.
Q: What breaks when one role can approve and execute the same transaction?
A: The control loses independence, which means mistakes and fraud are harder to detect and easier to hide.
Practitioner guidance
- Map sensitive workflows to control functions Break each high-risk process into authorization, custody, recordkeeping, and reconciliation, then assign each function to different roles or systems.
- Separate privileged administration from operational execution Keep account administration, production deployment, and audit-log management in distinct hands.
- Automate conflict detection and recertification Use access reviews and rule-based monitoring to flag role combinations that create SoD conflicts, then route them into remediation before the next audit cycle.
What's in the full article
SecurEnds' full article covers the operational detail this post intentionally leaves for the source:
- Role-by-role examples of how finance, HR, and IT teams separate approval, execution, and reconciliation in practice
- Automation features for detecting SoD conflicts across applications, user roles, and workflow paths
- Audit-oriented guidance on proving that conflicting access has been reviewed and remediated
- Practical examples of red flags such as developer deployment access, payment approval overlap, and contractor deprovisioning gaps
👉 Read SecurEnds' guide to segregation of duties in finance, IT, and HR →
Segregation of duties in IAM: where does the control actually fail?
Explore further
08/06/2026 5:47 pm
SoD failures are identity failures, not just process failures. The article treats segregation of duties as a business control, but in practice the break happens when identity entitlements allow one actor to both create and certify a sensitive action. That is an IAM design problem as much as a policy problem. When access governance, approvals, and evidence collection are not separated, the audit trail loses independence. Practitioners should treat SoD as an entitlement architecture requirement, not a documentation exercise.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means SoD reviews often start from incomplete entitlement data rather than a reliable baseline.
A question worth separating out:
Q: How do organisations know if segregation of duties is actually working?
A: They look for evidence that conflicting access is rare, reviewed, and remediated quickly. A working SoD programme produces clean access reviews, separate approval chains, and logs that show independent validation. If the same identity keeps appearing across multiple control steps, the programme is failing even if policy says otherwise.
👉 Read our full editorial: Segregation of duties still breaks first at identity control points
