In the 1st part of this series I explained why risks are an essential element of GRC Process Control as they provide focus, direction and guidance - the foundation of an enterprise GRC solution. In this second and final part I will provide a brief guide to the different ways in which you can manage risks within GRC Process Control which, perhaps unsurprisingly, is more complicated than you might expect.
The first thing to appreciate is that within GRC Process Control risks are master data objects themselves. Therefore, to be able to assign risks to other master data objects (e.g. controls, control objectives etc) they have to already exist within the Risk Catalogue. If you have an established control framework which you are simply moving into GRC Process Control, then the risks have already been defined and it will be a case of simply copying them into the Risk Catalogue for assignment later on. However, if you are creating a new control framework then the initial phases of this work should be focused on mapping out the enterprise risks prior to documenting the controls which mitigate them. It might still be challenging to define all of your risks up-front. This is not a problem as you can continually add to, and modify, the risk catalogue at any time, making new or updated risks available for assignment but care should be taken to ensure that they align with wider risk management strategies rather than simply polluting the GRC Process Controls catalogue.
Risks are also used in GRC Process Control to provide a link between some master data objects. It may be surprising to learn that control objectives cannot be directly linked to controls in GRC Process Control. However, both master data objects are linked when they share common risk assignments, and these indirect relationships can be seen using some available standard risk reports.
The main purpose for identifying and documenting risks is so that you can ensure the relevant measures are in place to mitigate them in line with your company's risk appetite. This helps to maintain the right balance between implementing controls and maintaining operational efficiencies. Therefore, it’s important to have the ability to perform a risk gap analysis to understand whether those risks relevant to your organisation have been mitigated or not.
Within GRC Process Control, all of the risks which need to be addressed reside at the sub-process level.
These are made up of risks which are either:
(a) Inherent to the sub-process and so are assigned from within the sub-process itself;
(b) Inherited automatically by the sub-process via control objective assignment (whereby the risk has previously been assigned to the control objective master data); and
(c) Inherited automatically by the sub-process via account group assignment (whereby the risk has previously been assigned to the account group master data). Note: The use of account groups is usually required when dealing with financial regulations e.g. SOX.
This indicates those risks that need to be mitigated by controls assigned to the same sub-process. The risk(s) a control mitigates is specified in the control master data objects themselves which are also assigned to the sub-process. Therefore, the risk gap analysis can be performed at the sub-process level. GRC Process Control achieves this analysis by automatically comparing the risks that reside on the sub-process with those risks mitigated by the controls assigned to the same sub-process. Standard reports such as 'Risk Coverage' can be used to display whether all risks per organisation/process/sub-process have been mitigated or not by the relevant assigned controls. Alternatively, you can display risk coverage in the 'Risk' tab within the sub-process master data object itself, although this will only give you a view for the individual sub-process you are currently viewing.
As you can see, there is a quite a lot of functionality and flexibility available to identify, assign and mitigate sub-process level risks in your organisation. However, it's important to fully understand the relationships between these risks and the relevant master data objects, and map these out carefully in your implementation in order to manage risk effectively using GRC Process Control.
