<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=523033&amp;fmt=gif">

Access Controls in Oracle EBS: Model Behavior

security remodel s.jpgSo far in this series we got your boss’ attention and then you said smart things about Access Controls – and now you’ve been put in charge of a project to ensure that Oracle EBS is in good shape. Let’s talk more technically about your ERP and how we can operationalize two weeks of theory!




The Re-Model

A quick google search will land you several models for how Oracle EBS is built, and most likely all of them are correct. The model that we will use today is fairly common – this “cascading” model shows a correlated path from the user down to the function.  This is a concise way of thinking of access in Oracle EBS as what we care about is who (user) can do what (function)? This simple diagram is missing two core elements: forms and data access. Let’s cover these as well. I will keep our discussion simplified for the sake of non-technical readers – apologies to those Oracle heavyweights who may find that simplification comes at the cost of specificity!


security setup.png

Users log into the system to perform business transactions.  In order to perform a business transaction, users need to have access to forms and functions. At Fastpath, we call these combinations of forms and functions Business Processes. At PwC, we called them Abilities. You may call them something else, but the concept is the same. Forms are the UI organization of fields, buttons, etc. and functions are the rights to interact with those elements. Forms and functions are grouped into sub-menus, which are grouped into menus. Menus are assigned to responsibilities, and responsibilities can be grouped into roles. Role-based Access Control (RBAC) allows the creation of roles to match job descriptions in the company – administrators can create a role called Procurement Manager that has all of the menus, sub-menus, forms, functions, etc. needed to perform that job’s duties instead of having to assign the responsibilities manually to each Procurement Manager added to the system. Data access restricts what data users can see or touch – e.g. a Procurement Manager in EMEA can be restricted to only EMEA purchasing and inventory despite having the same role composition as the US Procurement Manager. There is much more granularity, nuance, and complexity in the Oracle access model, but we will stop here to keep this as an introduction only.


Access Controls in Oracle EBS

And here we are: the titular track in this four-part album. As an auditor, I was often asked to explain control deficiencies – this is difficult without being able to lay a base foundation of knowledge, akin to explaining an ‘illegal formation’ penalty in football without the audience knowing what the rules are in the first place. We have our base, so let’s go.


Chutes and Ladders

As the first section of this article shows, Oracle security is complex. Additionally, Oracle is managed by human beings, who are fundamentally fallible. Combine complexity with fallibility, and you get mistakes, which lead to errors, issues, or deficiencies. This is where we bring our controls back into the conversation. By defining clear policies, enforcing those with detailed procedures, and including clear, easy-to-perform controls, we significantly reduce the risk of mistakes. Let’s talk about common risks and pitfalls specific to Oracle and which controls from Part 2 can help.


The most common pitfall in Oracle EBS access control is the over-reliance on roles or responsibilities. I can’t count the number of times I heard a client say, “Well of course that access is okay – that role is called ‘Inquiry Only!’” Roles and responsibilities are packaging, and you can call them whatever you want. Remember last time you moved, and the box that had KITCHEN STUFF scribbled on the outside actually had pillows in it? Over time even the most diligently created roles and responsibilities can morph into something other than their original purpose. This is where annual reviews of role and responsibility composition are key – you need to validate that everything in the box matches what it says on the outside!


The second most common pitfall is job change. User addition controls normally operate well for new hires, and terminations controls are generally effective. Where change gets lost is when someone changes their job responsibilities. I’m not talking about when Bob moves from Marketing to Manufacturing, but when Susan changes from Procurement Manager to Procurement Manager + Payments Processor. This sort of “scope creep” in business is typical, and operationally driven due to need.  Regular user reviews are key, and frequency should be defined by risk. Are you a 10-person finance shop and nobody ever leaves? Well, annual may be sufficient, but if you are more dynamic and complex than that, quarterly is typically best. As a bonus, this quarterly user review will also capture instances where the user additions or terminations controls fail – it’s a safety net!



Segregation of duties (SOD) was introduced in Part 2. Due to the complexity of Oracle, organizations rarely realize that users have the ability to create a vendor and pay a vendor, or modify bank data and create a payment. Traditional business process control environments can miss this risk as they are sample-based, and the regulation has become more focused on what could happen rather than what has happened. SOD conflicts can be created via the combination of roles, the pairing of responsibilities within a role, or even the bunching of forms and functions within a responsibility. Regular SOD reviews have become an almost-mandatory control for companies. The policy and ruleset (i.e. key conflicts) should be reviewed annually, and access should be reviewed against that policy and ruleset alongside your regular access review.


Critical Access and Configuration

Finally, critical access and configuration are the source of anxiety for many auditors and system owners. Workflow configuration, the AZN menu, account period setup, and the chart of accounts are all examples of configuration settings that can have sweeping impact on the completeness and accuracy of data coming from Oracle. Access to critical data such as the vendor master and employee master files, and the level of that access, can be very serious. The cost of data privacy violations can be significant, and the effort to rebuild a damaged master file can be crippling. A regular review of critical access rights and system configuration should be included quarterly, at the least.


The next article in this series will discuss tools that can be used to assist the execution of these controls, read more here.