Topic starter
24/06/2026 10:34 pm
TL;DR: Segregation of duties in modern ERP environments fails less because policies are missing than because privilege creep, role-level review, and cross-application conflicts let a single identity accumulate end-to-end transaction power, according to SafePaaS. The control problem is structural: finance and access governance break when review models cannot follow transaction paths across systems.
Editorial analysis by NHI Mgmt Group, based on content published by SafePaaS: “Common Segregation of Duties Conflicts (And How to Fix Them)”.
Key questions
Q: What breaks when segregation of duties is the only control in place?
A: SoD blocks some toxic combinations, but it does not clean up stale, unused, or orphaned access.
A: These issues persist when access is granted for convenience, then left in place as roles, projects, and staff changes accumulate.
Q: How do security teams know if SoD controls are actually working?
A: SoD controls are working only if live access state matches the approved separation model across systems.
Practitioner guidance
- Map SoD to transaction paths Trace the full financial workflow from master-data change through approval and settlement, then mark every identity that can influence more than one step in the chain.
- Test cross-application toxic combinations Run SoD analysis across SAP, Coupa, Salesforce, NetSuite, and similar systems together so distributed conflicts are visible before certification.
- Re-certify access against process outcomes Review whether an identity can still create, approve, and complete a materially sensitive transaction, not whether the person still matches the original role title.
Bottom line: SoD breaks in ERP when one identity can combine permissions across procurement, finance, and approvals into a full transaction path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 7:17 am
SoD in ERP is a transaction-containment problem, not just an access policy problem. The article shows that the decisive failure mode is the gap between permission review and financial workflow reality. A role can look acceptable while the actual combination of entitlements still permits vendor creation, payment approval, or journal manipulation. That means practitioners should treat SoD as lifecycle governance over transaction power, not as a static role-design exercise.
A question worth separating out:
Q: Who should own Segregation of Duties automation across finance, IT, and application teams?
A: SoD automation should be jointly owned, with finance, IT, internal audit, compliance, legal, department managers, data owners, business operations, and executive leadership all contributing. The article makes clear that no single team can implement strong internal controls alone. Application owners remain responsible for monitoring access in their systems, while IT and risk teams need shared governance for the broader control program.
👉 Read our full editorial: Segregation of duties at scale in ERP finance and access controls