How should organisations perform a segregation of duties health check in Oracle ERP environments?

Why This Matters for Security Teams

A segregation of duties health check in Oracle ERP is less about a static policy review and more about proving that no single identity can complete an entire sensitive business flow without a second control. Oracle environments often combine seeded roles, custom responsibilities, approvals, integrations, and exceptions, which means SoD conflicts can hide in the seams between finance, procurement, and technical administration. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, a reminder that identity blind spots are common even before ERP-specific risk is assessed in the Ultimate Guide to NHIs. For control design, NIST SP 800-53 Rev. 5 emphasises access enforcement and separation of duties as core safeguards, not after-the-fact audit artifacts.

Practitioners commonly miss indirect paths, such as a user who cannot post a journal directly but can create it through one role, approve it through another, and trigger posting through a workflow exception. The health check should therefore test actual transaction paths, not just named roles, and it should include privileged access, batch jobs, interface accounts, and emergency access. In practice, many security teams discover SoD failures only after audit findings or fraud indicators have already surfaced, rather than through intentional preventive testing.

How It Works in Practice

Start by building a process-to-control map for the Oracle ERP modules that matter most: order-to-cash, procure-to-pay, record-to-report, asset management, and user administration. For each process, identify the business events that should never sit with one identity across the full lifecycle, then trace how those events are actually executed through roles, responsibilities, workflow rules, web services, and scheduled jobs. A useful health check compares intended SoD policy with real activity history so the team can see where compensating controls are doing hidden work.

In Oracle ERP, the highest value tests usually include:

• Role aggregation analysis across multiple responsibilities assigned to the same user.
• Conflict checks for initiator, approver, and poster combinations in the same transaction path.
• Review of custom forms, extensions, and workflow approvals that bypass standard segregation.
• Validation of privileged admin access, break-glass accounts, and shared service IDs.
• Testing of interface accounts and batch users that can create or update records outside normal UI controls.

Use the Oracle role catalog and transaction logs together, then compare them against a SoD rule set that reflects actual business risk, not a generic template. Where possible, tie the control to NIST SP 800-53 Rev. 5 access control expectations and use the Ultimate Guide to NHIs to extend the same discipline to service accounts and API credentials that interact with ERP data. The strongest programmes also test compensating controls, such as independent review, exception approval, and transaction monitoring, because Oracle customisations often create access paths that role mining alone will not reveal. These controls tend to break down when organisations rely on role names instead of executed transactions, because custom integrations and delegated administration can recreate the same conflict through a different path.

Common Variations and Edge Cases

Tighter SoD controls often increase business friction, requiring organisations to balance fraud reduction against close-time urgency, operational continuity, and application complexity. That tradeoff becomes more visible in Oracle ERP environments with many subsidiaries, legacy customisations, or shared support teams. Current guidance suggests that compensating controls are acceptable for specific exceptions, but there is no universal standard for how strong those controls must be across every business unit.

Edge cases usually involve situations where one identity is not the only risk holder. Examples include emergency superuser access, robotic process automation, scheduled posting jobs, and third-party support accounts. These should be treated as SoD-relevant identities even when they are not traditional employee accounts, because they can still initiate, transform, or finalise transactions. The same logic applies to non-human credentials that touch Oracle through APIs, middleware, or integration queues; if those identities can move a transaction from creation to completion, they belong in the health check scope. NHI Management Group’s Ultimate Guide to NHIs is useful here because ERP control gaps often expand once service accounts are ignored. The practical rule is simple: if a path can bypass human review or collapse multiple steps into one actor, it deserves the same SoD scrutiny as a named user.

Related resources from NHI Mgmt Group

• How should organisations detect and mitigate Segregation of Duties risks in D365 F&O environments?
• How should organisations build ERP security and controls test plans for Oracle EBS environments?
• How should organisations improve SAP access governance when native segregation-of-duties controls only show technical violations?
• What do organisations get wrong about segregation of duties in federated environments?