Apps Segregation of Duties

SOD Remediation for Oracle Applications
January 17, 2008 NorCal OAUG Training Day

2007 Protiviti Inc. Confidential: This document is for internal use only and may not be distributed to an outside party.
Introduction
Vision without action is a daydream. But action without vision is a nightmare.

- Japanese Proverb
Oracle Implementation/Upgrade
PEOPLE
Users/Roles
PROCESSES
Business Flows
TECHNOLOGY
Oracle Applications
Training Objectives
Segregation of Duties Overview (SoD) SoD Assessment Approach Segregation of Duties Assessment Case Study Controls Areas to Consider During An Upgrade or Implementation Project to Prevent Future Stand-Alone Remediation Projects
Segregation of Duties Overview
Common Compliance Pain Points

Using/customizing seeded responsibilities and menus Responsibilities were not designed with SOX in mind or were not designed at all (seeded responsibilities are used out of the box) Trying to find/assess SoD conflicts without a tool (manual methods will miss places where users have access)
Segregation of Duties (SOD) Basics

Segregation of Duties is meant to reduce the risk of concealment of employee error or fraud by separating the following high level functions:
The recording of a transaction The authorization of the transaction Custody of the asset Control procedure (i.e. reconciliation)
An essential feature of segregation of duties or responsibilities within an organization is that no one employee or group of employees has exclusive control over any transaction or group of transactions.
Opportunities for Automated Controls to Enforce SoD
Transaction Processes
Transaction Approvals
Access to Physical Assets
Reconciliations
Segregation of Duties (SOD) Conflict Types

Three-way SOD conflict - An individual can perform three of these four duties for a given asset:
Custody of assets Authorization or approval of related transactions affecting those assets Execution of the transaction or transaction activity Reconciliation of related transactions
Two-way SOD conflict - An individual can perform two of these four duties for a given asset
Segregation of Duty (SOD) Issues

Role-based access often drives potential SOD issues Access should be granted based on pre-defined job descriptions Role-based security access should be customized per the business needs not using out of the box profiles that typically do not address SOD and grant powerful access
Segregation of Duties (SOD) Examples

Users with Voucher Entry & Purchase Order Entry Users with Voucher Entry and Create Payments Users with Create Receipts and Enter Sales Invoices Users with access to business process should not have access to post Journal Entries Users with Administer Payroll and Administer Workforce Users with access to Payroll and HR present a risk of adjusting salaries, running payroll, then changing salaries back Beware of Sysadmin , Super User and other IT users with powerful access!
Segregation of Duties Assessment Approach
Our Approach to Optimizing & Sustaining ERP Compliance

Project to Process SoD, Security, Access, Provisioning, Application & Process Controls
Analyze
Perform assessments via Protiviti Assure methodology Deploy on internal audit and SOX clients or new clients to prove the case
ERP Assessments
Consulting & Remediation Services Standardize
Standardize
Continuous Monitoring Software Automate Clean-up Security/SOD issues Design automated controls Re-engineer SOX testing approach Design controls into new implementations
Analyze
Automate
Implement continuous monitoring systems
Optimize Automated Controls

An integrated implementation approach is necessary to design effective internal controls, understanding that system-based controls are more reliable and desirable. This pertains to both General Computer Controls as well as embedded application-specific controls. It is more efficient to get these right at the time of implementation.
Standard within the Software SystemBased Detective Controls Reliable SystemBased Preventive Control Configuration Options Application Security Effectiveness in SOX Testing Efforts Policies Procedures Monitoring Exception Reporting Reconciliations Desirable
PeopleBased Detective Control
PeopleBased Preventive Control
Extensive SOX Testing Efforts
Segregation of Duties Assessment Case Study
Case Study Scenario

Project: SoD Remediation Objective: To assist the client with remediation of SoD conflicts and user access to sensitive abilities in Oracle prior to their External Audit. Tools:
Oracle Internal Controls Manager (ICM) The client's corporate SoD Rule Set
Approach:
1. Review the initial SoD conflict and Sensitive Abilities results using ICM constraint reports 2. Identify any false positives and enter the appropriate waivers in ICM 3. Review the remaining SoD conflict and Sensitive Abilities results with the appropriate business owners to determine what security changes can be made to resolve the issues 4. Develop mitigating control suggestions based on input from management to address remaining conflicts
Examples from the Procure to Pay (PTP) Cycle

Sensitive Ability Constraints Reviewed: Transaction Set Up SOD Constraints Reviewed: Create PO/Blanket PO Maintain PO/Blanket PO Receive Goods Receive Goods Process Invoices Process and Maintain Invoices Process and Maintain Invoices Process and Maintain Invoices Process and Maintain Invoices Process Debit/Credit Memos Process Debit/Credit Memos Process Debit/Credit Memos Process Debit/Credit Memos Release Invoice Holds Maintain Buyers - Buyers Maintain Approvals Signing limits Maintain Buyers Maintain Buyers Create PO/Blanket PO Maintain PO/Blanket PO Process Payments Create PO/Blanket PO Maintain PO/Blanket PO Receive Goods Maintain Goods Maintain PO/Blanket PO Receive Goods Maintain Goods Process and Maintain Payments Receive Goods
Examples from the Order to Cash (OTC) Cycle

Sensitive Ability Constraints Reviewed: Set Up Set Up SoD Constraints Reviewed: Enter Cash Receipts Enter Cash Receipts Enter Cash Receipts Create Customers Create Customers Create Customers Create Customers Create Customers Create Customers Create Customers Maintain Customers Profile Maintain Customers Profile Maintain Customers Profile Maintain Customers Profile App Invoice Adj Process AR Inv / Process Trans App Invoice Adj
AR and OM Setup Interface Processing

Enter Sales Orders Approve Invoice Adjustments Process AR Invoices Enter Sales Orders Enter RMA Process Debit/Credit Memos Process AR Invoices Process Transactions Enter / Maintain Cash Receipts (2) Maintain Misc Cash Receipts Enter Sales Orders Enter Cash Receipts Maintain Cash Receipts Maintain Misc Cash Receipts Process Inv Adj Approve Invoice Adj (2) Maint Inv Adj
Sample PTP ICM Violation Report
Inter-Responsibility Conflict
Sample OTC ICM Violation Report
Intra-Responsibility Conflict
PTP Conflict Compensating Control Suggestions

Conflict Create PO / Maintain Buyers Possible Compensating Control Configurable Control: PO Approval Groups and Assignments; Do not allow "Owner can Approve" his own PO Process DM CM / Process Payments Erroneous or unauthorized Check Signatures, Invoice Matching payments to vendors Process; Hold Unmatched Invoices Process Invoices / Create PO Erroneous or unauthorized PO Approval hierarchy, Invoice Matching payments to vendors Process; Hold Unmatched Invoices Process Invoices / Maintain Erroneous or unauthorized Inventory Cycle Counting, Invoice (Receive) Goods payments to vendors Matching Process; Hold Unmatched Invoices Process Invoices / Maintain PO Erroneous or unauthorized PO Approval hierarchy, Invoice Matching payments to vendors Process; Hold Unmatched Invoices Process Invoices / Process Payments Erroneous or unauthorized Check Signatures, Invoice Matching payments to vendors Process; Hold Unmatched Invoices Receive Goods / Create or Maintain Unauthorized purchase or PO Approval hierarchy, Invoice Matching POs erroneous recording of liability Process; Hold Unmatched Invoices Release Invoice Holds / Receive Erroneous or unauthorized Inventory Cycle Counting, Invoice Goods payments to vendors Matching Process; Hold Unmatched Invoices Risk Unauthorized Buyer can create PO
OTC Conflict Compensating Control Suggestions

Conflict Approve Invoice Adjustment / Maintain Invoice Adjustment Create Customer / Enter Cash Receipts Create Customer / Enter RMAs Create Customer / Enter Sales Orders Create Customer / Maintain Cash Receipts Create Customer / Process DM CM Risk Unauthorized write off of invoices Fictitious customer; hide cash receipt Possible Compensating Control Configurable Control: Approval Limits
Enter Cash Receipts / Approve Invoice Adjustments Maintain Customer Profile / Enter Sales Orders Maintain Customer Profile / Maintain Misc Cash Receipts
Customer Statements; SoD of handling, logging and depositing of checks received from customers; bank reconciliations Unauthorized credit given to Customer Statements, review of open customers RMAs Unauthorized sales order and Configurable Control: Sales Order shipment of goods Approval workflow Hide cash receipt Review of Reversed Cash Receipts; Cash Receipt deletion not allowed by the system Unauthorized credit given to Customer Statements; Review of AR customers; Unauthorized Aging; SoD of handling, logging and changes to customer records; depositing of checks received from hide cash receipt customers; bank reconciliations Unauthorized write off of Configurable Control: Approval Limits invoices Unauthorized sales order and Configurable Control: Sales Order shipment of goods Approval workflow Hide cash receipt SoD of handling, logging and depositing of checks received; bank reconciliations
Additional Recommendations
The following are improvements that would eliminate the need for compensating controls:
Restrict Access for Release Holds and Sales Order entry. Access to the Sales Order form is required to be able to release holds. The ability to Release Holds, however, should be excluded from those users who should NOT be able to release an order. The best practice is to restrict this access to those in credit management who approve the release of credit hold on an order. This is normally considered the higher risk area with regards to Sales Order processing. Rearranging department responsibilities to make supervisors only an approver and reviewer, not doers. This would mean that access for supervisors is mostly View Only, except for the approval of transactions. The team would have the access to process transactions. Supervisors would approve any changes or adjustments and delegate to processing to their teams. Functions with Inquiry Only access should by designated as View Only in the function name to simplify future audit related activities. This can be done by creating a copy of the normal function, giving it a name with View Only in it, and adding the parameter in the function, QUERY_ONLY="YES". By designating these functions clearly, the access would be more easily justified.
Additional Recommendations (Cont.)

The following are improvements that would eliminate the need for compensating controls:
Access to Setups should be limited to Inquiry Only Access. The IT and Business Analysts should be given a responsibility that has Inquiry Only access to all setups in production, but read/write access in a development environment. This would enable them to view any setup for troubleshooting. When they determine that a change should be made in the system, they should follow the Change Management process: file a change request and have it tested in dev and approved by the business owner. When the approval is received, the System Administrator would grant the BA temporary access to the Super User responsibility to make the change in production. This is considered a best practice, as it keeps Super Access to a minimum. Access to Super User responsibilities should also be granted on a temporary basis only and be controlled through the change management process. The process should require appropriate business/process owner approval prior to granting temporary access. Responsibilities granted temporarily should be end dated at the time the access is granted based on the amount of time access is needed.
Control Areas to Consider During An Upgrade or Implementation Project to Prevent Future Stand-Alone Remediation Projects
Transaction Processing Controls

Business processes supported and impacted by applications must ensure information integrity through effective design, development, and usage of: Automated Application Controls
field edits workflow approvals error messages matching tolerances number ranges default values posting keys document matching recurring entries
Manual Process Controls

policies and procedures reconciliations, reviews and approvals management reporting
Application Interface Controls

restart and recovery procedures control totals job monitoring error handling transaction logs historical data access transaction references meaningful descriptions/ classifications
Facilitation of Audit Needs
Security Administration
Security strategies, tools, personnel, and processes should be coordinated effectively to address the following key components:
Administration
provisioning (granting, termination, and modification) of user IDs workflow / approvals tool administration password resetting password parameters
Segregation of duties
separation of incompatible functions data owner monitoring of access levels
Sensitive access
powerful authorities post-implementation support
Data Management
As part of the implementation, data must be converted and then maintained to ensure the integrity of system processing. The following are critical considerations in this area:
Data Conversions
data mappings conversion design conversion testing reconciliation
Master Data Maintenance

data ownership policies and procedures impact analysis
Data Archiving
system performance and storage requirements data access requirements data redundancy
Data Cleansing
inactive data duplicative data erroneous data
During an upgrade data management activities may just relate to completing the upgrade process steps of what to correct by module (i.e. data re-mapping, etc.)
Change Management & Testing

Change management is critical for ensuring consistency of processing throughout an applications life cycle. This effort includes:
Client strategy (e.g. dev, test, prod) Image refreshes Object migration Problem management for ongoing changes Version control
All development and implementation efforts must include thorough testing to ensure defined solutions are complete and accurate. This effort includes:
Comprehensive test plan for functionality, security, and controls Documented test cases and test results Sign-off and acceptance Use of positive and negative testing techniques
Things to Consider When Implementing/Upgrading

ERP systems are already built with standard business process functionality and it is best to try to avoid programming, meaning we want to implement the out of the box solution, and limit customizing the application as much as possible Limiting customizations and designing them correctly can prevent problems when upgrading in the future. For example, creating new customized menus with unique names with prevent overrides during upgrades which can occur if you customize a standard menu. The difference between a manual control and an automated one is mostly a change of focus from detective to preventive control. Preventive controls are considered to be stronger and therefore preferred controls. The more automated controls you can implement (instead of relying on manual controls) can significantly reduce audit/testing efforts. Automated controls can be tested immediately and require only 1 sample , while manual controls must be demonstrated over time and multiple samples must be tested based on control frequency (i.e. daily, monthly, etc.).
Summary
Segregation of Duties Overview (SoD) SoD Assessment Approach Segregation of Duties Assessment Case Study Control Areas to Consider During An Upgrade or Implementation Project to Prevent Future Stand-Alone Remediation Projects
Questions?

Apps Segregation of Duties

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Apps Segregation of Duties

Hochgeladen von

Copyright:

Verfügbare Formate

SOD Remediation for Oracle Applications

January 17, 2008 NorCal OAUG Training Day

Vision without action is a daydream. But action without vision is a nightmare.

Segregation of Duties Overview

Common Compliance Pain Points

Segregation of Duties (SOD) Basics

Opportunities for Automated Controls to Enforce SoD

Access to Physical Assets

Segregation of Duties (SOD) Conflict Types

Segregation of Duty (SOD) Issues

Segregation of Duties (SOD) Examples

Segregation of Duties Assessment Approach

Our Approach to Optimizing & Sustaining ERP Compliance

Consulting & Remediation Services Standardize

Optimize Automated Controls

PeopleBased Detective Control

PeopleBased Preventive Control

Extensive SOX Testing Efforts

Segregation of Duties Assessment Case Study

Case Study Scenario

Examples from the Procure to Pay (PTP) Cycle

Examples from the Order to Cash (OTC) Cycle

AR and OM Setup Interface Processing

Sample PTP ICM Violation Report

Sample OTC ICM Violation Report

PTP Conflict Compensating Control Suggestions

OTC Conflict Compensating Control Suggestions

Additional Recommendations (Cont.)

Transaction Processing Controls

Manual Process Controls

Application Interface Controls

Facilitation of Audit Needs

Master Data Maintenance

Change Management & Testing

Things to Consider When Implementing/Upgrading

Das könnte Ihnen auch gefallen