Cybersecurity 101: the words that mean what.
Threat, vulnerability, exploit, risk – four words that get used interchangeably, and the one mental model that finally separates them.
Walk into any security meeting and you will hear four words used as if they meant the same thing: threat, vulnerability, exploit, and risk. They do not. Getting them straight is the first thing that separates someone who can read a CVE from someone who can decide what to do about it.
The four words, with examples
The cleanest definitions, with the example we will use for the rest of this article: an employee laptop sitting in an airport lounge.
| Word | Definition | Laptop example |
|---|---|---|
| Threat | Someone or something that wants to cause harm | A thief who steals laptops in lounges |
| Vulnerability | A weakness that could be used to cause harm | Disk is not encrypted |
| Exploit | The specific way a vulnerability is used | Boot from USB and copy /home |
| Risk | The chance and impact of harm actually happening | Likely + sensitive data + bad press = high |
Notice that a vulnerability is harmless on its own. An unencrypted disk in a vault that nobody can reach is a vulnerability without a threat. The risk is near zero. The same disk in an airport is a different story.
Term pairs that get mixed up in the wild
Even once the four core words are straight, some closely related pairs still get flattened into each other in everyday conversation. The confusion is usually harmless over coffee and expensive in a postmortem, because it hides which control actually failed.
| Pair | What people say | What is actually different |
|---|---|---|
| Vulnerability vs. exploit | "We found the exploit in the login form." | Weak input validation on the login form is the vulnerability. The specific malicious string that abuses it is the exploit. A vulnerability can sit unexploited for years; an exploit is one concrete way of using it. |
| Threat vs. risk | "Ransomware is our biggest risk." | Ransomware operators are a threat: an actor with intent and capability. Risk is what happens when that threat meets your specific vulnerabilities and impact potential. Two companies facing the same threat can have very different risk if one patches and backs up and the other doesn't. |
| Asset vs. attack surface | "We need to protect our assets." | An asset is anything of value – data, a server, a brand. The attack surface is every point where a threat could try to reach an asset: open ports, forms, APIs, employees. You protect assets by shrinking and hardening the attack surface around them. |
| Likelihood vs. impact | "That's a high risk." | Both are separate axes multiplied together, not one feeling. A vulnerability with high impact but near-zero likelihood – a flaw that needs physical console access inside a locked data center – is not automatically a high risk, and one with high likelihood but low impact – a typo on an internal wiki page – isn't either. |
The CIA triad – what we are actually protecting
Every control you will ever read about exists to protect one of three properties. Memorise this; the rest of your career hangs off it.
- Confidentiality: only the right people can read it. Lost laptop: confidentiality is the first thing to go.
- Integrity: only the right people can change it, and you can detect when someone tries. Lost laptop: if it is returned, can you trust the binaries on it?
- Availability: the right people can use it when they need to. Lost laptop: the employee cannot do their job until you replace it.
A control is good when it raises the cost of attacking one of the three CIA properties more than it raises the cost of using the system normally. That is the whole game.
The risk equation – informal but useful
You will see a hundred variants of the risk equation. The one that survives contact with reality is the simplest:
Risk ≈ likelihood × impact
Likelihood is the chance the threat actually meets the vulnerability. Impact is what happens if it does. Both are usually guessed in three to five buckets ("low / medium / high / critical"), not in numbers. That is fine. The point of the equation is not to compute a number: it is to make you write down two separate guesses instead of one fuzzy feeling.
Worked examples: three scenarios, one model
The model is only useful once you've run it a few times on situations that don't look alike. Below are three, spanning a lost device, a web application, and a piece of network infrastructure – deliberately different enough that you can see the same four questions produce different answers.
Scenario 1: a laptop at a café
An employee leaves their laptop at a café table for 90 seconds while paying. We score:
- Threats in this setting: opportunistic thief (high), targeted attacker (low for a marketing intern, high for an exec).
- Vulnerabilities: no full-disk encryption, screen unlocked, password manager unlocked, work email cached.
- Exploits: walk off with it; or 60 seconds at the keyboard to grab a session token.
- Impact: depending on role, anywhere from "annoying" to "company-ending".
The interesting move is the one most teams skip: write down which control reduces which leg of the risk. Full-disk encryption raises the cost of the walk-off exploit. A 60-second screen lock raises the cost of the at-keyboard exploit. They are not interchangeable.
Scenario 2: a SQL injection flaw in a customer portal
A mid-size retailer's product search box concatenates user input straight into a SQL query instead of using parameterized queries.
- Threats: mostly automated – bots and financially motivated crime groups running SQL-injection scanners against every retailer they can find, plus a low-probability targeted actor if the retailer is newsworthy.
- Vulnerabilities: unsanitized, unparameterized input in the search query; an application database account with far more privileges than a search feature needs.
- Exploits: a hand-crafted string like
' OR '1'='1' --, or a tool such as sqlmap automating the same idea across every parameter on the site. - Impact: if the query only ever touches the public product catalog, this is embarrassing. If the same flaw sits near a table with customer records or payment tokens, it's a breach-notification event.
Here the highest-leverage control is parameterized queries: it removes the exploit path entirely rather than raising its cost. A least-privilege database account is the fallback: it can't stop the exploit, but it limits how much a successful one can reach.
Scenario 3: an unpatched VPN appliance
A hospital runs a remote-access VPN appliance with a publicly known CVE, unpatched ninety days after the vendor's advisory.
- Threats: ransomware affiliate groups that scan the internet for known-vulnerable appliances at scale, often buying initial access from brokers rather than finding it themselves.
- Vulnerabilities: the unpatched CVE itself, plus flat internal network segmentation that lets anything reachable from the VPN also reach clinical systems.
- Exploits: a public proof-of-concept or a ready-made framework module, run against every IP address known to expose that appliance.
- Impact: for a hospital specifically, ransomware doesn't just cost money: it can delay patient care, which is exactly why healthcare risk registers weight availability so heavily alongside confidentiality.
Patch management tied to a clear SLA closes the vulnerability outright. Network segmentation and offline backups don't stop the exploit, but they cap the impact if patching lags – which, in practice, it sometimes will.
Threat actor archetypes: who you're actually modeling against
"Threat" is deliberately generic, but a real model has to get specific about who. Security teams generally sort real-world adversaries into four archetypes, and which one you're facing changes what "likelihood" and "impact" mean in practice.
| Actor type | Primary motivation | Typical targets | Usual playbook |
|---|---|---|---|
| Nation-state | Espionage, strategic advantage, sometimes disruption | Government, critical infrastructure, defense contractors, IP-heavy companies | Patient, well-resourced, custom tooling, willing to sit undetected for months |
| Organized crime | Money – ransomware, fraud, data theft for resale | Anyone with money or data to monetize, opportunistic at scale | Ransomware-as-a-service, phishing kits, initial-access brokers; fast and loud once they've monetized |
| Hacktivist | Ideology, publicity, protest | Organizations tied to a cause they oppose | Website defacement, DDoS, leaking internal documents for embarrassment rather than profit |
| Insider | Grievance, financial gain, coercion, or plain negligence | Their own employer | Abuse of legitimate access – no exploit needed if you already hold the keys |
Notice the insider row doesn't need an exploit in the traditional sense – legitimate access is itself the vulnerability. That's part of why insider risk is consistently rated among the hardest categories to defend, and why it leans on monitoring and least-privilege rather than technical hardening alone.
How this vocabulary turns into a job title
Once threat, vulnerability, exploit, and risk stop being abstractions, you can see them mapped almost directly onto entire job functions. This is usually the point where "I understand the vocabulary" turns into "I know which of these I want to do for a living":
- Vulnerability management / vulnerability analyst: spends the day finding and prioritizing vulnerabilities before anyone can exploit them: scanning, patch coordination, CVSS and KEV triage.
- Threat intelligence analyst: tracks specific threat actors, their tooling, targeting patterns, and infrastructure, so defenders know which threats are realistically likely against their organization.
- Penetration tester / red teamer: is paid to find exploits for known and unknown vulnerabilities, under authorization, before a real threat actor does.
- Risk analyst / GRC (governance, risk, and compliance): owns the likelihood-times-impact calculation across the whole organization and decides which risks get accepted, transferred, or funded down.
- Incident responder: shows up after a threat has already exploited a vulnerability, working backward from impact to reconstruct what happened.
If any of those sound like a direction worth exploring, the cybersecurity roadmap and careers guide walks through the learning order that actually works and where each path leads.
What to take to your next meeting
- Stop saying "this is a security risk". Say "the risk is X, because the threat of Y could exploit the vulnerability of Z".
- For any new control someone proposes, ask: which CIA property does this protect, and from which threat?
- If neither question has an answer, the control is decoration.
That is the whole foundation. The rest of this Learn series is just specific cases of these four words, applied to networks, to operating systems, to code, and eventually to the prompts you will hand an LLM to do this work at scale.
Frequently asked questions
What is the difference between a threat, a vulnerability, an exploit, and a risk?
What is the CIA triad in cybersecurity?
How do you calculate risk in cybersecurity?
Why is an unencrypted disk not automatically a high risk?
Daniel A. and Óscar S. run Breachfolio, a small independent site about security and AI. This article was drafted with AI assistance and reviewed by a person before it went live. We write from documentation, vendor sources and published research rather than from original lab benchmarks, and we link a source in the sentence that relies on it. How we work · About us