Skip to Content

With respect to my document Rule set – Rules & Rule Types and as I’ve got some requests to discuss the org rules in more detail I would like to share some more information about organizational rules.

 

Organizational rules in GRC Access Control are used to eliminate false positive SOD reporting based on organizational level restrictions for users. Organizational 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 control 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.

 

Basically organizational rules allow you to filter false positives from the risks analysis. What does that mean? If you have a role concept where you derive roles from master roles, for example the leading organizational level is the company code, the risk analysis might show a risk which is due to the limitation of the authorization based on the organizational level no risk. Let me give you an example:

 

Role A: Z_ROLE_A_1000 for company code 1000 with action FB60

Z_ROLE_A_1000.png

Role B: Z_ROLE_B_2000 for company code 2000 with action FK02

Z_ROLE_B_200.png

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.

 

The combination of FK02 and FB60 is a SOD risk, as posting of vendor invoices and changing of vendor master data shouldn’t be performed by the same person. A user who gets the two roles would have both transactions assigned hence the risk analysis shows a risk. Actually this isn’t a risk, but as the organizational values are not considered it shows as a risk. This behavior is false positive as the user cannot execute FB60 and FK02 for the same company code. To filter these false positives you can utilize organizational rules.

 

While running a regular risk analysis, the user would show up with a SOD conflict, as he has both conflicting transactions assigned.  To find out if the risk exists for the same company code you can use the organizational rule. Therefore create an organizational rule hat filters the company code 1000 and apply this org rule to the risk analysis. After adding the org rule to the analysis the user won’t show up with the risk. Please be aware that after creating org rules the SOD rules must be regenerated (GRAC_GENERATE_RULES).

 

In most of the cases org rules are created for designated risks. Alternatively it is also possible to define org rules for all possible false positives by using wildcards (e.g. XGPR*).

 

Looking forward to your input.

 

Best regards,

Alessandro

To report this post you need to login first.

22 Comments

You must be Logged on to comment or reply to a post.

  1. Gretchen Lindquist

    Alessandro,

    Funny you should mention:
    “There are only very few companies who have a business need to create org rules”

    Org rules have been a big issue at both of the SAP customers where I have worked and are quite a challenge to manage manually. Rather than being used to eliminate SOD false positives, org rules that I have seen have been about ensuring that users with access to data of one business unit do not also have access to data of another, regardless of the tcodes. I have heard that the org rules can be configured to manage such a control, but we have not gotten around to doing it yet. If we ever get around to doing it with a ruleset, I will be sure to blog about it.

    Thanks for posting your very informative document.

    Regards,

    Gretchen

    (0) 
    1. Alessandro Banzer Post author

      Hi Gretchen,

       

      thanks for your feedback. Based on your experience (which is definitely much more than mine) I am completely agreeing with you. In my scenario I am using org rules from time to time and it helps to manage false positives as mentioned in the document.

       

      Hope to get served with new functionalities in the future.

       

      Regards,

      Alessandro

      (0) 
  2. Ameet kumar

    Hi Alessandro,

     

    Thank’s for sharing this detailed and self explanatory document. I was waiting for this for some time now. Though it is hard to see these org-rules in real time and as mentioned by Gretchen as well, but I totally agree with you that except this concept we have no other way out (if there is any then I might not be aware of ) to eliminate the false positive SoD’s.

     

    Regards,

    Ameet

    (0) 
  3. Koteswara Rao

    Thank you very much for your detailed explanation on Organizational Rules functionality. I will completely agree with you. Regards, Koteswara Rao.

    (0) 
  4. Colleen Hebbert

    Hi Alessandro

     

    Another 5 star document!

     

    Thanks for another great document explanation of this material. You should really ask if Luciana Ullmann or someone would get you involved in building up the SAP GRC Wiki as this material is fantastic.

     

    Can next up be an example of practical example of a supplementary rule?

     

    Regards

    Colleen

    (0) 
    1. Alessandro Banzer Post author

      Hi Colleen

       

      thanks a lot. Really appreciate your feedback.

       

      I try to work out a designated document for supplementary rules as soon as possible.

       

      Best regards,

      Alessandro

      (0) 
    1. Alessandro Banzer Post author

      Hi Madan,

       

      as I do not have authorization to work on such documents I have to post directly here. Also that document is from version 5.3 which is slightly different to my post. I always try to bring in a business view with examples, lifecycles, processes, etc.

       

      Regards,
      Alessandro

      (0) 
      1. Colleen Hebbert

        Hi Alessandro

         

        I always try to bring in a business view with examples, lifecycles, processes, etc.

         

        I think that is the key thing that separates your documents and blogs from the SAP material and why it is not duplicate content (which we need to try to avoid)

         

        But it is also why I think you should be part of developing the WIKI as your practicals examples explains these topics quite well.

         

        Regards

        Colleen

        (0) 
        1. Alessandro Banzer Post author

          Hi Colleen

           

          up to them – I am always looking forward and try to share knowledge and contribute together. We may all benefit from each other.

           

          Regards,

          Alessandro

          (0) 
          1. Prem Balraj

            Hi Alessandro,

            If you would like to post this in Wiki, please pass on this document and I can do on behalf of you.

             

            Thanks

            Prem

            (0) 
  5. Plaban Sahoo

    Hi Alessandro,


    frankly speaking, I was expecting the links(in SPRO/NWBC), where we can create Org. values, in this document. So, could you suggest if any such. document is available.

     

    I am also trying from my side, to configure Org. values in SPRO->..->Define Organizational value maps, but its a little confusing, as it provides a Entry called Org. value Mapping, where i have to create a new entry for each org. value.

     

    Regards
    Plaban

    (0) 
    1. Colleen Hebbert

      Hi Plaban

       

      I am unsure if you are aware of this but starting a sentence with “Frankly speaking” can be interpreted as hostile and critical behavior. I really hope this in not your intention given how much assistance the GRC space has provided you with over the past month.

       

      I suspect you mean well based on showing appreciation throughout other posts. Though, you would show the community further appreciation by closing out your questions if they have been resolved or replying to them with updates.

       

      In relation to your desire and your comment here you appear to be merging two topics.

      1. Organisational Rules (this blog) is about functionality in the Risk, Analysis and Remediation Module
      2. Organisational Maps (your requirement) is about assisting in building derived roles as part of the Business Role Management module

       

      We have a collaboration project on that you could add a request for the BRM topic to be produced (if you have searched help.sap.com, SCN and wiki and cannot find a topic). Depending on member’s availability and desire, someone might be able to volunteer and have a go at producing such a document.

       

      Have you attended the GRC300 training? Organisational maps are captured as a topic there.

       

      Regards

      Colleen

      (0) 
      1. Plaban Sahoo

        Hi Colleen,

         

        I apologize, if there was any ‘hostile and critical’ behavior reflecting from my comment. That was never the intention.

        I have closed out my resolved questions.

         

        Regards

        Plaban

        (0) 
        1. Colleen Hebbert

          That was never the intention.

           

          All good. I suspected that was the case which is why I explained that language style and perception to you. Thanks for helping keep our space “clean” by closing out your questions

          (0) 
    2. Alessandro Banzer Post author

      Hi Plaban,

       

      this document elaborates the concept and behaviour of organizational rules in access risk analysis and isn’t suspected to be a step-by-step instruction.

       

      As Colleen mentioned if you are missing content please use the collaboration document (GRC Document Collaboration Topics) to request so that others can step in and help.

       

      I always appreciate feedback on my documents but please consider what was the intention and purpose of the documents. This is definitely more a concept than a manual and hence no steps are shown.

       

      Regards,

      Alessandro

      (0) 

Leave a Reply