Threat, vulnerability, likelihood, impact: the parts of a risk

No single number is the risk. Risk is a measure of the extent to which an entity is threatened by a potential event, and it is typically a function of two things: the adverse impact if the event occurs, and the likelihood that it occurs (NIST SP 800-30 Rev. 1). The parts that feed those estimates — threat source, threat event, vulnerability, predisposing condition, likelihood, impact — are estimated separately before anyone combines them. An unlikely, devastating event and a common, minor one are different governance problems; one score hides that. NIST SP 800-53 Rev. 5 makes the assessment a control in its own right (RA-3).

The model: a threat needs something to exploit and something to harm

threat source —initiates→ threat event —exploits→ vulnerability —causes→ adverse impact
                              ↓                          ↓
                likelihood of occurrence          magnitude of impact
   (intent, capability, targeting; exposure)   (FIPS 199: LOW / MODERATE / HIGH)
                        └──────────  risk = f(likelihood, impact)  ──────────┘

This is the generic risk model of SP 800-30 Rev. 1: a threat source initiates a threat event; the event exploits a vulnerability with some likelihood of success; the vulnerability sits among predisposing conditions; and the exploit causes an adverse impact. Risk is the combination of likelihood and impact, not a property of one box.

The parts, one by one

1. Threat source — the thing that can cause an event. SP 800-30 Rev. 1 characterises it as an intent targeted at exploiting a vulnerability, or as a situation that may exploit one accidentally. Its types range from hostile cyber or physical attacks to human error, structural failures and disasters. It is not necessarily an attacker.
2. Threat event — an event or situation with the potential to adversely affect the organisation through an information system, caused by a threat source. Several sources can initiate the same event: a denial-of-service attack, a malicious administrator, a hardware fault or a power failure can all take the same server offline.
3. Vulnerability and predisposing condition — a vulnerability is a weakness in a system, a procedure, an internal control or an implementation that a threat source could exploit. A predisposing condition is broader: a condition that affects whether an initiated event results in harm. A site in a flood-prone region raises it; a system with no network connection lowers it.
4. Likelihood of occurrence — rarely one probability. SP 800-30 Rev. 1 combines the likelihood that the event is initiated with the likelihood that it causes harm; for adversarial sources it weighs intent, capability and targeting, for others historical evidence. It is assessed against a stated time frame.
5. Impact — the magnitude of harm expected from unauthorised disclosure, modification or destruction of information, or from loss of availability. FIPS 199 supplies the vocabulary: LOW is a limited adverse effect, MODERATE serious, HIGH severe or catastrophic.

The same parts, in order

SP 800-30 Rev. 1 runs the assessment in that direction — threat sources and events → vulnerabilities → likelihood → impact → risk. Likelihood is estimated against the vulnerabilities and controls that actually exist, so the first steps are inputs, not background.

Likelihood and impact are two estimates, and that is the governance distinction

The same risk level can be reached from opposite directions, and the two cases ask different questions:

	Unlikely, high impact	Likely, low impact
Which factor drives the level	impact	likelihood
What the estimate depends on most	how much harm the loss would cause	how often the event occurs
The governance question it raises	can the organisation survive it, and who owns the consequence?	how much of it is absorbed as normal operating cost?

How the estimates are expressed is a separate, contextual choice. SP 800-30 Rev. 1 describes three approaches: qualitative (categories such as very low to very high), semi-quantitative (bins or scales whose numbers mean nothing outside the assessment), and quantitative (numbers whose proportionality holds outside it too). The preferred one depends on organisational culture and on how it treats uncertainty.

The common misconception: “a vulnerability is the risk”

A vulnerability is a weakness, and on its own it has neither impact nor likelihood. SP 800-30 Rev. 1 is explicit that a vulnerability’s severity is context-dependent: it depends on the potential adverse impact if the vulnerability is exploited by a threat source. The same finding can be critical on one system and negligible on another.

Two corrections follow. A threat is not the same thing as an attacker: errors, component failures and natural events are threat sources too. And a vulnerability score is an input, not the answer: scanning tools can express vulnerability impact with a score such as CVSS, the Common Vulnerability Scoring System (SP 800-53 Rev. 5, RA-5 discussion), but that score describes the weakness without your controls or the harm a loss would cause.

What to remember

• Risk is a function of an event’s adverse impact and its likelihood of occurrence.
• The parts are threat source, threat event, vulnerability or predisposing condition, likelihood and impact.
• A vulnerability is a weakness; it has no impact or likelihood until a threat source can reach it.
• A threat source is not necessarily an attacker — errors, failures and disasters count too.
• Likelihood and impact are estimated separately and then combined; they are not one number.
• A vulnerability score is an input, not the risk.

Level and prerequisites

L1 — fundamentals: the vocabulary and the mental model of a risk, no procedure and no register. Prerequisites: the confidentiality, integrity and availability sheet (what an adverse impact is measured against) and the assets and dependencies sheet (what can be harmed). Registers and scores are L2; vulnerability management as a process is L3.

Where to go next

• Cybersecurity Governance — the area this sheet belongs to.
• The technical side — scanners, CVE and CVSS feeds, patch cycles — belongs to vulnerability management in the technical areas.

References

• National Institute of Standards and Technology, Guide for Conducting Risk Assessments (NIST SP 800-30 Rev. 1) — the definition of risk, the risk-factor model and the assessment process.
• NIST, Standards for Security Categorization of Federal Information and Information Systems (FIPS 199) — the LOW, MODERATE and HIGH potential impact vocabulary.
• NIST, Security and Privacy Controls for Information Systems and Organizations (NIST SP 800-53 Rev. 5) — control RA-3, risk assessment.
• NIST, Managing Information Security Risk (NIST SP 800-39) — the risk management components and the tiers at which risk is assessed.