When remediation recommendations are made to adjust your user access definitions (Responsibilities) to better comply with your organization’s SOD and SA rules library, just how do you go about it?

Let’s set the stage by taking a look at the architecture of Oracle EBS responsibilities that are generally interrogated by an SOD and SA solution.

The main component (with regards to SoD and SA controls) of a responsibility definition that provides access to applications in Oracle EBS begins with the Top-Level Menu assignment to the responsibility definition.

This is a hierarchical structure that is made up of Menus, Sub-Menus, and Functions.

The menus and sub-menus provide for the navigation through the application eventually leading to an action to be performed.

That action is the function. We have 2 main areas that functions provide actions to-

Retrieving data and creating / altering data.

Retrieving data

Provides the user with the ability to pull data onto a form specific to its structure and access to application specific data and function(s). This data could be transactional, financial, personal (PII), PCI related (payment cards), vendor or customer related (bank related information) and so on.

Creating / Altering Data

Is performed at the code level and defined by three main actions – Create (Insert), and Alter (Update or Delete). This relates to activities such as creating supplier or customer records, updating bank account information, or deleting an invoice line.

You can learn more about the different data classifications and the associated regulatory compliance requirements here-

The crucial aspect in determining the user’s capabilities with the data lies in the function definition.

Therefore, our focus here will be solely on the parameter that can be altered to modify the user’s interaction with the data.

This parameter is called “QUERY_ONLY=YES” and restricts that function’s ability to data retrieval only. Without getting too much into the weeds here on how functions are defined, you can click here for more information from Oracle.

A well-designed SoD and SA solution scrutinizes responsibilities down to the function level and uses this parameter value to exclude the function from the SoD and SA rules at runtime.

It’s time for change!

It has been determined that the users should retain access to the responsibility, and that they don’t, or should not be using the particular function causing the violation. Your process should be –

Document the requirement in a standard format used for initiating change requests. This should include at minimum –

• What is the change being made
• Why is the change being made
• Who is requesting the change
• Who approves the change
• When does it need to be made
• Who and how many people will be impacted
• How will the change be made
• What will happen if the change is not made
• If the change is not made, what are the mitigating controls in place to compensate for the standing risk

Create awareness of the request by meeting with the stakeholders to review the request and gather their approval to move forward. The stakeholders should be made of folks across the RACI to include –

• Process Owners
• Control Owners
• Approvers
• Certifiers
• IT Org

Once the review is complete and there is consensus to move forward (don’t forget to document approvals and store them in your ITGC change management system) it’s time to move on to the next step. This process was covered in our previous post “ITGC Change Management for Roles and Responsibilities“.

How will the changes be made?

The vast majority of these changes will be handled by something called a Function Exclusion or Menu Exclusion. This is an addendum to the access definition that allows you to remove the function or the menu from the specific responsibility without affecting the menu definition itself. This activity is carried out using the System Administrator responsibility. The violation report from your SoD / SA solution should report the violation down to the function level. You will use this function name to apply the exclusion to the responsibility definition. Navigate to System Administrator > Responsibility > Define. Query the responsibility where the function exclusion needs to be applied. On the “Menu Exclusions” tab, enter the function name that needs to be removed from the responsibility. Save your work.

Other common updates to exclude functions or fields from the responsibility using standard Oracle functionality are-

Both of these extensions can be applied to remove access or render entire forms as query only and share the same downside. Most SoD and SA solutions don’t read these extensions to exclude them from the rules at runtime and create false positives in the violation reports produced, and usually require a form of documentation for audit evidence as such.

Need help? HALEY Consulting and Advisory Services are here to support you every step of the way.