When should organisations prioritise cross-application SoD over single-system controls?

When cross-application SoD becomes the right control layer

Cross-application segregation of duties becomes the stronger control when a business process is split across systems that each look reasonable on their own, but combine into an unsafe end-to-end path. The question is not whether any one application has approval rules, but whether one actor can complete incompatible steps across the workflow. That is a governance and access design problem, not just a role design problem.

In practice, this matters most where procurement, payments, vendor setup, case handling, trading, claims, or release management move across separate platforms. A single-system check may stop one bad action inside one application, but it will not detect a user who requests in one system, approves in another, and executes the final step elsewhere. That is why the control objective needs to follow the process, not the application boundary.

For teams formalising the control model, the useful test is whether the business can describe the workflow as a chain of accountable steps with distinct ownership. If the same person, service account, or automated actor can bridge those steps, the SoD rule should be written at the workflow level and then enforced in the relevant applications. NHIMG’s Segregation of Duties (SoD) Guide is useful here because it frames toxic combinations, mitigations, and how SoD extends beyond a single system into broader access governance.

Why single-system controls miss the real conflict

Single-system controls usually assume the application contains the full decision path. That assumption breaks when data, approvals, and execution are distributed across platforms. The control failure is often not an obvious privileged role inside one system, but a sequence of normal-looking permissions that only becomes risky when combined.

This is especially common when organisations decentralise operations. One application may handle vendor onboarding, another handles invoice approval, and a third initiates payment. If access reviews and role design are done independently in each system, no one may notice that the same identity can influence the transaction from start to finish. Cross-application SoD forces the review to follow that full chain.

The control also needs to account for delegated and automated access. Shared operational accounts, integration identities, or bots can create the same conflict pattern as a human user if they can span request, approve, and execute steps. NHIMG’s Multi-Agent and A2A Security Guide is relevant because it explains how delegated action, multi-hop coordination, and authentication boundaries affect control design when execution is spread across actors or tools.

What good cross-application SoD looks like in practice

Good cross-application SoD starts with mapping the workflow, not the org chart. The control owner should define the incompatible steps, identify where each step occurs, and decide whether the same identity can touch more than one step without creating unacceptable exposure. Only then should teams decide whether to block, route for approval, or apply a compensating control.

• Map the end-to-end process across systems, including manual handoffs and exception paths.
• Define SoD rules around the business action, such as create, approve, and release, not just around application roles.
• Test the full path for identity reuse, overlapping privileges, and override channels.
• Use compensating controls only when the workflow cannot be redesigned, and make them specific enough to detect the conflict.

The biggest mistake is to treat one application’s role matrix as the source of truth for the whole process. Another common failure is letting exceptions accumulate until the control exists only on paper. Cross-application SoD works when it is measured against the actual business flow and backed by evidence that conflicting combinations are either blocked or independently monitored.

Practitioner Guidance

What to prioritise: Start with the highest-value workflows where a single actor can influence the outcome across more than one system, especially where money movement, master data, or release authority is involved. Those are the places where end-to-end SoD failures create the greatest business impact.

What to verify: Verify that the control design tests the full workflow path, not just one application at a time. If access recertification cannot show who can request, approve, and execute across systems, the SoD model is too narrow to trust.

Common mistake: Do not assume that passing audits in separate applications means the combined workflow is safe. Cross-application conflicts often survive because each system looks compliant in isolation.

Practitioner takeaway: Prioritise cross-application SoD when the business outcome depends on a chain of actions across systems, because that is where hidden toxic combinations usually live.

Related resources from NHI Mgmt Group

• Why do cross-application SoD conflicts create more risk than single-system conflicts?
• When should organisations prioritise single sign-on over separate application logins?
• Should healthcare organisations prioritise single sign-on over adding more login controls?
• Should organisations prioritise external exposure or internal credential governance first?