Segregation of duties in identity governance: closing access conflict gaps

At a glance

What this is: This is a practical guide to building an segregation of duties checklist that maps critical business processes, identifies toxic access combinations, and defines how to review and remediate conflicts.

Why it matters: It matters because IAM, IGA, and PAM teams need SoD controls that work across human access and system-managed provisioning, not just during audit season.

By the numbers:

• incidents of fraud occur due to a lack of internal controls 32% of the time

👉 Read Delinea's segregation of duties checklist for internal controls

Context

Segregation of duties is the practice of splitting a critical process so no single person can create, approve, and complete a high-risk transaction. In identity governance terms, it is one of the clearest ways to prevent privilege concentration from turning into fraud or control failure across ERP, HCM, CRM, and related business applications.

The problem is not the concept itself, but the operationalisation. Many teams can name SoD conflicts, yet still struggle to keep rules, reviews, and provisioning aligned as access changes over time. That is why SoD belongs inside identity lifecycle governance, not as a one-off compliance exercise.

Key questions

Q: How should teams build an effective segregation of duties checklist?

A: Start with the business processes that create the most fraud or control risk, then map the duties, approvals, and entitlements involved in each process. Turn those mappings into a ruleset of toxic access combinations, define who reviews exceptions, and attach the checklist to provisioning and review workflows so it is used consistently, not only during audits.

Q: Why do segregation of duties conflicts still appear after periodic reviews?

A: Because periodic reviews only see the access state that exists at the moment of review. If roles, approvals, or transaction paths change between cycles, conflicts can reappear before anyone notices. The gap closes when SoD rules are enforced in provisioning and lifecycle workflows rather than documented after the fact.

Q: What do security and compliance teams get wrong about segregation of duties?

A: They often treat SoD as a policy document instead of a control that must be operationalised across business applications and identity processes. A list of prohibited combinations is not enough unless the organisation can enforce it, escalate exceptions, and prove that remediation happened.

Q: Who should own remediation when an SoD conflict is found?

A: Ownership should sit with the business application owner, supported by compliance, security, or IT as needed. The key is that someone must be accountable for either changing access, applying a mitigating control, or documenting accepted risk, and that decision must be retained as evidence.

Technical breakdown

SoD matrices and toxic access combinations

An SoD matrix maps business tasks to the entitlements that enable them, then flags combinations that should never sit together in one profile. The matrix becomes the ruleset for identifying toxic access, such as creating vendors and paying vendors, or ordering inventory and accounting for it. In practice, the value comes from translating business process steps into access combinations that auditors, application owners, and IAM teams can all evaluate consistently.

Practical implication: Use a shared ruleset so access reviews can spot conflicting entitlements before they are provisioned.

Preventive SoD checks in provisioning workflows

Traditional SoD is often detective, meaning conflicts are found after access exists. A preventive model pushes checks into identity management and provisioning so the request can be blocked or escalated before entitlement is granted. That changes SoD from periodic review to policy enforcement, which is especially important where ERP or finance workflows create rapid, high-value transaction paths.

Practical implication: Embed SoD validation in provisioning and approvals so toxic combinations are stopped at request time.

Escalation, remediation, and evidence for audit

SoD only works when teams define what happens after a conflict is found. The article points to three outcomes: change access, apply a mitigating control, or accept and document the risk. The governance challenge is not only remediation, but proving that the review happened, the decision was owned, and evidence was retained for leadership, audit, and compliance purposes.

Practical implication: Document ownership, remediation choice, and evidence capture in the same workflow that finds the conflict.

NHI Mgmt Group analysis

SoD is an access governance control, not just a finance control: the article shows how toxic combinations emerge when business processes span multiple applications and no one owns the full entitlement picture. That is an identity problem because the risk sits in who can both initiate and complete a sensitive transaction. Practitioners should treat SoD as part of broader identity governance, not as a standalone audit checklist.

Repeatable SoD matters because manual review does not scale: once a ruleset has to be rebuilt every cycle, control quality depends on institutional memory rather than policy. The article correctly pushes toward a matrix and structured workflow because identity controls lose value when they cannot be reproduced consistently across systems. Practitioners should standardise the ruleset before they standardise the review cadence.

Preventive SoD only works when provisioning and governance are connected: moving checks upstream changes the control from finding problems to stopping them. That is the right direction for IAM and IGA teams, because conflicts are cheapest to handle before access becomes active. Practitioners should integrate SoD logic into request, approval, and entitlement paths rather than rely on retrospective review.

Identity lifecycle is where SoD either holds or fails: the checklist implicitly assumes that access decisions will be re-evaluated when roles, duties, or processes change. That assumption fails when entitlements drift faster than review cycles, creating a standing conflict window that audit can see but not prevent. The implication is that lifecycle governance must carry SoD rules forward, not simply record them after the fact.

Standards pressure is increasing on SoD evidence quality: regulations and control frameworks expect more than policy statements. They require demonstrable oversight, exception handling, and traceable decisions tied to access outcomes. Practitioners should make SoD evidence part of the access record so compliance is generated by process, not assembled after the review.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That lifecycle gap is why teams should pair SoD with the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs when access moves faster than review.

What this signals

Privilege concentration is the real SoD pressure point: if nearly all non-human identities already carry excessive privileges, then SoD failures are rarely isolated anomalies. They are a symptom of access design that allows incompatible duties to accumulate in the same profile, which makes lifecycle governance and entitlement design inseparable.

The next maturity step is not more spreadsheet review. It is connecting SoD rules to identity lifecycle controls, so access combinations are checked at request time, revalidated when duties change, and retired when the underlying business role ends.

Teams that still rely on quarterly reconciliation will keep finding conflicts after the fact. The programme signal to watch is whether exception handling, provisioning controls, and audit evidence are generated from the same workflow, not assembled separately.

For practitioners

• Define the SoD ruleset by process first Map high-risk workflows such as accounts payable, purchasing, and inventory handling before you write entitlement rules. That keeps the matrix anchored in business operations rather than in application silos, and it makes toxic combinations easier for auditors and owners to validate.
• Embed SoD checks in access requests Move SoD validation into identity management and provisioning flows so conflicting access is stopped before it is granted. Where you cannot block the request, force explicit approval and record the reason for the exception.
• Assign clear remediation ownership Name the business application owner, compliance lead, or security team member who will resolve or document each conflict. The control fails when the review finds a problem but no one is accountable for closing it.
• Track conflict trends by risk level Measure high-risk, medium-risk, and low-risk conflicts separately so you can see whether remediation is reducing the most dangerous exposures. If the high-risk count does not fall over successive reviews, the programme is not changing the underlying access model.

Key takeaways

• Segregation of duties is an identity governance control that prevents one actor from combining incompatible duties inside a critical business process.
• The strongest signal in the source is that fraud and control failure persist when access reviews stay detective instead of being embedded in provisioning and lifecycle workflows.
• Practitioners should connect SoD rules to entitlement design, remediation ownership, and evidence capture if they want the control to scale beyond audit checklists.

Key terms

• Segregation of Duties: Segregation of Duties is a control that splits a sensitive process into separate tasks so one identity cannot initiate, approve, and complete the same risky action. In identity governance, it reduces fraud and error by preventing toxic combinations of access from living in one user profile.
• SoD Matrix: An SoD matrix is a mapping of business tasks, application entitlements, and incompatible access combinations. It turns process knowledge into a repeatable control structure that helps IAM, audit, and application owners identify conflicts before they become operational risk.
• Toxic Access Combination: A toxic access combination is a set of permissions that creates unacceptable risk when held by the same identity. It matters because the risk usually appears only when entitlements are considered together, not in isolation, which is why matrix-based review is essential.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, secrets management, and workload identity. If you are responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by Delinea: Segregation of Duties checklist for robust internal controls. Read the original.