How do you distinguish a vulnerability from a threat from a risk?

These three words get used interchangeably in casual conversation, but in security they are distinct — and the distinction is the whole basis of how teams prioritize their work.

The definitions

• Vulnerability — a weakness or flaw that could be exploited. An unpatched server, a weak password policy, a misconfigured S3 bucket, an SQL injection bug.
• Threat — something or someone that could exploit a vulnerability to cause harm. A ransomware crew, a malicious insider, a natural disaster, or an automated scanner.
• Risk — the intersection: the likelihood that a threat successfully exploits a vulnerability, combined with the impact if it does. Risk is what you measure and manage.

A common shorthand is Risk = Threat × Vulnerability × Impact. No threat, or no vulnerability, or no impact means little or no risk.

Why the distinction matters

You can rarely fix everything, so you prioritize by risk, not by raw vulnerability count. A critical vulnerability on an internet-facing server holding customer data is high risk. The same vulnerability on an isolated lab machine with no sensitive data is low risk — even though the vulnerability is identical.

It also clarifies your options. You can reduce risk by removing the vulnerability (patch), reducing the threat's access (network segmentation, firewall rules), or reducing impact (backups, encryption). You don't always have to fix the flaw directly.

Why this matters

Interviewers ask this to see if you think like a risk manager rather than a checkbox-filler. A candidate who explains that a scary-sounding CVE can still be low risk in context — and who knows the levers for reducing risk — demonstrates the judgment security teams depend on.