How to use Organizational Rules in SAP Access Control (GRC)

In this article, I would like to give you an overview of organizational rules in SAP Access Control (GRC) and explain how you can use them in the context of risk analysis.

In general, you can use organizational rules in SAP Access Control to eliminate false-positive Segregation of Duties (SoD) reporting, based on organizational level restrictions for users. It’s important to understand that you should not create organizational rules for the purpose of mass org level reporting. Instead, use them only for functions that you specifically (and consciously) need to segregate. For example, a global company may allow a combination of duties that you would normally consider a high risk. As a practical example, think of the following SoD conflict: posting vendor invoices and changing vendor master data. But if we segregate, for instance, by company code, there is no SoD conflict. You can achieve this separation through the use of organizational rules.

Organizational Rules and Risk Analysis

Organizational rules allow you to filter false positives from the risks analysis. What does that mean? For example, if you have a role concept in which roles are derived from master roles, and the leading organizational level is the company code, the risk analysis might indicate a risk (false positive) due to the limitation of the authorization, based on the organizational level.

Let me give you an example of a typical role design:

Role A contains transaction FB60 (posting of vendor invoices) for company code 1000, whereas Role B contains transaction FK02 (changing vendor master data) for company code 2000.

Segregation of Duties and false positives

The combination of FK02 and FB60 is considered as a SoD risk because the same user should not perform those two functions. A user who gets the two roles in the example above would have both transactions assigned, and hence the risk analysis would indicate a risk. In practice, this isn’t a risk, but as the organizational values are not considered, the risk analysis reports a violation. This behavior is considered a “false positive” as the user cannot execute FB60 and FK02 for the same company code. To filter specifically these false positives you can utilize organizational rules within SAP Access Control.

While running a regular risk analysis, the user in the example above would show up with a SoD conflict, as he has two critical transactions assigned. To find out if the risk exists for the same company code you can use organizational rules. To do that, create an organizational rule that filters the company code 1000 and apply the org rule to the risk analysis. After adding the org rule to the analysis, the user won’t show up with the risk, and the result is filtered for this particular “false positive.” Please be aware that to smoothly run the risk analysis after creating org rules, the SoD rules must be regenerated (program GRAC_GENERATE_RULES).

Conclusion

In most of the cases, you should create organizational rules only for designated risks. If required, it is also possible to define org rules for several false positives by using wildcards (e.g. XGPR*). Whenever you utilize organizational rules, keep in mind that accidentally eliminating “real positives” is the worst case scenario, so use them carefully.