Notifications
Clear all
Topic starter
10/06/2026 9:01 pm
TL;DR: Separation of duties matrices reduce fraud and unauthorized access by splitting initiating, approving, and processing tasks, and Zluri’s guide frames them as a practical IGA control for access governance, auditability, and compliance. The real issue is that SoD fails when access reviews, approvals, and monitoring stay spreadsheet-driven and disconnected from lifecycle enforcement.
NHIMG editorial — based on content published by Zluri: Security & Compliance Segregation Of Duties Matrix Template
Questions worth separating out
Q: How should security teams implement separation of duties in SaaS environments?
A: Start by defining incompatible duties at the entitlement level, then map those duties to roles and approvers in your SaaS stack.
Q: Why do separation of duties controls fail in practice?
A: They fail when access stays broader than the current job need, when approvals are detached from live permissions, and when exceptions are not tracked.
Q: How do you know if a separation of duties matrix is actually working?
A: Check whether active permissions match current responsibilities, whether approvals are logged end to end, and whether conflicting actions can still be completed by one identity.
Practitioner guidance
- Map incompatible duties to live entitlements Translate SoD from policy language into entitlement-level controls so one identity cannot request, approve, and execute the same sensitive action.
- Certify access against current role scope Run recurring reviews that compare active permissions with actual job responsibilities, then remove overlapping access before the next review cycle.
- Separate approval paths from execution paths Ensure the identity that approves access or a transaction is not the same identity that can process it, and add exception handling for temporary overrides.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- The template structure for roles, access levels, functional areas, and approval processes in a working SoD matrix.
- The example approval workflow with app owners, reporting managers, and IT admins, including override handling and changelog tracking.
- The access certification flow that ties reviews, remediation, and audit reporting into one IGA process.
- The discovery and integration details behind Zluri's SaaS visibility model, which are implementation-specific rather than conceptual.
👉 Read Zluri's guide to separation of duties matrix design for IGA teams →
SoD matrices and IGA: what IAM teams need to keep enforcing?
Explore further
10/06/2026 9:58 pm
SoD is a lifecycle control, not a spreadsheet control. The article treats separation of duties as a role matrix, but its real value depends on joiner-mover-leaver discipline, access certification, and exception handling. Once entitlements drift or approvals become detached from current role scope, the matrix no longer separates duties in practice. Practitioners should treat SoD as a governed lifecycle process across human and non-human identities.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, and a quarter encountered multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
A question worth separating out:
Q: What is the difference between SoD and least privilege?
A: Least privilege limits how much access an identity has, while SoD limits which conflicting duties that identity can combine. You need both. An account can be narrowly scoped and still violate SoD if it can request, approve, and execute the same sensitive action. Segregation is about incompatible power, not just small permissions.
👉 Read our full editorial: Separation of duties matrices are still the core IAM control
