Threat, Vulnerability, Risk — Three Words, Three Jobs

Fundamentals · July 30, 2026 · 9 min read

Three words carry most of the weight in security conversation, and they are used so loosely that a sentence containing all three often means nothing.

A vendor sells a “threat report” that is a list of unpatched software. A “risk register” turns out to enumerate adversary types. A number is presented to a board as risk that was produced by multiplying a severity score by an adjective. Each of these is a category error, and each has consequences that are financial rather than semantic.

The distinctions are old and simple. They are worth restating because the sloppiness is expensive.

What each word actually points at

A threat is a party with the capability and the intent to cause harm — or, in a broader reading, an event with the potential to. It exists outside your system. It is not something you have; it is something that exists in the world whether or not you are aware of it. Crucially, it is not yours to remove. Nothing you do to your own estate eliminates a threat. You can only change what the threat costs, what it gains, and how quickly you notice it.

A vulnerability is a weakness in something you own — code, configuration, process, physical arrangement, or a person’s expectations. It is entirely inside your boundary. It is the one of the three that you can genuinely eliminate, and that eliminability is precisely why so much of the industry’s tooling and attention concentrates here.

A risk is neither of those. It is a statement about a possible future involving something you care about: given this threat, and this weakness, this harm may occur, with roughly this likelihood, at roughly this consequence. Risk is the only one of the three that can be compared against a cost, which is why it is the only one that supports a decision about money.

The relationship is not multiplicative in any honest sense, but the dependency runs one way. No threat, no risk. No vulnerability, no risk. No consequence, no risk — a perfectly exploitable weakness in a system whose loss would cost nothing carries none.

The controllability asymmetry

The most useful practical consequence of the distinction is about ownership.

Vulnerabilities are yours. You can patch, reconfigure, redesign, retire, segment. The action is available and the result is verifiable.

Threats are not. You cannot patch an adversary. What you can do is alter the terms: raise the cost of operating against you, reduce the value of what they would obtain, and shorten the time between their arrival and your awareness of it. Every one of those is real work with real effect, and none of it is elimination.

This asymmetry explains a recurring pattern in security programmes. Because vulnerability work has a completion state and threat work does not, effort migrates toward the former. A programme can show a declining count of open findings and feel like it is progressing while its exposure to a determined adversary is unchanged, because the adversary was never going to use a vulnerability from that list.

Where the words go wrong

A “threat report” that is a scan. If the document lists weaknesses in your own systems, it is a vulnerability assessment. Calling it a threat report implies knowledge about adversaries that it does not contain, and encourages the reader to believe that the listed items are the ones somebody is coming for.

A “risk register” that is a threat list. “Ransomware” is not a risk. It is a threat category. The risk is something like: an operator obtains administrative access through an exposed remote-access service, encrypts the systems supporting order fulfilment, and the business cannot ship for a number of days that management would find unacceptable. That formulation names the asset, the route and the consequence — three things “ransomware” does not — and it can be argued about, priced and mitigated.

A risk score with no consequence in it. Severity scoring systems for vulnerabilities are intentionally environment-independent; that is what makes them comparable between organisations. Treating such a score as a risk score substitutes intrinsic technical characteristics for the thing that actually determines impact, which is what the affected system does and what depends on it.

Hazard treated as threat. A flood, a component failure and a data-centre power fault are hazards: they have no intent. Adversaries do. The distinction matters because intentional risk is not actuarial. A hazard’s probability distribution does not care what controls you install. An adversary’s does — they observe the control and adapt around it, which means historical frequency is a much weaker guide to future likelihood than it is for accidents.

Consequence is the underworked term

Of the components that make up a risk, likelihood attracts the most argument and consequence carries the most information.

Likelihood estimates for adversarial events are, honestly, poor. They are guesses dressed in ranges, and they move whenever anything changes. Consequence is comparatively tractable: what does this system do, who depends on it, what happens on day one and day five without it, what obligations trigger, what is the recovery path and how long has it actually taken when tested.

Programmes that invest their analysis on the consequence side end up with better decisions even when their likelihood estimates are bad, because consequence determines what you would do about it in any case. A system whose loss stops the business gets resilience investment regardless of how likely you think the loss is. A system whose loss is an inconvenience does not, however alarming the threat landscape appears.

Three questions that disambiguate

When a claim arrives and it is unclear which of the three is being asserted, three questions resolve it quickly.

Is this outside our boundary or inside it? Outside is a threat. Inside is a vulnerability.

Can we make it go away entirely? If yes, it is a vulnerability. If the honest answer is only “we can make it more expensive for them”, it is a threat.

Does it name something we would lose? If not, it is not yet a risk, whatever the register calls it.

None of this is difficult. It is only neglected, and the neglect surfaces in the one conversation where precision matters most — the one where somebody outside security asks what the money buys. A programme that can distinguish the weakness it removed, the adversary it made pay more, and the loss it made less likely is having a different conversation from one that reports all three as a single declining number.