Look for whether the platform can continuously detect conflicting access, connect it to lifecycle events, and remove or flag it across the full SaaS estate. If it only produces reports after the fact, it is supporting compliance evidence more than real segregation.
How to judge whether SoD software is doing real control work
SoD software is effective when it does more than document conflicts. It should identify toxic combinations early enough to block or route them, correlate those conflicts with provisioning and deprovisioning events, and keep pace with changes across SaaS, ERP, and cloud systems. If the tool cannot act on current access state, it is usually measuring compliance rather than preventing misuse.
The practical test is whether the platform understands the Segregation of Duties (SoD) Guide approach to rules, conflicts, and mitigations, not just whether it can generate a report. Strong SoD control usually depends on good lifecycle data, so a solution also needs a reliable view of joiner, mover, and leaver changes that can be linked back to the access model.
For IAM teams, that means judging the tool against the actual decision path it supports. If a conflict can be detected but not tied to an owner, an exception, or a removal workflow, then the software is only partially effective. The control should be able to explain which entitlement, role, or transaction creates the conflict and whether the issue can be remediated before it becomes an audit finding or an operational workaround.
What effective SoD looks like across the full access estate
Good SoD software is not limited to one application or one business unit. It should cover the systems where access is created, inherited, and reused, including SaaS platforms, shared admin consoles, and adjacent identity processes. That matters because many SoD failures happen when the conflict exists in one system but the risk materialises through connected access elsewhere.
Coverage also matters for non-human actors when they participate in business processes. NHIMG’s Top 10 NHI Issues and Lifecycle Processes for Managing NHIs show why lifecycle visibility, ownership, and recertification matter when access is not purely human. If SoD logic ignores service accounts, automation, or shared technical access, it can miss the real control gap even when human roles look clean.
Another sign of maturity is whether the platform separates detection from disposition. An effective system can flag a toxic combination, but it also supports the operational path to resolve it through removal, redesign, or a documented exception with compensating controls. That distinction is important because organisations often overestimate control strength when the tool only produces evidence for auditors after the fact.
How to test whether the control is prevention or just reporting
The most useful way to test SoD effectiveness is to trace a conflict from discovery to outcome. Start with a known toxic combination, then check whether the software can catch it before access is live, keep it visible when roles change, and force a decision when the conflict persists. If the answer is yes only after a scheduled review, the platform is weak on real-time control.
You should also test whether the product can distinguish a temporary exception from a durable design flaw. If every conflict becomes an alert with no prioritisation, teams will ignore it. If every exception is silently approved, the control is hollow. Effective SoD software supports a defensible judgment about when the conflict is acceptable, when it needs redesign, and when it should block access outright.
Where identity governance is part of the design, internal control mapping becomes more useful. NHIMG’s Identity Security Programme Guide and IAM and Identity Provider Buyer’s Guide help teams think about the surrounding ownership, lifecycle, and vendor fit that SoD tooling depends on. SoD software rarely fails in isolation; it usually fails when it sits on top of poor role design, incomplete inventory, or unmanaged exceptions.
Risk and Threat Considerations
Weak SoD creates exposure when conflicting access is allowed to persist, especially in finance, procurement, admin, and platform-support paths. The main failure mode is not that a report is missing, but that a user or technical account can both create and approve the same business action, or can combine access in a way that defeats review.
Failure mechanism: The tool detects conflicts too late, lacks lifecycle correlation, or cannot enforce removal, so toxic access survives long enough to be used or normalized.
Impact: Organisations inherit audit findings, higher fraud and abuse risk, and a false sense of control because the software documents segregation without actually maintaining it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | SoD reduces excess access and conflicting permissions that violate least privilege. |
| AU-6 — Audit Record Review, Analysis, and Reporting | SoD software must surface conflicts and disposition them from access activity and lifecycle events. | |
| Recommendation — Enforce AC-6 to remove conflicting entitlements and minimize users' effective access. Use AU-6 to review conflict signals and escalate unresolved segregation exceptions. | ||
| CIS Controls v8 | CIS-5 — Account Management | SoD depends on timely provisioning, changes, and removal across accounts and roles. |
| Recommendation — Apply CIS-5 to keep account lifecycle changes aligned with segregation rules. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | SoD effectiveness hinges on governing identities, entitlements, and access workflows in cloud estates. |
| Recommendation — Use IAM to enforce access governance and prevent conflicting entitlement combinations. | ||
Practitioner Guidance
What to verify: Test the product against live access changes, not just historical exports. A credible SoD platform should show the conflict when the entitlement is granted, inherited, or retained, and it should preserve enough context to explain why the conflict exists.
What good looks like: The strongest outcome is continuous monitoring tied to an actionable workflow, where conflicts are either prevented, time-bound, or explicitly approved with compensating controls and ownership. That is the difference between control operation and control evidence.
Practitioner takeaway: Treat SoD software as effective only when it changes access outcomes in time to matter, because a tool that merely reports conflicts is supporting governance, not enforcing segregation.
Related resources from NHI Mgmt Group
- How can IAM teams tell whether an agent has excessive effective permissions?
- How should IAM teams decide whether to keep ADFS in their architecture?
- How can IAM teams decide whether agentic authorization is working?
- How do IAM teams decide whether an AI use case needs new controls or better NHI hygiene?