Risk and outcomes
By the end of this module you will be able to:
- Apply the risk formula (likelihood multiplied by impact) to a given cybersecurity scenario
- Distinguish between threat, vulnerability, and exploit as distinct technical concepts
- Explain the difference between risk appetite and risk tolerance with organisational examples
- Describe how a risk register is used to track and prioritise cybersecurity risks
Real-world incident · December 2020
18,000 organisations installed a backdoor they thought was a security update.
In December 2020, it emerged that SolarWinds, a Texas-based IT management company, had been distributing compromised software updates to approximately 18,000 of its customers since at least March 2020. Among those customers were the US Treasury, the US Department of Homeland Security, Microsoft, and FireEye, a leading cybersecurity firm.
The attackers, later attributed by the US government to Russia's SVR (Foreign Intelligence Service), inserted malicious code into SolarWinds' Orion platform during its build process. Every organisation that installed the Orion update received a backdoor without knowing it. The software supply chain, specifically the trust customers placed in a vendor's update mechanism, had become the attack vector.
Most affected organisations had formally assessed the risk of using third-party management tools. What most had not assessed was the risk that a trusted vendor's own build process could be compromised. This module examines how organisations identify, measure, and manage that kind of risk systematically, so that low-likelihood but high-impact threats receive appropriate attention before they become incidents.
SolarWinds customers had assessed the risk of using third-party tools. What risk category had most of them overlooked, and how would a formal risk register have changed that?
Module 1 established what cybersecurity protects (the CIA triad) and where it fits within the broader discipline of information security. This module turns to the question every organisation must answer next: which threats matter most, and how do you decide where to invest limited resources?
With the learning outcomes established, this module begins by examining what risk means in cybersecurity in depth.
2.1 What risk means in cybersecurity
Risk is not a vague sense of worry. It is a calculable quantity, even when precise numbers are unavailable. Understanding its components is the first step toward managing it systematically rather than reacting to incidents after the fact.
The core formula is: Risk = Likelihood x Impact. Likelihood is the probability that a given event occurs. Impact is the severity of the harm if it does. Neither dimension alone determines risk. A highly likely event with negligible impact, such as a user forgetting their password, is low risk. A very unlikely event with catastrophic impact, such as a nation-state attack destroying critical infrastructure, may still warrant significant investment.
The SolarWinds scenario illustrates this well. Before the compromise was discovered, a security team might have assessed "malicious code inserted into third-party software update" as low likelihood but very high impact. Had that risk been formally scored and placed on a register, it might have prompted controls such as software bill of materials (SBOM) verification or network segmentation for Orion systems. Most organisations did not formally assess it. The result was a 9-month undetected breach.
“Risk management is the identification, assessment, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events.”
ISO 31000:2018, Risk Management Guidelines - Section 3.2, Definition of risk management
ISO 31000:2018 establishes risk management as an organisational process, not a one-time audit. It applies across all sectors and is the international standard underpinning the NIST CSF 2.0 Govern function. The UK's NCSC risk management guidance aligns closely with ISO 31000 principles.
With an understanding of what risk means in cybersecurity in place, the discussion can now turn to threat, vulnerability, and exploit, which builds directly on these foundations.
2.2 Threat, vulnerability, and exploit
These three terms appear frequently in news coverage and are often used interchangeably. They describe distinct concepts in the risk formula, and confusing them leads to incomplete defences.
A threat is any potential cause of an unwanted incident. Threats can be natural (flooding a server room), accidental (an employee deleting the wrong file), or intentional (a criminal group seeking to steal financial data). A threat exists whether or not there is anything it can exploit.
A vulnerability is a weakness in a system, process, or control that a threat could exploit. Vulnerabilities can be technical (unpatched software), procedural (no verification process for fund transfers), or physical (an unlocked server room door).
An exploit is the actual mechanism or technique used to take advantage of a vulnerability. When an exploit is successfully applied, a threat is realised and an incident occurs. The term is also used as a noun for a specific piece of code designed to trigger a particular vulnerability.
Common misconception
“'Threat' and 'vulnerability' mean the same thing.”
In the 2013 Target breach, the threat was an organised criminal group, the vulnerability was a combination of poor network segmentation and unactioned security alerts, and the exploit was malware deployed via a stolen third-party vendor credential. Removing any one of these could have broken the chain. Calling everything 'a threat' or 'a hack' obscures where the actual defence gap was and sends remediation effort to the wrong place.
The Target 2013 data breach illustrates why this distinction matters operationally. In November 2013, attackers stole approximately 40 million payment card details from Target, the US retailer. The threat was an organised criminal group. The vulnerability was a combination of network segmentation failures that allowed a third-party HVAC (Heating, Ventilation, and Air Conditioning) vendor's access to reach payment systems, along with security alerts that were generated but not acted upon. The exploit was malware deployed on point-of-sale terminals via stolen vendor credentials. Understanding these as distinct concepts means understanding that better segmentation, stronger vendor controls, or acting on the alerts could each have prevented the breach independently.
With an understanding of threat, vulnerability, and exploit in place, the discussion can now turn to risk appetite and risk tolerance, which builds directly on these foundations.
2.3 Risk appetite and risk tolerance
Once risks are understood, organisations must decide how much of them they are willing to accept. Two related terms describe this decision-making at different levels.
Risk appetite is the amount and type of risk an organisation is willing to accept in pursuit of its objectives. It is a strategic-level statement, typically set by senior leadership or a board. An organisation with a high risk appetite for rapid product development may simultaneously have a very low risk appetite for handling children's personal data.
Risk tolerance is the acceptable variation around a risk appetite statement. Where appetite sets the direction, tolerance sets the operational boundary. A hospital might set an appetite of "we will not accept risks that could compromise patient safety" and a tolerance of "we accept that up to 0.5% of routine IT changes will cause minor service disruption, but not outages exceeding 30 minutes."
“Organizations should identify their risk appetite and risk tolerance before implementing cybersecurity risk management activities.”
NIST Cybersecurity Framework 2.0 - Section 2.2, Govern (GV.RM), Risk Management Strategy
The NIST CSF 2.0 places risk appetite as a prerequisite to all other cybersecurity activities. Without it, organisations cannot make consistent decisions about which risks to mitigate, accept, transfer, or avoid. This is why Govern is listed as the first function, not the last.
Common misconception
“Setting a blanket low risk appetite makes an organisation safer.”
Organisations that set blanket low risk appetites without realistic tolerance thresholds become paralysed. Every change requires sign-off. Staff route around the process. The result is an informal risk acceptance culture that bypasses controls entirely, creating more actual risk than a well-calibrated medium appetite would produce. Risk appetite must reflect what the organisation can actually deliver and resource.
With an understanding of risk appetite and risk tolerance in place, the discussion can now turn to risk registers and treatment options, which builds directly on these foundations.
2.4 Risk registers and treatment options
The risk register is the primary operational tool for tracking identified risks. A register entry typically includes: a unique risk ID, a description of what could happen and why, likelihood and impact ratings on a defined scale, a risk owner, current controls already in place, a planned treatment action, and a review date.
After identifying and scoring a risk, four treatment options apply. Mitigate means reducing likelihood or impact through controls. This is the most common approach when controls are cost-effective. Accept means acknowledging the risk without additional controls, appropriate when the cost of mitigation exceeds the potential impact. Transfer shifts the financial impact to a third party, typically through insurance. Avoid means stopping the activity that creates the risk, used when risk cannot be reduced to an acceptable level.
Risk registers are living documents, not one-time audits. The SolarWinds breach prompted many organisations to add supply-chain software integrity as a new risk entry. A risk register that is not reviewed quarterly stops reflecting reality and becomes a compliance artifact rather than a management tool.
Common misconception
“Cyber insurance transfers supply-chain risk, so it can be removed from the risk register.”
Insurance is a financial transfer mechanism. It pays out after an incident. It does not reduce the probability of an incident occurring, prevent operational disruption during recovery, reduce reputational damage, or guarantee full financial cover. When NotPetya hit Maersk in 2017 at a cost of approximately $300 million, insurers argued 'act of war' exclusions. Transfer reduces financial exposure; the risk itself stays on the register.
A regional law firm stores client contracts in a system that has not received a security patch since 2021. A criminal group is known to target legal firms to steal deal information. Which statement correctly identifies the distinct risk components?
An NHS trust's board sets a risk appetite: 'We will not accept any risk that could result in patient data being disclosed to unauthorised parties.' Achieving this would require £8 million and two years to retire 47 legacy systems. The annual security budget is £400,000. What does this illustrate?
A security analyst is reviewing a legacy payroll system that cannot be patched, is no longer vendor-supported, and will take 18 months to replace. Which combination of treatments is most appropriate in the interim?
Key takeaways
- Risk is the product of likelihood and impact. Both dimensions must be assessed; a highly unlikely but catastrophic event still demands attention.
- Threat, vulnerability, and exploit are distinct. A threat is the actor or cause, a vulnerability is the weakness, an exploit is the technique. Removing any link in the chain prevents the incident.
- Risk appetite is a strategic choice set by leadership. Risk tolerance defines the operational boundary around that choice. Both must be realistic and resourced to be effective.
- Risk treatment options are mitigate, accept, transfer, and avoid. Insurance is a financial transfer mechanism, not a mitigation. The risk stays on the register.
- Risk registers are living documents. Risks must be owned, reviewed, and updated as the threat environment changes.
You can now assess risk, distinguish threats from vulnerabilities, and navigate a risk register. The next question is: what data are you actually protecting, and how do you know if someone has tampered with it? Module 3 examines data classification, the three states data moves through, and the cryptographic tools that verify integrity.
Standards and sources cited in this module
NIST Cybersecurity Framework 2.0 (February 2024)
Section 2.2, Govern function (GV.RM): Risk Management Strategy
Defines risk appetite as a prerequisite to cybersecurity risk management. Referenced in Section 2.3.
ISO 31000:2018, Risk Management Guidelines
Clauses 6-8, Risk management process
International standard for risk management principles. Cited in Section 2.1 for the definition of risk management and the treat/accept/transfer/avoid framework.
NCSC UK, 'Risk management' guidance (2022)
Full guidance document
UK-specific risk management approach aligned to ISO 31000. Referenced in Section 2.3 for proportionate risk appetite guidance.
US Senate Intelligence Committee, SolarWinds Report (2021)
Full report
Primary source for the SolarWinds supply-chain attack detail and attribution. Used as the opening case study.
KrebsOnSecurity, 'Target Hackers Broke in Via HVAC Company' (2014)
Full article
Source for the Target 2013 breach anatomy: vendor credential theft, network segmentation failure, unactioned alerts. Used in Section 2.2.
Module 2 of 25 · Cybersecurity Foundations