Hexadius has been involved in multiple SAP Segregation of Duties (‘SoD’) remediation projects. These projects tend to be complex due to the special authorization structure in SAP. Many of these remediation projects encounter issues related to the SAP role design. A bad role design often makes it difficult to remove SoD risk violations.
This results in many organizations questioning whether they should undertake role redesign before SoD remediation OR SoD remediation before role redesign. This blog shares some learnings which can help decide what approach works best for you.
What does a typical SoD remediation look like?
In general, the SAP SoD remediation projects consist of the following broad steps:
- Update SoD rule set definition to align it with the actual business risks.
- Perform SAP SoS risk analysis to identify current risk violations.
- Seek feedback from business to identify what conflicting access needs to be retained (die to business constraints) – and establish Mitigation Controls to reduce such access risks.
- Seek feedback from business to identify what conflicting access can be removed – and perform access changes in SAP to execute this.
While the first three activities are more or less predictable and can be planned in advance based on the SAP set up (number of users, modules used, etc), the last activity is often challenging to plan. This is because of lack of information on the extent of access risks in the existing user access.
SoD remediation approaches
The approach for SoD remediation depends on the extent of risk violations as well as the nature of technical changes in SAP access required. Some examples of technical changes are as follows:
- Removal of SAP roles from user – this is only feasible if all the access (transaction or authorization) is not required by the user (or user has another SAP role with the required transaction code/ authorization)
- Removal of transaction code from SAP roles – this is only feasible if all users with that SAP role do not require the transaction code to be removed (or those who require have another SAP role with that transaction code)
- Removal of authorization from SAP roles – this is only feasible if all users with that SAP role do not require the authorization to be removed (or those who require have another SAP role with that authorization)
- Removal of UPDATE authorization from DISPLAY ONLY SAP roles – this is only feasible if there are no cross-role authorization creep/ dependency
- Splitting a role into multiple roles – this is often required if the role has too many unrelated access
SoD remediation also needs to address any intra-role SoD violations (i.e., access risks within an SAP role).
There are additional complexities when the SAP role design is not good. Some examples are as follows:
- SAP role is assigned to multiple users. These users have different access risks, and it is required to remove different transaction code/ authorizations from these users. So, SAP role changes required for each user are different.
- Roles assigned to various users with the same access risks are different. While the same outcome is desired for all these users, multiple SAP roles need to be cleaned up to address this.
SAP role design issues
All in all, in many such SoD remediation projects, SAP role redesign may be a more efficient and effective solution rather than applying patches. This is especially true where the role design is itself deficient. Some tell-tell signs of SAP role design issues, which will likely manifest itself in SoD remediation projects are as follows:
- Use of ‘Job Role’ based SAP roles (for example, G/L Accountant, Procurement Manager) rather than ‘Task’ based SAP roles (for example, JE processing, PO processing)
- Lack of Master-Derived role enforcement (for example, PO processing roles for different Company Code or Plants have different transaction codes or authorizations)
- Lack of consistent role naming convention
- Lack of access matrix.
Deciding what comes first
There is often no right answer for this. However, based on all these factors, here are some of the considerations to decide what is an ideal flow for you – SoD remediation first or SAP role redesign first:
- Number of SoD risk violations (especially violation count per user) – higher count points to a bad role design and may be an indication that starting directly with SAP role redesign is a better option. Low count often means that a direct SoD remediation will work.
- Number of intra-role SoD risk violations – large number of intra-role violations means that role design needs to be reviewed and roles need to be split up. Once split into granular roles, it will be easy to remediate SAP roles from users, which is usually straightforward.
- ‘Job Role’ based roles are usually difficult to clean up for SoD remediation. Organizations should consider role redesign before starting SoD remediation exercise.
Every SAP set up is unique. If you need help to decide, contact us for consultation. You can also contact us for more details on our SAP role redesign and/ or SoD remediation approach.