Why do Oracle and adjacent systems create SoD risk even when each platform looks compliant?

Why application-local compliance can still miss SoD risk

Segregation of Duties is a workflow control, not just a system setting. Oracle, SAP, Workday, and similar platforms can each appear compliant on their own while the end-to-end business process still lets one person or automation assemble incompatible rights across tools. The control failure is in the combined path, not the isolated application view.

That is why SoD issues often survive clean audits inside each platform. A role review that stops at one system can miss the fact that procurement, vendor setup, payment approval, and journal posting may be split across different applications but still reachable by the same user or service account.

SoD analysis must therefore start from the business duty, then trace every place that duty is executed or approved. When the workflow spans multiple systems, the relevant question is whether one actor can complete conflicting steps anywhere in the chain, not whether each platform owner can defend its own entitlement model. NHI Management Group’s Segregation of Duties (SoD) Guide is useful here because it treats toxic combinations, compensating controls, and access governance as a cross-system problem.

Where toxic combinations hide in Oracle and adjacent systems

Cross-platform SoD risk usually shows up when a process is fragmented across ERP, HR, procurement, and identity administration tools. A user may not have conflicting permissions in Oracle alone, but the same person may also hold access in SAP, a workflow engine, a ticketing system, or a master data tool that completes the control path.

That creates a common blind spot: the permissions are individually defensible, yet collectively unsafe. Typical examples include maintaining vendor records in one system, approving invoices in another, and triggering payment release or exception handling elsewhere. Each entitlement can pass local policy checks while the combined path still enables fraud, manipulation, or unauthorized change.

The risk is amplified when privileged users, delegated approvers, or automation accounts are reused across environments. If access models are not reconciled at the process level, teams can end up relying on a patchwork of compensating controls that were never designed to stop a cross-system toxic combination.

What changes when SoD is measured at the workflow level

Workflow-level SoD forces you to map duties, not just roles. That means defining the incompatible activities first, then checking how they can be exercised across every connected application, integration, and approval step that contributes to the business outcome.

This approach also changes how remediation works. Removing one permission in Oracle is not enough if the same business capability can be achieved through SAP, Workday, a shared admin function, or an integration account. The real fix may be role redesign, process redesign, tighter approval routing, or a compensating control that genuinely interrupts the conflict.

For governance teams, the practical implication is that compliance evidence has to follow the process boundary. A clean entitlement report in one platform is only partial evidence if the user can still complete the same duty elsewhere in the operational chain. The NIST 800-53 access control and audit controls provide a useful baseline for thinking about least privilege and traceability across that chain.

Risk and Threat Considerations

SoD failures matter because they create an opportunity for fraud, error, or abuse even when each application seems well controlled. The most serious exposure is usually not a single blatant privilege, but a distributed sequence of legitimate actions that only becomes unsafe when combined across systems.

Failure mechanism: Controls are evaluated per application instead of per business process, so no single system sees the full toxic combination. Cross-system workflow steps, shared administrators, delegated approvals, and integration accounts can therefore recombine into a conflicting duty path that local reviews miss.

Impact: Organisations can approve, record, and release the same transaction through different tools without any one platform showing a policy breach. That increases the likelihood of fraud, unauthorized change, audit findings, and weak accountability, especially where exception handling or manual overrides are common.

Practitioner Guidance

What to prioritise: Build SoD rules from business activities first, then map those rules to the systems that actually execute them. The unit of analysis should be the process, not the platform, because that is where the toxic combination is created.

What to verify: Confirm that your evidence covers cross-system combinations, shared admin paths, and automation or service accounts, not just named user roles. If your review cannot show how a duty is blocked end to end, the control is not yet provable.

Common mistake: Treating one compliant application as proof that the business process is compliant. In multi-platform environments, that shortcut usually leaves the real conflict untouched.

Practitioner takeaway: SoD is only reliable when the control follows the workflow across systems, because compliance inside one platform does not prevent an incompatible duty from being assembled elsewhere.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do biometric systems create governance risk even when overall accuracy looks strong?
• Why do fragmented IAM systems create blind spots even when each tool looks compliant?
• Why do hidden HTTP systems create risk for organisations even when the main application looks secure?