Risk Tip #6 – Managing Shared Risk
I have often been asked to provide insight into the management of shared risks, particularly by those working in Commonwealth Government Departments.
Element 7 of the Commonwealth Risk Management Policy states that: each entity must implement arrangements to understand and contribute to the management of shared risks. It goes onto to define shared risks as: those risks extending beyond a single entity which require shared oversight and management. Accountability and responsibility for the management of shared risks must include any risks that extend across entities and may involve other sectors, community, industry or other jurisdictions.
That might sound simple enough – but is it?
The answer to that question lies in my view that in organisations of today there is no such thing as a risk that isn’t a shared risk. There would be very few organisations where the ownership of the risk, the ownership of the controls and those affected by the consequences would reside in one functional area.
To that end, the way I manage shared risks (i.e. – every risk), is shown in the process below:
Each of these steps is described below.
The Methodology
Step 1 – identify the risk
Identify the event/incident that, if it occurs, will have an impact on the objectives of the organisation
Step 2 – identify the causes
Identify the potential causes of the identified risks. Identifying the causes is one of the most critical steps in any risk identification. If you don’t identify the causes, then how can you ever hope to identify the controls needed to stop it happening?
Step 3 – identify the controls aligned to each of the causes
Identifying the controls directly linked to the causes will highlight where there may be control gaps that need to be filled. It may also highlight opportunities to reduce the number of controls in circumstances when the controls may not be contributing to the management of that (or any other) risk.
Step 4 – identify owners for each of the controls
It is critical to identify the owners of the controls. Without ownership, no-one will have responsibility for maintaining the currency of the control, ensuring its effective implementation, and/or the measurement of effectiveness.
These owners will become part of the stakeholder group for the management of the risk.
Step 5 – detail the consequences should the risk eventuate (including who will be affected)
Understanding the breadth of consequences will provide an understanding of, not only the impact of the risk, but also the stakeholders inside and outside of the organisation that will be affected.
Step 6 – identify the controls aligned to each of the consequences
Identifying the controls linked to the consequences will, once again, highlight where there may be control gaps that need to be filled. It will also highlight other stakeholders that will be responsible/relevant in the response to an incident should the risk eventuate.
Step 7 – identify owners for each of the controls
These owners will become part of the stakeholder group for the management of the risk.
Step 8 – identify other stakeholders
During this step, we identify:
- Organisations or functions that provide:
- Decision making;
- Funding;
- Services related to the risk (including outsourced providers);
- Policy (including regulators).
- Organisations/groups that will be impacted, directly or indirectly by the consequences should the risk occur but who do not fit into the categories above. These are secondary stakeholders.
Step 9 – based on the owners identified in steps 4, 5, 7 and 8 – develop a stakeholder map
The stakeholder map is a visual representation of the stakeholders identified through previous steps. They will be stakeholders that will be responsible for trying to prevent the risk, detect any instances of the risk, those that implement corrective controls after the event if it occurs, and those affected by the consequences (secondary stakeholders).
Step 10 – assign ownership to the risk
Once the stakeholder group has been identified, ownership can now be assigned. This can be difficult in some circumstances as the majority of the controls associated with the risk may not sit in the area responsible for the outcomes.
The level of ownership of the risk within the organisation is also a key consideration. My rule of thumb regarding this is that the ownership of the risk must be at or above the ownership of the highest-level control. My rationale for this lies in the fact that, in order to be able to assure that a risk is being managed effectively, the risk owner needs to gain assurance from the control owners as to the effectiveness of the control. A risk owner at a lower level of the organisation will not necessarily have the authority to request assurance from a control owner at a higher level of the organisation and, as such, it becomes impossible to gain a full understanding of the risk and its likelihood.
Step 11 – remainder of process (assign likelihood, consequence, determine risk level, evaluate, treat .etc.).
We will not go through the full process beyond the assigning of ownership, however, before that can be done, all of the steps we have listed above need to be completed.
Example
So, let’s go through this step by step for a risk that is common to many organisations.
Step 1 – identify the risk
The risk we will use for this example is:
Unauthorised access to, release of or misuse of confidential information
Step 2 – identify the causes
In this case, there are a number of causes that may lead to this risk occurring:
|
Unauthorised access to, release of or misuse and loss of information |
Lack of/inappropriate IT access controls |
| Lack of/inappropriate physical access controls | |
| Inadequate/ineffective training of staff | |
| Cyber attack | |
| 3rd party release | |
| Inappropriate storage and disposal |
Step 3 – identify the controls aligned to each of the causes
We can then identify controls for the identified causes:
|
Unauthorised access to, release of or misuse and loss of information |
Lack of/inappropriate IT access controls | Security model for electronic data and hardcopy categorisation |
| Security model in place and reviewed for each system | ||
| Regular review of access logs | ||
| Active notification of unauthorised access | ||
| Lack of/inappropriate physical access controls | Card access restrictions for data storage areas | |
| Information management strategy | ||
| Sign out/sign in procedure for sensitive information | ||
| Audit program of access logs | ||
| Inadequate/ineffective training of staff | Training/awareness that reflects the security model | |
| Annual induction | ||
| ICT Induction | ||
| Cyber attack | Malware/virus protection | |
| Firewalls of the appropriate standard | ||
| Firewall OS patched | ||
| Firewall actively monitored | ||
| Servers Patching | ||
| Procedure in place in the advent of attack | ||
| 3rd party release | Confidentiality agreements | |
| Regular review of access logs | ||
| Inappropriate storage and disposal | Policies and procedures | |
| Records Plan | ||
| Regular review of access logs |
Step 4 – identify owners for each of the controls
We then identify the owners for each of these controls:
|
Unauthorised access to, release of or misuse and loss of information |
Lack of/inappropriate IT access controls | Security model for electronic data and hardcopy categorisation | Manager ICT |
| Security model in place and reviewed for each system | Senior Business system officer | ||
| Regular review of access logs | Team leader IT | ||
| Active notification of unauthorised access | Manager ICT | ||
| Lack of/inappropriate physical access controls | Card access restrictions for data storage areas | Security Manager | |
| Information management strategy | Knowledge Manager | ||
| Sign out/sign in procedure for sensitive information | Security Manager | ||
| Audit program of access logs | Security Manager | ||
| Inadequate/ineffective training of staff | Training/awareness that reflects the security model | Learning and Development | |
| Annual induction | Knowledge Manager | ||
| ICT Induction | Manager ICT | ||
| Cyber attack | Malware/virus protection | Manager ICT Team Leader IT | |
| Firewalls of the appropriate standard | Manager C | ||
| Firewall OS patched | Team leader IT | ||
| Firewall actively monitored | Team leader IT | ||
| Servers Patching | Team leader IT | ||
| Procedure in place in the advent of attack | Manager IT Team | ||
| 3rd party release | Confidentiality agreements | Manager IT Team | |
| Regular review of access logs | Team leader IT | ||
| Inappropriate storage and disposal | Policies and procedures | Manager ICT | |
| Records Plan | Manager ICT | ||
| Regular review of access logs | Team leader IT |
Step 5 – detail the consequences should the risk eventuate (including who will be affected)
The consequences in this case are as follows:
- Negative impact on reputation;
- Potential legal action;
- Potential interest from the regulator.
Step 6 – identify the controls aligned to each of the consequences
The controls in this case are:
|
Crisis Management Plan |
| Crisis Management Team established | |
| Communications Team | |
| Disaster Recovery Plan |
Step 7 – identify owners for each of the controls
In this case the owners are as follows:
|
Crisis Management Plan | CEO |
| Crisis Management Team established | Communications Manager | |
| Disaster Recovery Plan | ICT Manager |
Step 8 – identify other stakeholders
In this case, there are a range of other stakeholders that have ‘skin In the game’ that may not own the controls previously listed but fall into the categories previously outlined.
- Organisations or functions that provide decision making; funding; services related to the risk (including outsourced providers); and policy (including regulators).
- Secretary;
- Head Corporate Services (owns IT, procurement and security functions);
- IT contractor;
- Classified waste contractor;
- Procurement Manager; and
- Contract Manager.
- Organisations/groups that will be impacted, directly or indirectly by the consequences should the risk occur but who do not fit into the categories above. These are secondary stakeholders.
- Clients/companies that have had their data released
Step 9 – based on the owners identified in steps 4, 5 and 7 – develop a stakeholder map
Based on the analysis to date, the following is the stakeholder map for this risk:
Step 10 – assign ownership to the risk
In this case, based on the level of the controls, the most appropriate person to be the owner of this risk is the Head Corporate Services.
Conclusion
The simple facts that organisations need to recognise are:
- All risks within the organisation are shared risks; and
- Ownership of those risks needs to rest at or above the level of the person who owns the highest-level control.
We have only looked at a risk internal to an organisation where all the controls are owned within that organisation. Consider the complexity of managing risks where there are controls that are owned by other organisations. To illustrate, here is the stakeholder map for the risk of a collision of two trains:
If the stakeholders are not understood, and the process shown in this blog is not undertaken – an organisation can never hope to effectively manage their (shared) risks.
