TL;DR: Spreadsheet-based Segregation of Duties reviews break down when access changes continuously across multiple applications, and cross-application conflicts can remain invisible unless a tool consolidates identities, rules, exemptions, and audit history, according to Zluri. Manual review models assume access is stable long enough to reconcile, which no longer holds in SaaS-heavy environments.
Editorial analysis by NHI Mgmt Group, based on content published by Zluri: “SoD Software: A Buyer's Guide and Vendor Comparison”.
By the numbers:
- The guide describes a 150-app SaaS stack as an example of the scale at which conflicting access becomes hard to track manually.
Key questions
Q: What breaks when SoD is checked only inside one application?
A: Cross-application duty conflicts stay invisible.
Q: When should organisations prioritise SoD software over spreadsheet reviews?
A: Prioritise software when access changes faster than manual review can reliably track, especially in SaaS-heavy environments with multiple business systems.
Q: What do security teams get wrong about separation of duties?
A: They often treat SoD as a role design problem instead of an effective permissions problem.
Practitioner guidance
- Test cross-application conflict detection Build a few real toxic combinations that span different systems, such as ERP approval rights paired with payment creation rights in another finance tool, and verify the platform flags the identity once rather than two separate accounts.
- Require identity-level violation correlation Confirm that the control layer consolidates multiple accounts back to one person and shows the supporting accounts as context, instead of treating each account as an isolated review item.
- Run policy simulation before enforcement Use a single-identity check and a full-scope dry run against actual entitlements before enabling automated remediation, so you can measure how many violations a rule will create and whether the scope is acceptable.
Bottom line: The real SoD problem is distributed access, not a missing spreadsheet column, because conflicting entitlements often live in different systems.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
SoD software is only useful when it resolves identity across application boundaries. The central failure mode in modern SaaS environments is not the absence of a policy matrix, but the inability to see conflicting access when each entitlement lives in a different system. Spreadsheet review assumes a stable, bounded access picture; that assumption breaks once identities span finance, ERP, cloud, and workflow applications. The practical conclusion is that buyers should judge SoD by correlation depth, not by whether it can generate a conflict list.
A question worth separating out:
Q: Should SoD software sit inside a broader IGA platform or stand alone?
A: Both models can work, but a broader IGA platform usually reduces duplicate entitlement data and remediation effort. The key decision is not packaging, it is whether the SoD engine still supports identity-centric conflict detection, simulation, and auditable exemptions.
👉 Read our full editorial: Security and compliance SoD software: what buyers need to evaluate