How Cross-System SoD Violations Create Fraud Paths No One Can See - Gathid

Segregation of Duties (SoD) controls are designed to prevent fraud by ensuring that no single individual can execute a complete, high-risk process end to end. In theory, this is straightforward: separate initiation from approval, creation from reconciliation, request from release.

In practice, most organizations have implemented these controls (often rigorously) within their core systems. And yet, fraud pathways continue to emerge in environments that appear compliant on the surface.

The reason is not that SoD controls are missing. It’s that they are incomplete.

The Problem Isn’t Within Systems—It’s Between Them

Traditional SoD controls are built and enforced at the system level. ERP platforms detect conflicting finance roles. Procurement systems flag incompatible approvals. Applications enforce separation within their own boundaries.

Each system does its job correctly. But the enterprise does not operate as a single system. Rather, it operates as a connected environment.

This is where risk begins to form.

An identity might initiate a transaction in one platform, approve it in another, and reconcile it in a third. Viewed in isolation, each action appears legitimate. Taken together, they form a complete control loop—exactly the scenario SoD was designed to prevent. Because these actions span multiple systems, they often fall outside the scope of traditional SoD controls. The result is a class of violations that are structurally real, but operationally invisible.

How Fraud Pathways Form

Cross-system SoD violations rarely appear as obvious misconfigurations. They emerge gradually, through the normal evolution of enterprise environments. For example:

• A finance user gains approval rights in an ERP system, while retaining initiation access in a separate procurement platform
• A role designed for reporting is combined with operational permissions in another system, enabling indirect control
• A user inherits access through directory groups that span multiple applications
• A service account or integration bridges two systems, extending authority beyond intended boundaries

Each change is justified in isolation. Over time, however, these changes create a pathway that allows a single identity to execute actions that should remain separated. These pathways are rarely designed. They emerge from the structure of authority across the environment.

Why These Risks Persist

One of the most challenging aspects of cross-system SoD risk is how long it can remain undetected. There are several reasons for this:

• Fragmented visibility: Each system only sees its own permissions and roles, not how they combine elsewhere
• Rule limitations: SoD rules are typically defined within systems, not across them
• Review constraints: Access reviews focus on entitlements, not on how those entitlements interact
• Assumption of coverage: Organizations assume that if each system is compliant, the overall environment is too

This creates a false sense of control. From an audit perspective, everything appears to be functioning as expected. But the underlying authority structure tells a different story.

The Gap Between Compliance and Risk

This is where internal audit and risk teams face a growing challenge. Traditional SoD controls are effective at demonstrating compliance within defined boundaries. However, they are less effective at identifying how authority combines across those boundaries to create real-world exposure. As a result, organizations can:

• Pass system-level SoD checks
• Complete access reviews successfully
• Maintain documented controls

…while still carrying hidden pathways that enable fraud or control failure. The gap is not procedural. It is structural.

Seeing What Actually Matters

To identify cross-system SoD violations, organizations need to move beyond isolated rule checks and start understanding how authority exists across the enterprise as a whole.

This means shifting the question from:

“Are there conflicts in this system?”

to:

“Can this identity execute a complete high-risk action across all systems?”

Answering that requires visibility into how roles, permissions, groups, integrations and identities connect—not as separate lists, but as a unified structure. Only then can organizations see:

• Where authority accumulates across systems
• Which identities can execute end-to-end control loops
• How seemingly acceptable access combines into real risk
• Where escalation pathways exist

From Detection to Prevention

When cross-system authority is understood, SoD becomes more than a compliance exercise. It becomes a mechanism for identifying and controlling structural risk. Instead of reacting to isolated violations, organizations can proactively:

• Identify risky combinations before they are exploited
• Reduce unnecessary privilege across systems
• Ensure separation is maintained at the process level, not just the system level
• Provide defensible evidence that controls reflect how the business actually operates

This is particularly critical in regulated environments, where the expectation is not just that controls exist, but that they are effective.

Segregation of Duties was never about enforcing rules in isolation. It was about preventing the concentration of power. In modern enterprises, that concentration no longer happens within a single system. It emerges across them. Identity systems define access. SoD rules enforce policy.

But authority—how access combines across systems—is what determines risk.

The Risk You Can’t See Is the One That Matters

Cross-system SoD violations are not edge cases. They are a natural outcome of complex, interconnected environments. They persist not because organizations are ignoring controls, but because those controls are scoped too narrowly.

Organizations need to understand how authority actually exists, across systems, processes and identities. Because fraud pathways don’t need to be designed. They just need to go unseen.