Why do segregation of duties issues become harder to manage as ERP systems are customised?

ERP flexibility often expands access paths faster than control design keeps up. Custom roles, exceptions, and support workflows can blur who can request, approve, and execute sensitive actions. As complexity rises, manual review becomes slow and unreliable, so organisations need repeatable governance around access design, not just periodic audit checks.

Why This Matters for Security Teams

segregation of duties becomes harder in customised ERP environments because the system stops behaving like a standard control environment and starts behaving like a business-specific privilege map. Each new role, workflow exception, approval path, or integration can create a new way to request, approve, and execute the same sensitive transaction. That makes SoD reviews less about checking a fixed rule set and more about understanding how access really works across finance, procurement, HR, and operations.

This matters because control intent can be lost during customisation. A role that looked safe in design may become risky once it inherits transaction variants, workflow bypasses, or delegated support access. NIST’s Cybersecurity Framework 2.0 is helpful here because it reinforces governance, not just technical enforcement. NHIMG’s Top 10 NHI Issues also highlights how privilege sprawl and weak lifecycle control create cumulative risk as environments expand. In practice, many security teams discover SoD failures only after a custom workflow or emergency access path has already been used to complete an unauthorised end-to-end transaction.

How It Works in Practice

In a standard ERP, SoD is usually modeled around a manageable set of duties such as creating vendors, approving payments, and reconciling accounts. Customisation complicates that model in three ways. First, the same business outcome can be reached through multiple transaction codes, API calls, batch jobs, or workflow exceptions. Second, custom roles often inherit permissions from base templates, so a control gap in one inherited entitlement can cascade across many users. Third, support teams frequently receive broad temporary access to resolve incidents, and those exceptions can become de facto permanent if revocation is not automated.

Current guidance suggests treating SoD as a design-time and runtime problem. At design time, access models should be reviewed whenever a custom object, workflow branch, or integration is introduced. At runtime, sensitive actions should be logged, monitored, and compared against an approved duty matrix. The NIST CSF 2.0 governance and risk functions support this kind of repeatable control ownership, while NHIMG’s Lifecycle Processes for Managing NHIs reinforces the need for lifecycle discipline when privileges, secrets, and delegated access must all be tracked together.

• Map duties to business events, not just ERP roles, so custom workflows do not bypass the control matrix.
• Review inherited entitlements after every major configuration change, transport, or integration release.
• Use time-bound exceptions for support access and require automatic revocation after the ticket closes.
• Correlate approvals, execution, and reconciliation logs to identify one person or one role completing conflicting steps.

These controls tend to break down when organisations allow custom development teams to deploy access changes faster than governance can re-certify the resulting duty conflicts.

Common Variations and Edge Cases

Tighter SoD controls often increase operational overhead, requiring organisations to balance transaction integrity against business speed and support burden. That tradeoff becomes sharper in heavily customised ERP estates, where legitimate business exceptions can look identical to risky privilege combinations until the full workflow context is reviewed.

One common edge case is emergency access. Best practice is evolving, but current guidance suggests that break-glass access should be separately governed, heavily logged, and explicitly excluded from ordinary role design. Another is third-party or shared service administration, where a provider may need broad technical access but should still be prevented from completing conflicting business steps. A third is automation: bots and service accounts can trigger approvals, postings, or reconciliations at machine speed, which means SoD cannot rely on human review alone. NHIMG’s Regulatory and Audit Perspectives is useful when documenting why custom access paths need evidence, not assumptions.

Where teams struggle most is in environments with many local country customisations, merged ERP instances, or long-lived compensating controls. In those cases, the control objective remains the same, but the enforcement method usually shifts from static role checks to continuous review of actual execution paths.

Related resources from NHI Mgmt Group

• Why does authorization become harder as agentic AI and autonomous systems take on more access decisions?
• When does segregation of duties enforcement become critical in enterprise application governance?
• How can organizations manage unauthorized agents in their systems?
• Why does SoD become harder in customised ERP role models?