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
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
Cross module authorisation, Cross Location authorisation
Unrestricted access to critical t-codes and critical movement types
Some users are having SOD in critical nature.
Avert risk stemming from excess authorizations
Mitigate risk emanating from SOD conflicts
Comply with SOX requirements related to system access authorizations
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.
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.
The role designing phase would require both, system administrators, functional consultants and the business users to ensure the user authorisations reflect the organisational needs.
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.
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 HOD’s contribution is mainly on providing Organizational Chart and Job Description (for every role).
Validate the Access Control Matrix – ACM with proper txns codes with corresponding org values
User Assignment – Correct mapping of user with respective roles
Removing SOD if found at role level and users assignment level
Taking justification and valid decision in allotting critical t-codes and mvt. types
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.
CASH (Finance – Cash Dept)
ROLE Naming Convention
ZCP:FI_CASH_CHIEFCASHIER_SUSER ( Composite Roles )
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
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.
Dealing with critical T codes
Dealing with Customized Z programs which includes create / change t-codes
To build SOD rules for customized T codes wherever necessary
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
No SOD rule set defined for Critical Movement type or HR Info type level
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
Removal of Generic business User IDs
Total support and patience at the time of Testing of Roles and after Go-Live
Creation on Firefighter ids and its usage modularity
Maintenance of roles after post migration stage
Don’t mix up display t-codes with create / change t-code within the role
Use proper naming convention for roles based on function
Avoid using * in org values in critical fields
Restrict the usage of critical t-code and movement types at super users level
Judicious use of Fire IDs and its review of log
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.
CA Jayjit Biswas