How should teams apply mitigating controls when ERP segregation of duties cannot be enforced fully in the application security model?

Teams should treat Segregation of Duties as a risk-based control design problem, not a binary setting. Start with the ERP security model, then add compensating controls where gaps remain, such as approval workflows, restricted passwords, field controls, audit numbering, and post-transaction review. The goal is to reduce practical risk in the highest-impact processes, not chase theoretical perfection.

How to Treat SoD as a Control Design Problem, Not a Switch

When the ERP security model cannot enforce segregation of duties cleanly, the right question is not whether SoD exists, but where the residual risk lands. That means separating duties by process, role, system path, and approval authority, then layering controls around the highest-impact transactions. Compensating controls should narrow practical abuse opportunities, not pretend the application can do what it cannot.

The strongest implementations start by identifying which combinations are truly toxic in that ERP process, then deciding whether the risk is best reduced through pre-transaction approval, restricted access paths, or post-transaction detection. In practice, the control design is usually uneven, because some duties can be prevented in the workflow while others can only be reviewed after the fact.

SoD also depends on the surrounding identity and access model. If the same user or account can request, approve, and execute a transaction, the compensating design has to break that chain somewhere else, through role design, field-level restrictions, or independent review. IAM and IGA Basics is useful here because it frames SoD as part of broader access governance, not just a single ERP setting.

Which Compensating Controls Actually Reduce ERP SoD Risk

The most effective compensating controls are the ones that constrain either initiation, approval, or completion of the transaction. Approval workflows work best when approvers are operationally independent and the approval itself carries real accountability. Restricted passwords, shared-account limits, and field controls can help when the ERP cannot separate functions at the application layer, but they only work if teams can prove who used what access and why.

Audit numbering and sequence checks matter because they make missing, duplicated, or out-of-order transactions visible. Post-transaction review adds a second line of defense, especially for high-value activities such as vendor setup, payment release, journal posting, or master-data changes. The aim is to create a control stack that makes an unauthorized combination harder to complete and easier to spot when it does occur.

Segregation of Duties (SoD) Guide is directly relevant because it addresses compensating controls, toxic combinations, and extending segregation concepts to accounts that are not human users. That broader pattern matters when ERP workflows involve shared operational access, service accounts, or automation supporting finance processes.

For the application side of the control design, a verification standard helps teams avoid vague assurance. OWASP ASVS is useful as a companion reference for authentication, authorization, and access-control expectations that should be tested rather than assumed.

Where SoD Breaks Down in Practice and What Teams Should Watch

Most SoD failures come from exception paths, not the core workflow. Temporary access, emergency overrides, manual corrections, and privileged operations often bypass the controls that look strong on paper. If the control depends on people remembering to behave differently in edge cases, the design is too fragile.

Another common failure is overreliance on one compensating control, especially approval. An approval step does not help if the approver is too close to the process, the queue is automated, or the evidence is too coarse to distinguish legitimate business need from convenience. Review controls also lose value when the volume is high enough that reviewers only sample superficially.

IAM and IGA Basics reinforces the practical point that access governance only works when roles, entitlements, and reviews are designed around how the process actually runs. That is the same reason SoD cannot be treated as a compliance checkbox separated from entitlement design.

Risk and Threat Considerations

SoD gaps create fraud, error, and misuse exposure because they let a single actor complete incompatible steps in one business process. The risk is highest where the transaction has financial impact, changes master data, or creates downstream authority for later activity.

Failure mechanism: A weak ERP model, shared credentials, emergency access, or poorly designed exceptions can collapse initiation, approval, and execution into the same trust path, letting a user bypass intended checks.

Impact: That can produce unauthorized payments, concealed changes, weak auditability, and delayed detection, especially when compensating reviews are manual or inconsistent.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP ASVS	V8 — Authorization	SoD gaps are an authorization and access-control problem in ERP workflows.
Recommendation — Verify that transaction paths enforce authorization boundaries and independent approval checks.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Compensating SoD controls reduce excessive access and function overlap.
	AU-6 — Audit Review, Analysis, and Reporting	Post-transaction review and sequence checks rely on audit analysis.
Recommendation — Limit permissions so no user can complete conflicting ERP steps without oversight. Review ERP audit data for conflicting actions, overrides, and exception patterns.
CIS Controls v8	CIS-6 — Access Control Management	SoD compensation depends on controlling accounts, roles, and access paths.
Recommendation — Restrict conflicting access and review role assignments for toxic combinations.
ISO/IEC 27001:2022	A.5.15 — Access control	ERP SoD compensating controls are an access-control design issue.
Recommendation — Define and enforce access rules that prevent incompatible ERP duties.

Practitioner Guidance

What to prioritise: Start with the processes that have the largest financial, regulatory, or fraud consequence, then define which step must be independent and which step can only be reviewed after the fact. Do not spend the most effort on low-value role conflicts while leaving payment, vendor, or journal paths weak.

What to verify: Confirm that each compensating control has a named owner, an evidence trail, and a measurable review outcome. If an approval cannot show who approved, what they reviewed, and what exception justified it, it is not a strong compensating control.

Common mistake: Treating SoD as solved because the ERP role matrix looks clean. The real test is whether users can still complete the prohibited business outcome through overrides, indirect access, or unreviewed exception handling.

Practitioner takeaway: Good SoD design reduces practical abuse opportunity in the highest-risk flows, it does not require perfect application-level separation everywhere.