Is it possible to spend a significant budget on building an SAP role model during an S/4HANA implementation and still discover a few months later in an audit that the authorization model generates thousands of Segregation of Duties (SoD) conflicts?
As the following case demonstrates, it is. And it is far from an isolated situation.
The case described in this article concerns a large organization operating in the logistics services sector, where SAP plays a key role in supporting both operational and financial processes. In environments of this scale, roles and authorizations directly affects not only data security, but also compliance with internal control requirements and audit expectations.
At one point the organization decided to implement a new SAP S/4HANA system and build a new role model designed to ensure proper security of business processes. The implementation project was delivered by an experienced S/4HANA implementation provider with strong SAP delivery capabilities, primarily focused on delivering system functionality.
The issue emerged already at the project planning stage. The implementation scope did not include dedicated requirements regarding the authorization model or segregation of duties rules. The expected security level was not defined, SoD rules were not specified, and no clear responsibility was assigned on the client side for approving the role model from an internal control perspective.
There was also no structured approach to authorization management on either the client or vendor side. The implementation partner focused mainly on delivering the project on time and launching the system, while the authorization model was treated as a supporting element rather than a separate area requiring its own methodology.
Once the project was completed, the organization received a new structure of business and technical roles which – according to project assumptions – was supposed to become a stable foundation for access management in the system.
For some time nothing suggested that the real situation might look very different…
Verification – Authorization Audit
The real verification of the role model took place only during a standard audit cycle covering financial processes and IT systems.
During the SAP authorization review, auditors analyzed both the structure of roles and the assignment of authorizations to users. The audit results turned out to be a major surprise for the organization.
Despite the recently completed role design project, a significant number of Segregation of Duties conflicts and excessive access rights were identified in the system.
In practice, this meant situations where a single user could perform activities belonging to different stages of the same business process – for example entering financial documents, posting them and executing payments.
The audit conclusions indicated that the issue was not related to a few isolated exceptions or incorrect role assignments. The scale of identified inconsistencies suggested that the root cause might lie deeper – in the very design of the role model itself.
As a result, the organization decided to conduct a more detailed authorization analysis aimed at determining the exact scale of the problem and identifying its underlying causes.
Analysis Using Dedicated Tool -smartGRC
The detailed analysis was conducted using the smartGRC tool. Unlike a standard audit review, its objective was not only to identify conflicts but also to understand precisely how they had been created.
The analysis was based on a Segregation of Duties matrix specifically prepared and tailored to the organization’s business processes. This approach made it possible to accurately reflect real system activities and link them to specific risk scenarios.
The scope of the analysis included:
- SoD conflicts in both user authorizations and roles
- critical system accesses
- actual usage of granted system functions
The results clearly demonstrated the scale of the problem.
More than 10,000 Segregation of Duties conflicts were identified in user authorizations, with approximately one third classified as high-risk conflicts. Moreover, nearly all users included in the analysis had at least one SoD risk.
The source of such a large number of conflicts was several dozen roles that already contained embedded SoD conflicts – something that should not occur according to good role design practices.
The analysis also revealed a clear concentration of risks in specific business process areas. More than 60% of conflicts were related to financial processes, such as document posting, accounts payable processing, or master data management.
At the same time, a relatively small number of typical business scenarios generated a significant share of all conflicts. The ten most common risks accounted for nearly 60% of all SoD conflicts in the system.
The analysis of authorization usage revealed an additional issue – a large portion of granted access rights were not actually used by users in their daily work. Approximately 80% of available system functions remained unused.
Another side effect of such a broadly designed role model was increased SAP licensing costs. Wide authorization scopes meant that many users had access to functions qualifying them for higher license categories, which translated into higher FUE consumption and increased system maintenance costs.
The collected data led to a clear conclusion: the issues identified during the audit were not caused by individual mistakes or exceptional role assignments. Their root cause was the structure of the role model itself.
Diagnosis and Key Findings – Where Was the Problem and How Can It Be Avoided?
The in-depth analysis of the role model showed that the root cause of the problem did not lie in individual role assignments to users or occasional administrative mistakes. The SoD conflicts resulted primarily from the way the roles themselves had been designed. This, in turn, was a consequence of the lack of an appropriate methodology during the role design phase.
In many cases, roles were designed broadly to cover the entire range of activities performed within a given business process. As a result, a single role often included functions that, from an internal control perspective, should be separated between different individuals.
Each user assigned to such a role automatically inherited the associated SoD risks. At the same time, the analysis of authorization usage revealed that users frequently received access to a significantly wider set of operations than they actually needed in their daily work. This indicated that many roles had been designed more broadly than required by the real scope of user responsibilities.
In this situation, the conclusion was clear: the only effective solution was to redesign the authorization model from scratch. Although this approach may initially appear radical, given the scale of identified issues it was in practice the most rational option. Attempting to fix existing roles would have been not only time-consuming but also unlikely to produce a lasting result.
Experience from this case shows that effective role design in SAP systems requires a different approach from the one often applied in implementation projects. The key factor is incorporating Segregation of Duties principles already at the role design stage rather than treating them solely as a control mechanism applied after implementation. In practice, this means following several fundamental principles:
- Use the SoD matrix as a design tool – The SoD matrix should not be used only to report conflicts after a project has been completed. Instead, it should be applied already during the role definition phase so that the authorization structure is designed from the outset with segregation of duties in mind.
- Design roles based on actual user responsibilities – Roles should reflect the real scope of tasks performed by users within the organization. In practice, this means avoiding situations where a single role contains all functions available within a given business process.
- Apply the principle of least privilege – Users should only have access to the functions necessary to perform their responsibilities. Analyses of authorization usage in many organizations show that a significant portion of granted access rights remains unused, while at the same time increasing the overall risk level.
- Ensure consistent role architecture and naming conventions – The role model should be built according to clearly defined construction and naming principles. A consistent role architecture simplifies both access management within the system and future audit analyses.
Such an approach allows organizations to move from a reactive model where conflicts are identified only after roles have been implemented, to a design-driven model in which security principles are an integral part of the authorization architecture from the beginning.
Conclusion
The case described above demonstrates that even an S/4HANA implementation carried out by an experienced vendor does not guarantee a properly designed authorization model if access management is not treated as a separate project area requiring its own methodology.
In the analyzed organization, the new role model was created as part of the system implementation. However, it was only during a standard audit cycle that the scale of Segregation of Duties conflicts and excessive access rights became visible.
Only a detailed analysis conducted using the smartGRC tool made it possible to determine the real scale of the problem and understand its root causes. It turned out that the SoD conflicts were not the result of individual mistakes or occasional role assignments to users, but rather of the overall design of the role model.
The most important lesson from this case is that the quality of an authorization model does not depend solely on the experience of the implementation vendor. What matters most is defining clear authorization requirements at the project planning stage, assigning responsibilities on both the client and vendor side, and adopting a structured role design methodology that incorporates Segregation of Duties principles.
If SoD rules are treated only as a control mechanism applied after implementation, conflicts will inevitably appear sooner or later—regardless of who delivers the project.
For this reason, many organizations are increasingly moving away from the approach of correcting roles after implementation and instead adopting a “security by design” model, in which security principles become one of the fundamental pillars of the entire authorization architecture.
About the Authors:
This article is based on the experience of the GRC Advisory team gained through numerous SAP authorization reviews and on expertise developed during the creation of tools supporting authorization analysis within the smartGRC platform.
