Risk versus vulnerability

What is risk, and what is vulnerability? While connected, they are not the same, and perhaps, often confused? It is important to see the difference, and that is the starting point of Terje Aven’s 2007 article on A unified framework for risk and vulnerability analysis covering both safety and security. Risk is a more general concept, while vulnerability relates to a certain source. In this paper safety and security, normally based on different analysis approaches and using alternative building blocks, are brought together in a unifying risk and vulnerability framework that covers both accidental and malicious events.

Back to the future

Actually, today’s review is the precursor of Aven’s 2009 article on safety and security critical systems that I reviewed earlier this year.  In fact, there is an even earlier precursor to today’s article, which I will come back to later, which means that Terje Aven will be among the more frequently reviewed authors here. He has indeed authored many fine articles on risk and how risk should be viewed and assessed – particularly in the journal of Reliability Engineering & System Safety.

Circular logic?

The article clearly set out a new framework for risk and vulnerability analysis. At times, though, it is difficult to read, and I’m not sure I fully understand the semantics. For example, my favorite quote from this article is this



Having defined risk, we can define risk analysis as an analysis of risk.

Right.

Even the definition of vulnerability is kind of circular:

A vulnerability is a feature or aspect of the system that is judged to give high vulnerability.

Anyway, semantics aside, in Aven’s article, vulnerability is linked to a system, e.g. power production systems, information and communication systems, and transport systems. Systems are exposed to situations or events, that may or may not lead to various consequences or outcomes (so-called observable quantities).  A source is a situation or an event with a potential of a certain consequence. Sources are defined as threats (malicious attacks, related to security), hazards (accidental events, related to safety), and opportunities (“harmless” events that present an opportunity for a threat or a hazard to materialize, e.g. a planned maintenance shutdown that does not go according to plan).

Risk is seen as the combination of possible consequences and associated uncertainties of what will be the consequences. Vulnerability is seen as as the combination of possible consequences and associated uncertainties, given a certain source. Risk is generic, vulnerability is specific.

Risk has vulnerability in it?

While Aven does separate risk and vulnerability, he also sees them as inextricably linked.

As vulnerability is a part of risk, a vulnerability analysis is a part of the risk analysis. […] A risk and vulnerability analysis comprises source identification, identification of vulnerabilities, uncertainty assessments, and risk description.

Risk and vulnerability analysis

According to Aven, a risk and vulnerability analysis will normally consist of the following main steps:

  1. Identify the relevant functions and subfunctions to be analysed, and relevant performance measures (observable quantities).
  2. Define the systems to meet these functions.
  3. Identify relevant sources (threats, hazards, opportunities).
  4. Perform an uncertainty analysis of the sources.
  5. Perform a consequence analysis, addressing uncertainties.
  6. Describe risks and vulnerabilities.
  7. Evaluate risks and vulnerabilities.
  8. Identify possible measures, and return to 3.

Mind you, Aven notes

These steps follow in time, but should not be read as a strict time table. For example, having identified a source, a quick consequence analysis is often performed to see if this source represents a significant risk or should be excluded from further analysis. Hence step 5 comes before step 4, as a first run. There are also other iterations. For example, steps 4 and 5 may generate new sources, and the source list need to be updated. Information gathering is a part of the first five steps. The level of depth of the various analysis steps, would of course depend on the purpose and scope of the analysis.

The above list indicates that the analysis is primarily a qualitative analysis up to step 6, which is where the quantitative assessment begins. In describing the consequences, Aven suggests the following scheme:

(a) Potential consequences (outcomes)—represented by representative performance measures (future observable quantities) such as costs, income, production volumes, deliveries, loss of lives, etc.
(b) Ubiquity—which describes the geographical dispersion of potential damages. (c) Persistency—which describes the temporal extension of the potential damages.
(d) Delay effect—which describes the time of latency between the initial event and the actual impact of damage. The time of latency could be of physical, chemical or biological nature.
(e) Reversibility—which describes the possibility to restore the situation to the state before damage occurred.
(f) Violation of equity—which describes the discrepancy between those who enjoy the benefits and those who bear the risk.
(g) Potential of mobilization—which is to be understood as violation of individual, social and cultural interests and values generating social conflicts and psychological reactions by individuals and groups who feel inflicted by the risk consequences. The potential of mobilisation could also result from perceived inequities in the distribution of risk and benefits.
(h) The difficulty in establishing appropriate (representative) performance measures (observable quantities on a high system level).

The key question that now follows, is whether there are any uncertainties related to the above scenarios? How likely is a given scenario actually? How uncertain is the likelihood, i.e. are there many factors influencing the consequences, and what are these factors? Uncertainty thus becomes a determining factor in determining the actual risk. So basically, one must assess the expected value of consequences matched with their probability, as well as the uncertainty of the background information associated with consequences and likelihoods.

When is risk really risk(y)?

In the end Aven suggests a simple yet effective approach for summarizing the risk picture, where consequences (and their probabilities) are viewed dependent on the level of uncertainty that accompanies the assessment.

The risk levels in the table, so Aven says, must be read as a tendency, not as increasing values, and should be used as a starting point for further discussions, taking both the consequences and the uncertainties into full account. The table is not the answer, it is a tool for further handling of risk.

Conclusion

What this framework shows is that risk is ambiguous, ambiguous because uncertainties are part of the picture. Risk has two dimensions: a) Possible consequences and b) associated uncertainties. It also underlines that risk analysis needs to take on a broad perspective that acknowledges that there are uncertainties, that there might be different assessments of these uncertainties, and that there might be different ways of dealing with these uncertainties. In essence, this framework brings together both quantitative and qualitative values, and gives them weight, so that they can be used for decision support.

Reference

AVEN, T. (2007). A unified framework for risk and vulnerability analysis covering both safety and security Reliability Engineering & System Safety, 92 (6), 745-754 DOI: 10.1016/j.ress.2006.03.008

Author link

Related

Posted in ARTICLES and PAPERS
Tags: , , , , , ,

ARTICLES and PAPERS
Finding the right location - minimizing disruption costs
Classical facility location models assume that once optimally located and set up, facilities will op[...]
Single, sole, dual, multiple sourcing?
Old classics never die. While some papers are written, published and quickly forgotten (because no o[...]
BOOKS and BOOK CHAPTERS
Risk Management in Maritime Transportation Networks
This week’s focus are risks in the maritime supply chain, and today's article introduces a new metho[...]
Book Review: Enterprise SCM
Have you ever played SimCity? I never liked Transport Tycoon that much, but I used to play SimCity a[...]
REPORTS and WHITEPAPERS
ISO 28002 – Supply Chain Resilience
Have you heard of ISO 28002?  No? You should take note of this standard, because the ISO 28000 serie[...]
America’s Crumbling Infrastructure
My daily morning routine includes a cup of coffee while watching the World Business Report on BBC Wo[...]