Jul 6

In regard to my document about Rule Set / Business Risks I would like to give some detailed information about rules and rule types. As we learned rules (or risk rules) are possible combinations of transactions and permissions for a business risk.

Rules must be generated when ever risk contents change. This can be done in SPRO (GRC > Access Control > Access Risk Analysis > SOD Rules > Generate SoD Rules). Generally rules are combinations of actions and aren't maintained manually (done automatically by the program).

The number of rules defined from a risk is determined by 

  • the number of action combinations, and
  • permission/field value combinations contained in each function of the risk.

The following graphic shows the rule structure in more detail:

Now let me give you a short overview of the different types of rules considered by GRC.

Transaction Rules

Rule components are as follows:
  • System
  • Conflicting Actions
  • Rule ID
  • Risk Level
  • Status
Example (from the graphic above):

F001001: Maintain fictitious GL account & hide activitiy via postings
F001001 - Risk ID
F001001 - Action code combination number (represents Conflicting Actions)

Permission Rules

Rule components are as follows:
  • System
  • Object
  • Field
  • Rule ID
  • Risk Level
  • Status
Example (from the grapic above):

F00100101: Maintain fictitious GL account & hide activity via postings
F00100101 - Risk ID
F00100101 - Action code combination number
F00100101 - Object combination number

Critical Action

List of actions considered critical. Option to run at both Action and/or Permission level. Critical Actions are created same way as Segregation of Duty risks, exept Risk Type = Critical Action, and can contain only 1 function (as shown above with SCC4).

Critical Permission

List of objects/permission considered critical. Created same way as Segregation of Duty Risks, exept Risk Type = Critical Permission, can contain only 1 function, and function cannot contain actions.

Critical Roles and Profiles

Roles and profiles considered critical. Critical roles and profiles will be excluded from analysis if the configuration parameter 1031 (Ignore Critical Roles & Profiles) is set to YES.


Used to eliminate false positive SOD reporting based on organizational level restrictions for users. Organziational rules should not be created for mass org level reporting as it should only be enabled for functions that you specifically need to segregate. Most companies are controlling what data a user has access to via role assignment. There are only very few companies who have a business need to create org rules.


Additional security parameters other than authorizations a user must have to enable access. First checks to see if the user exists in the supplementary table, then checks if conditions are met. Based on exclusion setting, it will include or exclude the user in the risk analysis.

Please share and contribute in this document to make it better. See also my document on SAP SCN GRC community: http://scn.sap.com/docs/DOC-54530

Regards, Alessandro

Posted by Alessandro Banzer

Twitter Facebook

0 Trackbacks

  1. No Trackbacks


Display comments as(Linear | Threaded)
  1. No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.

You can use [geshi lang=lang_name [,ln={y|n}]][/geshi] tags to embed source code snippets.