Why conduct an entitlement audit? This one key question never loses its relevance: who has access to what data in SAP?
SAP privilege reviews help answer a key question: to what extent do the roles and transactions assigned to a user in the system reflect his or her actual responsibilities? This is not an easy task, as in practice it is often difficult to determine precisely what an employee is really responsible for, especially as his or her roles and responsibilities change over time.
To simplify the process of deploying new employees, organizations often copy permissions from another user. While this practice speeds up the granting of access, it also results in a loss of control over who has access to what, especially when the privilege structure in the system is complex and users are given dozens or even hundreds of roles simultaneously. Over time, the access structure becomes unreadable and difficult to manage. At this point, there is a need for a privilege review, the purpose of which is to verify often incorrectly assigned privileges.
At this point, the auditors step in.
Lack of access control most often comes to light during day-to-day operations – for example, when an employee is found to have published a document to a company to which he or she is not formally assigned, or moved goods between plants without proper authorization. While such incidents are usually quickly corrected, they rarely become the impetus for deeper changes. There is a widespread belief that it is better to have “too much rather than too little” authority, and the need to provide support often outweighs the principle of minimizing access.
Financial auditors, however, view the issue differently – through the lens of the principle of minimum privileges, according to which users should only have access to functions necessary to do their jobs.
From a financial audit perspective, the goal is to confirm that the data generated in an ERP system (e.g., SAP) is reliable and that access to functions affecting financial performance has not been granted to unauthorized persons. Auditors assess compliance with the principle of segregation of duties (SoD) and check access to sensitive functions such as payment processing, editing supplier bank data or modifying customer and supplier master data. A well-prepared SoD matrix and critical access list provide a practical starting point for an organization to review and a framework for evaluating current roles and authorizations.
A well-prepared SoD matrix and critical access list provides a practical starting point for an organization to review and a framework for evaluating current roles and permissions. Rather than asking the question of what access a user should have (which requires an analysis of duties, tasks and experience), it is much easier and faster to determine what access they should not have – especially when an auditor provides a ready-made list of risks and sensitive activities, or when such a list of best practices is already available in an access risk management tool (GRC class).
1 The entitlement audit also brings tangible business benefits:
- Better understanding of processes and responsibilities – helps clarify who is responsible for what and where there may be “gray areas” in the decision-making process.
- Enhanced operational security – restricting excessive access is one of the simplest and most effective forms of prevention.
- Prepare for change – well-organized permissions make migrations, upgrades and the transition to cloud environments much easier.
- Reduced risk of errors and abuse by eliminating role conflicts and critical access combinations.
- Support for internal and external audits – transparent reports and a clear risk matrix significantly speed up audit processes.
The important thing is that most organizations don’t have time to think about the authorization model when implementing an ERP system. The most important things are usually testing, master data, scheduling and just getting the system up and running. Access rights are often set at the last minute – usually by copying users or roles – without analyzing real needs and risks. As a result, the system may work well from a process perspective, but leaves too many security and control gaps.
That’s why it’s worth conducting a post-stabilization entitlement audit as a conscious step to organize access and improve the organization’s security and compliance maturity.
How to conduct an SAP access audit in practice.
Now that we understand, why access audit is important and what benefits it brings, the logical question is: how to conduct it in practice? Organizations have several options – from manually analyzing SAP tables to using various tools to support SoD risk assessment. The choice depends on several factors, such as:
- The number of users and the complexity of the IT environment (e.g., whether it is primarily SAP-based or includes domain-specific systems), manually auditing more than 100 users is almost impossible to do completely and accurately
- resources and competence of the internal team, technical specialists will start with SUIM in SAP and share results that are difficult for business teams to understand
- Pressure and expectations of internal or external auditors regarding SoD and access controls to sensitive data,
- and whether the audit is a one-time review or a cyclical activity.
Many organizations start by downloading SUIM reports, exporting data from tables and manually analyzing in Excel. After spending weeks reconciling raw system data, they often turn to external auditors for guidance – only to realize that their approach was wrong from the start. Audit firms, especially the Big Four, offer not only sophisticated tools (such as PwC’s ACE), but also structured methodologies focused on risk, business context and repeatability. However, they do not stop at identifying risks. Once a conflict of segregation of duties is detected, auditors dig deeper, asking whether access has been used, whether risks have materialized, and what data has been changed or affected. Proving that broad access to critical resources has not been abused can be a time-consuming and resource-intensive task, especially if there is no usage tracking system or contextual audit trail. Therefore, the real power lies not just in the tool, but in combining the right technology with the right methodology, starting with the risks and business needs, rather than raw transactions or lists of critical access transactions.
Many IT professionals believe that implementing a GRC tool will automatically solve their access management problems. However, this is a classic trap: if the problem is not clearly defined, the tool will not solve it. The real question is often not, “Do we lack a GRC tool?” but rather: “Do we really understand who has access to what and why?”. Without this clarity, even the best solution will not yield meaningful results. A well-known solution in this area is SAP GRC Access Control 12.0 (for on-premises environments). SAP also offers a cloud-based version – SAP IAG – that supports both on-premises systems (via SAP Connector) and cloud native systems (such as SuccessFactors).
GRC Hack #2
On-premise implementation of SAP GRC Access Control typically takes 3 to 6 months. If time is of the essence, a cloud-based version of IAG can provide a faster implementation – or you can consider SaaS alternatives.
In fact, alternative access control solutions are becoming increasingly popular – especially those that focus on flexibility, integration with non-SAP systems, faster deployment and simplified maintenance. One example is smartGRC , available in both on-premise and cloud models, which can deliver initial results in as little as 1 month.
Is a one-time audit service an alternative to the GRC system?
Executives often ask the question:“Do I really need a full GRC system to understand who has access to what?”
There are two main approaches:
- A one-time audit by an outside firm – quick, cost-effective and useful for getting an up-to-date picture (e.g., before a financial review).
- GRC system implementation – an ideal solution for organizations requiring continuous control, independence and scalability.
GRC Hack #3
A one-time audit is just a snapshot. In dynamic SAP environments, access risks are constantly changing. Without continuous oversight, repeated audits become necessary.
If frequent audits are not necessary, outsourcing may still be the best option. However, for organizations seeking the flexibility of lean GRC solutions , they offer a cost-effective compromise – especially when the audit scope also includes non-SAP systems, which typically require more time to prepare and review the segregation of duties.
Plan of action – conducting an SAP entitlement audit – where to start?
Starting an SAP entitlement audit by identifying transaction codes (t-codes) is a common mistake, especially among technical teams. This approach misses a key first step: understanding the business processes, roles and risks that determine access requirements. Without this context, t-code analysis is akin to mapping a city based on lampposts alone – it is technically accurate, but strategically blind.
GRC Hack #4
Don’t start with t-codes! Start with business processes and risk areas – only then assign them to transactions. Moving straight to technical issues loses the big picture.
2. develop a separation of duties (SoD) matrix and a list of sensitive accesses
This is the basis of any access control review. At this stage, the organization identifies business processes subject to potential violations and identifies segregation of duties (SoD) conflicts – such as posting a journal entry and approving a payment. The project team, together with business area owners, identifies a list of so-called business activities that can occur within the same process. Each risk is assigned a level of importance – e.g. low, medium, high. Any GRC tool provides such functionality, but it is worth noting a few nuances.
GRC Hack #5
The biggest challenge in creating an SoD matrix is ensuring a common understanding of the definition of risk across the company. Without this, the discussion has no real value. There are already solutions on the market, such as smartGRC, that enable the integration of artificial intelligence, support users by suggesting risky combinations of actions, showing examples of risk materialization and pointing to specific SAP transactions or Fiori applications. This reduces workshop time and improves matrix quality.
2. technical mapping of the SoD matrix
Once the SoD risk matrix and list of sensitive accesses have been finalized and agreed with the business, the next step is to technically map them into the GRC system. This is the point at which process-level risks are translated into actual entitlements in IT systems – most often in SAP.
At this stage, each business activity is assigned to a specific set of SAP transactions, Fiori applications or other technical elements (e.g. programs, reports, functions). Relationships are then established between transactions and authorization objects – elements of the SAP system that control the scope of user access.
For each pair of business activities , conflict conditions are defined – for example, whether a user has access to both create and approve a document. The result is a complete set of rules containing mapped technical definitions of activities and conflict rules.
GRC Hack #6
At this stage, it is worth using a tool that allows you to easily map systems beyond SAP S/4HANA. For example, SmartGRC (smartgrc.eu) allows you to create technical definitions in XML format using a composite and atomic structure to model any authorization concept. The system automatically validates the import and flags issues such as missing atoms in composite roles or atoms assigned to non-existent users. This not only speeds up implementation, but also helps improve the quality of authorization concepts in the source system.
3. Make reports on the opening balance.
This is the stage where the system analyzes actual user permissions and identifies where SoD risks and sensitive accesses occur. Reports take into account organizational levels – for example, whether conflict occurs within the same company code.
Depending on the tool, a report can contain thousands of entries, so transparency, filtering and aggregation of results are key. More advanced solutions also offer trend analysis over time, allowing organizations to assess whether the situation is improving or worsening. Data is typically presented in intuitive dashboards.
GRC Hack #7
It is valuable if the report shows the actual use of risk-related Fiori transactions and applications – this helps determine whether the risk is only theoretical or active, meaning that it is used by the user in daily operations.
GRC Hack #8
It’s even better if the report isn’t just a “static list,” but an interactive task list – allowing actions such as assigning items to business owners, adding mitigation measures, or forwarding them for approval or removal of access.
4 Develop a recovery plan.
This is the stage where specific decisions are made based on the report. The safety team or process owners determine:
- Which authorizations should be revoked,
- Which activities should be blocked or reorganized
- and what changes should be made to user roles.
Based on this, a technical specification is created for system administrators – including a list of transactions, roles and users that need to be updated. Depending on the tool, recommendations can be prepared in bulk or require individual analysis.
GRC Hack #9
This is a critical stage of the entire project – it is worth allocating sufficient time and resources in advance. Before revoking access to individual users, it’s better to first refine roles and the overall authorization model – this will make the changes more permanent, logical and easier to maintain in the future.
5 Monitor current risks.
An access audit does not end with a one-time analysis – risks should be monitored continuously. Once changes are implemented, it is important to:
- Regularly review new permissions and role changes,
- detect new conflicts and user activity in sensitive areas,
- and analyze trends – are the number of threats increasing, decreasing, or remaining constant?
More advanced tools enable scheduling of recurring analysis, reporting automation and automatic notifications to process owners.
This is also the stage where implementing a GRC tool provides the greatest return on investment – enabling continuous monitoring without the need for repeated manual audits, saving time and resources.
GRC Hack #10
The greatest value is provided by continuous monitoring – instead of conducting audits once a year, it is much more effective to monitor risks on a quarterly or monthly basis. The GRC system allows you to schedule recurring analyses and visualize risks over time, helping you assess whether corrective actions are actually working.
An SAP entitlement audit is a key step in ensuring compliance, security and integrity of financial data. Whether you are an auditor, process owner, or IT specialist, going through the five key audit steps provides a clear picture of your organization’s access structure:
- Define SoD matrix and list of sensitive accesses
- Mapping to the system (technical mapping)
- Execution of the opening balance report
- Formulate specific recommendations
- Monitoring risks over time
GRC tools enable organizations to implement audits faster, cheaper and more efficiently while maintaining high standards of control and compliance. You don’t have to be “stuck” with one tool. There are alternatives to consider – especially when time, flexibility and budget matter.
The choice of GRC approach and tool has a significant impact on the effectiveness of each stage. Complex, but often complicated to maintain, solutions (such as SAP GRC Access Control) can overwhelm a project with technical complexities. Meanwhile, alternative solutions such as SmartGRC focus on simplicity, transparency and collaboration with business users. With features such as:
- Quick implementation and user-friendly interface
- Integration with OpenAI
- Support for non-SAP systems via XML
- Active reporting and trend analysis
Summary.
GRC tools can help not only with risk monitoring, but also with the workflow of granting access and designing roles – but their effectiveness depends on the content on which they are based. That’s why it’s so important to create a clear and well-organized SoD matrix and risk definitions in the first place. Without solid content, even the best tool will not deliver the expected benefits.
