sap grc asking to mitigate even old risks

[Former Member]

sap grc is asking to mitigate even old risks. Before the GRC was implemented, some roles were assigned to the users. But after the GRC system is set up and when we add the role to the user through access request, then the system asks to mitigate the new risks which are coming from the role being requested via access request, this is ok we will mitigate this.

But the grc is also asking to mitigate the old risks which are coming the old roles assigned to the user, i.e. before the GRC was implemented. if I dont mitigate the old risks then then i am not able to submit the access request. Is there a way, wherein I want to submit the access request by just mitigating the new risks but not the old risks.

[Colleen · Accepted solution]

HI Abdul

Before looking at the technical aspects, just wanted to check why you don't want to deal with old risks? Is there a remediation project on the side to address these issues? This is a process discussion. ARQ process provides an opportunity to deal with existing risks at the same time as new access.

However, I can understand that your access approvers may not be trained/equipped to deal with the older roles. Without knowing about your system, I would suggest looking at following topics/options to see what you system is configured:

• Risk Terminator for Users - do you have this switched on to prevent access going through with unmitigated risk (configuration parameters 1082 and 1083)
• MSMP stage settings for approval with risk - is approve despite risk selected? Refer to https://blogs.sap.com/2016/06/18/every-option-you-need-to-know-in-msmp-path-modify-task-settings/ for the screen shot
• Configuration parameter 1072 - Mitigation of critical risk required before approving the request
• Configuration parameter 1073 - Enable SoD violations detour on risks from existing roles
• Configuration Guide "If an SoD risk exists in an access request, the application considers it a special condition and sends it to a detour path in the workflow. However, SoD risks may arise from the new roles the user is requesting and they may arise from the existing roles that are already assigned to the user. Set the value to YES to consider risks from new and existing roles for the detour. Set the value to NO to consider risks only from new roles (and not existing roles) for the detour. "

Regards

Colleen

[Former Member · Accepted solution]

Hi Colleen, Yes there is a separate remediation project on the side, which is more holistic and with which we can deal with old risks.

1. 1082 and 1082 is not switched on.
2. MSMP stage settings approve despite risk selected is not selected for the second line approver (risk approver). However for the first line approval (line manager) this is selected approve despite risk is selected as the line manager ownership is to just check if the related function/area roles are assigned.
3. 1072 is set as Yes. Yes – Enabled (Set the value to YES to require mitigation of Risks of the type Critical Access )
4. 1073 is set as Yes. Set the value to YES to consider risks from new and existing roles for the detour. Set the value to NO to consider risks only from new roles (and not existing roles) for the detour. Thanks – I think I need to change this value to NO to consider risks only from the new roles. Plz let me check on this one, I will get back to you. thanks once again.
   

[former_member73766]

Hi Abdul,

Can you explain more about the old roles assigned to the user? The roles are still assigned? the sync jobs were run? This risks are still relevant?

Regards

Rafael