Active Monitoring of SOD Not Optional

8/10/2019 Active Monitoring of SOD Not Optional

1/11

Active Monitoring of Segregation of Duties, Not Optional

AbstractImplementing proper Segregation of Duties (SOD) in an Oracle Applications

Environment has challenges. Active Monitoring for SoD violations is important tomaintain good controls because of various risks relating to developing and maintaining

SoD.

Executive Summary

One of the most critical areas of Sarbanes-Oxley (SOX) compliance has been theimplementation of Segregation of Duties (SOD). Organizations need to be aware of the

risks associated with developing and maintaining proper SOD in an Oracle Applications

environment. Although many companies have implemented either a Role-Based orResponsibility Conflict Matrix approach to developing and maintaining proper SOD,

proactive monitoring for conflicts is a prudent step in the development of internal

controls and of an AntiFraud program as is required by SOX.

Because of the nested nature of the menus and various levels of submenus, identifying

the various Functions by which business processes can be performed can be difficult or

next to impossible if done manually. Beyond the initial identification of SOD, SOXrequires companies to maintain the proper SOD on an ongoing basis. SOX also requires

companies to develop an AntiFraud program, for which SOD is a key issue to address.

Because of inherent risks in the Oracle Applications, and certain development andmaintenance practices, SOD violations can be introduced advertently or inadvertently in

many ways.

There are various tools in the marketplace that have been introduced to proactivelymonitor for SOD violations, including tools from Oracle, Applimation, Logical Apps.

Changes that need to be addressed in the application include the following:1. New Users or changes to Users that allow a User to have conflicting Functions

through one or more Responsibilities.

2. Changes to Responsibility definitions, including Function Exclusions, whichintroduce conflicting functions to one or more Users.

3. Changes to Menu definitions that introduce conflicting functions to one or more

Users.4. Additional Functions being registered since new functions could be registered

having the same business function as another function.5. Functions to be changed in order to be associated with different objects.6. Changes to Function Names at the database level.

As companies move from their initial SOX projects in 2004 to controls automation and

monitoring in 2005, many companies will look for ways to proactively prevent andmonitor for SOD violations. Doing so will demonstrate tighter controls and a more

proactive Antifraud program.


2/11

White Paper

One of the most critical areas of Sarbanes-Oxley compliance has been the

implementation of Segregation of Duties. The intent of Segregation of Duties (SOD) is

to avoid the circumstance which one individual can perform functions which areinherently in conflict with one another, such as Purchasing and Accounts Payable,

Purchasing and Receiving, General Ledger and Supply Management, etc. Developingappropriate SOD is necessary for the development of good internal controls and as part of

an Antifraud program. In Oracle terms, implementing SOD means that no one User

could gain rights to conflicting Functions through and Responsibility or combination ofResponsibilities.

As an example, no one user should have the ability to both enter a supplier and enter an

invoice for a supplier. Such an arrangement would allow a person to enter a fraudulentsupplier and also enter invoices against that supplier. Absent mitigating controls, a

payment would be made against that invoice and the employee would have stolencompany assets.

Current State

Companies have used various methods to identify conflicts in their Production system,including reviewing Responsibilities manually, running scripts or a stored procedure

against the various tables, and by using the vastly inadequate reports available in the

System Administrator Responsibility. Next, companies have remediated such conflicts

by setting up new Responsibilities and new Menus that match the business processes andcontrols they have defined. However, even if a company has properly identified and

remediated such SOD violations, there is still risk that they will not be properly

maintained.

After the initial remediation phase, most companies address SOD in one of two ways.

The first is a Role-Based approach. The second is the use of a Responsibilities ConflictMatrix.

Two Common Approaches to SOD Monitoring

The Role-Based approach starts by identifying and assigning Responsibilities proper forcertain roles in the company. More often than not, these roles are associated with a given

job title. The Responsibilities given to each role are reviewed by the organizations

process group and/or internal audit function to be certain there are no violations of SOD.On an ongoing basis, the Sys Admin group is expected to grant the Responsibilities only

in keeping with each employees role.

The Responsibilities Conflict Matrix approach would look something like this:


3/11

In this matrix, Responsibilities that have conflicting function within them are identified

and marked with an X. When Responsibilities are requested for certain individuals, itis up to the Sys Admin group to review this conflict matrix to determine that the granting

of such Responsibility for a given User would not cause a conflict with the other

Responsibilities they already having been granted.

Inherent in both the Role-Based approach and the Responsibilities Conflict Matrix

approach is the assumption that this process is clearly documented, understood by, andfollowed by the Sys Admin group. However, what happens when the Sys Admin group

makes a mistake or knowingly violates the process?

To demonstrate the effects of such a conflict, lets discuss a potential scenario that couldunfold at your company. Suppose that a person who can enter invoices is granted the

ability to enter suppliers in January and this error goes undetected until your internal

controls audit (404 audit) in November of that year. Your auditor will ask you to provethat such a lapse of internal control did not cause a material misstatement of your

financials statements. No problem, right? You start by pulling an audit trail of every

Supplier entered and any change to the Supplier Master from January until November.

To start, the ability to pull this audit trail may be lacking. Standard audit trail within theapplications is to tell you who and when that record was created and by whom and when

the record was last updated. However, the audit trail doesnt tell you what was changed

or anything about the changes in between the time it was created and when it was lastupdated. A record could have been changed six times, but the system will only tell you

information by whom and when the record was LAST updated.


4/11

Lets assume, however, that you have been following the thought leadership of ERP

Seminars in this area and you were aware of the lack of a sufficient audit trail. Becauseof this, you enabled Oracle Audit at the table level for the tables associated with the

Supplier Entry form. By pulling a full audit trail of this information, you were able to

ascertain that the employee who had been erroneously granted the Supplier Entry

Responsibility had not entered any Suppliers in this time frame. Case closed. Yourauditors ask you to correct the issue and, more than likely, such internal control weakness

is not reported on your Section 404 report.

Lets pull back this assumption and discuss where you may have been had you not

enabled Oracle Audit on the appropriate tables. What you are left with in this scenario isan inadequate audit trail on the entry of Suppliers and left with much more work to prove

that such lapse in SOD didnt cause a material misstatement of your financial statements.

This could involve reviewing every Supplier and all material invoices added in this time

frame to confirm that they are invoices for legitimate business purposes. This may provethe lack of a material misstatement in your financial statements, but may not prove an

effective antifraud program.

Problems with the Current Approaches

Both the Roles-Based and Responsibility Conflict Matrix can leave your company with

risks in the SOD area. First, if your company has a substantial amount of menus,responsibilities, and users, the process to review the impact of this tangled web would

leave even the most determined employee frazzled. Menus have several layers of

submenus associated with them and identifying the Functions within each Menu can be a

difficult task in and of itself. The second task, tracing these through the Responsibilitiesthat connect these menus to the various Users is another challenge. Finally, analyzing the

combination of Responsibilities for each and every user to be certain that no one User has

conflicting Functions given all their granted Responsibilities is indeed a daunting task.

Now introduce the usual challenges of a understaffed IT department poor training,

poorly documented change management practices, job turnover, critical requests andintentional fraud are all possible scenarios where your System Administrator could

introduce SOD violations into your applications or commit fraud themselves.

Challenges at Companies with Large Number of Users

Companies with a large number of users of Oracle Applications have had a difficult time

reviewing for potential violations due to the sheer volumes of Users and corresponding

Responsibilities. Many have developed stored procedures, VB scripts or other methodsof extracting the various data needed to assess SOD violations. This data is challenging

to extra because of the nested nature of menus whereby the ultimate code for a given

business process can be several layers down buried in a submenu of a submenu of asubmenu.

Let me illustrate this dilemma. Lets start by imagining I am part of the IT staff and havebeen tasked by the CFO to determine which users have both the ability to Enter Suppliers

and Enter Invoices in Accounts Payable, a common issue when reviewing for SOD


5/11

violations. I will first start by trying to identify all the Menus and related Responsibilities

that can enter a Supplier. In order to determine what the Enter Suppliers Function lookslike in Oracle, you start with the seeded Payables Manager Responsibility since you

know that comes with the ability to enter a Supplier. That Responsibility screen looks

like this:

This Responsibility comes seeded with a Menu called AP_NAVIGATE_GUI12.

The next step is to dig further to determine what makes up this Menu so I query up the

AP_NAVIGATE_GUI12 menu and get this screen:

As a former auditor, I recognize two things that concern me. First, I recognize that thismenu can be modified. That is, I can insert lines so that I can add Functions to a seeded

menu. That means as I analyze the various Responsibilities and related Menus, I cannot

rely on the fact that what appears to be a standard Oracle menu is still standard. I


6/11


7/11

I changed the User Function Name to something totally unrelated to the fact that thisfunction allows me to enter Suppliers. What happens when I look back at the Suppliers

Submenu that we queried earlier? Here is how it now shows in that screen:

It now displays the User Function Name of Jeffs Function that has nothing to do withthe fact that it allows a User to enter a Supplier (note for illustration purposes, I also

changed the description on this line which is also updateable).

What does this illustrate? If you are trying to protect your company from fraud, you must

query for SOD violations at the point where someone with access to these forms cannotchange the data. The only field through this process that cannot be changed is theFunction name (i.e. AP_APXVDMVD).


8/11

The Function Name in this form is AP_APXVDMVD. Note that this field is updateableat the database level and, therefore, anyone with access to these forms should not be

allowed access to the Production database. For more information on this topic, see twowhite papers written by us on Production database access for System Administrators and

Super Users at www.oubpb.com/requestwp.html.

This Function Name is what most companies have used to query for SOD violations at

the database level. How, you ask, is this accomplished?

First, each business process conflict of interest is identified. We will stick with the

example where any single user should not have the ability to both enter a Supplier andenter an invoice in Accounts Payable (assuming we have no other mitigating controls in

this process). Next, each Function in the application that can perform this business

process needs to be identified. For entering a supplier, there are at least two suchFunctions in the Applications. The first, we identified above at AP_APXVDMVD. Thesecond is a similar in the purchasing forms called PN_APXVDMVD.

Every Function related to each business process needs to be identified and put on aconflict matrix like this:

Process A Process B Function(s) for A Function(s) for B

Enter Suppliers Enter Invoices AP_APXVDMVD,

PN_APXVDMVD

AP_APXVDDUP,

AP_APXVDMVD

If you havent started developing this information yet, the magnitude of the task can seemoverwhelming. Add to the complexity is the possibility that other Functions may beadded to perform this business process as new modules are added to the Applications.

For example, in 11i the iProcurement module introduced a new Function called

ICX_SUPPLIER_REG.

The process is complicated further by the need for a fairly complex query (via a stored

procedure or other mechanism) and monitoring the tables for violations on an on-going


9/11

basis. The data necessary to analyze for SOD is contained in up to nine different FND

tables representing Users, Responsibilities, Menus and Functions.

The end result, for many companies, is to look for a solution that is in the public domain

or available for purchase.

Tools in the marketplace

Oracle first paved the way for companies trying to identify users with conflicting SOD byits development of an incompatibilities matrix as part of its Internal Controls Manager

(ICM) module. This product allows for the query and monitoring (with workflow

notification where violations or certain conditions exist) of SOD at the Function level andworkflow notifications if violations or certain conditions exist. However, the drawback

to Oracles incompatibilities matrix is that is doesnt come seeded with the Functions that

are conflicting similar to the illustration above. Oracle has cited legal risk in their

decision to not provide the content for this tool. In their defense, there are a lot of factorsthat need to be considered outside of the basic querying of data when determining if a

user indeed has a SOD violation. In our example, we have cited that the entering of asupplier and entering of an invoice in Accounts Payable could be considered a SODviolation if both Functions were available to one person. However, it may be acceptable

for a person to have both processes if there is a process to review a preliminary payment

register before payments are issues or if the checks are reviewed before they are signed.In light of the various conditions, no silver bullet can be developed by Oracle (or any

other company for that matter) to identify and monitor for SOD violations. Such

potential conflicts always have to be considered in light of the overall process and other

controls in place.

Having recognized that Oracle will not provide this content, we have being trying to

build such a matrix with the input of users so that other users may benefit from such amatrix. The net result will be a public domain list of conflicting Functions that can be

found at www.oubpb.com.

Aside from efforts in the public domain and Oracles development of the tool, other

companies have been working towards a comprehensive solution to the SOD monitoring

problem. The two companies that are leading the way in this area are Applimation

(www.applimation.com) and Logical Apps (www.logicalapps.com). Recent newcomersin this space include Approva (www.approva.net) and UK-based ApplTop Solutions

(www.appltop.com)

The author of this white paper doesnt endorse any solution, but provides this information

in case there is interest in understanding what is available in the marketplace.

Comprehensive Proactive Monitoring is Required

Ideally a proactive monitoring process for SOD violations will approach the problem

from many angles. Proactive monitoring will also monitoring and reviewing for thefollowing:


10/11

1. New Users or changes to Users that allow a User to have conflicting Functions

through one or more Responsibilities.2. Changes to Responsibility definitions, including Function Exclusions, which

introduce conflicting functions to one or more Users.

3. Changes to Menu definitions that introduce conflicting functions to one or more

Users.4. New Functions being registered since new functions could be registered having

the same business function as another function.5. Functions to be changed in order to be associated with different objects.

6. Changes to Function Names at the database level.

New Users or Changes to Users

As indicated earlier, many companies take either a Role-Based or Responsibilities

Conflict Matrix approach. This requires the System Administrator to know and

understand the approach and to enforce the approach as requests for new Users orchanges to existing Users are made.

Changes to Responsibility Definitions or Function Exclusions

There are several things that can be changed at the Responsibility level. They include

which Menu is associated with the Responsibility, the Request Group associated with the

Responsibility, and the Function exclusions. Function exclusions are used to excludecertain Functions from the Menu assigned to the Responsibility. Function exclusions

allow for the use of a basic menu to be used for more than one Responsibility without

having to establish a unique Menu for each. As an example, suppose you have a menu in

the General Ledger that allows for both Journal Entry and Posting of such Journals alongwith other functions. This menu could be used to establish a Responsibility called

General Ledger Supervisor using the base menu. Then, a second Responsibility called

General Ledger User could use the same function and exclude the Functions PostJournals and Enter Journals: Post Journals which would exclude the ability of the General

Ledger User from posting the journal entries.

Changes to Menu Definitions

The Menu defines what Functions a Responsibility can access. In Oracle terms, the

Function is the callable code to perform a business process. In some cases, multiple

Functions are registered in the application that will perform the same business process.For example, there are two Functions that allow for the entry of Suppliers. One is called

AP_APXVDMVD (called by AP) and the other is called PN_APXVDMVD (called by

Purchasing). Whenever a Function is added to an existing menu, there is added risk thatthe Responsibilities using that menu may give one or more Users a SOD conflict.

New Functions Being Registered

Risk can be introduced when a new function could be registered. The risk would be that

someone (for example a Developer or System Administrator) could register a new

Function that wasnt being actively monitored and, therefore, could bypass themonitoring mechanism.


11/11

Functions Being Associated with Different Objects

Objects are base-level code that are stored in the Application Layer and then associatedwith a process in the application via the registering of a Function. There is a risk that

someone (for example a developer) could build a new object from scratch or copy an

existing object(s) and replace an existing object associated with a Function already

registered in the Application. In doing so, they could override the controls and use theFunction to commit fraud.

Changes to Function Names at the Database Level

Finally, risk is introduced when the Function Name that has been identified to monitor in

the incompatibilities matrix or in a custom stored procedure is changed at the databaselevel. It is prudent to monitor the FND tables where these Functions are stored to

ascertain that no user has updated the Function name. If a user updates the Function

Name, the monitoring mechanism you have in place would not query for the changed

Function Name or a user could use the updated Function Name as part of a new orexisting menu to enter data, thereby enabling them to commit fraud.

Conclusion

As companies move from their initial SOX projects in 2004 to controls automation and

monitoring in 2005, many companies will look for ways to proactively prevent and

monitor for SOD violations. Doing so will demonstrate tighter controls and a moreproactive Antifraud program.

About the AuthorJeffrey T. Hare, CPA is the founder of ERP Seminars ( www.erpseminars.com) and the Oracle User Best PracticesBoard (www.oubpb.com) and has written various white papers on SOX Best Practices in an Oracle Applicationsenvironment. He has presented white papers to various users groups throughout the country as well as at OAUG andAppsworld conferences. He is the author and presenter of the seminar SOX Best Practices in an Oracle Applications

Environment. His background includes Big 4 experience, over six years experience in CFO/Controller roles, and the

past 7 years in the Oracle Financials space. Jeff can be reached [email protected].

About ERP Seminars:

We recognize the need for companies to have continuing knowledge of industry Best Practices. We team with

respected independent consultants and firms to provide quality, relevant seminars based on these Best Practicesprepared and presented by well-rounded professionals with ERP expertise.

About Oracle Users Best Practices Board:The mission of the OUBPB is the aggregation of willing writers and reviewers who will participate in a process todevelop Best Practices for the Oracle community. The end result will be a repository of "best practice" white papersand other content for end users and consultants to reference in their projects and ongoing development.

Version Control

Date Author Version Change Reference

19-May-05 Jeff Hare 1.0 No Previous Document

20-Sep-05 Jeff Hare 2.0 Updated SOD Third Party providers, links

Documents

Active Monitoring of SOD Not Optional