They recur because the control is often documented once but not embedded into the access path. If business process owners, audit, and identity teams do not share the same ruleset and approval workflow, the same conflicting duties can be granted again even after a review finds them.
Why the Same SoD Conflict Keeps Reappearing
sod conflict recur when the rule exists as a review artifact, not as an enforced control point. In ERP and HCM, that usually means the workflow can still grant the same toxic combination because the approval path, role design, and exception handling are not aligned to the rule itself.
The practical issue is not that teams cannot identify conflicts. It is that the access path still allows them to be reintroduced through role changes, delegated approvals, emergency access, or inherited entitlements after the review is closed.
When a SoD conflict is treated as a one-time finding instead of a standing policy object, the environment quietly resets to the same risk state every time someone provisions access from a different entry point.
Where ERP and HCM Workflows Break Down
ERP and HCM systems often spread access decisions across business owners, HR events, ticketing, identity governance, and application admin functions. If each layer uses a slightly different interpretation of the rule, the conflict check becomes inconsistent even when everyone believes the process is working.
That inconsistency is especially common when one workflow controls hire, move, and leave events, while another controls privileged business roles or temporary exceptions. A user can be clean at onboarding and still become conflicting later through a role add-on, bypass approval, or manual fix.
In mature environments, the real control question is whether the SoD rule is evaluated at every access transition that can change risk, not just during periodic certification. If the rule only lives in review notes or policy text, it is easy for an access path to drift back into the same violation.
How to Stop Reintroducing the Same Conflict
The fix is to make SoD part of the entitlement logic, not just the audit logic. That means the conflicting duty set should be defined in the same ruleset used by provisioning, exception handling, and recertification, so the control is enforced where access is actually granted.
It also helps to separate ownership clearly: process owners define the business conflict, audit validates the evidence of control operation, and identity or access teams implement the rule in the workflow. When those groups work from different definitions, the system will continue to reissue the same access under a different label.
A useful design test is whether a reviewer can explain why an approved exception is safe, not only why it was approved. If the answer depends on tribal knowledge, a spreadsheet, or a manual note that never reaches the provisioning system, the conflict will keep recurring.
Risk and Threat Considerations
Recurring SoD conflicts create a compounding control failure, because each regrant increases the chance that conflicting duties will eventually be exercised together. In ERP and HCM, that can weaken financial integrity, payroll accuracy, and fraud prevention at the exact point where reviewers assume the issue was already closed.
Failure mechanism: the control is reviewed out of band from the workflow that creates access, so a later role change, emergency grant, or exception path reintroduces the same toxic combination without a fresh rule evaluation.
Impact: repeated violations reduce trust in certification results, widen the blast radius of privileged access, and make compensating controls harder to defend because the underlying design flaw was never removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly addresses conflicting duties and enforced role separation in access workflows. |
| AC-6 — Least Privilege | SoD conflicts recur when users receive more access than their job requires or retain excess rights. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Recurring SoD issues are often only visible through review of access and exception evidence. | |
| Recommendation — Enforce AC-5 so provisioning and approvals cannot reissue conflicting duties through alternate paths. Apply AC-6 to remove excess entitlements that enable recurring toxic combinations. Use AU-6 to review access events and exception patterns that recreate the same SoD violation. | ||
| ISO/IEC 27001:2022 | A.5.3 — Segregation of duties | Annex A segregation controls map directly to preventing incompatible duties in business workflows. |
| A.5.15 — Access control | Access control governance determines whether SoD rules are embedded into entitlement decisions. | |
| Recommendation — Define and enforce segregation rules across ERP and HCM approval paths. Embed SoD checks into access control decisions rather than review-only processes. | ||
Practitioner Guidance
What to verify: confirm that the SoD rule is enforced at provisioning, modification, and exception approval, not only during periodic review. The test is simple: if the same conflict can be recreated from a different workflow step, the control is incomplete.
Decision rule: if the exception path can override the conflict check, treat that path as part of the control design and require explicit approval, evidence retention, and expiry. If it cannot be governed that way, the exception is functionally a permanent bypass.
What good looks like: one shared rule defines the conflict, one workflow enforces it, and one set of owners can explain every permitted exception. If you need separate interpretations for audit, HR, and application support, the control will keep regressing.
Practitioner takeaway: recurring SoD failures are usually a workflow design problem, not a detection problem, so fix the grant path first and use review evidence only to confirm that the control is actually embedded.