Separation of duties gaps still drive fraud and compliance risk

At a glance

What this is: This is a separation of duties analysis showing that conflicting access across finance and IT processes creates avoidable fraud and compliance exposure.

Why it matters: It matters because IAM, IGA, and PAM teams must detect and prevent entitlement combinations that let one identity carry out incompatible actions across critical workflows.

👉 Read Saviynt's analysis of separation of duties controls and application access governance

Context

Separation of duties, or SOD, is a control design that prevents one identity from controlling incompatible steps in the same business process. In practice, it is used to reduce fraud, errors, and conflicts of interest where access rights can affect financial, operational, or reputational outcomes.

The governance gap is usually not the policy itself but the way entitlements accumulate across applications and roles. When one user or service account can both request and approve sensitive actions, the control boundary fails even if each permission looks acceptable in isolation.

Key questions

Q: How should security teams implement segregation of duties across multiple business applications?

A: Start by mapping the business actions that must never sit in the same identity across ERP, finance, HR, CRM, and workflow systems. Then translate those actions into conflict rules that are checked whenever access changes, not only during audit season. The goal is to catch toxic combinations before they become operationally usable.

Q: Why do conflicting entitlements create so much fraud risk?

A: Because they remove the independent check that prevents one identity from completing both sides of a sensitive transaction. If the same person or account can create and approve, submit and release, or request and authorise, the control no longer constrains behaviour. Fraud, error, and audit failure become much easier to hide.

Q: How do organisations know if SOD controls are actually working?

A: Look for two signals: risky requests being blocked before access is granted, and existing violations being found and remediated on a recurring schedule. If violations only appear after incidents or audits, the control is reactive. Effective SOD programmes show both low conflict rates and fast exception handling.

Q: Who should be accountable when SOD violations involve service accounts?

A: The same identity governance owners who manage human access should own the policy outcome, but operational accountability may sit with application, finance, or platform teams depending on the workflow. If a service account can trigger a critical business step, it belongs in the SOD model and must be reviewed, approved, and remediated like any other identity.

Technical breakdown

How conflicting entitlements create SOD violations

SOD violations emerge when a single identity is granted permissions that should be segregated across process stages. In finance, that might mean creating and approving invoices. In IT, it could mean requesting access and approving access to the same sensitive system. The issue is not the action itself but the combination, because the combination removes the independent check that the control is meant to preserve. Cross-application environments make this harder because incompatible entitlements are often distributed across multiple systems and role models.

Practical implication: map toxic entitlement combinations across business processes, not just within individual applications.

Why detective and preventative analysis both matter

Preventative SOD checks stop risky access before it is granted, while detective controls surface violations that already exist. A mature SOD programme needs both because business roles change over time, exceptions get introduced, and historical access can remain hidden. Scheduled analysis and request-time policy checks each catch different failure modes. Without both, organisations either allow toxic access at provision time or discover it only after a control breach, audit exception, or suspected fraud event.

Practical implication: combine request-time blocking with recurring violation review and remediation workflows.

Cross-application SOD depends on shared policy logic

Cross-application SOD is more difficult than single-application rule enforcement because conflicting duties often span ERP, HR, finance, and access systems. The control must recognise that a harmless entitlement in one platform can become a risk when paired with access elsewhere. That is why rule sets, entitlement visibility, and workflow integration are central to effective governance. In practice, SOD becomes an identity governance problem rather than a point-tool problem.

Practical implication: align SOD rules, access review, and remediation across the systems where business conflicts actually arise.

NHI Mgmt Group analysis

SOD is a lifecycle governance problem, not just a policy rule. The article treats separation of duties as an access control question, but the real issue is whether identity governance can prevent incompatible rights from persisting across joiner, mover, and leaver events. That means the same identity can drift into conflict through role changes, exception handling, or manual remediation. Practitioners should treat SOD as an entitlement lifecycle control, not a static audit checkbox.

Cross-application conflict is where most SOD programmes lose precision. A single application may enforce clean segregation, yet the risk reappears when entitlements are combined across ERP, HR, and finance systems. That is why policy models must evaluate the full business process, not isolated permissions. The practical conclusion is that governance teams need process-aware visibility, not just system-by-system reviews.

Preventative and detective SOD controls solve different parts of the same problem. Preventative checks matter at request time, but detective analysis is still necessary because toxic access often already exists when the control is introduced. The article correctly points to both automated detection and remediation, which is the only sustainable way to manage entitlements at scale. Practitioners should expect SOD to be continuous, not periodic.

Conflicting access becomes fraud exposure when accountability collapses. SOD is fundamentally about preserving independent review, which is why it applies equally to human users and service accounts that can trigger sensitive business actions. Where an identity can both initiate and approve a critical workflow, the control objective has already failed. The implication is that IAM and IGA teams must govern effective authority, not just named permissions.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
• For a broader lifecycle lens, see NHI Lifecycle Management Guide for how identity governance changes when access must be provisioned, rotated, and removed consistently.

What this signals

Separation of duties is only as strong as the identity lifecycle behind it. If access changes are not recertified with process context, a clean control design can still devolve into conflicting authority over time. The governance lesson is that SOD belongs inside joiner-mover-leaver, access review, and exception management workflows, not outside them.

The next maturity step is process-aware entitlement governance, where identity teams validate whether a permission combination creates an actual business conflict instead of relying on technical role labels alone. That is where SOD stops being an audit artefact and becomes a living control.

For practitioners

• Inventory toxic entitlement combinations Build a business-process view of incompatible actions such as create and approve, request and approve, or submit and release across finance and IT workflows.
• Enforce request-time SOD checks Block or route access requests when the requested entitlement would create a conflicting duty with the user's existing access across connected applications.
• Run recurring detective reviews Schedule periodic analysis to uncover previously unknown violations, then route each case to remediation, mitigating controls, or access revocation.
• Extend governance to service accounts Include non-human identities in the same SOD model when they can submit, approve, or trigger business actions that affect financial or operational controls.
• Track remediation outcomes by control type Measure how many violations are blocked upfront versus found later, and use that split to identify weak policy design, stale roles, or missing integrations.

Key takeaways

• The article shows that SOD failures come from conflicting access, not from a lack of policy language.
• Cross-application permissions and changing roles make detection and remediation as important as prevention.
• Organisations that govern SOD continuously across users and service accounts reduce fraud, audit, and operational exposure.

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.
• Toxic Entitlement Combination: A toxic entitlement combination is a set of permissions that becomes risky when held together, even if each permission seems acceptable on its own. Auditors look for combinations such as request and approve, create and certify, or administer and review, because they create self-reinforcing control failure.
• Detective SOD Control: A control that finds segregation violations after they already exist. It is used to surface hidden conflicts, prioritize remediation, and confirm whether preventative policy checks are working across applications and identity types.
• Preventative SOD Control: A control that blocks or routes an access request before the conflicting permission is granted. It is strongest when it evaluates the request against existing entitlements and business process rules in real time.

What's in the full article

Saviynt's full blog covers the operational detail this post intentionally leaves for the source:

• Rule logic for detecting conflicting duties across ERP and finance applications
• Workflow examples for preventive rejection versus detective remediation
• Workbench filtering and review flow details for auditors and SOD administrators
• Integration points for application access governance across common enterprise systems

👉 Saviynt's full post covers SOD rules, detective workflows, and cross-application violation handling.

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 identity security programme, it is worth exploring.