Active Monitoring of Segregation of Duties, Not Optional

Abstract
Implementing proper Segregation of Duties (SOD) in an Oracle Applications
Environment has challenges. Active Monitoring for SoD violations is important to
maintain 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 the
implementation 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 or
Responsibility 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, SOX
requires 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 and
maintenance practices, SOD violations can be introduced advertently or inadvertently in
many ways.
There are various tools in the marketplace that have been introduced to proactively
monitor 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, which
introduce 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 and
monitor for SOD violations. Doing so will demonstrate tighter controls and a more
proactive Antifraud program.

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 are
inherently in conflict with one another, such as Purchasing and Accounts Payable,
Purchasing and Receiving, General Ledger and Supply Management, etc. Developing
appropriate 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 of
Responsibilities.
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 fraudulent
supplier and also enter invoices against that supplier. Absent mitigating controls, a
payment would be made against that invoice and the employee would have stolen
company 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 and
controls 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 Conflict
Matrix.
Two Common Approaches to SOD Monitoring
The Role-Based approach starts by identifying and assigning Responsibilities proper for
certain 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:

In this matrix, Responsibilities that have conflicting function within them are identified
and marked with an X. When Responsibilities are requested for certain individuals, it
is 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, and
followed 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 could
unfold 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 prove
that 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 the
applications 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 last
updated. 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.

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. Because
of 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. Your
auditors 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 is
an 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 prove
the 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 Responsibilities
that 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 and
intentional 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 methods
of 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 a
submenu.
Let me illustrate this dilemma. Lets start by imagining I am part of the IT staff and have
been 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

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 looks
like 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 this
menu 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

cannot be sure that someone hasnt added to this menu, thereby making it custom.
Second, I recognize that this menu is made up of a series of Submenus. Therefore, each
menu will have several layers associated with it.
Next, to try to get to the bottom of how a Supplier can be entered, I query the
AP_SUPPLIERS_GUI12 submenu and get this screen:

When I get to this screen, I recognize that at the first line, I have both a Submenu
assigned to it (AP_APXVDMVD_MENU) and a Function called Enter Supplier. So
the Function called Enter Supplier is what provides me the ability to enter a supplier on
the Suppliers form, right? Kinda There is a hitch. Lets look at the definition of this
Function as follows:

Once I get to this screen, I recognize the fact that the User Function Name is updateable.
What happens if I change the User Function Name?

I changed the User Function Name to something totally unrelated to the fact that this
function 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 with
the 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 cannot
change the data. The only field through this process that cannot be changed is the
Function name (i.e. AP_APXVDMVD).

The Function Name in this form is AP_APXVDMVD. Note that this field is updateable
at 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 two
white 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 and
enter 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 such
Functions in the Applications. The first, we identified above at AP_APXVDMVD. The
second is a similar in the purchasing forms called PN_APXVDMVD.
Every Function related to each business process needs to be identified and put on a
conflict matrix like this:
Process A
Enter Suppliers

Process B
Enter Invoices

Function(s) for A
AP_APXVDMVD,
PN_APXVDMVD

Function(s) for B
AP_APXVDDUP,
AP_APXVDMVD

If you havent started developing this information yet, the magnitude of the task can seem
overwhelming. Add to the complexity is the possibility that other Functions may be
added 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

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 by
its 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 and
workflow 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 factors
that 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 a
supplier and entering of an invoice in Accounts Payable could be considered a SOD
violation 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 a
matrix. 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 newcomers
in 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 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, 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 or
changes 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 exclude
certain 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 along
with 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 Post
Journals 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 that
the 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 the
monitoring mechanism.

Functions Being Associated with Different Objects

Objects are base-level code that are stored in the Application Layer and then associated
with 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 the
Function 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 database
level. 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 or
existing 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 more
proactive Antifraud program.
About the Author

Jeffrey T. Hare, CPA is the founder of ERP Seminars (www.erpseminars.com) and the Oracle User Best Practices
Board (www.oubpb.com) and has written various white papers on SOX Best Practices in an Oracle Applications
environment. He has presented white papers to various users groups throughout the country as well as at OAUG and
Appsworld 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 at jhare@erpseminars.com.
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 Practices
prepared 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 to
develop Best Practices for the Oracle community. The end result will be a repository of "best practice" white papers
and 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
20-Sep-05

Jeff Hare
Jeff Hare

1.0
2.0

No Previous Document
Updated SOD Third Party providers, links