SOD review strategy after GRC implementation

[Former Member]

I am doing the role review project after the GRC implementation. I started reviewing the HR roles, and after deleting tcodes which are not used by the consultants, I still left with lot of risks in their roles. Now as they said, they are using the rest of tcodes, so I am not sure what should be the next strategy, may i mitigate the remaining risks. But as still there are lot of risks, so I should create mitigation control for the whole risk or only limited to rule id.

Experts, from your experience can you suggest the best possible step to review the roles in this case.

[Former Member · Accepted solution]

Hello,

This is note will provide you the required information:

Note 1593056 - Best Practices for Remediation of Segregation of Duties risk

Roles should be "SoD free". I think this is a good starting point. If you have a role with SoD conflicts a good strategy could be divide the role in two or more roles without SoD conflict. Even though you might assign the roles to the user anyway it's a good strategy. Why? If in the future you have two or more persons to cover the corresponding functions and you can eliminate the SoD, you'll have the roles already created.

Cheers,

Diego.

[Former Member · Accepted solution]

Dear Diego,

Your recommendation is right. But even if we split the roles we have to assign the roles to the users as they are used by them and it still shows lot of risk as per the GRC risk report.

I would like to clear, as we are not able to remove the conflicting tcodes what wil be the next step. I already checked the org values and even that cannot be changed. So mitigation is the only solution left, please suggest.

Also mitigation to do now at user level or the role level.

[Former Member · Accepted solution]

Sameer,

Yes, the next step is to mitigate the corresponding users. But take into account that split the roles is a good practice.

Another approach that for me is theorically incorrect, but technically possible is to move the corresponding conflicting actions to a Firefighter. At this point is required the roles to be splitted. If you have a user A with assigned roles R1 and R2 and this generates a SoD conflict, you can remove to the user A the role R1 or R2 ( but not both). Then you can assign the remaining role to a FF user and allow user A to use this firefighter. This is technically possible and it will remove the corresponding SoD in RAR, but this is not the idea of a Fifefighter user and I think this is theorically incorrect. Of course, the correct option is to mitigate.

Cheers,

Diego.

[Former Member · Accepted solution]

Diego,

The suggestion to move the conflicting tcodes came to my mind, but the problem is user will have to login into GRC system to execute the FF tcodes.

This will be frustrating for them, as they will be doing the task on Production system and when they will not be able to execute some transaction, they will have to login into GRC Production system to execute rest of transactions.

I am not sure about the earlier version but in AC 10, user need to login into GRC Production system to run the FF assigned tcodes.

[Former Member · Accepted solution]

Sameer,

You're right. It isn't confortable for the user. Maybe it's not a problem if the transactions included in the FF are used for special situations and not on daily basis. The point is, as i mentioned earlier, the correct option is to mitigate. In GRC 5.3 the user don't need to login to GRC prod system, He/She just execute tx. /virsa/vfat in backend. Anyway, users complain about it, and they're right, because if the risk exist, you have to accept it and then mitigate it. If there's no enough people to split the functions and one person should do more than one conflicting functions there are two options. The manager should be able to split the functions among two or more users. If this is not possible, you have to accept the risk, because the risk do exist. GRC cannot solve this point, because there's no magic solution to this. But GRC provides you the tools to document and control the mitigation controls.

Cheers,

Diego.

[Former Member]

Hi,

The Best practice is redeisgn the roles first, due to this you can avoide the SOD conflicts at role level. at finally mitigate the users with proper mitigation controles,if is the any conflicts found with the assignment of different conflict roles to the users.

Regards,

Arjuna.