SAP GRC SOD DISCUSSION

[madhusap]

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.

Regards,

Madhu.

[naveen_alluru]

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

[madhusap]

Hi Naveen,

I just gave an example. For every scenario this is what they are looking for. Risk should be shown only for few and for others risk should not show at all.

Mitigation means, even though they have risk we mitigate it. But how do we restrict to show risks for few users and not for others.

If we define 2 conflicting transactions as risk, it will be risk for all users. How can we say that risk show up only for few users and not for few users. ?

This is the thing i was asked for

Regards,

Madhu.

[naveen_alluru]

you are right. risk need to be identified at organisation level, not yet user level.

only work around is possible....

or create 2 roles with same tcodes and objects....one mitigate at role level for those whom they dont want to see .....and one for others

[Former Member]

I agree that I think using 2 roles would work better. Is there any difference in the jobs that those users will do? Between the ones with the risk and those without? or is it just going off for having both abilities in the system, to create and edit?

[Former Member]

Madhu,

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!

Cheers,

Gretchen

[AndrzejP]

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

[AndrzejP]

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

job position?

organization?

specific users?

others?

[kevin_tucholke1]

Madhu:

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.

Thanks

Kevin Tucholke

[Colleen]

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.

Regards

Colleen