Security and compliance SoD software: what buyers need to evaluate

At a glance

What this is: This buyer’s guide explains what to evaluate in Segregation of Duties software, with cross-application detection, identity-centric violation handling, simulation, exemption governance, and audit history as the core decision points.

Why it matters: It matters because IAM and IGA teams need SoD controls that can keep pace with SaaS sprawl, support defensible audits, and avoid mistaking periodic access review for actual conflict detection.

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.

Context

Segregation of Duties software exists to prevent the same identity from accumulating conflicting access that can enable fraud, error, or control failure. In practice, the problem is not just whether a role looks risky in isolation, but whether conflicting entitlements can be found across multiple systems before they create an audit or governance issue.

The article argues that spreadsheet-based reviews and single-application admin consoles fall behind once access changes continuously across a SaaS-heavy environment. That is an IAM and IGA problem, not just a reporting problem, because the control has to see the identity across applications, exemptions, and remediation history at the same time.

For buyers, the core question is whether the tool is a true SoD control or only an access review layer with SoD language attached. The difference determines whether the programme can surface conflicts early enough to matter and produce evidence that stands up under audit.

Key questions

Q: What breaks when SoD is checked only inside one application?

A: Cross-application duty conflicts stay invisible. A user can look compliant in SAP or in a business app on its own, yet still hold a toxic combination when procurement, payment, finance, or HR entitlements are considered together.

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. Once conflict detection depends on repeated cross-referencing between applications, the control becomes too fragile to trust for audit, fraud prevention, or remediation.

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. A role may look compliant on paper while the underlying application access still allows conflicting actions. Teams need to test actual privilege paths, not just review job titles or role names.

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.

Technical breakdown

Why spreadsheet SoD reviews break at scale

A spreadsheet can represent a conflict matrix, but it cannot observe live entitlement drift. SoD breaks when the underlying access model is distributed across identity providers, SaaS applications, ERP systems, and finance tools, because the conflict only exists when two separate entitlement sets are viewed together. Manual cross-referencing works briefly, then collapses under application count and change frequency. The technical issue is not storage of the matrix, but whether the control layer consolidates identities and entitlements into one enforcement view.

Practical implication: validate that the platform can correlate entitlements across systems before you rely on it for SoD enforcement.

Identity-centric conflict detection versus account-centric detection

Account-centric detection treats each login or system record as a separate object, which is too narrow when one person holds multiple accounts. Identity-centric detection resolves those accounts back to the same person and evaluates the combined entitlement picture, so the violation is tied to the individual rather than fragmented across systems. That matters in environments where HR, finance, and IT roles are split across multiple applications and separate account namespaces. Without identity consolidation, an SoD conflict can remain hidden even while every individual account looks acceptable in isolation.

Practical implication: require identity-level correlation, not just per-account checks, before accepting a vendor’s SoD claims.

Why simulation and exemption governance are part of the control

SoD rules are not useful if they cannot be tested before enforcement or reviewed after exceptions are granted. Simulation shows the blast radius of a policy change against real entitlements, which reduces false positives and avoids sudden operational disruption. Exemption handling is equally important because legitimate business exceptions can quietly become permanent control gaps unless they carry reason, duration, and re-evaluation. Audit history closes the loop by preserving what the policy looked like at a given point in time, which is critical when a control must be proven retrospectively.

Practical implication: test rule changes in simulation, then require time-bound exemptions and versioned policy evidence for auditability.

NHI Mgmt Group 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.

Identity-centric SoD is the real control, not account-level reporting. If the same person holds several accounts, a per-account model can produce a false sense of coverage while the combined access still creates separation-of-duties risk. That is why account-centric tools often behave like access reporting products rather than true governance controls. The field should treat person-level aggregation as the minimum bar for credible SoD enforcement.

Simulation and time-bound exemptions turn SoD from a static rule into a governable process. A rule that cannot be dry-run, versioned, or re-opened after expiry produces evidence gaps as soon as the environment changes. The strongest programmes treat exemption lifecycle and policy versioning as part of the control itself, not as administrative extras. Practitioners should evaluate whether the tool can prove control operation over time, not just detect a violation on the day it was created.

SoD belongs inside broader identity governance, but it must not be diluted by it. When SoD is bundled into a wider IGA stack, shared entitlement data and remediation workflows can reduce duplication. But the buying mistake is to assume any access governance platform can do SoD well. The market should expect tighter integration with provisioning and access review, while still demanding distinct two-sided conflict logic for separation of duties.

What this signals

Cross-application SoD is the market test: if a control cannot evaluate entitlements across ERP, finance, and cloud systems as one identity picture, it is not solving the problem the buyer actually has. The operational challenge is consolidation, not policy wording.

The buying decision should shift from feature lists to governance evidence. Practitioners need to know whether a platform can prove what the policy was, who approved exceptions, and how many identities were affected before enforcement was turned on.

For practitioners

• 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.
• Make exemptions time-bound and reviewable Require a documented reason, a maximum duration, and automatic re-evaluation when the exemption expires so temporary SoD exceptions do not become permanent control bypasses.
• Preserve versioned audit evidence Insist on full policy snapshots at publish time, including author, timestamp, and configuration state, so you can show auditors exactly what the SoD rule looked like on a prior date.

Key takeaways

• The real SoD problem is distributed access, not a missing spreadsheet column, because conflicting entitlements often live in different systems.
• The article’s scale example is a 150-app SaaS stack, which shows why manual cross-referencing becomes unreliable in modern environments.
• Buyers should insist on identity-level detection, simulation, time-bound exemptions, and versioned audit evidence before treating a tool as credible SoD software.

Key terms

• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Identity-centric detection: Identity-centric detection is the practice of interpreting security alerts through identity context such as role, privilege, and expected behaviour. It helps analysts separate routine activity from suspicious access patterns and improves the accuracy and speed of triage.
• Exemption Governance: Exemption governance is the process of allowing a documented exception to a control while preserving accountability, expiry, and re-review. In SoD programmes, exemptions must be time-bound and traceable or they become permanent bypasses that undermine the control itself.
• Policy Simulation: Policy simulation is the practice of making malicious instructions look like legitimate governance text, such as configuration files or rules. It works by exploiting the model’s tendency to trust structured context, which can override the protections that would normally apply to user requests.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.