Notifications
Clear all
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.
NHIMG editorial — based on content published by SafePaaS: Segregation of duties and ERP financial control breakdowns
Questions worth separating out
Q: What breaks when segregation of duties is only checked at the role level?
A: Role-level checks miss the way separate permissions combine into a harmful transaction path.
Q: Why do cross-application SoD conflicts create more risk than single-system conflicts?
A: Cross-application conflicts are harder to detect because each platform sees only part of the workflow.
Q: How do organisations know whether SoD controls are actually working?
A: SoD is working when no identity can complete a financially material transaction chain without independent oversight, and when entitlement reviews catch conflicts before they reach production use.
Practitioner guidance
- Map SoD at the transaction level Trace the full procure-to-pay, order-to-cash, and record-to-report paths so you can identify combinations that let one identity originate, approve, and complete the same financial flow.
- Correlate entitlements across systems Join access data from ERP, procurement, finance, and admin tools so cross-application conflicts such as vendor creation plus payment approval are visible in one review cycle.
- Remove access as part of SoD enforcement Treat offboarding and temporary access expiry as control actions, not hygiene tasks, so one-time exceptions do not become permanent financial authority.
What's in the full article
SafePaaS's full article covers the operational detail this post intentionally leaves for the source:
- Specific procure-to-pay and record-to-report conflict examples that map directly to ERP control design.
- The automation approach for detecting SoD conflicts across SAP, Coupa, and other finance platforms.
- A downloadable process guide for teams that need to operationalise segregation checks in daily workflows.
👉 Read SafePaaS's analysis of segregation of duties automation in ERP finance →
Segregation of duties in ERP: where do controls break down?
Explore further
25/06/2026 7:17 am
Segregation of duties is failing at the transaction path, not the role definition. ERP governance often treats access as a static permission set, but the risk lives in the sequence of actions an identity can perform. When vendor creation, payment approval, and posting rights can be combined across workflows, the control has already failed before any transaction is executed. Practitioners should stop treating SoD as a role catalog exercise and start treating it as transaction-chain containment.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who is accountable when the same identity can request and approve access?
A: Accountability sits with the identity governance and control owners who allow request and approval to collapse into one path. In audited environments, that weakness can also trigger SOX exposure because it undermines logical access controls. The fix is separation of duties in both process design and system enforcement.
👉 Read our full editorial: Segregation of duties at scale in ERP finance and access controls
