GRC Process Control - Its all about Risk (Part 2)

n 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 focussed 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 companys risk appetite. This helps to
maintain the right balance between implementing controls and maintaining operational
efficiencies. Therefore, its 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, its 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
- See more at: http://www.turnkeyconsulting.com/blog-entry/_/grc-process-control-its-all-about-
risk-part-2/228/#sthash.Es2OOmDo.dpuf