What breaks when segregation of duties is not separated from approval workflows?

What actually breaks when SoD is only treated as a permission rule?

The control stops being about who can perform conflicting actions across the full business process and becomes a narrow access check on a single account or role. That is where the governance failure starts: request, approval, and fulfilment can still be concentrated in one path if the workflow is not designed to prevent self-approval, override, or routed fulfilment by the same actor.

SoD works when the organisation defines the conflict at the process level, not just the entitlement level. If the workflow itself can carry the same requestor through approval and execution, the control may look present in an access review while still allowing a prohibited combination in practice.

That is why SoD is best understood as a governance constraint on business action, not only a role design exercise. The permission model matters, but it is only one layer of the control objective.

Why workflow separation matters more than a toxic entitlement list

A toxic combination list can catch obvious static conflicts, but it will miss dynamic paths where the same person can trigger, approve, and complete the same change through different steps or systems. In other words, a clean entitlement catalog does not prove that the approval chain is independent.

This is especially visible in request systems, ticketing flows, ERP approvals, and emergency access processes. If approvals are delegated, auto-routed, or fulfilled by an operator who can also influence the request, the organisation has preserved a formal workflow but broken the intended separation.

To make SoD effective, teams need to map which decisions are independent, which are merely queued, and which can be overridden. The question is not only “can this user hold both permissions?” but also “can this user control both sides of the control point?”

For a broader identity and access view, IAM and IGA Basics explains why access governance must cover entitlements, reviews, and ownership together, while the Segregation of Duties (SoD) Guide shows how to turn conflict rules into enforceable control design rather than policy text.

How SoD failures show up in operations and audits

When SoD is not separated from approval workflows, the most common symptom is that controls pass on paper but fail under process walkthroughs. Auditors and control owners may see role restrictions or review evidence, yet a live transaction path still allows the same individual to influence the outcome end-to-end.

That creates weak evidence quality, because the organisation can no longer show that the approver was truly independent from the requester or fulfiller. It also makes compensating controls harder to defend, since the exception is no longer a rare edge case but a structural design issue.

This is where the control gap becomes visible in incidents: fraud, unauthorized changes, and inappropriate access can be executed without requiring a dramatic entitlement escalation. The workflow itself becomes the bypass.

Risk and Threat Considerations

When SoD is collapsed into permissions alone, the main risk is hidden privilege concentration across the workflow. A person may not hold an obviously toxic entitlement, yet still be able to shape the request, approve it, and complete the action, which creates control failure without obvious alerting.

Failure mechanism: The control treats static access as the whole problem, so routing, delegation, override, and fulfilment paths are left unchecked and the same actor can influence multiple control points in one business process.

Impact: Organisations lose independent approval integrity, weaken audit evidence, and expose themselves to fraud, unauthorized changes, and false assurance that segregation exists.

Practitioner Guidance

What to verify: Test the end-to-end transaction path, not just the role matrix. Confirm that requestor, approver, and fulfiller are independently constrained across the live workflow, including delegation, emergency access, and override paths.

Decision rule: If a user can affect both the creation and approval of the same request, treat the workflow as non-segregated even when the role model looks clean. Remediate the process design before relying on access recertification to close the gap.

Practitioner takeaway: Effective SoD is proven by independence in execution, not by a tidy entitlement list; if the workflow still lets one person steer both sides of the control, the control has failed.

Related resources from NHI Mgmt Group

• What breaks when segregation of duties is compromised in supplier creation and payment workflows?
• What breaks when segregation of duties is not applied to AI actions?
• What breaks when AI governance relies only on approval workflows?
• How should security teams enforce segregation of duties in IAM workflows?