Oracle Fusion Security Roles and Segregation of Duties

Why Security Role Design Makes or Breaks a Fusion Deployment

Security role design in Oracle Fusion is not something you defer to the end of a project. Not a configuration detail. Not a task for the final sprint.

The decisions you make during design — sometimes in the first few weeks — determine whether your system passes an audit, whether your financial controls actually hold, and whether users can do their jobs without being over-permissioned or completely blocked.

We see this constantly during Fusion implementations. The role model looks manageable at first glance: job roles, abstract roles, duty roles, data security policies — each layer has a purpose, and on paper it seems structured. But assemble those layers without a clear segregation of duties framework and you end up with a web of conflicting privileges that auditors will flag, and that your compliance team will spend months trying to unpick.

Predefined roles are where most teams get into trouble early.

So what does segregation of duties actually mean in practice? No single user should hold a combination of privileges that lets them initiate, approve, and record a transaction without a second person involved. The classic example is procure-to-pay: a user who can create a purchase order, approve it, receive goods, and process the supplier invoice holds end-to-end control over a high-risk financial cycle. That is an SoD violation — exactly the kind of finding that surfaces in external audits under SOX or internal risk frameworks, and it triggers scrutiny that goes well beyond the IT team.

The tricky part is that the violation often does not come from a single role. It emerges from a combination of roles assigned to plug an operational gap. Someone is understaffed, they get an extra role to cover, and suddenly a conflict exists that nobody spotted at assignment time. Without an SoD matrix mapped to Fusion's actual privilege structure, those combinations stay invisible until an auditor runs a cross-role conflict report.

And at that point, the damage is already done.

Role redesign in a live Fusion environment is painful. You are re-mapping duty roles, reassessing data security policies, re-testing business processes, and retraining users — all while the system is in production and teams are relying on it.

Organisations that treat security design as a core workstream during Oracle Fusion implementation avoid most of this. Those that treat it as something to sort out after go-live almost always pay for it twice.

Role design decisions made early in a project often set the template for the entire organisation.

The fix is not complicated in principle — just easy to skip under project pressure:

• ✓Define your SoD conflict matrix before you build a single role
• ✓Map every business process to the privileges it requires
• ✓Validate that no role combination in your design creates a conflict

That work belongs in design. Not in remediation six months after launch.

Understanding the Oracle Fusion Role Hierarchy: Job, Abstract, and Duty Roles

Oracle Fusion's security model runs on a three-tier role hierarchy. Job roles, abstract roles, duty roles — each layer connects to the next in a structured chain. If you don't understand how those connections work, you can't design or audit Oracle Fusion security roles and segregation of duties controls with any real confidence. For the wider picture, see our Oracle Fusion security and compliance overview.

Oracle Fusion Role Hierarchy

A three-tier structure in Oracle Fusion Security in which job roles are assigned to users, abstract roles group shared attributes across job functions, and duty roles carry the actual functional privileges that control system access.

The Three Tiers Explained

Job roles sit at the top. These are what you actually assign to users — Accounts Payable Specialist, General Ledger Accountant, Procurement Manager. Oracle ships predefined versions of most of these. Organisations either use them as-is or copy and modify them. One user can hold multiple job roles if their work crosses functional lines.

Abstract roles sit beneath job roles and represent entitlements shared across many different positions. Employee and Contingent Worker are the classic examples. They're not tied to a specific function — they grant capabilities like submitting expenses or viewing payslips that apply broadly.

In most configurations, abstract roles are inherited by job roles rather than assigned directly to users.

Duty roles are where the actual privileges live. A duty role bundles together the privileges for a discrete task within a module — and they're never assigned to users directly. They're components that job roles and abstract roles pull in as part of their definition. One duty role can be shared across many job roles, which is efficient. But it's also a significant source of SoD risk when those combinations put conflicting capabilities in the same hands.

A Worked Example: The AP Specialist Job Role

Take the predefined Accounts Payable Specialist job role. Oracle ships it with a set of duty roles that collectively define what the role can do:

• Payables Invoice Entry Duty — create and edit supplier invoices
• Payables Payment Processing Duty — process and approve payments
• Supplier Inquiry Duty — read access to supplier records

The job role itself holds no privileges directly. It's just an aggregation of those duty roles into a package that reflects what an AP Specialist actually does day to day.

So where do SoD problems start? Right here.

If that single job role bundles both invoice creation and payment approval duties, one person can create and approve their own payment. That's a textbook SoD conflict — and Oracle's predefined roles don't always prevent it by default. We see this constantly during technical audits. Analysing the duty role composition of every job role you assign isn't optional. It's the starting point. The process behind these controls is covered in more depth in our guide to Oracle Fusion Accounts Payable.

Why the Hierarchy Matters for SoD Design

Duty roles are shared across job roles. Change one duty role and that change cascades to every job role that includes it.

That makes duty-role-level analysis the most efficient place to find and fix privilege conflicts. Map your SoD rules against duty roles and you get coverage across the entire role library at once — rather than chasing job-role-by-job-role combinations one at a time.

Abstract roles add another layer. A common mistake we see in audits: reviewers skip abstract roles entirely when building SoD matrices. That's a problem, because abstract roles like Employee are typically assigned to the entire workforce. Any duty role embedded in one is effectively a universal entitlement. If something sits in the Employee abstract role, your whole user base has it.

Get clarity on all three tiers before you start assigning roles. The hierarchy isn't just an Oracle architecture detail — it's the mechanism behind every access decision the system makes.

Data Security Policies: Controlling What Users Can See, Not Just Do

Function security controls what a user can do — which pages they open, which processes they run. Data security controls which records those actions actually apply to. In Oracle Fusion, you can grant someone every function privilege needed to manage employee records and still lock them out of anything beyond their own business unit's workforce. Two separate control layers. Both need deliberate design.

Skipping data security configuration is one of the most common gaps we see in Fusion implementations. Organisations spend weeks mapping job roles and duty roles — then go live with data security policies left at default. Users end up querying far more data than their role warrants.

How Oracle Fusion's Data Security Model Works

Data security in Oracle Fusion runs through data security policies. Each policy ties together three things: a database resource (a specific object — a person record, a payroll relationship), a condition filtering which rows are accessible, and a set of data privileges (view, edit, delete) granted within those rows.

Policies attach to roles, not users directly.

When a role is assigned, the user inherits every data security policy that comes with it. The database applies row-level filtering at query time — automatically, invisibly, and only as accurately as the conditions allow.

Conditions are written against specific attributes. Common examples include restricting access to records where the legal employer matches the user's assigned legal entity, or where the business unit falls within a defined hierarchy. The tricky part is that a poorly written condition can silently over-permit or under-permit access — and neither failure is obvious until someone notices something wrong.

Security Profiles in HCM

In the HCM product family, data security runs through an additional layer: HCM security profiles. Named configurations that define which records a user can access within HCM objects.

There are distinct profile types for different objects:

• Person security profiles — define which person records are accessible (all persons in a department, direct reports only, persons within a legal employer)
• Organisation security profiles — define which business units, legal employers, or departments a user can see
• Position security profiles — restrict access to position records
• Payroll security profiles — limit which payroll definitions a user can view or process against

These profiles are assigned through HCM data roles. An HCM data role pairs a job role with one or more security profiles, scoping that role to a specific data population.

Take a Payroll Manager job role combined with a security profile covering only UK legal employers. That user can perform payroll manager functions — but only against UK records. Same job role globally, different data scope per region.

Condition-Based Row Filtering Outside HCM

Outside HCM — in Financials, Procurement, and Project Management — data security policies use database-level conditions written against the object's attributes. These conditions reference the user's session context (assigned business units, ledgers, cost centres) and filter query results accordingly.

A Payables Manager in one business unit should not be able to query invoices belonging to another. The data security policy on the invoice object enforces this by comparing the invoice's business unit attribute against the business units provisioned to the user.

Oracle ships default data security policies with each role. But those defaults are often broader than most organisations actually need.

Reviewing and tightening them during implementation — not after go-live — is significantly less disruptive.

The Function-Without-Data Trap — and Its Reverse

Most security reviews focus on function security because it is visible. You can see which roles grant access to which pages. Data security is less visible — which is exactly why it gets missed.

The risk runs in both directions.

A user can have full function access to a process but no data access, leaving them unable to do their job. Or they can have broad data access with limited function access — meaning they cannot act on records they can see, but they can still read information they have no business seeing.

That second scenario carries higher risk from a segregation of duties perspective. Read access alone can expose payroll figures, headcount plans, or supplier pricing to people with no legitimate need for it — even if they cannot process a single transaction.

Auditing Data Security in Your Current Configuration

Start by pulling a report of all data security policies attached to the roles in use. Oracle's Security Console lets you view policies by role. For each one, review the condition and identify the scope it permits.

Pay close attention to any role carrying the condition 1=1 or an equivalent catch-all. That grants access to every row on the object with no filtering. Oracle uses these in some seeded roles by design — but when they get inherited into custom roles or assigned to operational users, the exposure is significant. We see this regularly during audits, and it is rarely intentional.

For HCM, cross-reference each active HCM data role against its security profiles. Confirm that person security profiles are scoped to the correct legal employer or management hierarchy.

No operational role should carry an "all persons" profile unless that scope is genuinely required — a central HR administrator being the obvious exception.

Tightening data security after go-live is achievable, but it requires regression testing to confirm users still have access to the records they actually need. Building this into your security role design process from the start — and into your Oracle Fusion testing strategy — is always the more efficient path.

Segregation of Duties: Designing Controls That Satisfy Auditors

SoD is consistently one of the most scrutinised areas in Oracle Fusion audits. The principle itself isn't complicated: no single user should be able to initiate, approve, and record a transaction without a second set of eyes. The complexity is in translating that into actual role assignments across a system where hundreds of duty roles exist and job roles bundle many of them together.

This isn't a one-time cleanup before audit season. It's a repeatable design methodology built into how you assign and maintain security roles across Oracle Fusion Financials.

Identifying Conflicting Privilege Pairs

Start with a conflict matrix — a documented list of privilege pairs that, when held by the same user, create unacceptable risk. Oracle provides predefined SoD rules through Access Certifications and Advanced Access Controls, but treat these as a starting point. Every organisation has process variations that introduce conflicts Oracle's standard ruleset won't catch.

In Fusion Financials, the conflict pairs that come up most often are:

• AP/GL conflicts: A user who can create and post supplier invoices and also manually journal to the General Ledger can manipulate the financial record with no secondary reviewer catching it. The AP entry and a correcting journal can cancel each other out — masking a fraudulent payment entirely.
• Procurement authorisation conflicts: A user with purchase order creation privileges who also holds approval authority — even at a low monetary threshold — can self-approve transactions. We see this constantly when procurement job roles are copied from a template without stripping inherited approval duties.
• Supplier master and payment processing: Amending supplier bank details alongside the ability to run payments is a direct fraud vector. These two capabilities must sit in completely separate roles. No overlap.

Mapping Conflicts to Business Risk

Auditors want risk-led documentation. A list of technical privilege conflicts on its own means very little.

For each conflict pair, your documentation needs to answer three questions: what transaction could be manipulated, what's the financial or compliance impact, and how likely is the risk given your existing process controls? This mapping exercise also forces a useful internal conversation.

Not every conflict carries the same weight. A user who can create a requisition and approve it under £500 is a very different risk profile from a user who can create invoices and post journals. Ranking conflicts by severity helps prioritise remediation — and gives auditors a clear picture of where controls are tightest and where you've made deliberate trade-offs.

In our experience, the conflict matrix is only as useful as the business risk narrative attached to it. Auditors consistently flag organisations that produce lists of privilege conflicts with no explanation of what each conflict actually enables — the technical detail without the risk context rarely satisfies an internal audit or external review.

Documenting Compensating Controls

Remediation isn't always possible without breaking operational workflows. A small finance team may not have the headcount to fully separate AP and GL functions.

When that's the case, a compensating control needs to be designed, documented, and tested. Not just noted as an exception and left there.

The compensating controls auditors accept tend to share three characteristics: performed by someone independent of the conflicted user, covering the full transaction population rather than a sample, and leaving a clear evidence trail. A monthly GL-to-AP reconciliation signed off by a finance manager works. Automated workflow routing that requires a second approver above a defined invoice threshold works. "Management review" with no further detail does not.

Your control documentation should state the control owner, frequency, evidence produced, and how exceptions are escalated. Vague is not audit-ready.

Keeping Controls Current

SoD design isn't a point-in-time exercise. Role assignments shift when people move teams, when new functionality goes live, or when Oracle's quarterly updates modify the privileges bundled into standard duty roles. A conflict that didn't exist six months ago can appear after an update.

And nobody notices until audit.

The tricky part is that most teams only run access analysis reports when something flags. That's too late. Build a process to re-run access analysis after every Oracle quarterly update and after any significant role redesign. Pair it with periodic access certifications — formal reviews where managers confirm their team's role assignments are still appropriate.

Organisations that treat SoD as a continuous control, rather than something they prepare for audit, consistently produce stronger evidence and spend far less time on remediation when audit arrives.

Audit and Monitoring Tools: Oracle Access Governance and FSAH

Designing your SoD controls and data security policies is only half the job. The harder part is staying on top of them over time.

Role assignments drift. People change jobs and keep access they no longer need. New configurations introduce conflicts that weren't there at go-live.

Oracle provides three core tools to deal with this: Oracle Access Governance (OAG), the Fusion Security Console, and Financial Statement Audit History (FSAH). Each addresses a different layer of the problem. Auditors expect evidence from all three.

Oracle Access Governance

OAG is a cloud-native identity governance platform. It connects to Oracle Fusion and evaluates role assignments against a library of SoD policies on an ongoing basis.

When it finds a conflict — say, a user holding both a payables invoice entry role and a payment approval role — it flags it, assigns a risk rating, and routes a remediation task to the appropriate reviewer or manager. Every step is documented and timestamped. That audit trail is exactly what auditors are looking for when they ask for evidence of periodic access review.

Access certification campaigns are where OAG earns its keep for SOX and internal audit requirements. You schedule quarterly or annual campaigns, role owners or line managers certify whether each user's access is still appropriate, and every decision — approved, rejected, or escalated — gets logged. Missed deadlines trigger automatic escalation. That gets recorded too.

This replaces the manual spreadsheet process we see constantly during Fusion audits. Spreadsheets almost never satisfy an external auditor on closer inspection.

OAG also surfaces analytics showing access concentration: which roles are held by the most users, which combinations overlap frequently, which business units carry the highest SoD risk. Useful for prioritising remediation rather than treating every conflict as equally urgent.

Fusion Security Console

The Security Console is the native administration interface inside Oracle Fusion. Day-to-day security management lives here — role assignments, custom role creation, role reports, and privilege analysis.

The role conflict analysis feature lets you input two or more roles and check whether they share duty roles or function security privileges in a conflicting way. We see teams use this during design, but it's just as useful when a help desk team is evaluating an access request before granting a new role.

The User Account report is one of the most practically useful outputs here. It shows every role assigned to a specific user — including inherited duty roles and data security policies.

When an auditor requests a complete access listing for a sample of users, this is your starting point. Export it, check it against your approved access matrix, document exceptions with a remediation note. That sequence is what adequate evidence looks like in most audit frameworks.

Role hierarchy reports are another feature most teams underuse. They let you trace how a job role inherits privileges through its duty roles, all the way down to individual function security privileges. If an auditor questions why a user can perform a specific transaction, you can show a documented chain of inheritance rather than trying to explain it verbally.

Financial Statement Audit History (FSAH)

FSAH does something different. It doesn't manage access — it records what users actually did with it.

Specifically, it captures journal entry creation, posting, approval, and reversal events at the transaction level: who did it, when, and from which source. For financial statement auditors, this is the link between access and activity. Knowing a user had the access to post journals is one level of risk. Knowing they actually posted journals during a restricted period is a material finding.

The tricky part is that FSAH only delivers value if you're querying it regularly — not just when something goes wrong. A common approach is a monthly exception report that compares users holding sensitive roles against users who actually performed the transactions those roles permit. Anyone appearing in both lists, particularly outside normal business hours or approval workflows, warrants a closer look.

Running Role Conflict Reports: A Practical Sequence

So what does a complete role conflict report actually look like in practice?

The Security Console gives you role assignments. OAG evaluates those assignments against your SoD ruleset. FSAH confirms whether the conflicting access was actually used. Auditors expect all three layers evidenced — not just one.

Auditors reviewing Oracle Fusion security roles and segregation of duties controls will test whether your monitoring process is repeatable and documented, not whether it's perfect. An organisation that catches conflicts, reviews them, applies compensating controls, and records the decision is in a far stronger position than one with no conflicts on paper simply because nobody has looked.

Together, OAG, the Security Console, and FSAH give you a complete monitoring stack — preventive controls in the role design, detective controls in the transaction history, and a governance layer that documents review and remediation.

The gaps we see in audits are almost always process gaps, not tool gaps.

Reports that exist but never get run. Certifications completed without genuine review. Exception lists that get filed rather than acted on. The tools are there. The question is whether the process behind them is real. Where security events also flow to external systems, our guide to Oracle Integration Cloud for Fusion ERP explains how to keep those integrations governed and auditable.

Remediating SoD Violations: A Practical Approach Post Go-Live

Finding segregation of duties violations after go-live is common. It doesn't mean the implementation failed. It means audit scrutiny has tightened and your environment is being held to a higher standard.

What matters now is how you respond.

A structured remediation approach, applied in the right sequence, closes gaps without disrupting operations or forcing a full role redesign from scratch. The work falls into four phases: audit, prioritise, remediate, and re-test.

Rushing any of these creates new problems. Skipping re-testing is the single most common reason violations resurface at the next audit cycle.

Audit First, Remediate Second

The most damaging mistake we see during technical audits is attempting remediation before completing a full access audit. Teams remove roles based on complaints or a single flagged user — without first understanding the full scope of the conflict. That approach closes one gap and often creates another.

Need a Security Role Review or SoD Audit?

Our team works with organisations at every stage of their Fusion journey — from pre-go-live role design to post-implementation SoD remediation. If your environment has unresolved access conflicts, audit findings, or a role model that has drifted since go-live, we can help you get it under control.

You might also find helpful