Organizational-Level SoD Analysis in SAP GRC: Understanding False Positives and the Limits of Organization Rules

The introduction of the Sarbanes-Oxley Act (SOX) in the United States brought greater attention to segregation of duties in enterprises. Many enterprises have started implementing various solutions to identify the conflicting access in their ERP system. SoD analysis has now become a fundamental component of SAP access governance over the last two decades.

As an SAP Security & GRC consultant, you might have utilized SAP Access Control to identify conflicting authorizations both at the user and role level, working with rulesets, functions, actions, and permissions.

If you are new to SAP and not sure what Segregation of Duties (SoD) is, read this:

One question remains unanswered and puts the SAP Security, GRC, and internal audit teams into an uncomfortable situation: If the user has conflicting access at a transaction code/authorization object level, but the activity is different at the organizational scope, why should it be considered as a SoD?

In my 20+ years of experience, the issue has always been at the top of the discussion list, and in many of the implementations, I’ve ended up explaining the challenges and why SAP hasn’t considered embedding this definition. Before we move forward, let’s understand the structure of a SoD definition:

Let’s break this further:

A user is authorized to create purchase requisitions (ME51N) for one purchasing group and release requisitions (ME54N) for another. Should the situation be treated as a SoD conflict?

• SAP GRC says → “Yes, it’s a conflict” (SAP GRC may flag it as a conflict when risk analysis is performed at the action or permission level).
• Business says → “Not necessarily,” as the organization-level definition is different.

But can different organizational values automatically prove that the risk does not exist?

• Auditors/GRC Teams → Not necessarily.

This is where the question of a “false-positive” comes in. Different purchasing-group values alone don't prove that a conflict is a false positive.

SAP Access Control has evolved over many years, from Virsa systems – Compliance Calibrator to SAP Access Control 5.3 to 10.x and 12.0, organizational-level SoD analysis remains an unsolved puzzle.

The traditional risk model is fundamentally built around functions, actions, and permissions, with organizational rules providing an additional mechanism for refining the analysis.

Why has organizational scope not simply become a native dimension of every permission in every risk definition?

SAP hasn’t provided a detailed explanation of this design limitation or the architectural choices involved. However, from a SoD, SOX, and enterprise access-governance perspective, I see four key challenges that explain why this is not merely a matter of adding another field to the risk definition.

False negatives are more dangerous than false positives.

A false positive creates noise in the business teams. Security teams spend time investigating these conflicts, documenting the reasons, and presenting them to the auditor. Organization Rules and Supplementary Rules in SAP Access Control help GRC consultants define and document these exceptions. A false negative, however, can cause a real conflict to disappear from the risk population.

Let’s assume that a user has authorization to create purchase requisitions for Purchasing Group A and release requisitions for Purchasing Group B.

An analysis that automatically treats the two groups as separate may suppress the conflict. But,

• What if the user gets another role with broader authorization?
• What if the respective authorizations are assigned manually or as a bolt-on?
• What if the relevant authorization checks do not enforce the assumed separation?
• What if the business process permits the activities to be combined?

The risk analysis engine could incorrectly conclude that the conflict does not exist, creating a false negative.

For SOX-regulated organizations, this is a serious concern. Remember, the objective of access risk analysis is not simply to minimize the number of reported conflicts or showcase that the system is risk-free. It is to identify relevant exposures reliably and take appropriate action.

What I’ve observed in my experience:

• Many enterprises don’t really use the “Org/Supplementary Rules." Some of them don’t even know the purpose of these. Educating them is a need.
• Some enterprises modify the ruleset and remove these transaction codes to remove the risks. Such an approach is not recommended.
• A few enterprises document them properly with supplementary controls, add the right mitigations, and monitor the usage of such transaction codes. Alert configuration is well defined, and the monitors review them from time to time.

Disclaimer: The above-mentioned observations are my personal experiences and don’t reflect any specific organization.

Org values do not always prove separation of duties

Organizational structures represent how an enterprise operates. They do not necessarily represent independent control boundaries.

Let’s consider company codes - 1000 and 2000. If a user can maintain vendor information for one company code and process payments for the other company code, do we consider that these activities are genuinely separated?

Possibly. But vendor master data might be shared, payments might be processed centrally, or the user might have access across both entities through other roles.

The same issue arises with other organizational elements such as plants, purchasing organizations, sales organizations, etc.

Different values in the risk definition and the role design may indicate separation in the authorization model, but they do not automatically prove that the underlying business risk has been removed.

Business risks vs Org values - No universal mapping

SAP authorization objects contain fields that control access to business activities. Some fields represent organizational values such as BUKRS (Company code), WERKS (Plant), EKORG (Purchasing Organization), EKGRP (Purchasing Group), VKORG (Sales Organization), and so on, but their significance depends on the authorization object and the process being analyzed.

Authorization might be restricted by company code in one object, while another is restricted by a purchasing organization. These fields cannot simply be compared. A proper risk analysis must determine whether the two organizational elements can be compared directly, whether a valid organizational relationship exists, and whether that relationship is relevant to the specific SoD risk.

Note that even a valid organizational relationship does not necessarily prove that two activities are independent from a business-control perspective.

Performance and complexity grow rapidly.

The current rule definition is already complex, and the organizational-level definition adds another dimension to it.

Remember, an enterprise SAP landscape may contain thousands of users, vast role assignments, complex authorization values, and a large ruleset covering multiple business processes.

If organizational scope becomes part of risk analysis evaluation, the risk engine may need to resolve effective authorization values, account for wildcards and ranges, complex organizational relationships, and evaluate intersections across the permissions associated with each risk. This increases the complexity and creates more confusion than simplifying the activity.

Important: Not every SoD risk has the same organizational semantics. A Company Code distinction may be meaningful for one risk but insufficient for another.

My learning from these four challenges

The fact that organizational-level definitions are not built into SoD risk definitions does not mean that the solution is incomplete or inadequate. The challenge is more complicated than it might seem. It involves understanding SAP authorizations, how business processes work, whether controls are effective, whether the conclusions can stand up to an audit, and whether the organizational separation genuinely changes the risk.

The real challenge is not just making an SoD engine understand organizational context. It is ensuring that the conclusions it draws are reliable, explainable, and defensible.

How Does SAP GRC Handle Organization Rules?

To understand the opportunities to improve or enhance the ruleset, it is important to understand what is available in SAP GRC and what a more context-aware model would need to establish.

SAP Access Control uses a rule-based approach to identify access risks.

The risk definitions follow a hierarchy – Risk → Function → Action → Permission.

Organizational restrictions add another dimension to this analysis.

SAP offers Organization Rules as another way to improve organization-based risk analysis and to prevent potential false positives.

The same issues are also referenced in SAP’s documentation. Incorrectly configured Organization Rules can filter out too much, making it impossible to identify genuine control concerns. This reinforces the importance of careful configuration and validation. Refer to the SAP Help Portal – Organization Rules

Practical implication: Organizational-level context can improve risk analysis, but only when the criteria used to interpret that context are valid for the risk being evaluated.

The question is not simply whether organizational fields can be compared. It is whether the comparison provides defensible evidence that the underlying business risk does not apply.

Organization Level Boundaries Are Not Control Boundaries

Let’s understand this in a better way with three scenarios.

Scenario A: Different company codes

A user can maintain vendor-related data for Company Code 1000 and process payments for Company Code 2000.

This definition suggests that the activities are fully separated and there is no risk.

But what if the vendor master data is shared, payment processing is centralized, or the user can operate across both entities through authorizations from other roles? Thus, this distinction may not eliminate the underlying risk.

The conclusion depends entirely on the specific risk, authorization design, and the business process.

Scenario B: Different plants

A user has access to perform inventory-related activities for Plant 1000 and goods movements for Plant 2000.

Different plant values may indicate separation of the risk. But the analyst must determine whether the relevant activities can be combined across plants, whether broader authorizations exist, and whether the risk concerns a shared process.

Scenario C: Shared services

How do you handle organization-level risks when an enterprise has a centralized finance or procurement team? This is quite common in large conglomerates. In one conglomerate where I worked, the central finance team owns 10+ SAP instances of different businesses. The underlying business processes are fully integrated. Creating separate roles with restricted organizational values may prevent an individual from performing both activities through a single role. However, when both roles are assigned to the same user, the user receives the combined access. Thus, defining risks solely at the organizational-value level has limitations.

It is important to understand that the organizational boundary becomes relevant to SoD analysis only when the relationship between the business process and the risk can be established.

Still want to implement a Context-Aware SoD Model?

As you are aware, the traditional risk definition flow is represented as the following:

Risk → Function → Action → Permission

If you wish to add another layer and call it an “Organizationally aware model”, the rule definition could extend it as follows:

Risk → Function → Action → Permission → Organizational Definition

In this model, the Organizational Definition describes the organizational scope in which a permission is effective.

For example, the permission associated with creating purchase requisitions might be restricted to Purchasing Groups A and B, while the permission associated with releasing purchase requisitions might be restricted to Purchasing Groups B and C.

The intersection is Purchasing Group B.

That overlap identifies the organizational scope in which the potential conflict deserves attention. It does not, by itself, prove that every other scope is safe; the risk-specific policy and authorization semantics must support that conclusion.

A mature model must be evaluated on five dimensions:

1. Explicit scope: What organizational restrictions are present in the effective authorization?
2. Derived scope: Can we derive additional organizational relationships from trusted SAP configuration?
3. Scope overlap: Do the permissions overlap in a dimension relevant to the risk?
4. Business applicability: Does the overlap create the specific risk described in the risk definition?
5. Evidence and confidence: Can the result be explained and reproduced using validated inputs?

This approach moves the analysis beyond identifying the presence of incompatible permissions toward evaluating whether those permissions can combine within the relevant organizational context.

However, adding an Organizational Definition to a risk model is only the starting point. The engine must also define how it interprets unrestricted values, handles missing mappings, evaluates cross-dimensional relationships, and responds when the evidence is incomplete.

Will this improve the current analysis?

In my view, introducing this additional dimension could create more complexity. I strongly believe that organizations do not need to wait for a new generation of SoD technology or ruleset to improve their current analysis. They can begin with a disciplined methodology as detailed below:

1. Ensure that the authorization design is well maintained. I don’t recommend using an enabler/bolt-on role concept.
2. Identify which conflicts are genuine false positives. Start by identifying high-volume or high-impact risks for which organizational separation is genuinely needed. Not every risk benefits from organizational filtering.
3. Verify effective role assignments, authorization values, unrestricted access, ranges, and relevant SAP configuration.
4. Establish a strong documentation process and explain why the organizational dimension chosen is relevant to the risk and what evidence supports meaningful separation.
5. Multiple roles, cross-organizational relationships, shared services, unrestricted authorization scenarios, and organizational assignment changes.
6. Review and approval of organizational policies affecting SOX risk reporting through the organization’s governance process. Technical configuration should not be the sole determinant of the acceptability of a control conclusion.
7. Make sure that the rationale, configuration, approvals, and inputs are traceable. Changes to authorizations, organizational relationships, or business processes may invalidate earlier conclusions.

This ensures organizational analysis is developed as a governed risk-assessment process rather than a mechanism for simply reducing report volumes.

Conclusion: The Goal Is Better Risk Decisions, Not Fewer Conflicts

Organizational-level SoD analysis addresses a genuine challenge in traditional permission-based risk analysis: the existence of conflicting permissions does not always tell the complete story.

At the same time, different organizational values do not automatically establish that a risk has disappeared.

The next step in SAP SoD analysis should not be to report fewer risks. It should be to understand which risks genuinely apply, where they apply, and why.

That is the difference between filtering conflicts and making better risk decisions.