Skip to content

Risk Analysis

Risk analysis is the possibility that something bad happens. In IT contexts, we have cyber risk, which is the potential that a threat might exploit a vilnerability, which causes a security breach and causes harm.

IT systems are subject to threats which may have an adverse effect on the organisation's operations or assets, can effect individuals, other organisations, or national security.

This is through exploiting both known and unknown vulnerabilities which compromise CIA properties of some information during the processing, storage, or transmission of that information.

Risk Management

Risk management is the identification, evaluation and prioritisation of different risks, then coordinating and economically apply resources to minimise, monitor, and control the probability or impact of these events.

We perform several risk analysis exercises in an effort to identify, track, and mitigate risks in the software development lifecycle. Through these exercises, we can find threats, their likelihood, and impact of them, and make informed decisions about how to mitigate them.

Risk analysis is the overarching concept that encompasses several risk analysis methods, which are found through an identification or evaluation of those risks.

We have assets, which a threat wants to exploit through a vulnerability. This constitutes a security risk. We need to introduce some security mechanism to protect this asset, to reduce the overall risk level.


  • Vulneratbility--weakness that could be exploited by a threat
  • Threat--entity exploiting a vulnerability
  • Threat Event--event or circumstance with potential adversely organisational assets
  • Likelihood--probability that a threat event occurs
  • Adverse Impact or Consequence--magnitude of harm caused by a threat event
  • Risk--function of likelihood and impact or consequence
  • Treatment or Countermeasure--a measure to reduce the risk level

Risk Analysis in Software Development

This relates to the requirements and use cases of software, in addition to the architecture and design of the software. We develop requirements and model the system as part of the system design, then perform threat analysis and mitigations based on these models.

Threat Modelling

This is an activity in the SDLC which occurs early on, and reviews the features and architecture of the product in a systematic way from a security point of view. We then identify threats and derive mitigations for these threats.

These mitigations are context-specific. Modelling can be done on different levels of abstraction, so it is appropriate for a multitude of different systems.

Overall Process

The overall process is as follows:

  • context identification
  • risk identification
  • risk estimation
  • risk evaluation
  • risk treatment

Context Identification

This allows us to characterise the target of analysis, giving the focus and scope of the analysis. We then identify and give value to the assets. We can define the likelihood scale and description, a consequence scale for each asset, then specify the criteria for the risk evaluation, e.g., what is the client happy to tolerate.

Likelihood Scale

Likelihood can be categorised by the following table:

Likelihood Description
Certain 5 times or more per year
Likely 2-5 times per year
Possible once a year
Unlikely less than once per year
Rare less than once per 10 years

Consequence Scale

Consequence Description
Catastrophic Very significant impact. Legal or regulatory implications. Significant reputational impact.
Serious Major effect, may lead to significant delays
Moderate Moderate efect, may lead to some delays
Minor Some impact of the risk, fairly minor
Insignificant Fairly insignificant, may lead to a tolerable delay

Risk Evaluation Matrix

We can create a risk function between the impact and the likelihood of the risks, assigning a score to each element.

Risk Identification

This is the process of identifying threats to assets through brainstorming. To do this, we bring in system owners, users, developers, domain experts, and risk analysis experts.

We then identify the vulnerabilities of the assets by going through questionnaires and checklists (e.g., check equipment is physically protected against unauthorized access to data or data loss)

Risk Estimation

This is the process of determining the level of each of the identified risks. We assign each threat event a likelihood value and an impact value, as defined above.

The assessment of a likelihood value is normally based on the adversary intents, capabilities, and targeting, and is based on historical evidence, empirical data, or other factors.

Assessments of the impact is based on the harm that we expect from the threat event, and the range of effects of the threat, including the relative size of the set of resources affected.

Risk Evaluation

Risk can be assessed quantitatively, qualitatively, or semi-quantitatively. We then map the risks into a risk evaluation matrix.

When evaluating risks, we need to understand that we cannot completely eliminate all risks, and that we will only be able to treat a subset of the risks. We prioritise the more serious risks.

Quantitative vs Qualitative vs Semi-Quantitative

Quantitative assessments use numbers, e.g., cost-benefit analysis of alternative risk responses or courses of actions. The meanings of these analyses may not be clear and will need interpretation.

Qualitative assessments are used to communicate risk results to decision makers, but due to the inherent subjectiveness, we may yield substantially different results from different analysts.

Semi-quantitive makes use of both qualitative and quantitive methods to categorise risk into bins or scales, which we can then assign a qualitative owrk to.


When evaluating risk, there is some inherent uncertainty built in. This could be due to limitations in how the future resembles the past, imperfect knowledge or the threat, undiscovered vulnerabilities in technologies or products, or unrecognised dependencies, leading to unforseen impacts.

The degree of undertainty should be communicated in the results in qualitative ways by providing ranges of values or fuzzy regions instead of concrete points.


Risks with the greatest loss and the greatest probability of occuring are handled first. Lower probabilities and lower loss risks are then handled in descending order.

The process of assessing overall risk can be difficult, and we need to balance resources used to mitigate risks with high probability vs low loss vs risks with high loss but a lower probability.

Risk Treatment

Risks can be split into four options: accept, treat, avoid or terminate, or transfer.

We need to identify a combination of these or a specific option to apply, then evaluate and prioritise treatments for different risks.


The following standards are used for security analysis:

  • International: ISO 27001, ISO 27005, ISO 31000
  • National: IT-Grundschutz (Germany), Magerit (Spain)
  • Standards-based: OCTAVE, CORAS