Because the conflicting action is often distributed across several systems, no one application has enough context to detect the full risk. A control that only evaluates one app can look compliant while the end-to-end business process still violates SoD intent.
Why cross-app workflows break single-app SoD checks
segregation of duties is a process control, not just an application setting. In a cross-app workflow, one system may approve, another may execute, and a third may record the result. If each application checks only its own permissions, none can see the full conflict, so the control can look effective while the end-to-end business process still violates SoD intent.
The practical problem is that the risk lives in the sequence, not in any one screen. A user may be allowed to request in one system, approve in a second, and post or release in a third, and each application can be “clean” on its own. The SoD failure appears only when those steps are stitched together across the business process.
That is why workflow design matters as much as role design. A single-app control usually knows about local entitlements, local approvals, and local audit trails, but SoD needs context about who can influence multiple steps, which systems are connected, and whether a compensating control truly covers the whole transaction path.
Where the control breaks down in practice
Cross-application SoD failures usually show up in integration layers, manual handoffs, and shared identity paths. One app may enforce role restrictions while a downstream app trusts a file feed, API call, or service account that bypasses the local approval model. For a deeper identity and entitlement view, IAM and IGA Basics is useful because it frames access reviews, entitlements, and governance as cross-system problems rather than per-app settings.
Another common failure mode is that the same person can perform separate steps in different systems without any one system recognising the conflict. Segregation of Duties (SoD) Guide is the better model here because it treats toxic combinations, mitigations, and control extension across service accounts, bots, and automated flows as part of SoD design.
Single-application checks also struggle when the approval evidence is fragmented. One system may show the request, another the approval, and a third the release, but the approval logic never evaluates the end-to-end chain. That creates false confidence: the local control passes, yet the business outcome still concentrates incompatible duties in one actor or team.
What good SoD governance has to measure instead
Effective SoD governance has to trace the business transaction across systems, not just verify that each app has a role matrix. That means identifying where the authoritative decision happens, where execution happens, and where override or emergency access can short-circuit the normal path. It also means deciding which system owns the SoD decision when no single application has enough information.
Practitioners should treat inter-application trust as part of the control surface. If a downstream system accepts upstream approvals without validating the broader duty conflict, the SoD design is incomplete. If the business process spans multiple platforms, then the SoD rule needs a workflow-level view, an orchestration control, or a compensating review that can evaluate the full transaction.
In mature programmes, the best evidence is not a passing application control test but a tested business scenario. You want to prove that a user cannot both create and approve, or approve and release, even when those steps are split across different tools, queues, or service boundaries. That is the real test of whether the control protects the process or only the application.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cross-app SoD depends on enterprise access governance across systems. |
| Recommendation — Map conflicting workflow steps to IAM controls and enforce enterprise-wide segregation rules. | ||
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly governs duties split across users, roles, and processes. |
| AC-6 — Least Privilege | Limits users to the minimum access needed when workflows span systems. | |
| Recommendation — Apply AC-5 to prevent incompatible approval and execution combinations across the process. Restrict each role to the smallest access set that still supports its workflow step. | ||
| ISO/IEC 27001:2022 | A.5.3 — Segregation of duties | Annex A explicitly requires duties to be separated where practicable. |
| Recommendation — Design process controls so no single actor can complete conflicting workflow steps. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Cross-app SoD needs risk treatment at the process level, not per application. |
| Recommendation — Set a risk strategy that evaluates end-to-end workflow conflicts, not isolated app checks. | ||
Practitioner Guidance
What to verify: Test the full transaction path, not just local roles. If any step is controlled outside the application you are reviewing, verify where SoD is actually enforced and whether downstream systems can bypass it.
Decision rule: If no single application can see all conflicting steps, treat app-level SoD as partial evidence only. Require a workflow-level control, an orchestration check, or a documented compensating control before calling the process segregated.
What good looks like: The control can explain, with evidence, how a conflicting user cannot complete the end-to-end business action even when approvals, execution, and recording are split across different systems.
Practitioner takeaway: SoD is reliable only when the control boundary matches the business process boundary, because conflicts that are invisible to one application can still be fully real in the workflow.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org