This document discusses segregation of duties (SOD) in ERP systems like SAP. It defines SOD as separating authorization, custody, and record keeping among different users to prevent fraud. The document outlines the need to manage SOD through role-based authorization and tools like GRC 10 to detect and resolve conflicts. It provides examples of SOD conflicts and describes managing the SOD lifecycle through rule building, analysis, remediation, and continuous compliance monitoring.

1. 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. 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. 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. 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. 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. 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. 7
SOX 404 Compliance Gaps Remain…
Formal Review and
Approvals: 23%
Segregation of
Duties: 19%
Lack of Process-
related
Documentation
34%
No gaps identified: 8%
Other 16%
Source: Jefferson Wells International & The Institute of Internal Auditors
GLOBAL SCENARIO

8. 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. 9
Typical Procure to Pay Process
Lack of systemic controls increases risk to the organization!

10. 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. 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. 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. 13
SOD Control Definitions through Manual Chart

14. 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. 15
MAIN OBJECTIVE IS TO ACHIEVE
SOD
AT INDIVIDUAL / SAP USER LEVEL
Take off to SAP Role Based Authorization

16. 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. 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. 18
SOD Management Process through Automation
Risk Recognition
Rule Building and
Validation
Analysis 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. 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. 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. 21
Prevention Tool
SAP Role Based Authorization

22. 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. 23
Approach

24. 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. 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. 26
Roles and Responsibilities
Functional 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 level
4. Taking justification and valid decision in allotting critical t-codes and mvt. types
5. 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. 27
Role Testing & GO Live

28. 28
Key Challenges
1. 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. 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. 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. 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. 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. 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. 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. 35
THANK YOU
Feel free to ask Questions

36. 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