How can a Segregation of Duties Audit in SAP be effectively conducted?

Why bother with an authorization audit? This one critical question never gets old: Who has access to what in SAP?

SAP authorization reviews help answer a key question: To what extent do the roles and transactions assigned to a user in the system reflect their actual responsibilities? This is not an easy task, as it’s often difficult in practice to precisely define what an employee is truly responsible for, especially since their role and duties tend to evolve over time.

To simplify the onboarding process, organizations frequently copy authorizations from another user. While this practice speeds up access provisioning, it also causes the organization to lose control over who has access to what, particularly when the system’s authorization structure is complex and users receive dozens or even hundreds of roles at once. Over time, the access structure becomes unreadable and difficult to manage. This is where the need arises for an authorization review, aimed at verifying accesses that are often assigned incorrectly.

That’s where the auditors come in.

Lack of access control most often comes to light during day-to-day operations — for example, when it turns out that an employee posted a document in a company they’re not formally assigned to, or transferred goods between plants without the proper authority. While such incidents are usually corrected quickly, they rarely become a trigger for deeper changes. There’s a prevailing belief that it’s better to have “too much than too little” access, and the need for backup coverage often outweighs the principle of access minimization.

Financial auditors, however, see things differently — through the lens of the principle of least privilege, meaning users should only have access to the functions necessary to perform their job.

From the perspective of financial audits, the goal is to confirm that the data generated in the ERP system (e.g., SAP) is trustworthy and that access to functions that impact financial results has not been granted to unauthorized individuals. Auditors assess compliance with the Segregation of Duties (SoD) principle and review access to sensitive functions such as executing payments, editing vendor bank data, or modifying master data for customers and suppliers. A well-prepared SoD matrix and a list of critical accesses give the organization a practical starting point for their review — and a framework to evaluate current roles and permissions

A well-prepared SoD matrix and a list of critical accesses give the organization a practical starting point for their review — and a framework to evaluate current roles and permissions. Instead of asking what access a user should have (which requires an analysis of responsibilities, duties, and experience), it’s much easier and faster to determine what access they shouldn’t have — especially when the auditor provides a ready-made list of risks and sensitive actions, or when such a best-practice list is already available in an access risk management tool (GRC class).

1. An authorization audit also delivers tangible business benefits:

• Better understanding of processes and responsibilities – it helps clarify who is responsible for what and where “gray zones” in decision-making may exist.
• Improved operational security – reducing excessive access is one of the simplest and most effective forms of prevention.
• Preparation for change – well-organized authorizations make migrations, upgrades, and transitions to cloud environments much easier.
• Reduced risk of errors and abuse through the elimination of role conflicts and critical access combinations.
• Support for internal and external audits – clear reports and a readable risk matrix significantly speed up control processes.

What’s important is that most organizations don’t have time to think through their authorization model during an ERP implementation. The focus is usually on testing, master data, the timeline, and the go-live itself. Access rights are often finalized at the last minute – usually by copying users or roles – without analyzing actual needs and risks. As a result, the system may function correctly from a process perspective, but it leaves too many gaps in terms of security and control.

That’s why it’s worth conducting an authorization audit after stabilization, as a conscious step toward cleaning up access and improving the organization’s maturity in the area of security and compliance.

From the review need to buy a GRC tool – How to run an SAP access audit in Practice.

Now that we understand why an access audit is important and what benefits it brings, the next logical question is: how do you actually conduct it in practice? Organizations have several options – ranging from manual SAP system-table analysis to the use of various tools that support SoD risk assessment. The choice depends on several factors such as:

• the number of users and complexity of the IT landscape (e.g. whether it’s primarily SAP-based or includes domain-specific systems), auditing more than 100 users manually is almost impossible to conduct in complete and accurate manner
• the resources and competencies of the internal team, tech guys will start with SUIM in SAP, and will share results which are hard to understand by business teams
• the pressure and expectations from internal or external auditors regarding SoD and sensitive access control,
• and whether the audit is a one-time review or a recurring activity.

Many organizations begin by pulling SUIM reports, exporting table data, and manually analyzing it in Excel. After weeks spent reconciling raw system data, they often turn to external auditors for direction—only to realize their approach was flawed from the start. Audit firms, especially the Big Four, bring more than just sophisticated tools (like PwC’s ACE)—they bring structured methodologies focused on risk, business context, and repeatability. And it doesn’t stop at identifying a risk. Once a segregation of duties conflict is found, auditors will dig deeper—asking whether the access was used, if the risk materialized, and what data was changed or affected. Proving that extensive critical access wasn’t misused can become a time-consuming and resource-intensive task—especially if no usage tracking or contextual audit trail is in place. That’s why the real strength isn’t just in the tool—it’s in combining the right technology with the right methodology, starting from risk and business needs, not raw transactions or critical access transaction lists.

Many IT guys believe that implementing a GRC tool will automatically solve their access management challenges. But this is a classic trap: if the problem hasn’t been clearly defined, the tool won’t fix it. The real question is often not “Are we missing a GRC tool?” but rather “Do we actually understand who has access to what—and why?” Without that clarity, even the best solution will fail to deliver meaningful results. The well-known solution in this space is SAP GRC Access Control 12.0 (for on-premise environments). SAP also offers a cloud-based version – SAP IAG – which supports both on-prem (via SAP Connector) and cloud-native systems (e.g. SuccessFactors).

GRC Hack #2

Implementing SAP GRC Access Control on-prem typically takes 3–6 months. If time is critical, the cloud-based IAG version may offer a faster deployment path—or you can consider SaaS alternatives.

In fact, alternative access control solutions are becoming increasingly popular—especially those that focus on agility, non-SAP system integration, faster implementation, and simplified maintenance. One example is smartGRC , available in both on-prem and cloud models, with the potential to deliver first results in just 1 month.

Is one-time audit service an alternative to GRC System? 

Executives often ask:” Do I really need a full GRC system just to understand who has access to what?”

There are two main approaches:

• One-time audit with an external firm – quick, cost-effective, and useful for snapshots (e.g. before financial reviews).
• GRC system implementation – ideal for organizations needing continuous control, independence, and scalability.

GRC Hack #3

A one-time audit is just a snapshot. In dynamic SAP environments, access risks change constantly. Without continuous oversight, repeated audits become inevitable.

If frequent audits aren’t needed, outsourcing may still be the best fit. But for organizations seeking agility, lean GRC solutions offer a cost-effective middle ground — especially when non-SAP systems are also in scope which usually requires more time to prepare and run the segregation of duties review.

Roadmap – executing an SAP authorization audit – where do I start?

Starting an SAP authorization audit by identifying transaction codes (t-codes) is a common mistake—especially among technical teams. This approach skips the critical first step: understanding the business processes, roles, and risks that drive access requirements. Without that context, analyzing t-codes is like mapping a city by looking only at streetlights—technically precise, but strategically blind.

GRC Hack #4

Don’t start with t-codes! Begin with business processes and risk areas—only then map them to transactions. Jumping straight into technicals misses the big picture.

2.      Develop Segregation of Duties (SoD) matrix and the List of sensitive accesses

This is the foundation of any access control reviews. At this stage, the organization identifies business processes exposed to potential violations and defines Segregation of Duties (SoD) conflicts — e.g. posting a journal entry and approving payments. The project team, together with business area owners, defines a list of so-called business activities that may occur within the same process. Each risk is assigned a severity level — e.g. low, medium, high. Every GRC-class tool provides such functionality, but there are some nuances worth addressing here.

GRC Hack #5

The biggest challenge in building an SoD matrix is ensuring a shared understanding of risk definitions across the business. Without that, the discussion has no real value. There are already solutions on the market like smartGRC that allows for AI integration, supports users by suggesting risky activity combinations, showing examples of how risks can materialize, and pointing to specific SAP transactions or Fiori apps. This shortens workshop time and improves the quality of the matrix.

2. Technically map sod matrix.

Once the SoD risk matrix and list of sensitive accesses are finalized and agreed upon with the business, the next step is to map them technically within the GRC system. This is the moment when process-level risks are translated into actual authorizations 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). Then, relationships are created between transactions and authorization objects — the elements in SAP that control a user’s access scope.

For each pair of business activities, conflict conditions are defined — for example, whether a user has access to both creating and approving a document. The outcome is a complete rulebook that contains mapped technical definitions of activities and conflict rules.

GRC Hack #6

It’s a good idea to use a tool at this stage that can easily map systems beyond SAP S/4HANA. For example, SmartGRC (smartgrc.eu) allows for technical definitions to be created in XML format using a Composite and Atom structure — enabling the modeling of any authorization concept. The system automatically checks the validity of the import and highlights issues such as missing Atoms in Composite roles or Atoms assigned to nonexistent users. This not only accelerates deployment but also helps improve the quality of the authorization concept in the source system.

3. Perform opening balance reports.

This is the stage where the system analyzes actual user authorizations and identifies where SoD risks and sensitive accesses occur. Reports take into account organizational levels — for example, whether a conflict appears within the same company code.

Depending on the tool, the report may include thousands of entries, so clarity, filtering, and result aggregation are crucial. More advanced solutions also offer trend analysis over time, allowing organizations to assess whether the situation is improving or deteriorating. Data is typically presented through intuitive dashboards as a standard.

GRC Hack #7

It’s valuable when the report shows the actual usage of transactions and Fiori applications linked to the risk — this helps determine whether the risk is only theoretical or active, meaning it’s being used by the user in daily operations.

GRC Hack #8

Even better if the report is not just a “static list” but an interactive task list — allowing actions such as assigning items to business owners, adding mitigating controls, or submitting them for approval or access removal.

4. Formulate remediation.

This is the stage where concrete decisions are made based on the report. The security team or process owners determine:

• which authorizations should be revoked,
• which activities should be blocked or reorganized,
• and what changes need to be made to user roles.

Based on this, a technical specification is created for system administrators — including a list of transactions, roles, and users to be updated. Depending on the tool, recommendations can be prepared in bulk or require case-by-case analysis

GRC Hack #9

This is a critical stage of the entire project — it’s worth allocating time and the right resources in advance. Before revoking access from individual users, it’s better to first improve the roles and the overall authorization model — this makes the changes more sustainable, logical, and easier to maintain in the future.

5. Monitor ongoing risk.

An access audit doesn’t end with a one-time analysis — risks must be monitored continuously. After implementing changes, it’s important to:

• regularly review new authorizations and role changes,
• detect new conflicts and user activity in sensitive areas,
• and analyze trends — is the number of risks increasing, decreasing, or remaining stable?

More advanced tools enable scheduled recurring analyses, report automation, and automatic alerts for process owners.
This is also the stage where implementing a GRC tool delivers the most ROI — by enabling ongoing control without the need for repeated manual audits, saving both time and resources.

GRC Hack #10

The greatest value comes from continuous control — instead of performing audits once a year, it’s far more effective to monitor risks quarterly or monthly. A GRC system allows you to schedule recurring analyses and visualize risks over time, helping to assess whether corrective actions are actually delivering results.

An SAP authorization audit is a critical step in ensuring compliance, security, and the integrity of financial data. Whether you’re an auditor, process owner, or IT specialist, going through these five key audit stages provides a clear picture of the organization’s access landscape:

1. Defining the SoD matrix and list of sensitive accesses
2. Mapping it into the system (technical mapping)
3. Running the opening balance report
4. Formulating concrete recommendations
5. Monitoring risks over time

GRC tools enables organizations to implement audits faster, cheaper, and more efficiently — while maintaining high standards of control and compliance. You don’t have to be “locked in” to a single tool. Alternatives exist, and they’re worth considering — especially when time, flexibility, and budget matter.

The choice of approach and GRC tool has a significant impact on the effectiveness of each stage. Comprehensive but often complex-to-maintain solutions (such as SAP GRC Access Control) can overwhelm the project with technical intricacies Meanwhile, alternatives like SmartGRC focus on simplicity, clarity, and collaboration with business users. Thanks to features such as:

• Fast deployment and user-friendly interface
• Integration with OpenAI
• Support for non-SAP systems via XML
• Active reports and trend analysis

Recap.

GRC tools can help you not only with risk monitoring, but also with access provisioning workflows and role design support — but they are only as effective as the content behind them. That’s why it is absolutely critical to prioritize building a clear and well-structured SoD matrix and risk definitions first. Without strong content, even the best tool won’t deliver value.