Skip to Content


Hi Consultants,

Today i had a discussion with our client for SOD implementation and below are the requirements given by them.

Create Booking transaction and Edit Booking Transaction have conflicts according to business. [Our example scenario]

Assume that there are 6 different positions in the organization. They say that for 3 people it is a risk and for other 3 it should not be a risk.

We clarified them that if we define a risk in the system, it is common for all users and will not depend on user's position. But they wanted us to create risks in such a way that it should come up for few people and shouldn't come up for few people.

Has anyone come across such scenarios? If you have come across how did you handle those?

I want to understand SCN GRC consultants point of view on this.



Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

5 Answers

  • Posted on Feb 14, 2014 at 10:40 AM

    Mitigate them for whom you do not want to see the risk

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Madhu Babu #MJ


      I suspect that if you spoke with the organization's external auditors, they would tell you that the actions/ permissions in question are either a risk to the business per their processes or they are not a risk. Even if you try Adrzej's suggestion, which is something that I have seen done, the users with the "mitigated" risks still show up as having risks; they are just risks that have been "mitigated" by approved exception.

      If it really is a risk to the business, approving them as exceptions, whether at the role level or the user level, does nothing to mitigate/lessen the risk/danger of the bad outcome that could happen. It still could happen; they are just saying in effect that they accept the risk, which is not at all the same thing as mitigating the risk. Accepting a risk is a legitimate business decision, but it is not the same at all as mitigating it. Good luck!



  • author's profile photo Former Member
    Former Member
    Posted on Feb 14, 2014 at 10:49 AM

    Hi Madhu,

    Adding to what Naveen mentioned the easiest way is to create a mitigating control: "Risk not pertinent due to user's position or job responsibilites" or sth like that, and assign fot this conflict to users for whom that risk should not be visible. Then if someone runs SoD report, depending on your SAP GRC set-up will either not pop-up to users, or be shown as mitigated.

    Hope it helps.

    Best regards, Andrzej

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Feb 14, 2014 at 12:05 PM

    What should be the key, when SoDs are displayed and when not?

    job position?


    specific users?


    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Feb 14, 2014 at 05:19 PM


    What your are describing may be able to be handled by using Supplementary Rules. The requirement is that you can locate a particular user attributte from a table that has the BNAME field.


    Kevin Tucholke

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Feb 17, 2014 at 05:38 AM

    HI Madhu

    I see your question not so much as how to solve this in GRC but why would it be a risk for 3 users and not for another for same system access. I agree that a risk is about the exposure and not the individual (more so, the 3 as the exceptions are probably in positions of trust that could be exploit trust).

    However, when we look at actions and permissions there may be other factors at play that reduce impact which in turn reduce risk severity. that is, there are other inherent system controls. Or the financial cost to implement the control is more than the financial loss should a fraudulent event occur.

    For example, if the transaction is one for Approval there may be financial delegation at place. To an organization they may not want to report on risk for small financial delegations (may be picked up another way) whilst over a certain threshold needs to be reported and managed.

    Bringing my example back to GRC specific, in this case (as Kevin mentioned) a supplementary rule could be used to exclude those users. Alternatively, as others have mentioned, mitigating the users will allow you to filter them from the report but still acknowledge they have the risk.



    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.