TL;DR: Segregation of duties examples across accounting, payroll, IT, healthcare, and ERP systems show that fraud and error usually appear when one person can both create and approve the same action, according to SecurEnds. The practical lesson is that clear role splits and continuous conflict checks matter more than policy language alone.
At a glance
What this is: This guide uses practical examples to show how segregation of duties breaks down when one role can initiate and approve the same transaction or access change.
Why it matters: It matters because IAM, IGA, and PAM teams need controls that prevent fraud, cover audit requirements, and expose risky overlaps before they become repeatable abuse paths.
Context
Segregation of duties is a control design problem, not just a policy statement. When one person can both create and approve the same action, the control boundary disappears and fraud, error, or concealment become easier.
The article uses accounting, payroll, IT, healthcare, and ERP scenarios to show how overlap creates practical weakness. For identity and access programmes, the question is not whether duties are named separately on paper, but whether access, approval, and review are actually separated in day-to-day operations.
That makes this topic relevant to IAM, IGA, and PAM teams as much as finance or audit teams. If the same identity can initiate, authorise, and conceal an action, the programme has a governance gap, not a documentation gap.
Key questions
Q: What breaks when the same identity can both create and approve a transaction?
A: The control stops being preventive and becomes self-authorising. Fraud, error, and concealment become easier because the same person can move a transaction through the full lifecycle without independent challenge. The strongest fix is to remove that overlap at the entitlement level, not just ask managers to watch more carefully.
Q: Why do SoD conflicts matter more in complex ERP environments?
A: Because risk no longer sits inside one application. It emerges when access, workflow permissions, and transaction rights combine across systems, which is exactly how users and non-human identities can move from ordinary access to a financial control failure.
Q: How do organisations know whether segregation of duties is actually working?
A: Segregation of duties is working only if no identity can combine enough permissions to complete the full banking workflow without an independent check. The test is not whether a policy exists, but whether cross-system role combinations are blocked before they create an end-to-end abuse path. If combinations are still possible, the control is only documented, not enforced.
Q: What should auditors and IAM teams check first when SoD gaps appear?
A: Start with the highest-risk workflows, such as payments, payroll, vendor setup, and privileged admin actions. Then check whether any role can both start and approve the same event, or hide the evidence after the fact. That reveals the control gap faster than reviewing every role in the organisation.
Technical breakdown
Why overlapping approval and creation paths break control design
Segregation of duties fails when a workflow lets the same role perform both the initiating and approving steps of a transaction. That creates a single trust boundary where fraud, error, or hidden policy violations can pass unchecked. In practice, the control is strongest when system design prevents the same identity from holding conflicting entitlements, rather than relying on after-the-fact review. This applies equally to financial workflows and access governance, because the real risk is concentrated authority, not the business function itself.
Practical implication: map every high-risk workflow to the identities that can both create and approve, then remove those overlaps at the access layer.
How access review logic differs from simple role naming
Naming roles is not the same as enforcing SoD. A clerk, manager, or controller label only matters if the underlying permissions prevent one identity from carrying conflicting powers across systems. This is why SoD matrices are useful: they translate business duties into explicit control conflicts that can be tested. Without that translation, organisations often believe separation exists because job titles differ, while the actual permissions still allow the same person to complete the full transaction path.
Practical implication: validate SoD by entitlement and transaction path, not by job title or org chart.
Why ERP and shared-service environments surface the worst conflicts
ERP systems and shared-service teams compress many business steps into one platform, which makes conflicts easier to hide and harder to spot manually. Vendor creation, journal entry, payment approval, and reconciliation can sit close together in the same workflow, so a small permission mistake creates broad fraud potential. The technical issue is not the software alone but the concentration of authority across the workflow. That is why SoD controls in ERP environments need continuous detection, not occasional sampling.
Practical implication: monitor ERP privilege combinations continuously and treat conflicting access as a live exception, not a quarterly audit finding.
NHI Mgmt Group analysis
Segregation of duties is really a permission-boundary problem, not a policy problem. The article shows that fraud and concealment appear when one identity can initiate and approve the same action. That means the real control failure is not missing documentation but overlapping authority across business workflows. Practitioners should treat SoD as an entitlement design issue, not a compliance checkbox.
The most useful SoD test is whether a control can be bypassed without changing roles. The examples in accounting, payroll, IT, and ERP all point to the same pattern: if one person can complete the workflow end to end, the control is already weakened. For identity teams, that makes conflict detection and access review complementary, not interchangeable. The programme has to measure effective separation, not declared separation.
SoD matrices become valuable only when they reflect real transaction paths. A role chart that says one team enters and another approves is only a starting point. What matters is whether the underlying system enforces that split across all relevant steps, including overrides, reconciliations, and log review. The practitioner conclusion is simple: control design must follow the workflow, not the department name.
ERP and shared-service models create a high-density conflict environment. The article’s ERP examples show why broad system roles are especially dangerous when they bundle vendor setup, payment, and approval capabilities. That concentration does not just increase fraud risk, it also makes audit evidence fragile because exceptions are harder to isolate. Practitioners should treat enterprise applications as control aggregation points, not just business tooling.
Continuous conflict detection matters because SoD violations are often structural, not exceptional. The guide’s automation section points to a deeper truth: organisations that rely on annual reviews discover problems too late. Once a role combination exists in production, it can be reused repeatedly until someone notices. The implication is that SoD governance belongs in access lifecycle controls, not only in audit reporting.
What this signals
SoD only works when the control is enforced in permissions, not just in policy language. If the same account can create, approve, and reconcile, then the governance model has already failed at design time. IAM and IGA teams should treat this as a lifecycle and entitlement issue, not an annual audit exercise.
Continuous conflict detection is the real operational difference between paper compliance and working control. Manual review catches too little, too late, especially in ERP and shared-service environments where duties overlap by design. The programme signal is clear: if exceptions are only found after the quarter closes, the control is not operating at the pace of the business.
For practitioners
- Map conflicting duties to actual entitlements Build SoD rules around the permissions that let one identity both initiate and approve high-risk actions, especially in finance, HR, and ERP systems.
- Separate approval from record creation Block the same user from entering invoices, setting up employees, or creating vendors and then approving the related payment or disbursement.
- Continuously check for role overlap Run automated conflict detection against active accounts so access changes that create SoD violations are flagged before they are reused in production.
- Review audit visibility for privileged roles Ensure the people who can create accounts, approve transactions, or change key records cannot also suppress the logs used to prove those actions.
- Maintain a live SoD matrix Keep a current matrix that ties business functions to creators, approvers, and reviewers so auditors can verify the split without reconstructing it from scratch.
Key takeaways
- Segregation of duties fails when a single identity can both start and approve the same action, because the control boundary collapses into self-authorisation.
- The article’s examples show the same pattern across accounting, payroll, IT, healthcare, and ERP systems, which is why SoD conflicts should be treated as a live governance issue.
- Continuous conflict checks and entitlement-based role design are the controls most likely to limit fraud, concealment, and audit findings.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | SoD is fundamentally about who can hold conflicting permissions across workflows. |
| Recommendation — Apply PR.AA-05 to prevent any one identity from holding incompatible approval and execution rights. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | SoD conflicts arise when privilege accumulation lets one user control too much of a process. |
| Recommendation — Use AC-6 to remove unnecessary privileges that allow one account to both create and approve actions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle and role assignment drive the overlaps described in the article. |
| Recommendation — Use CIS-5 to review role assignments and revoke account combinations that create SoD conflicts. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access Rights | The article centres on ensuring access rights are separated across duties and reviewable. |
| Recommendation — Apply A.5.18 to keep access rights aligned with job duties and separate conflicting permissions. | ||
| SOC 2 (AICPA) | CC6.2 — The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events. | SoD evidence supports access control and auditability expectations in vendor assurance contexts. |
| Recommendation — Use CC6.2 to document and test that conflicting duties are blocked across sensitive workflows. | ||
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.
- Conflicting Access: Conflicting access occurs when one account or role holds permissions that should be separated because they create a control bypass. The problem is structural, not personal, and it often appears when role design or provisioning rules are too broad.
- Context Gap: The context gap is the distance between a rule that looks correct on paper and the real meaning of a request inside an AI workflow. It appears when language changes meaning through history, sequence, or social engineering, and it is one reason fixed filters struggle with agentic abuse.
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.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org