Segregation of duties in identity governance: closing access conflict gaps

At a glance

What this is: This is a checklist-driven SoD governance guide that argues access conflicts keep reappearing unless review, escalation, and provisioning are connected across critical business applications.

Why it matters: IAM and IGA teams need this because SoD breaks when entitlement decisions are made without a repeatable conflict-checking process, leaving fraud and compliance risk embedded in routine provisioning.

By the numbers:

• Incidents of fraud occur due to a lack of internal controls 32% of the time, according to the Association of Certified Fraud Examiners cited by Delinea.

Context

Segregation of duties is an internal control design pattern that prevents one person from holding conflicting responsibilities in a critical process. In identity governance terms, it is about detecting toxic access combinations before they are approved, inherited, or provisioned into business systems.

This article focuses on how SoD checklist design becomes operational in ERP, HCM, and CRM environments, where finance, HR, and revenue workflows can overlap. The governance problem is not whether organisations understand SoD in principle, but whether the process is repeatable enough to catch conflicts before they become normalised.

The article is grounded in enterprise control design rather than a single product feature, so the practical question for IAM and IGA teams is how to move SoD from a review activity to a preventive control.

Key questions

Q: What breaks when segregation of duties checks are handled outside the provisioning workflow?

A: When SoD checks sit outside provisioning, conflicts can be introduced before anyone notices, or approved later without full context. That creates delayed remediation, inconsistent enforcement, and audit exposure. Embedding SoD controls into the workflow helps stop risky access earlier, before it becomes operational access that must be unwound after the fact.

Q: Why do SoD conflicts keep recurring in ERP and HCM workflows?

A: They recur because the control is often documented once but not embedded into the access path. If business process owners, audit, and identity teams do not share the same ruleset and approval workflow, the same conflicting duties can be granted again even after a review finds them.

Q: How should IAM teams decide which access combinations need SoD rules?

A: Start with business processes that carry financial, operational, or regulatory risk, then identify the specific duties and approvals within each workflow. The right rule is the one that reflects a real process conflict, not a theoretical role overlap that does not change actual business risk.

Q: When should organisations move from detective SoD review to preventive controls?

A: They should move as soon as the same high-risk conflicts keep reappearing in review cycles or the review cadence is too slow to prevent exposure. At that point, the control has to shift upstream into provisioning so access is evaluated before it becomes active.

Technical breakdown

How SoD matrices map toxic access combinations

An SoD matrix is the control structure that translates business duties into access conflict rules. It starts with a process, such as vendor setup, payment approval, or inventory accounting, and maps the discrete tasks and approvals that should never sit in one profile at the same time. The ruleset is the core output: a defined list of conflicting entitlements that becomes the basis for review, escalation, and enforcement. Without that mapping, teams may see roles and permissions but not the business risk created by their combination.

Practical implication: build the matrix from business processes first, then use the resulting conflict rules to govern entitlement decisions.

Why manual SoD reviews keep the same conflicts reappearing

Manual SoD checks can identify conflicts, but they often do not change the provisioning path that created them. That creates a governance loop in which the same toxic combinations return in later reviews because the control is detective rather than preventive. Repeatability depends on cadence, ownership, documented evidence, and a clear escalation path when conflicts are found. In practice, SoD control maturity is less about one-off analysis and more about whether the workflow itself prevents the conflicting access from being granted again.

Practical implication: connect SoD review outcomes to provisioning and remediation workflows so the same conflict is not recreated after each review cycle.

How preventive SoD checks change identity governance

Preventive SoD moves the control point upstream into identity management and provisioning. Instead of discovering conflicts after access is live, the organisation evaluates whether the requested access would create a toxic combination before it is approved. That changes the programme from retrospective assurance to active risk gating, which is particularly important where business applications span finance, HR, and revenue workflows. This is where identity governance stops being a reporting exercise and becomes a control in the access path itself.

Practical implication: embed SoD evaluation into request and provisioning flows so risky access is evaluated before it enters production.

Threat narrative

Attacker objective: The objective is to exploit conflicting duties to commit fraud, conceal errors, or bypass financial and operational controls.

1. Entry occurs when a user accumulates permissions across business applications without a pre-provisioning SoD check, creating conflicting access in ERP, HCM, or CRM workflows.
2. Escalation follows when those conflicting duties let one identity both initiate and approve sensitive business actions, reducing the chance that fraud or error is caught early.
3. Impact emerges when the organisation discovers the toxic combination only during review, by which point the same control gap may already have been repeated across the access lifecycle.

Breaches seen in the wild

• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SoD fails when access review is detached from provisioning: The control assumption is that conflicts will be caught before they matter, but that assumption collapses when conflicting access can be granted first and assessed later. In that model, review becomes a record of failure rather than a prevention mechanism. The implication is that SoD must be treated as an access-path control, not a post-hoc audit activity.

The real control gap is repeatability, not awareness: Most organisations know which combinations are toxic, but many cannot apply that knowledge consistently across systems and teams. A checklist helps, but only if it is tied to ownership, cadence, evidence, and escalation. Practitioners should treat inconsistent execution as the failure mode, because that is where risk keeps reappearing.

Segregation of duties is now an identity governance problem as much as a finance control: ERP, HCM, and CRM systems are where entitlement decisions turn business process risk into access risk. That makes SoD a governance bridge between IAM, IGA, and audit, not just a compliance artefact. Teams that separate business control design from identity workflow design will keep rediscovering the same access conflict.

Preventive SoD is the decisive maturity shift: The article points to a shift from detective review to pre-provisioning evaluation, which is where control value compounds. Once SoD checks sit inside identity and provisioning workflows, the organisation can stop approving risk by default and start making access decisions with conflict awareness. That is the practical dividing line between a checklist and a control system.

What this signals

SoD becomes meaningful only when it is operationalised inside identity workflows: A checklist by itself documents conflict logic, but it does not stop a user from receiving toxic access again. The programme question for IAM and IGA teams is whether access decisions are made with SoD awareness at request time, or whether the control still depends on periodic human review after risk has already entered the environment.

Conflict detection should be treated as a lifecycle control, not a one-time compliance exercise: Once teams connect analysis, escalation, and provisioning, SoD starts behaving like a repeatable governance mechanism rather than an audit artefact. That shift is what lets organisations reduce exception handling and make access outcomes more predictable across business applications.

For practitioners

• Map critical business processes first Inventory the ERP, HCM, and CRM workflows that handle sensitive approvals, payments, or master data before writing any conflict rules.
• Build a conflict ruleset from duty combinations Document the specific access combinations that should never coexist in one user profile, then review them with application owners and audit.
• Tie SoD review to provisioning workflows Check SoD before access is granted so toxic combinations are blocked or routed for approval before they become active.
• Define escalation and remediation ownership Assign who changes access, who applies mitigating controls, and who signs off on accepted risk when a conflict is discovered.
• Track whether high-risk conflicts decline Measure review-to-review trends in high-risk conflicts to confirm that remediation is working and new risk is not being introduced.

Key takeaways

• Segregation of duties breaks down when toxic access combinations are discovered after provisioning instead of being blocked in the access path.
• The article ties recurring fraud risk to weak internal controls and cites 32% of fraud incidents as linked to that gap.
• The practical answer is to connect SoD rules, escalation, and provisioning so review outcomes change future access decisions.

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.
• SoD Matrix: An SoD matrix is a structured map of incompatible roles, entitlements, and approval paths. It shows which combinations of access must never exist in the same identity or workflow. In practice, it becomes the reference point for detecting toxic access across financial, administrative, and privileged processes.
• Toxic Access Combination: A toxic access combination is a set of permissions that becomes dangerous when granted together, even if each entitlement looks acceptable on its own. In identity governance, these combinations matter because they can enable misuse, separation-of-duties failures, or broader compromise.
• Mitigating control: A mitigating control is a compensating safeguard used when risky access cannot be eliminated. It may be a reconciliation, approval workflow, detective report, or exception review. In practice, the control is only meaningful if a team can prove it executed for the relevant users and period.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.