SOD Conflicts and Role Based Back to LinkedIn.

com

Authorization in SAP
Published on February 28, 2015

CA CISA Jayjit Biswas Follow

123 19 20
Head IT Controls and BCM at Tata Motors Limited - Commerc

Segregation of Duties (SOD) Definition = Segregation of duties (SOD) provides the

assurance that no one individual has the physical and system access to control all phases
of a business process or transaction: from authorization to 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, persons who can authorize
purchase orders (Purchasing) should not be capable of processing payments (Accounts
Payable).

The Key Aspects of SOD

No one 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.

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 with suitable access rights is key to success of optimum SOD

Removing SOD conflict in Arithmetical Way

I always go by arithmetical formula considering following assumptions you are in SAP

ERP and having EULA

A.Total no of educated end users say 1500

B. Total no of work station you had say 1200

C. Total no of SAP licenses deployed say 900

First action bridge the gap between A and B. You can increase 300 computing end
users. Then bridge the gap between C and A. We are now getting additional 600 SAP
users.

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 of SOD conflicts you can ruled out.

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.

Basics of Roles Based Authorization

Objective

Institutionalise role based authorization to mitigate following risks.

Formal job roles and responsibilities of the user are not defined and mapped in SAP
R/3 system

Excess authorisation

Cross module authorisation, Cross Location authorisation

Unrestricted access to critical t-codes and critical movement types

Some users are having SOD in critical nature.

Benefits

Avert risk stemming from excess authorizations

Mitigate risk emanating from SOD conflicts

 Comply with SOX requirements related to system access authorizations

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.

Role Design

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

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.
Head of the Department HOD - (Authorized to authorize the access requirement of
the users). Approval of the access required for the user. Key Users and HODs
contribution is mainly on providing Organizational Chart and Job Description (for every
role).

Role Owner:

1. Validate the Access Control Matrix - 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 users function irrespective of naming convention.

Example

Functional Role

CASH (Finance Cash Dept)

Chief Cashier

Supervisor

ROLE Naming Convention

ZCP:FI_CASH_CHIEFCASHIER_SUSER ( Composite Roles )

ZSP:FI_CASH_CHIEFCASHIER_SUSER

ZTR:FI_CASH_CHIEFCASHIER_SUSER

Security Framework

For Example Cash Department. This is illustrative.

Cash Supervisor will be restricted from creating G/L account posting, posting
documents and clearing G/L Account.

Transactions and Activities will be based on Need to Do and Need to Know

Organizational Value Restriction for Cashier Roles.

Account Authorization for G/L Accounts BK02, CH01, GL50, SA01, SA02,
SA03
 Authorization for Business Areas C010, C011, C012, D010, F010, J010, L010,
M010, MSPA, P010, UO1O, V010

Authorization for Account Types S

Plant 1001 to 1099, 1100 to 1199

Key Challenges

1. Building Roles w/o SOD even if not detected by GRC 10 or 10+ SOD detecting
tools because of absence of proper SOD rule set.

2. Dealing with critical T codes

3. Dealing with 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

Precautions

1. Dont 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

Views expressed by author is personal only.

 Report this

CA CISA Jayjit Biswas

Head IT Controls and BCM at Tata Motors Limited - Commercial Vehicles Follow
13 articles

19 comments Newest

Leave your thoughts here

Venugopal Reddy 6mo

SAP Security and GRC consultant
Thank you , very helpful info
Like Reply

Bilal Khan 6mo

Finance Professional - Big 4 Experienced
Waqar Manzoor
Like Reply

There are 17 other comments.Show more.

Don't miss more articles by CA CISA Jayjit Biswas

Robotic Process Automation to disrupt Are We Missing to Look into These Areas? Moving Around with SAP Movement
traditional GRC Tools? Possible Fraud Indicators under GRC Types and Associated Vulnerabilities
CA CISA Jayjit Biswas on LinkedIn scanner. CA CISA Jayjit Biswas on LinkedIn
CA CISA Jayjit Biswas on LinkedIn

Looking for more of the latest headlines on LinkedIn?

Discover more stories

Help Center About Careers Advertising Talent Solutions Sales Solutions Small Business Mobile Language Upgrade Your Account
LinkedIn Corporation 2017 User Agreement Privacy Policy Ad Choices Community Guidelines Cookie Policy Copyright Policy Send Feedback