Sarbanes-Oxley

Best Practices in an
Oracle Applications
Environment
Presented by Jeffrey T. Hare, CPA
Presentation Agenda
Overview:
Segregation of Duties Best Practices
Instance Management Best Practices
SuperUser Access Best Practices
Application Security Best Practices
IT Security Best Practices
Key Setups Best Practices
Tools and Automation Best Practices
Change Management Best Practices
Other SOX Issues

© 2004 ERPS
Segregation of Duties Best
Practices

© 2004 ERPS
Segregation of Duties (SoD) Best
Practices
The
common
approach

© 2004 ERPS
SoD Best Practices

Problems with this approach:

1. Manual identification of conflicts for remediation.
2. Heavily reliant on Sys Admin group for changes going
forward.
3. Not proactive.
4. Violations during future IT Audits will be costly as you try to
prove that conflicts didn’t have material impact on financial
statements (hint: make sure you have an audit trail!)
5. Very manual.

© 2004 ERPS
SoD Best Practices

Phases:
1. Conflict Identification
2. Testing and Remediation
3. Maintenance
4. Monitoring

© 2004 ERPS
SoD Best Practices
A more thorough and automated approach:

Conflict Identification
•Identify conflicts at the business process level. Some audit
firms may supply this as part of their Risk and Controls Library.

•If not supplied by your external audit firm, have your external
audit firm confirm the SoD conflicts list.

•Translate those conflicts from business terms into your

application’s terms. In Oracle terms these are ‘functions’ that
are assigned to a menu.
© 2004 ERPS
SoD Best Practices

© 2004 ERPS
SoD Best Practices
Testing and Remediation
•Identify all users that have conflicting SoD in Oracle.

•Remediate known conflicts by developing new menus and

responsibilities or by limiting access within a form by making
changes to the custom library (or purchasing software to help
manage custom library changes).

© 2004 ERPS
SoD Best Practices
Maintenance
•Document the process to maintain the conflict matrix as new
modules and new business units are added to the system.

•Develop Change Management Processes for changes to or

new:
•Users -Access to the apps should be granted by the Sys
Admin group who should be the gatekeepers for SoD
violations. They grant access in Dev/Patch, run
incompatibilities query, then grant access in Prod (conflict
matrix.

© 2004 ERPS
SoD Best Practices
Maintenance
•Change Management Practices, cont’d:
•Responsibilities – New or changes to Responsibilities
should be reviewed the Application Security Steering
Committee, approved by workflow process.

•Request Groups – New or changes to Request Groups

should be reviewed by the Application Security Steering
Committee, approved by workflow process.

•Menus - New or changes to Menus should be reviewed by

the Application Security Steering Committee, approved by
workflow process.
© 2004 ERPS
SoD Best Practices
Monitoring
•Develop a process to audit changes to users, responsibilities,
menus, and request groups, preferably a real-time automated
solution (workflow or alert driven).

•Enable audit tracking of all processes relating to SoD so that an

audit trail can be maintained (reporting of audit trail information
is not out of the box in Oracle even if you turn on audit tracking).

•Develop a process to report the audit trail or alerts key users to

SoD violations (monitoring of Sys Admin group)

•Test controls to ascertain that they have been in effect all quarter.
© 2004 ERPS
Instance Management Best
Practices

© 2004 ERPS
Instance Management Best
Practices

•Minimum of Four Instances:

Dev – Initial development / playground
Patch – Testing of patches and family packs
Test – End-user testing instance for development/patches
Prod – Production environment
•Steering committee meets regularly to discuss priorities, includes
functional and technical users. Management to play tie-breaker,
when necessary
•May require more than four instances, smaller databases
© 2004 ERPS
SuperUser Access Best Practices

© 2004 ERPS
SuperUser Access Best Practices
•Give inquiry only or no access to Prod for IT Support
•In non-Prod environments, restrict access to limited data
•Develop “access to sensitive data” policy for IT Staff – download
templates www.erpseminars.com/resources
•Have strict policy on SQL updates in all instances. Make sure
any updates are well-documented and include management
approval (functional and technical management). Develop and
maintain audit trail.
•Have setups, new development, and SQL scripts migrated from
non-Prod environments to Prod by DBA

© 2004 ERPS
SuperUser Access Best Practices
•Beware of ability to update database through Help -> Examine
functionality (Utilities:Diagnostics profile option).
•When absolutely necessary to give SQL or form access in Prod,
document why work cannot be migrated by DBA, grant very
limited access, then revoke access when done. Ideally, only scripts
from Oracle Support would be run. Make sure you have an
adequate audit trail and functional and technical mgt approval
•Use sparingly, document broadly, be prepare to justify
•Full white paper on SuperUser Access can be requested at
www.erpseminars.com/whitepapers.html

© 2004 ERPS
 Other Application
Security Best Practices

© 2004 ERPS
Other Apps Security BP
•All standard Oracle responsibilities should be end-dated
since most have inherent SoD violations.
•Develop and enforce naming conventions for menus,
responsibilities, users, and request groups
•Any changes to menus, request groups, or responsibilities should
be done by creating custom ones:
•For ABC Corp:
• AP_NAVIGATE_GUI becomes
ABC_AP_NAVIGATE_GUI,
•Payables Manager becomes ABC Payables Manager
© 2004 ERPS
Other Apps Security BP
•Minimize or prohibit the use of function exclusion in
Responsibilities (will add complexity to maintaining SoD
documentation or monitoring queries)
•Eliminate setup menus from all users in Production. Limit
access to setup menus in non-Prod environment.
•Identify and end-date all generic logins since they hide the
identity of the person and eliminate an effective audit trail.

© 2004 ERPS
Other Apps Security BP

•Develop an Application Security Steering Committee made up of

End Users from various areas, IT management and Sys Admin.
Regularly review application security (pre-audit for Internal Audit)
•Assign unique passwords to new users, no generic passwords

© 2004 ERPS
Other Apps Security BP
• Key Profiles Options in 11i (11.5.8?)
• Signon Password Failure Limit – recommend 3, default 0 -
locks user account after failed logins
• Signon Password Hard to Guess – recommend yes, default
no - 1 letter, 1 number, not repeating char, d/n include
username
• Signon Password Length – default none, recommend 7
• Signon Password No Reuse – default 0, recommend 180
or more- # of days before password can be reused

© 2004 ERPS
Other Apps Security BP
• UMX (11.5.10) – allows for decentralized administration of
user access (Metalink Note 258281.1).
• Could allow users to grant access which may be helpful
• Could allow various locations to administer access
• Increases need to proactively monitor due to lack of
central control
• Self-Registration
• Many new workflows
• Forgot Password Support

• Remember, most theft happens from within, not from

external sources…

© 2004 ERPS
IT Security Best Practices

© 2004 ERPS
IT Security BP
Here is a sampling of IT Security Best Practices:
• Apply overall framework of CobiT. See
www.erpseminars.com/links for more information.
• Segregation of functions in IT for DBA, Sys Admin, and
Developer roles.
• Full System Administrator responsibility limited to Sys
Admin group in all instances.

© 2004 ERPS
IT Security BP
Here is a sampling of IT Security Best Practices:
• Lock down Help -> Examine functionality by:
• Make applicable forms read only via QUERY_ONLY=“YES”
in Form Functions screen
• Eliminate altogether by setting following profile options:
• Utilities:Diagnostics to No
• Corporate policy for unattended sessions (w/ desktop support)
• ICX:Session Timeout – default none, recommend 30
minutes – times out sessions (still can re-authenticate)
• ICX: Limit Time
© 2004 ERPS
IT Security BP
IT Security Best Practices Sampling, cont’d:
• Remediate ‘Apps/Apps’ access from custom development
(reports, VB, Access databases, BI systems, etc)
• Regularly change Apps password (no less than 90 days). Apps
password limited to DBA group.
• Change all Schema passwords upon initial installation. Have
DBA maintain.
• Mask or scramble sensitive data in non-production instances.
Potential impact on testing plans and strategies when
comparing to production results.

© 2004 ERPS
IT Security BP
IT Security Best Practices Sampling, cont’d:
• Require user login when responding to e-mail workflow
notifications (11.5.9?)
• Delegation of logins not looked upon favorably (Executives,
Directors) - circumvention of controls/approval hierarchies
• Trace usernames back to PCs to check for multiple logins
(audit sharing of logins) and for delegation (big brother!)
• Require user login when responding to e-mail workflow
notifications (11.5.9?)

© 2004 ERPS
IT Security BP
IT Security Best Practices Sampling, cont’d:
• Desktop security – NOT personal computers, but work
productivity tools
• Access to Sensitive Data policy – see
www.erpseminars.com/resources for policy examples.
• Audit all Security Setup Forms (see Appendix A of Metalink
Note 189367.1)
• Limit access to forms that allow entry of SQL statements or
other codes to be executed at runtime (see Appendix B of
Metalink Note 189367.1)

© 2004 ERPS
Key Setups Best Practices

© 2004 ERPS
Key Setups BP
Key Setups Best Practices Overview:
• Foundational Setups Best Practices
• Core Financials Best Practices
• Using Request Sets to Disseminate Critical Business
Information
• Using Workflow Mailer and the Scheduling Function to
Monitor Key Controls
• Using ADI and the Analysis Wizard to Report and Analyze
Financial Data

© 2004 ERPS
Key Setups BP
• Foundational Setups Best Practices:
• Cross Validation Rules and Security Rules should be
maintained by the same person or group that adds
values to your Chart of Account’s segments and makes
changes to your row sets for your FSGs.
• Use Security Rules to prevent the update of control
accounts such as AR, AP, PO Accrual, Prepayments,
Unapplied Receipts, On Account Receipts, and
Inventory Control Accounts. Also ‘secure’ Owners’
Equity Accounts so that only key GL personnel can
update them.
• Use Suspense Accounts to isolate data, where possible, to
isolate the data for reconciling purposes at month end.
© 2004 ERPS
Key Setups BP
• Foundational Setups Best Practices:
• Lockdown the Value Set update form to allow only update
to AKFF value set via Custom Library extension
• Remove setups menus from all users in Prod.
• Enable audit trail on setup forms for all applications and
key masters (customer, supplier, item, etc.) to provide for
proper audit trail

© 2004 ERPS
Key Setups BP
• Core Financials Best Practices – General Ledger:
• Implement new Journal Approval functionality
• Develop Spreadsheet Controls around spreadsheets that
develop and upload Journal Entries
• Attach supporting spreadsheets to JE to facilitate journal
approval review and on-line audit trail.

© 2004 ERPS
Key Setups BP
• Core Financials Best Practices – Accounts Receivable:
• Break apart Customer Form: Sales, Credit,
Collections, Treasury based on update needs (custom
library)
• Control access to Credit Memo’s via approval
workflow (coming in 11.5.10)
• Implement lockbox to avoid handling cash and to
automate cash receipts entry
• Review Transaction Type Setups; allow access to high
risk Transaction Types to only certain employees
(custom library)
© 2004 ERPS
Key Setups BP
• Core Financials Best Practices – Accounts Receivable:
• Mask at DB and hide fields at forms level for sensitive
customer credit card information
• Identify thresholds for major events and develop
appropriate Alerts or Workflow process to monitor:
• Ex. decrease in orders, bankruptcy or lateness of major
customer, etc.

© 2004 ERPS
Key Setups BP
• Core Financials Best Practices – Accounts Payable:
• Send Positive Pay file daily
• Implement new Invoice Approval workflow process
• Mask at DB and hide fields at forms level for sensitive
supplier bank information

© 2004 ERPS
Key Setups BP
• Using ADI and the Analysis Wizard to Report and Analyze
Financial Data:
• Harness the power of ADI…
• Publish a budget to actual P&L in ADI
• Use themes and conditional formatting to highlight
categories greater than budget by a certain amount or %
• Double click on cells of actuals where they exceed budget
figures to drill into the GL, then to Payables
• Use 11i’s new architecture in Payables to drill from the GL
back into Payables detail information (supplier, invoice,
purchase order, etc.)

© 2004 ERPS
 Tools and Controls
Automation Best Practices

© 2004 ERPS
Tools and Controls Automation
BP
• Using Request Sets to Disseminate Critical Business
Information:
• What are Request Sets?
• A grouping of concurrent requests that a user can submit
all at once
• Parameters can be shared or defaulted

© 2004 ERPS
Tools and Controls Automation
BP
• Using Request Sets to Disseminate Critical Business
Information:
• Examples:
• Dissemination of expense information via Account Analysis
Report with Payables Detail (using shared parameter for period,
but defaulting cost center for each request in the set)
• Dissemination of Aging by Salesperson – queue it to run nightly or
weekly for various salespersons (default salesperson for each request
in the set), combine with scheduling function and deliver via workflow
mailer so salespeople don’t need access to the AR system
• Users of a Responsibility to Internal Audit for key responsibilities –
System Administrator, Workflow Administrator, etc.

© 2004 ERPS
Tools and Controls Automation
BP
• Using Workflow Mailer and the Scheduling Function to
Monitor Key Controls:’
• In the Options tab when submitting a concurrent request,
choose Name in the Notify section.

© 2004 ERPS
Tools and Controls Automation
BP
• Using Workflow Mailer and the Scheduling Function to
Monitor Key Controls:
• Sample workflow generated e-mail:

© 2004 ERPS
Tools and Controls Automation
BP
Forms before controls automation:

© 2004 ERPS
Tools and Controls Automation
BP
Forms before controls automation:

© 2004 ERPS
Change Management Best
Practices

© 2004 ERPS
Change Management BP
Elements of a change management
document:
• Document Control section
• Reviewers section
• Recap of issue
• Nature of the change
• Impact Analysis of Change (DBA/Developer) Organizational
• Development Plan
• Training Plan (SOX)
Impact, not just
• Testing Plan (SOX Systems Impact!!!
• Communication Plan
• Documentation Plan (SOX)
• Process Documentation (SOX)
• Controls Testing Strategy (SOX)
• Segregation of Duties Impact Analysis (SOX)
• System Security Plan
• Transition Plan
• Contingency Plan
• Reviewer Sign-Off Section © 2004 ERPS
Audit Tracking Recap

© 2004 ERPS
Audit Tracking Recap
Here is a recap of the minimum audit tracking that needs to be
enabled to support Internal and External Audits:
• Users, Responsibilities, Menus, Request Groups
• Key foundational setups in each module (example in
Payables – Payables Options, Payment Terms, etc.)
• Key transactional setups in each module (examples
include Supplier Master, Customer Master, Item Master,
etc.)
These will be heavily audited for compliance with proper change
management practices. Efficient reporting of such needs to be
developed.
© 2004 ERPS
Other Current SOX Issues

© 2004 ERPS
Other Current SOX Issues
• Spreadsheet controls
• Interface cleanup
• Q4/Year End earnings release analyst calls –
1/2005, 2/2005

© 2004 ERPS
Q&A

© 2004 ERPS
Best Practices Caveat
Best Practices Caveat
The Best Practices cited in this presentation have not been
validated with your external auditors nor has there been
any systematic study of industry practices to determine
they are ‘in fact’ Best Practices for a representative sample
of companies attempting to comply with the Sarbanes-
Oxley Act of 2002. The Best Practice examples given
here should not substitute for accounting or legal advice for
your organization and provide no indemnification from fraud
or material misstatements in your financial statements.

© 2004 ERPS
ERP Seminars Info
 Cell for Jeff: 602-769-9049
 E-mail: jhare@erpseminars.com
 Website: www.erpseminars.com (request various WPs)
 Fall seminar series: Dallas, Chicago, Minneapolis, NorCal,
SoCal, Boston, Philadelphia
 Spring seminar series will probably include Atlanta
 #1 Action Point for you! Sign up for Oracle SOX eGroup at
http://groups.yahoo.com/group/OracleSox/
 Working on the following White Papers :
BP for SuperUser Access, BP for IT Security, BP for DBAs,
BP for Developers, BP in an Upgrade/ Implementation
 Leave card if you want copies of slides
© 2004 ERPS