1

Segregation of Duties in ERP (With special reference to SAP)

ISACA Pune Chapter office Monthly Lecture Meeting – 18.4.2015

Views expressed over here is totally personal in nature

2

What we will discuss today

• SOD Definition• Why SOD Matters• Need for SOD conflict Review• Global Scenario• SOD Examples wrt. to special reference to Procure to Pay Process• Key Considerations• Key Aspects• Mitigation through Role Based Authorization and using of GRC 10 suite• Q&A

3

Segregation of Duties (SOD) Definition

Segregation of duties (SOD) provides the assurance that no

individual has the physical and system access, to control all

phases of a business process or transaction; from authorization

of custody to record keeping. Thus in a way, it advocates Maker

– Checker concept at various levels.

An individual should not have responsibility for more than one of these three transactions components: authorizing transactions (approval), recording transactions (accounting), and handling the related asset (custody).

For example, person who can authorize purchase orders (Purchasing) should not be capable of processing payments (Accounts Payable).

4

Why SOD Matters

Internal Controls and Compliance

Part of management process, to keep an entity on course, in achieving its control activities.

Provide reasonable assurance that entity objective’s are being met by:

Effectiveness and efficiency of operations

Reliability of financial reporting under SOX, Companies Act

Compliance with regulations like SOX , Companies Act, ISO 27001 etc.

5

What’s Driving the Need?

7%

18%

21%

21%

33%

0% 5% 10% 15% 20% 25% 30% 35%

Other

Reduction in Costs

Defendable Environment

Automation and Repeatability

Risk of Non-Compliance

Source: AMR Research

6

Top Ten IT Control Deficiencies*

1. Unidentified or unresolved Segregation of Duties

2. Inadequate access controls supporting financial Applications / Portal

3. Inadequate Database access controls supporting Financial Applications

4. Development staff can run business transactions in production

5. Large number of users with access to “super user” transactions

6. Former employees or consultants continue to have system access

7. Posting periods not restricted within GL application

8. Custom programs, tables and interfaces are not secured

9. Procedures for manual processes do not exist or are not followed

10. System documentation does not match actual process

* Source: Ken Vander Wal, Partner, National Quality Leader, E&YISACA Sarbanes Conference , 4/6/04

GLOBAL SCENARIO

7

SOX 404 Compliance Gaps Remain…

Formal Review and Approvals: 23%

Segregation of Duties: 19%

Lack of Process-related

Documentation34%

No gaps identified: 8%

Other 16%

Source: Jefferson Wells International & The Institute of Internal Auditors

GLOBAL SCENARIO

8

Segregation of Duties (SOD) Examples

Function 1 Function 2 Business Risk Enter PO Receive PO Prevent buying and receiving items for user's personal use

Define Supplier Pay Invoice Prevent a user from setting up and paying a fictitious vendor for personal gain

Enter AP Invoice PO Returns Prevent goods from being received, invoiced and then returned Fixed Asset Physical Inventory

Asset Retirement Assets could be misappropriated and then summarily written off

Enter SO Manage Price Lists

A user could manipulate prices for the benefit of a customer or themselves

Enter Customer Ship SO A user could enter and ship an order to themselves Enter Credit Limits Enter SO Manipulated credit policies could increase risk or benefit

customers Misc. Inventory Txn Inventory Counts Adjust inventory balances to meet count results

Inventory Transaction Ship SO Shipping users should not be able to move inventory

9

Typical Procure to Pay Process

Lack of systemic controls increases risk to the organization!

10

Key Considerations

• How to define SOD controls?

• How to deploy and enforce Controls?

• What mechanisms should be provided to the process owners for preventing SOD conflicts?

• How to clean up existing SOD conflicts?

11

SOD Control Definitions: Use a Framework!

COSO: Committee of Sponsoring Organizations. In 1985, the Treadway Commission, formed to study US financial reporting systems now released COSO 2013 framework

• SOX follows COSO framework for regulatory & risk management• Standardizes the definition of internal controls – Referenced in Section 404 • Provides a framework for risk management and regulatory compliance• Requires risk assessments, a control-based environment, control-based activities, information and

communication procedures, and a monitoring mechanism for the control environment• Effective Fraud Management mechanism and use of IT tools

COBIT: Developed by IT Governance Institute as a standard for good IT security and control practices that provides effective governance

• COBIT was issued by the IT Governance Institute and is increasingly internationally accepted as good practice for control over information, IT and related risks

• Contains framework for control and measurability of IT by providing tools to assess and measure the enterprise’s IT capability for the COBIT IT processes

• Advocates “Need To Know Need To Do” Principle to resolve SOD issues.

12

No individual or related individuals should have complete control over a major phase of a process.

Workflows proceed from one person to another so that, without duplication, the work of the second acts as a recorded verification of the propriety of work of the first.

The person authorizing the use of an asset should not be responsible for its custody or derive any real or conceived benefits from the use of the asset.

Record keeping and bookkeeping activities should be separated from handling and / or custody of assets.

The Key Aspects of SOD

13

SOD Control Definitions through Manual Chart

14

1. Manual identification of conflicts for remediation.

2. Heavily reliant on System Admin group for changes going forward.

3. Not proactive process.

4. Violations during future IT Audits will be costly as you try to prove that conflicts didn’t have material impact on financial statements

5. Very manual.

Problems with this Manual Approach

15

MAIN OBJECTIVE IS TO ACHIEVE

SOD

AT INDIVIDUAL / SAP USER LEVEL

Take off to SAP Role Based Authorization

16

SOD - Ongoing Dilemma !!!!

Auditors

Management

Security & Controls Team

I need SAP_ALL

Why don’t you let me do my job?

I need XK01 now! ASAP!!!

Users

Violating so many controls? This is ugly …

Why can’t you ever get your

act together??DO YOU

WANT ME TO GO TO JAIL?

17

SOD Management Process through Administrative Way

Go by arithmetical formula considering following assumptions you are in SAP ERP and having EULA

SAP or ERP Licenses deployed =900 Educated End User = 1500Work Station = 1200

1. First action to bridge the gap between A and B. You can increase 300 work stations by deploying SAP . Then bridge the gap between B and C and also provide SAP licenses to additional 300 end users / workstations. By bridging the gap you are now getting additional 600 SAP users.

2. Get the benefit of this and distribute the roles or t-codes to entire 1500 SAP end users instead of earlier 900. Now check how much SOD conflicts you can be ruled out.

3. Thumb rule is more you get the actual SAP users on board, you can simply distribute the t-codes based job profile or even role assignment to reduce SOD conflict at maximum.

AA BB CC

18

SOD Management Process through Automation

Risk RecognitionRule Building and

ValidationAnalysis Remediation Mitigation

Continuous Compliance

Risk Recognition

• Identify or approve conflicts exceptions

• Classify Risk – High, Medium, Low

• Identify new risks and conditions for monitoring in the future

Rule Building and Validation

• Reference Best practice Rules for Your environment

• Validate rules

• Customize Rules & Test

• Verify against Test User / Role cases

Analysis

• Run Analytical

• Size cleanup efforts

• Analyze Roles

• Analyze Users

• Modify Rules based on analysis

• Set Alerts to distinguish executed risks

Remediation

• Determine alternatives for eliminating risks

• Present Analysis and select corrective actions

• Document approval of corrective actions

• Modify / create Roles or User Assignments

Mitigation

• Design alternative controls to mitigate risk

• Educate management on conflicts approval and monitoring

• Document a process for monitoring mitigation controls

• Implement controls

Continuous Compliance

• Communicate changes in Roles and user assignments

• Simulate changes to roles and users

• Implement Alerts to monitor for new selected risks and mitigating control testing

19

SOD Cleanup: Don’t Underestimate

• SOD Detection != SOD Resolution

• Manual cleanup is labor-intensive

• Consider simulation tools for responsibility and menu changes

• Mitigating/Compensating controls are generally preferable to 100%

disablement

• Synchronize changes to access with an ERP version upgrade if possible

20

Detection Tool GRC 10 Compliance Suite

• Automated SAP Security Audit and Segregation of Duties (SOD) Analysis product

• Real-time risk assessment solution• Simulation and remediation• Mitigation Controls• Embedded in SAP• Preventive as well as detective• Summary and drill-down reports

It is a Compliance Calibrator

21

Prevention Tool SAP Role Based Authorization

22

ObjectiveObjective• Institutionalise role based authorization across all process and modules of SAP

Benefits out this project are two fold.Benefits out this project are two fold.

1. .

In terms of Productivity In terms of Controls

Once roles are created properly it is easier for Role owner and HOD to allot the roles to users based on job profile which will reduce TAT of whole process and bring customer delight

Avert risk stemming from excess authorizations due to existing profile copy

No need for filling technical details like org values and t-codes at user level which resulted in significant TAT time

Mitigate risk of Cross location and Cross module access

Elimination of high numbers of user based roles which is very difficult to maintain now

Mitigate risk emanating from SOD conflicts

One time activity and once roles are created it will be easier for BPO and TCS team to sustain current pressure and significant reduction in time

Streamlining and standardisation of the existing authorisation system to have better control

23

Approach

24

Strategy

1. Designing the authorisations will be based on the organisational internal structure and the business processes. It will be designed to achieve appropriate Segregation of Duties and better internal controls.

2. The methodology involves Role based authorisation which will list the activities to be performed by the users. These roles will have one common organisational level profile and one functional profile which will define the transactions for the role.

3. The role designing phase would require both, system administrators, functional consultants and the business users to ensure the user authorisations reflect the organisational needs.

25

User

Transaction Based Role Organizational Value Based Role

Transaction Based Role :Transaction Role will consist of only transactions and reports. SAP Display Transaction and Reports.

•SAP Display Transaction and Reports.•SAP Create, Change, Delete transactions.

Organization Value Based Role :It comprises of organizational values such as Company Code, Plant, Sales Organization, Purchasing Organization, Shipping Point, etc… as required.

Composite Role :Transaction and Organizational roles are grouped in Composite roles. Only composite roles will be assigned to users.Each Composite role contains the necessary authorizations needed to perform the designated transactions based on the need to do and need to know

Role Design

26

Roles and ResponsibilitiesFunctional Consultants

Redesigning the Business Process documents for access control matrix in consultation with the key users. Identification of the transaction codes and grouping of them as per the roles. Prepare questionnaire for the key users for access requirement.

Key Users Identify and Validate the business activity access required for the users depending upon their roles.

HOD (Authorized to authorize the access requirement of the users). Approval of the access required for the user.

Key Users and HOD’s contribution is mainly on providing Organizational Chart and Job Description (for every role).

Role Owner:1. Validate the ACM with proper txns codes with corresponding org values 2. User Assignment - Correct mapping of user with respective roles 3. Removing SOD if found at role level and users assignment level4. Taking justification and valid decision in allotting critical t-codes and mvt. types5. Giving the names of users and ids which are missed by project team based on his

understanding of user’s function irrespective of naming convention.

27

Role Testing & GO Live

28

Key Challenges1. Building Roles w/o SOD even if not detected by Compliance Calibrator

2. Dealing with critical T codes

3. Dealing with 800+ customized Z programs which includes create / change t-codes

4. To build SOD rules for customized T codes wherever necessary

5. Dealing with SE16 table browser where access was not restricted to specific tables – so it necessary to build SE16N view roles based on specific table access

6. No SOD rule set defined for Critical Movement type or HR Info type level

7. Filling up of an ACM with accurate data:

Plant Code , Pur Org, Pur Doc Type, Mvt type, S-loc , Excise Grp, Excise Series ,Release Grp and Release Code etc

8. Removal of Generic business User IDs

9. Total support and patience at the time of Testing of Roles and after Go-Live

10. Creation on Firefighter ids and its usage modularity

11. Maintenance of roles after post migration stage

29

Possible Concerns related to SOD conflict resolution

Ways to resolve SOD conflicts through Roles Based Authorization

• Split the Roles and attach them with individual SAP transaction codes

•Remove authorization for SAP transaction codes that lead to SOD conflicts

Suppose Txn1(MI02) - Change Physical Inventory Document and Txn2 (MI04) -Enter Inventory Count with Document rest with one person. Then split the roles into 2 (R1 and R2) and attach Txn1 to R1 and Txn2 to R2

Above exercises result in

• Increase in Manpower

• Redefining roles and responsibilities which may lead to increase in manpower / training cost

30

Role Maintenance

• TML has identified around 250 Role Owners.

• Every Role has a Role owner.

• Any change in the role is approved and validated by the role owner.

• Standard FORMS have been developed to make any changes to the ROLE which should be Authorised by ROLE OWNER.

• Around 2500 roles have been created.

• All USERS under FI/SD & MM Modules are role based

Role Owners

31

Fire Fighters

• Fire Fighter tool of GRC 10 has been implemented to grant Authorisation access to the users in case of emergency.

• The Owner and the Controller for each Fire Fighter Id is configured in SAP• On the request from the USER, the owner of the Fire Fighter Assigns the Fire

Fighter to the user. The Fire Fighter Id has all the required TCODES to perform the activity

• A Log is maintained in the system and the owner and controller reviews and authorizes the log at the given frequency. The log gives all the details on usage of Fire Fighter i.e. The date, time, reasons, TCODES for which the Fire Fighter ID was used.

Role Maintenance

32

Risk Terminator

• Risk Terminator tool of GRC 10 has been implemented to validate granting of access to the users for Critical TCODES

• Around 180 Critical TCODES in Basis and 181 Critical TCODES in Business have been identified and updated in Risk Terminator. In addition to above we have 35 separate HR critical t-code maintained for SAP HR module.

• While granting access to the said TCODES, the Basis team takes an approval from Business Security and IT Security and Compliance Team.

Role Maintenance

33

Precautions

1. Don’t mix up display t-codes with create / change t-code within the role

2. Use proper naming convention for roles based on function

3. Avoid using * in org values in critical fields

4. Restrict the usage of critical t-code and movement types at super users level

5. Judicious use of Fire IDs and its review of log

6. Ongoing challenge is to maintain number of roles at optimal level - Use Rule Book for maintenance team for new role creation and amendment of existing roles

34

Summary

• Define granular, function-level conflicts using a conflict matrix

• Use Compliance Calibrator software ( GRC 10 Suite or Oracle’s ICM) to detect

SOD conflict

• Use controls automation software to deploy and enforce these controls

within your ERP

• Address the change management aspects of the solution

It is important to note that

Protection of unity in chain of command I.e there should not be too many checkers for one maker. The definition of role should be functional not

individual.

Removal of excess authorization should not lead to misuse of passwords. Increase of SAP users is key to success of optimum SOD

35

THANK YOU

Feel free to ask Questions

36

Jayjit's 22 years of professional journey covers IS auditing , SOX compliance and Management consulting. Considered to be a specialist in SOX Compliance function with deep understanding of Forensic and IS audit. He has an uncanny habit of blending controls to the best of business interest. He always look compliance and control as a driver of business and not the show stopper.

Jayjit is a prolific speaker and a thought leader on various international forum.

About the Presenter: Jayjit Biswas CA , CISA

jayjit.biswas@tatamotors.com

@jayjitbiswas

https://www.linkedin.com/in/jayjitbiswas