QAD Enterprise Edition

Segregation of Duties
Presented By: Andy Vitullo
Logan Consulting
Presentation Objective

How to Deploy Segregation of Duties (SOD) along with

Role Based Security to Ensure SOX Compliance
 Role Based Security
 SOD
 Define Logan Approach

Page 2
 What is Segregation of Duties?
Segregation of Duties (SOD)
 An internal control designed to prevent error and fraud by ensuring that at least two individuals are
responsible for separate parts of a business process.

SOD involves
 Breaking down tasks, within a process, that might reasonably be completed by a single individual into
multiple tasks so that no one person is solely in control.

Although it improves security, breaking tasks down into separate components can
 Negatively impact business efficiency.
 Increase costs, complexity and staffing requirements.

Efficiency and Cost

 Most organizations apply SOD to only the most vulnerable and the most mission critical elements of the
business.

Page 3
Business Purpose of SOD

Publicly traded companies must comply with the Sarbanes-

Oxley Act of 2002.

(SOX) is a Federal Law intended to protect investors from

the possibility of fraudulent accounting activities by
corporations.

SOX codified into Law the requirement for businesses to

sustain an internal control environment.
Page 4
A SOD Example

Payroll management is an administrative area in which both

fraud and error are risks.

A common segregation of duties for payroll:

 A resource responsible for the accounting portion of the job.
 An additional resource responsible for signing the checks.

Page 5
Does QAD Support System Based SOD?

Yes!

An entire SOD module was added to QAD and integrated

with the Standard QAD Role Based Security Model.

Non-Standard QAD Security Models not integrated with

SOD.
 EAM
 Channel Islands

Page 6
Components of QAD SOD

SOD Categories
 An Collection of QAD Security Roles.
SOD Matrix
 A Relationship of a SOD Category to All other SOD Categories.
 Defines conflicted Categories.
SOD Policy Exceptions
 User level definition allowing access to Menus that are in conflicting SOD
Categories.
 Non system “Mitigating Controls” must be implemented!
 Controller reviews all disbursement checks and physically signs the checks.
SOD Role Exclusion
 Roles that do not require conflict management. i.e. Report Roles.

Page 7
Case Study

The Players:
The Company
External Auditors
SOX Compliance Consultants
ERP Consultants

Page 8
The Conditions

The Company’s previous external audit discovered material

weaknesses in their ERP internal control environment.
 Material Weakness - Fraudulent, negligent, or innocent
misstatement, or an incomplete statement, of a material fact.
 Intentional – Fraudulent
 Unintentional – Negligent or Innocent

What was the Material Weakness?

 Improper System Based Segregation of Duties

Page 9
Impact of Material Weakness

External Auditors will/may return a “Qualified Opinion” on

the Financial Results presented to the Markets via the
Annual SEC 10K as a result of material weakness finding.

Will have a direct impact of market value of publicly traded

stock.

CEO And CFO in legal jeopardy as a result of SOX.

Page 10
Mitigation Approach

Perform Analysis of Current State

 Review current Roles
 Review Roles for Internal Control Conflicts within Permissions
 Create Incremental Roles
 Mitigate Privileged Access
Design SOD to Integrate with Role Based Security
 Set SOD Categories to Roles in a one to one relationship.
 Set SOD Categories equal to the Roles Names (Same Code Value).

Page 11
Review Current Roles

Run Application SOD Import/Export (36.3.27.15)

 Make sure to check the box for “Include roles”
 Right Click on the “Export to Excel” button

Page 12
Review Current Roles

 Access your saved file in Excel and the following file will appear

Page 13
Review Current Roles

Page 14
Review Roles for Internal Control Conflicts

Identify Resources/Menus that would be in conflict in an

SOD environment
 Example: Supplier Create(28.20.1.1) and Purchase Order
Maintenance(5.7)
Isolate Roles with the inherit SOD Conflicts

Page 15
Roles Example

Each Task in process will have a unique defined role

 Procure to Pay Cycle
 Supplier Create
 PO Creation
 Purchase Orders Receipt
 Supplier Invoice Creation
 Supplier Payment Processing
 Bank Reconciliation

Page 16
Mitigate Privileged Access
Privileged Access = Superuser
 A user that has unfettered Access to all Menu.
 Superuser should only be used during implementation.
 Superuser access is “OK” in test and development environments.
De-activate Unnecessary Roles
Create Report Roles
 Example: Role: NFR – Non Financial Reports
Remove Superuser Role access to all Users except System
Roles.
 No one person should have unfettered access to all menus

Page 17
Exclusions from SOD

Application Role Exclude from SOD (36.3.27.8)

 This function will allow you to remove roles that should be
excluded in the SOD security configuration.

Page 18
Set Up of Segregation of Duties – Process Flow

Page 19
QAD SOD Functionality

There are five main Functions needed in the SOD

Configuration
 Role Permissions Maintain
 Role Membership Maintain
 Role Exclude from SOD
 SOD Policy Exception Create/Delete/Modify
 SOD Import/Export
 SOD Configuration

Page 20
Role Permissions

Assigns QAD Menus to a Role.

Assigns other QAD Programs not on a menu to a Role.

Page 21
Role Permissions

Page 22
Role Membership

Assignment of Users to Roles.

Role Membership are domain/entity specific.

Page 23
Role Membership Maintain - View

Page 24
Role Membership to Role Permission Relationship

Page 25
Role Membership to Role Permission Relationship

Page 26
SOD Policy Exceptions

Allows a user access to a pair of SOD Categories that are

not compatible under SOD policy.

 An Example – A user has access to both Supplier Creation and

Purchase Order Maintenance.

 Violates Procure to Pay Cycle SOD policy

 A SOD Policy Exception is required for this users to have access to both menus.
 The mitigating control can be documented SOD Policy Exemptions.
 The SOD Policy Exception can be removed later if resources come available.

Page 27
SOD Policy Exception - View

Page 28
SOD Import/Export

A Microsoft Excel / QAD Integration Program.

Export SOD and Role Permission Configuration into a
multi-sheet workbook.
Performs SOD validity checks against Rule 1 and Rule 2
SOD Violations.
 Any rule violations will prevent a successful import.

Page 29
Import SOD Configuration

Load Validation Rules

 Rule 1 Violations – Role Permissions
 Are any Menu to Role relationship is in violation of the SOD configuration?

 Rule 2 Violations – Role Membership

 Are any Role to User relationship is in violation of the SOD configuration?

Page 30
SOD Import/Export Application Window

Page 31
SOD Matrix Maintain

SOD Matrix Maintain(36.3.27.3)

 Defines Conflicting SOD Categories.

Page 32
SOD Configuration Application Window

Page 33
SOD Configuration

Activates the SOD Configuration

 When activated, all validation rules are performed to check for
violations. You cannot continue implementing SOD if role
permission violations exist on your system. You must resolve the
violations raised, and then activate SOD.
Block SOD Violations
 When activated, the system prevents administrators from making
changes to role-based security that violate role permission (Rule 1)
and role membership (Rule 2) segregation of duties rules.

Page 34
No One Person Has Privileged Access

IT will have access to:

 User Creation
 Role Membership Maintain – Assignment of Users to the Role
 Role Permissions Maintain - Assignment of Menus to the Role

Finance and Accounting will have Access to SOD menus.

 Prevents IT from circumventing controls.
 IT would be unable to assign themselves Roles that are in conflict
of SOD.
Page 35
Audit Firm Due Diligence

Audit firms can analyze your configuration through their SOD

Models for specific ERP packages.
Audit Firms Key Requirements
 SOD Categories / Roles are appropriately assigned conflicts in SOD
Matrix.
 SOD Policy Exceptions Are Appropriately Documented.
 Non-system mitigating controls are sufficient to overcome system policy
exceptions.
 User Provisioning process
 Onboard resources to ERP and other systems.
 Offboard resources when employees leave the company.
 Evidence exists with business approval for access.

Page 36