Why do segregation of duties failures still happen in mature finance programmes?

Why SoD Breaks Down in Mature Finance Programmes

segregation of duties fails most often when finance teams assume the control is complete because one system shows approval separation, while another system still allows override paths, temporary elevation, or privileged workflows. That gap matters because SoD is not just an audit design issue; it is an identity and transaction-control issue. NIST’s NIST Cybersecurity Framework 2.0 reinforces that governance has to connect policy, access, and monitoring rather than treating them as separate programmes.

In mature environments, the failure is usually not absence of policy but inconsistent enforcement across ERP, workflow, PAM, and exception handling. That is why teams can pass periodic reviews and still end up with real-world paths that let one person initiate, approve, and post the same transaction through different layers. The problem also shows up when application logic and human access reviews are evaluated independently, even though attackers and insiders only need one combined path to create material exposure. NHIMG research on The State of Secrets in AppSec shows how control confidence can outpace operational reality when governance is fragmented. In practice, many finance teams discover SoD failure only after an exception path, emergency access grant, or application integration has already been used to bypass the intended control.

How SoD Controls Actually Fail Across Systems

The practical weakness is that SoD is often implemented as a rule in one platform, but finance activity spans multiple control planes. A user may be blocked from approving an invoice in the ERP, yet still be able to trigger a workflow change in a connected system, request temporary elevation through PAM, or exploit a service account that carries broader authority than the named user. That is why mature programmes need cross-system control mapping, not just policy language.

Operationally, the strongest designs combine RBAC, JIT elevation, and transaction monitoring. The goal is to make the approval path, the privilege path, and the exception path visible at the same time. Current guidance suggests:

• Map each SoD rule to every application and integration where the transaction can be initiated or completed.
• Separate standing access from temporary access so exceptions expire automatically after the task.
• Review privileged service accounts and background jobs alongside human user roles.
• Correlate workflow logs, ERP events, and PAM activity to detect cross-system circumvention.

This is also where financial controls intersect with secrets hygiene. If a shared credential or API key can bypass a workflow control, the SoD model is no longer meaningful. NHIMG’s DeepSeek breach coverage and the broader secrets management data in The State of Secrets in AppSec both reinforce the same point: control failure often starts with hidden access paths, not with the formal approval matrix. These controls tend to break down when finance processes rely on custom integrations and legacy exception handling because the effective authority chain no longer matches the documented one.

Common Variations, Edge Cases, and Control Gaps

Tighter SoD enforcement often increases operational overhead, requiring organisations to balance control strength against close cadence, incident response speed, and business continuity. That tradeoff is especially visible in treasury, month-end close, and merger integration work, where temporary access is common and the risk of over-broad elevation rises quickly.

There is no universal standard for this yet, but current guidance suggests treating “temporary exception” as a high-risk state that needs its own approval, expiry, and monitoring rules. Mature programmes also need to account for scenarios where SoD is technically intact for humans but broken by application logic, batch processing, or delegated admin roles. The control can look strong in audit evidence while still failing in practice if the same person can influence master data, approval routing, and posting through different tools.

Common edge cases include shared service centres, outsourced finance operations, and automation bots. In each case, the issue is less about who logged in and more about which identity executed which step. That is why SoD programmes increasingly rely on continuous control testing, exception analytics, and full-path visibility instead of annual recertification alone. Mature finance programmes still fail when the organisation audits entitlements but does not test the end-to-end transaction path under real operating conditions.

Related resources from NHI Mgmt Group

• Why do segregation of duties conflicts still happen in mature IAM programmes?
• Why does segregation of duties matter for IAM programmes beyond finance?
• Why do passwordless programmes still need strong help desk controls?
• How can IAM teams reduce segregation-of-duties exceptions without slowing the business?