The Difference Between Risk and Source of Risk

on

 



Let’s assume you have completed a detailed risk assessment, have identified a host of additional controls to purchase and implement, have the authority to spend $2,000,000 on additional controls and… go out shopping with your “bucket list”.


You spend the next few months implementing your controls and have great confidence that your risk planning and management are now ready.


Guess what…you go to work one day and you find your risk is suddenly realised—and your boss asks you how could this happen?


This scenario happens a lot and often the problem is not the risk, nor the implementation of additional risk controls—it is the failure to identify and assess the sources of risk.


Sources of Risk

We know that a risk is a potentially adverse event that may cause an outcome that could result in consequences (impacts) to assets that could disrupt objectives. Assets are important if they are mission-critical or enable the achievement of objectives.


A source of risk is anything that may contribute to that risk event occurring.


If you like, a source of risk is a “sub-level” risk to the identified risk that could, if not properly treated, end up becoming its own risk.


Therefore, it is important to identify sources of risk to ensure each control in place treats a specific source or risk. It stands to reason that additional control measures should be identified and implemented to treat any outstanding sources of risk, or to reduce the risk rating (based on the current controls in place) to an acceptable level.


Sources of risk may include (but not be limited to):


  • Lack of training
  • Lack of procedures
  • Lack of communication
  • Lack of budget
  • Delays in management approvals
  • Lack of servicing
  • Lack of supervision
  • Lack of documentation.


Example Scenario

Let’s assume someone leaves the gate to the “airside area” unlocked (the restricted area within an airport). Is this a risk?


Not yet as we have not yet identified the impact that might arise from this security breach—a risk statement requires two key elements:


A risk event (in this case, failure to lock the gate to the airside area)

A risk outcome—what might go wrong if someone inadvertently or unlawfully accesses the airside area due to the gate being unlocked…we don’t yet know that…

We may be tempted to say an obvious control is to ensure the gate is locked by installing CCTV to monitor whether the gate is actually locked or not. Expensive option… Further analysis may identify a range of “sources of risk” that require careful management, including:


  • Lack of training to teach the security guards to lock that gate
  • Lack of budget to provide proper training to the security guards
  • Lack of supervision of staff
  • Lack of clear, written protocols for locking gates to the airside area
  • Failure to purchase workable locks that can withstand temperature extremes
  • A lackadaisical security culture whereby security guards don’t really care as they recce the perimeter fencing at 2.00 am and are more interested in going home to bed
  • Failure to repair broken fencing that renders locks ineffective.

Now we can see that installing CCTV may only go part way to effectively treating this risk. Even if CCTV is installed, what if the security culture is less than optimal and the CCTV monitoring staff fall asleep and don’t care?


Consider the diagram below and you will see the relationship between risks, sources of risk and controls (both current and additional), and how the effectiveness assessment provides evidence for you to adjust the inherent risk rating to that of the residual risk rating.


Examples of risk categories

Here are some examples of strategic risk categories, noting the list is not meant to be exhaustive. Try and limit them to no more than about 6—10 categories:


  • Corporate Governance
  • Security
  • Finance
  • Resources
  • ICT and Cyber
  • Work Health and Safety
  • Programs
  • Operational
  • Reputation.

Here are some examples of risk categories for an ICT project within the same organisation, again noting they are not meant to be exhaustive but do illustrate the difference:


  • Project governance
  • Deliverables
  • Scope
  • Timeframes
  • Resources
  • Information Security
  • Cyber Security
  • Budget
  • Reputation.

It becomes clear that the risk categories for the ICT project need to be tailored for the project. It would be unwise to use the strategic-level categories for the project as they don’t align with the project context.



Comments

Post a Comment