Threat, vulnerability and risk are used interchangeably in meetings, and the confusion causes real problems. A team that calls every scanner finding a "risk" ends up with a backlog of thousands of items and no way to rank them. The three words mean different things, and once you separate them, prioritisation becomes much easier.
Threat: what could happen
A threat is a potential event that could harm an asset. It's usually caused by a threat actor (a criminal group, an insider, a competitor), but it can also be accidental or natural: an engineer deleting the wrong database, or a flood in a data centre.
Threats exist whether or not your system is weak. "Criminals want to take over customer accounts" is true of every web application. You can't fix a threat; you can only make it less likely to succeed or less damaging when it does.
Vulnerability: the weakness that lets it happen
A vulnerability is a weakness in a system, process or design that a threat could exploit. It can be a code bug (an SQL injection), a design flaw (an API that trusts the client to say which account it is), a misconfiguration (a public storage bucket) or a process gap (nobody removes access when people leave).
Vulnerabilities are what scanners, code review and penetration tests find. Publicly known vulnerabilities in software products get a CVE identifier; the type of weakness behind them is classified by CWE.
Risk: how likely, and how bad
Risk combines the two. It answers: given the threats we face and the weaknesses we have, how likely is harm, and how much would it hurt? The usual formula is:
Risk = Likelihood × Impact
Likelihood depends on both the threat (how motivated and capable attackers are) and the vulnerability (how easy it is to exploit). Impact depends on the asset (what's lost if it happens). That's why some frameworks write the formula as threat × vulnerability × impact. Scoring each on a 1–5 scale and using a risk matrix is the most common way to make the numbers consistent.
How the three fit together
| Threat | Vulnerability | Risk | |
|---|---|---|---|
| Question | What could go wrong? | What weakness allows it? | How likely and how bad? |
| Example | Account takeover | No rate limit on login | Likelihood 4 × impact 4 = 16 |
| Can you remove it? | No | Yes, fix it | Reduce it, transfer it, or accept it |
| Found by | Threat modeling, threat intelligence | Scanners, code review, pen tests | Risk assessment |
The key consequence: a vulnerability is not automatically a risk. A critical-severity flaw in a server that's unreachable and holds nothing of value carries little risk. A medium-severity flaw on your login page, which every attacker on the internet can reach, may carry a lot. That's the difference between a CVSS score (severity of the vulnerability) and a risk score (severity in your context).
Worked example: Invoicely
Take threat T1 from the Invoicely model:
- Threat: an attacker takes over customer accounts using passwords leaked from other sites (credential stuffing).
- Vulnerability: no rate limit or breached-password check on the login endpoint.
- Risk: likelihood 4 (credential stuffing is constant and automated) × impact 4 (full access to one customer's invoices) = 16, critical.
Adding a rate limit and breached-password check doesn't remove the threat; criminals will keep trying. It removes most of the vulnerability, which lowers the likelihood and therefore the risk. What's left afterwards is the residual risk.
Where threat modeling fits
Threat modeling works from the threat side: it asks what could go wrong with a design, often before any code exists, so there are no vulnerabilities to scan yet. Vulnerability management works from the other side, finding concrete weaknesses in running systems. A good risk register brings both together: each entry names the threat, the weakness that makes it possible, a score, and a decision.
Common mistakes
- Calling scanner findings "risks". They are vulnerabilities until someone assesses likelihood and impact in context.
- Writing threats without an actor or impact. "SQL injection" is a vulnerability class. "An attacker can read every customer's invoices through SQL injection in the search endpoint" is a threat you can score.
- Scoring risk with severity alone. Severity ignores whether anyone can reach the weakness and what's behind it.
Key takeaways
- Threat: what could go wrong. Vulnerability: the weakness that lets it go wrong. Risk: how likely it is and how much it would hurt.
- A vulnerability with no realistic threat is low risk; a serious threat with no vulnerability to exploit is also low risk. Risk needs both.
- Risk is usually scored as likelihood × impact so different threats can be compared and ranked.
- Threat models produce threats; scanners and pen tests find vulnerabilities; the risk register is where the two meet and get a decision.
Frequently asked questions
What is the difference between a threat and a vulnerability?
A threat is a potential harmful event, often caused by an attacker, such as account takeover. A vulnerability is a weakness in your system, such as no rate limit on the login endpoint, that would let the threat succeed. You can't remove threats, but you can fix vulnerabilities.
What is the formula for risk in cybersecurity?
The most common form is risk = likelihood × impact. Some frameworks write it as threat × vulnerability × impact, which says the same thing: likelihood depends on both how motivated attackers are and how weak the system is.
Is malware a threat or a vulnerability?
Malware is a threat, or more precisely a tool a threat actor uses. The vulnerability is whatever lets it run, such as an unpatched browser or a user who can install software without approval.
What is an exploit?
An exploit is the specific technique or code that takes advantage of a vulnerability. A threat actor uses an exploit against a vulnerability to realise a threat.