Topic starter
12/06/2026 1:22 am
TL;DR: Segregation of duties separates task authority so the same identity cannot both perform and verify sensitive actions, reducing fraud and access misuse risk according to Zluri. In identity programmes, SoD only works when policy, workflow, and review are aligned across human, NHI, and privileged access paths.
Editorial analysis by NHI Mgmt Group, based on content published by Zluri: “Segregation of Duties Policy and Procedure: An Overview”.
Key questions
Q: What breaks when segregation of duties is the only control in place?
A: SoD blocks some toxic combinations, but it does not clean up stale, unused, or orphaned access.
A: Segregation of duties reduces risk by preventing one person or team from controlling every step in a sensitive process.
Q: How do security teams know if SoD controls are actually working?
A: SoD controls are working only if live access state matches the approved separation model across systems.
Practitioner guidance
- Define SoD rules around conflicting duties Write policy conditions that block a single role or account from both initiating and approving sensitive actions, then tie each condition to a specific operational workflow.
- Separate access provisioning from access review Assign access certification to a function that does not create or modify the underlying entitlements, and make that separation explicit for privileged access paths.
- Include unmapped accounts in SoD checks Test shared, service, and orphaned accounts against the same SoD conditions used for named users so non-human access does not bypass review logic.
Bottom line: Segregation of duties is meant to prevent the same identity from creating, approving, and reviewing sensitive actions, but it only works when policy and procedure stay aligned.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
12/06/2026 11:15 am
SoD is an independence control, not a documentation exercise: The control fails when policy says duties are separate but the operational workflow still concentrates approval, provisioning, and review in the same team. That is a governance failure, not a tooling failure, because the review is no longer independent. Practitioners should treat SoD as a test of separation in practice, not a statement in a policy binder.
A question worth separating out:
Q: Should organisations include service accounts in segregation of duties checks?
A: Yes. Any account that can perform sensitive actions should be subject to SoD logic, including service or unmapped accounts. If those accounts are excluded, the organisation creates a parallel access path that can bypass the same governance applied to human users.
👉 Read our full editorial: Segregation of duties policy and procedure in IAM governance
This post was modified 4 days ago by NHI Mgmt Group