Default Oracle Responsibilities? Why Worry About Them?

Default Oracle Responsibilities? Why Worry About Them?

“What are Oracle’s Default Responsibilities?”

Each application in Oracle E-Business Suite has a ‘super user’ menu that gives it all the key functionality for that bit of the process, along with some of the other bits from other processes that it might need. Each process may consist of a number of applications – for example, the purchase-to-pay process includes Oracle iProcurement, Oracle iSupplier Portal, Oracle Purchasing and Oracle Payables modules, each of which will have their own ‘super user’ menu. As an example, the Oracle Payables one is AP_NAVIGATE_GUI12. This menu is a perfect example of one that triggers lots of segregation of duties conflicts, with it having the ability to maintain suppliers, record invoices and run payment batches amongst others by default.

Oracle have then created a ‘default’ responsibility with access to this ‘super user’ menu – in Oracle Payables case, this is ‘Payables Manager’, and other key ones include ‘Purchasing Super User’, ‘General Ledger Super User’ and ‘Receivables Manager’.

We would recommend that organisations regularly review their list of Responsibilities assigned to users, and if any of these are noted they should each be questioned and revoked down to something that’s segregated.

“Which modules should you focus on?”

I’d normally ask myself the question “what’s the risk I’m worried about?” If you are performing a project that is focussed on financial risk (such as an external audit) then I’d ignore CRM, HR, etc, though if your focus is on confidentiality, then I’d definitely put customer data and HR data in scope. When Systems Risk Services acted as the risk and controls lead for an implementation of Oracle CRM, we certainly made sure that access controls were restricted and that automated business process controls were implemented in the process.

“What else should I be looking for?”

From our experience, implementers often base their Oracle Responsibilities on these defaults – and many have been known to ‘tailor client access’ simply by creating a new responsibility that points to the same ‘super user’ menu, with no exclusions applied. Based on this, the System Risk Services Access Analytics service includes a report to pick up users that have been assigned either the ‘default’ ones, or where they have been assigned an equivalent and no exclusions have been applied. The report shows you which default responsibility is the equivalent to the new one – and it’s always interesting reading.

Any comments or thoughts, please let me know.