SAP Role Design for Success: Best Practices and Tips
Is your SAP role design structure accurate and well-organized? Do they follow a systematic naming convention that is easy to understand? Before making any further changes to the roles, are you performing a Segregation of Duty analysis? Have you received recommendations from your auditor about a SoD matrix?
The fact is that security requirements are not often considered when creating or modifying roles to meet the immediate business needs. Consequently, the sap role design structure becomes a mess, full of segregation of duties (SoD) and contains many critical authorizations. How does it affect your business?
Why SoD is so important? Why is it becoming the buzz word? The concept of SoD is that running a business shouldn’t be the responsibility of a single person. A single individual should not have authority or control over any task that could lead to fraud or criminal activity. It is based on the concept of shared responsibilities, where multiple departments or individuals are responsible for critical functions of a key process. This reduces the risk of fraud or other unethical behavior. As part of enterprise risk management and compliance with laws such as the Sarbanes-Oxley Act of 2002 (SOX), SoD plays an important role. A division of responsibilities among multiple personnel reduces the possibilities that any employee or third party could accomplish any of the following in isolation or by collaborating with others:
- Theft of funds;
- Taking part in corporate espionage;
- Inflating the stock price artificially or falsifying financial records to meet shareholder expectations.
It is always recommended to build sap role design that follow a systematic process that meets business requirements, access frameworks, and standardized naming conventions.
Before you begin a sap role design project, you should follow a 3-step process (DISCOVER – DEFINE – DELIVER). You will gain a deeper understanding of the current situation, develop a plan to fix or redesign it, and create roles that can be maintained easily in the future.
Phase # 1 – Discover (Evaluate the existing setup)
More than 65% of customers have problems with SAP authorizations. Managing authorizations will become a cumbersome task in time. Wider access, SOD risks, and other factors make it difficult for organizations to manage them efficiently. That’s why sap design role is important.
Prior to making decisions about whether to perform a cleanup or a complete redesign, it is highly recommended to understand the existing sap role design setup.
Prepare a comprehensive usage analysis by identifying transaction codes and roles. The “Reverse Business Engineering” concept can be used to identify what is assigned and what is used to clean-up the roles. Inputs from this phase will be used in the next phase.
Phase # 2 – Define (Make-a-plan)
After identifying existing design, business requirements, and gaps, the next step is to decide whether a cleanup or a complete redesign is required. Consider the following questions:
- Are there a lot of manually added objects in the roles
- In S_TCODE, are there ranges for the roles, such as A-Z, etc.?
- Are the sap role design granting broader authorizations?
- Are there a lot of modified objects in the roles?
- Are there a lot of enabler roles in the current sap role design?
- Does the roles have a lot of segregation of duties and critical risks?
- Are your roles based on job functions rather than tasks?
A complete role redesign is needed if you answer yes to two or more questions. The plan should include changes needed at the custom transaction code level, authorization adjustments, and sap role design adjustments, along with considering best practices from the industry.
Phase # 3 – Deliver (Cleanup or Role Redesign)
The role re-design project is always aimed at simplifying the existing SAP role design and optimizing the existing role setup in the SAP system. In addition, this will re-define the way the roles are assigned to the users by reducing SoD conflicts when users change their job positions.
Redesigned roles with restricted access will ensure greater compliance and fraud prevention in the long run. They will also improve efficiency and transparency in the SAP access provisioning process. Below is the detailed approach that is recommended when you aim to redesign the sap role design:
Create Master/Derived Roles
When designing roles, it is always recommended to use the master/derived role concept. As a result, Security Administrators can easily manage the roles. They can also keep the task-based roles consistent across the company codes and plants (the organization elements from which the roles are usually drawn). Developing the master and derived roles in the ECC/S4H system follows the below approach:
Before starting the sap role design project, custom transaction codes (also called Z transaction codes) should be analyzed. The impact of these transaction codes is not well understood by many of us. Auditors and industry experts recommend identifying and maintaining the relevant authorization objects in SU24 check proposals. If the custom transaction codes do not have proper authorization restrictions, the same must be maintained before they are added to roles.
Identify transaction codes required for master roles
The transaction codes required for master roles were gathered by:
- Conducting a Role Redesign workshop and reviewing the process flows for all the processes such as ATR, OTC and P2P.
- Extracting the transaction code usage information for a period of 8-12 months, to make sure that we covered all the transaction codes.
- From both these exercises, identify the list of transaction codes, and map them to the master roles.
- Align the new roles to the business processes
In order to identify Segregation of Duties, solutions such as SAP GRC are recommended. If you don’t have SAP GRC Access Control implemented, you may opt for ToggleNow’s FourEdge Security as a Service offering, which provides the SME team’s assistance in identifying segregation of duties and critical risks, and enabling a better role design free from inherent SoD conflict.
At every stage of Role design a SoD conflict check is conducted to prevent SoD conflicts.
Organizational Element Restrictions
In addition to the transaction codes, restrictions will be applied on various organization elements such as Company code, Plant, Shipping point etc., a complete list of organization elements on which restrictions should be applied should be identified during the workshops. Any org elements which are in-active should be removed while designing the sap role design.
Also, the master roles shouldn’t have any limitations on the org elements, and they should be maintained in the derived roles.
Incase if the existing role structure gives authorizations to the org level values through enabler roles, they have to be considered in the new sap role design.
Identify non-org level values
After identifying the transaction codes that should go into each of the new roles, identify the non-org level values such as sales order type, document type, etc. Typically, this is done by looking at the values maintained in the existing roles in the Production environment. To expedite the identification of these values, it is recommended that the new roles are built in the SAP development environment without non-org level values and compared against the existing roles in the production environment. Once the non-org values are identified, they should be validated with the respective business teams.
Following the creation of master sap role design, they must be derived for various org level values. Identifying the org level values requires analyzing the existing configuration and conducting discovery meetings with the key business teams. With respect to derivations, it is essential that they are maintained correctly with the correct org value restrictions. In most cases, restricting only at the company and/or plant level is insufficient, which is the most common mistake.
SoD risk management is no longer a complex task as it once was. Companies can simultaneously address a variety of security issues with modern SOD and Access Risk Management solutions. There is a need for enterprises to stare the problem right in the eye and confront the naked truth. If separation of roles and responsibilities isn’t possible, then implement stringent processes to address potential failure points.
It’s not necessary to hire a whole team. You just need smart teams, and ToggleNow has them!
With ToggleNow, enterprises have been able to eliminate their SOD problems without building dedicated teams or investing heavily in tools. Through its Segregation of Duties management service, ToggleNow provides a visualisation layer that puts the controls over SoD surveillance in the hands of existing System Administrators, Business Owners, and Audit\Compliance Teams. With top-down visibility and control of emerging SoD risks in the ERP environment, system administrators and audit/compliance teams do not have to perform elaborate manual checks.