Notifications
Clear all
Topic starter
12/06/2026 9:22 pm
TL;DR: Separation of duties remains a core internal control for fraud, compliance, and operational resilience, but Zluri’s 2026 guide shows it now extends well beyond finance into access provisioning, reviews, backup recovery, vendor management, and SaaS governance. The real issue is not the policy concept, but whether identity workflows actually prevent one actor from creating, approving, and reconciling the same access path.
NHIMG editorial — based on content published by Zluri: Security & Compliance Top 7 Separation of Duties Policy Examples for 2026
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: How should security teams implement separation of duties in access workflows?
A: Start by splitting request, approval, provisioning, and review into different roles or systems.
Q: Why do access reviews fail when separation of duties is weak?
A: Access reviews fail when the same team or person can both grant access and certify that access later.
Q: What breaks when employee role changes are not tied to separation of duties?
A: Old access often remains in place while new permissions are added, which creates overlapping privileges and hidden conflicts.
Practitioner guidance
- Define conflicting duties per workflow List which identities can request, approve, provision, and review each sensitive access path, then remove combinations that let one actor complete the workflow alone.
- Separate provisioning from certification Ensure the team that grants access is not the only team that recertifies it, and require evidence that exceptions are independently validated before renewal.
- Break mover access inheritance When employees change roles, revoke obsolete access before adding new permissions so old entitlements do not silently bypass the SoD model.
What's in the full article
Zluri's full guide covers the operational detail this post intentionally leaves for the source:
- Role-by-role examples for finance, HR, vendor management, backup, and network administration
- Stepwise access workflow patterns for provisioning, review, and remediation
- Practical SaaS access-management examples tied to SoD policy enforcement
- FAQ material covering RBAC, employee records, and financial process segregation
👉 Read Zluri's guide to separation of duties policy examples for 2026 →
Separation of duties policy examples: where IAM controls break?
Explore further
12/06/2026 11:23 pm
SoD is an identity control before it is a finance control. The guide correctly treats separation of duties as a mechanism for preventing one actor from holding initiation, approval, execution, and review power at the same time. That makes it relevant to IAM, IGA, and PAM teams as much as to auditors. In a modern programme, SoD should be read as a design constraint on privileged workflows, not a checklist item for compliance reporting.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly governance breaks when review and ownership are incomplete.
A question worth separating out:
Q: Who should be accountable when a SoD violation is found?
A: Accountability should sit with both the control owner and the approver chain that allowed the conflict to persist. In practice, the business owner of the workflow, IAM governance, and the system owner all need a defined remediation path. SoD failures are usually process failures, not single-person mistakes.
👉 Read our full editorial: Separation of duties in 2026: what IAM teams should watch
