cancel
Showing results for 
Search instead for 
Did you mean: 

ARQ: Mitigating a risk in a request???

former_member184114
Active Contributor
0 Kudos

Hi All,

ARQ and ARA is integrated for risk anlaysis. When a request contains some risk violations, it is routed to specific team and when they mitigate it, two things are happening:

1. New workflow is triggered for mitigation control assignment to the risk. This will send approval mail to mitigation control owner. He can either approve or

   reject it.

2. The existing request is open and free to take any actions. For example, when a mitigation control workflow is triggered and waiting for mitigation control

    approver's approval, I can either approve or reject the ARQ request.

My question is that, it is default behavior? If this is, then these workflows are independent. What happens if mitigation control approver rejects the assignment and I approve the request in ARQ?

This seems to be conflicting and ARQ request approval SHOULD be dependent on mitigation control assignment approval!

Can anybody please suggest on this?

Regards,

Faisal

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Faizal,

Agreed that there should be the way to make it request dependent specially for the mitigation workflow which are triggered through access request workflow.

But currently this is not possible. As both the workflow are very independent.

for example mitigate risk is just a function available in request workflow screen, you can set it manually too if you have not activated mitigation workflow.

I think if you have option selected in task settings as approve inspite risk it will allow you to approve irrespective of mitigation control approval/rejection.

You can try this by creating a test request if you already have workflow activated for mitigation and access request.

BR,

Mangesh

former_member184114
Active Contributor
0 Kudos

Mangesh,

Thanks for your reply.


for example mitigate risk is just a function available in request workflow screen, you can set it manually too if you have not activated mitigation workflow.

This is for the first time I tried to mitigate it using this function from ARQ. It gave me error:

"No Active version exists for process &SAP_GRAC_CONTROL_ASGN&"

Then I activated this workflow and mitigated the risk. This time is through and went to mitigation approver.

Can you please let me know how I can make it manual?


I think if you have option selected in task settings as approve inspite risk it will allow you to approve irrespective of mitigation control approval/rejection.

I have not selected "Approve despite risk" option. Actually, it should not allow me to approve if I dont select this option. However, system is allowing me to approve without its selection!

Can you please advise?

Regards,

Faisal

Former Member
0 Kudos

"No Active version exists for process &SAP_GRAC_CONTROL_ASGN&"

You get this error as you have set 1062 to yes and that means you are telling system to use mitigation assignment workflow, but as you had not activated MSMP workflow for mitigation assignment, system gave you this error.

1061: mitigation maintenance: This will activate mitigation maintenance function, but you will have to activate mitigation maintenance workflow too, to make it work.

Do not set above config if you want to do it manually.


I have not selected "Approve despite risk" option. Actually, it should not allow me to approve if I dont select this option. However, system is allowing me to approve without its selection!

Yes, you are correct system should stop you from approval if you have this option not selected in task setting.

Please send me screenshot for task settings for your stages, so I can advice.

BR,

Mangesh

former_member184114
Active Contributor
0 Kudos

Mangnesh,

Thanks for your reply.

Please find below settings:

Please advise.

Regards,

Faisal

alessandr0
Active Contributor
0 Kudos

Hi Faisal,

how did you configure parameter 1072? Set to YES? Then it should actually work with your setting.

Regards,

Alessandro

Former Member
0 Kudos

Hi Faizal,

Alessandro is right, it will work with this parameter 1072.

And my apologies for wrong argument. I completely forgot about this parameter. With this you can have your system locked before mitigation is assigned.

So my reasoning in my reply is wrong.

But you can have it done through workflow or through manually as I stated in the reply.

BR,

Mangesh

former_member193066
Active Contributor
0 Kudos

Look for Configuration parameter.

Risk Analysis - Access

Request 1072 Mitigation of critical risk required before approving the request

If its no then will get approved.

former_member184114
Active Contributor
0 Kudos

Alessandro,

Thanks for your reply.

It is currently set to "NO". I think I need to set it to "YES".

But will it ask to mitigate a risk at the final stage ?

Regards,

Faisal

former_member184114
Active Contributor
0 Kudos

Dear Mangesh,

Earlier, 1062 was set to "YES" due to which workflow was getting triggered. Now I changed it to "NO".

1061 was not available and I inserted it and set it to "NO". I still see the mitigate risk button in ARQ. Am I correct in understanding that 1061=NO will hide the "Mitigate Risk" button in ARQ?

May I know it usage please?

Regards,

Faisal

alessandr0
Active Contributor
0 Kudos

Dear Faisal,

depends on the settings. If the parameter is set to YES you are asked to set a mitigation for critical risks before final approval.

In the workflow you can define that you are not allowed to approve a request when there are risks. In this szenario set the risk analysis as mandatory, so that is has to be run, and do not allow to approve requests beside risks. If you have such set up the user has to run the risk analysis and if there are risks it is not possible to approe. Hence a mitigation is required.

Please be aware that you have to restrict the risk analysis options, as it might be possbile to work beside the tool if you run the risk analysis for the wrong system or with wrong parameters/criterias.

My set up is like mentioned above: I do not allow to approve beside risks and risk analysis is mandatory and restricted to permission level for productive system.

Does this answer your question?

Best regards,

Alessandro

alessandr0
Active Contributor
0 Kudos

Hi Faisal,

see sap note regarding parameter 1061:

The application allows users to create and change mitigating controls.

Set the value to YES to require that when users create or change mitigating controls, the application sends a workflow item to an approver

to approve the action.

Note: On the Mitigating Control screen, the Create button is replaced by a Submit button.

You can configure the role that receives the workflow item for approving the mitigating control changes using the Customizing activity

Maintain MSMP Workflows under Governance, Risk, and Compliance > Access Control > Workflow for Access Control.

Figure A below shows that on the control Owners tab the Mitigation Control Approver points to the Approver.

Figure B below shows you can use Maintain MSMP Workflows to change the approver agent ID (GRAC_CONTROL_APPROVER).

Regards,

Alessandro

Former Member
0 Kudos

Hi Faizal,

If 1061 is not available in configuration parameter setting it means it is set to default value which is NO for this parameter. But better you set it to NO so now you can have the clarity as you can see it there.

Setting this parameter will not hide "Mitigate risk" button as this should be there in both manual or automatic scenario.

Hope this clears your doubt.

BR,

Mangesh

former_member184114
Active Contributor
0 Kudos

Dear Alessandro,

Thanks again for your reply.

1072 is now set to "YES". Does it mean that it will only consider CRITICAL risks in a request, as the parameter itself suggests?


In the workflow you can define that you are not allowed to approve a request when there are risks. In this szenario set the risk analysis as mandatory, so that is has to be run, and do not allow to approve requests beside risks. If you have such set up the user has to run the risk analysis and if there are risks it is not possible to approe. Hence a mitigation is required.

I have used "YAC" as "Risk Mandatory" parameter at Manager and Role Owner stages as they as allowed to operate at line items also. It means, if any role is deleted from the request by any one of them, system will force to re-run the risk analysis (this is tested and working fine).

Now with above settings if I set 1072=YES, can I presume that any request having violations will not be get approved? OR requests with only critical risks will not be get approved? Please clarify?


Please be aware that you have to restrict the risk analysis options, as it might be possbile to work beside the tool if you run the risk analysis for the wrong system or with wrong parameters/criterias.

Can you please help me understand this better?


My set up is like mentioned above: I do not allow to approve beside risks and risk analysis is mandatory and restricted to permission level for productive system.

Yes, I have also set risk analysis mandatory as mentioned above. I have also disabled all risk analysis options except "Actions" and "Permission", latter being the default choice.

Can you please explain: I do not allow to approve beside risks

Regards,

Faisal

former_member184114
Active Contributor
0 Kudos

Mangesh,

Thanks for your reply.

Can we hide this "Mitigate Risk" button from Manager and Role Owner screen? I really do not see any value there as we have either specialized team to do it or our highest authority will do it. So, having this button available for responsible makes sense. But I don not expect Manager and Role Owner to do it as per my current business requirements.

The possibilities to do it, I think are:

1. Authorization Object - I have not used it yet. Would be interested to know about it.

2. Hide this button from SE80 for this approver application. However, this might disable for all the people who are using this approval application (other than Manager and Role Owner)

Any advice please?

Regards,

Faisal

former_member184114
Active Contributor
0 Kudos

Alessandro,

I am a bit confused betwee 1061 and 1062. Please correct me if I am wrong in explaining below:

1062: Triggers workflow for mitigation control maintenance. This also includes "assignment" a control while mitigating a risk. As I started this thread with, this parameter was set to "YES" and I faced problem of workflow version and got error:

"No Active version exists for process &SAP_GRAC_CONTROL_ASGN&"


I activated above process while still 1062 was set to "YES". This without any doubt, triggered a workflow when someone responsible tried to mitigate a risk. Actually it opened another workflow for above process.


Then as suggested by Mangesh, I set it to "NO". And this time when someone responsible tried to mitigate a risk, it allowed and no new workflow is triggered for above process.


So, based upon above experience, I can confirm that 1062 helps triggering workflow for mitigation control maintenance (I tested only for assignment, though).


As mentioned above, I could not find 1061 in my configuration initially. I added it and set it to "NO". Now may I know what could be the behavior of the application?


Currently:


1061=NO

1062=NO

Please advise.

Regards,

Faisal

Former Member
0 Kudos

Hi Faizal,

You answered the query itself, like if you hide this it will be applicable for all, so this is not good solution.

Authorization object for mitigation is GRAC_MITC, please try doing some testing with it.

BR,

Mangesh

alessandr0
Active Contributor
0 Kudos

Hi Faisal,

"Approve beside risks" means the setting which can be defined in the MSMP workflow configuration. Please see the following printscreen:

If you deactivate this checkbox it is not possible to approve the request when you have risks in the risk analysis results. Hence you can ensure that risks must be mitigated before final approval. Also to mention that this option is deactivated at the final stage (security stage) and activated for role owner and manager stage.

Example: request with risks

Manager Stage (1st stage): Approve Despite Risks possible (checkbox active)

Role Owner Stage (2nd stage): Approve Despite Risks possible (checkbox active)

Security Stage (3rd and final stage): Approve Despite Risks not possbile (checkbox inactive)

Also mentioned that at the final stage the risk analysis is mandatory.

Does this answer the question?

Regards,

Alessandro


former_member184114
Active Contributor
0 Kudos

Hi Alessandro,

Thanks for your reply.

As I shared my screen shot earlier, notice that this is NOT selected and even though there risks in a request, system is allowing it to be submitted. Very strange!

Earlier, 1072 was set to NO and now I have set it to YES. Even system is allowing me to submit the request having violations!

Can you please advise what I am missing? Am I ignoring any other parameter?

Regards,

Faisal

former_member184114
Active Contributor
0 Kudos

Hi Mangesh,

I did some test and could discover below:

The "Mitigate Risk" button is available for all the users handling the request (Requester/Manager/Role Owner).

I tried to mitigate a risk being a request by clicking the button. I could get the further screen. However, controls were not displayed. Though I have maintained a mitigation control for that particular risk.

Please see the screen:

I tried to raise a request being an administrator having full access. When I tried to mitigate that risk, it gave me all the control details appropriately and I could mitigate the risk!

I think this button is available to all the users. However, only authorized person will be displayed the control information while mitigating a risk.

This seems to be a kind of bug in the system.

Would be interested to hear your experience on this.

Regards,

Faisal

Former Member
0 Kudos

Hi Faizal,

I think it is working as per your expectations except the error which should have been something like "User has no authorization for the mitigation control".

I have not done lot of testing on this, but I think you are right that display of this button is not based on auth object.

For wrong error you better contact SAP.

BR,

Mangesh

Answers (0)