Implementing Mitigation Control IDs

[Former Member]

Hi,

We are planning to implement mitigation control ids in GRC. Currently we are only having 1 mitigation control id and all the users are mitigated into this id.

Now, the plan is to include the mitigation control advise/comments by the SOD approvers into the GRC and thus by introducing multiple mitigation control id we could achieve this.

In our system users are mapped as per the Business Unit and we have around 25-30 business units. so each BU is have a seprate mitigation control approval (SOD Approver).

We have around 150 Risk IDs.

We are not able to understand how to design mitigation control IDs in such case? Is it a best practice to create mitigation control ID for each Risk ID in the system (May be we can group similar Risk IDs)? Your help is appreciated.

Thanks,

Umesh

[Former Member]

Hi Umesh,

 Currently we are only having 1 mitigation control id and all the users are mitigated into this id.

This is something strange. So, you mean your have only 1 mitigation control, 1 monitor, 1 risk owner ??

I recommend you to go to the respective Line of Business to understand how they want the risks to be controlled or monitored. It is not fair to make 1 person review/approve/monitor the risks in the system.

For your information, the mitigation controls are created based on the risks (they can be often grouped) and the normal grouping is done on primary and secondary functions.

Regards,

Raghu

[Former Member]

No, for 1 Mitigation COntrol there are serveral Monitors and users who are mitigated are added to only 1 mitigation control id.

Can you pls explain more on primary and secondary functions? and what are the disadvantage of creating 1 mitigation control id for each risk (may be grouping some risks) considering the fact that we have 25 business units.

Thanks,

Umesh

[Former Member]

Hi Umesh,

 No, for 1 Mitigation COntrol there are serveral Monitors and users who are mitigated are added to only 1 mitigation control id.

Which means you have multiple people monitoring every risk in your system. Does all of the monitors belong to the same functional group?? If yes, what happens if there is a risk in other functional groups? How they can identify and monitor it??

If no, why a FI functional group monitor, needs to monitor the risk related to other groups?

 Can you pls explain more on primary and secondary functions?

If the risk is related to one functional area only, the respective functional area will own it. If it is a cross functional risk, then it will be owned by both the functional area managers, which is often referred as primary and secondary functions.

  and what are the disadvantage of creating 1 mitigation control id for each risk (may be grouping some risks) considering the fact that we have 25 business units.

It is just like giving 1 coke with 100 straws while you still have a stock in your refrigerator

Regards,

Raghu

[simon_persin4]

Hi Umesh,

I tend to agree with Raghu on this one.

I struggle to see how you can truely manage all of the associated risks with a single control. Are you saying that every risk identified in the system is managed via the operation of a single control across all of your business areas and that all of your users are covered by that control?

I tend to take a more risk based approach with a mitigation being explicitly linked to a single risk. The owner of the risk often has the management approver role for the associated mitigating control and is able to certify its relevance in controlling the risk. The monitor is then someone independent who is responsible for operating that control.

If the control spans multiple operating business units, then consider having a GLOBAL Business unit assigned with a central contol monitor. However, if it is a more localised control, then the approval and monitoring of the control also stays within the defined Business units.

Breaking down the mitigating control into smaller areas also provides the auditors with slightly more comfort that you have adequate controls which actually operate (not always the case, but slightly more realistic than one single global catch-all).

Simon