Threat vs Vulnerability vs Risk: Definitions and Examples

Threat vs vulnerability comes down to control. A vulnerability is a weakness in your systems, processes or people that you can find and fix. A threat is the person, group or event that could take advantage of it, and you can rarely switch it off. Risk is what results when the two meet something you value: the likelihood that a threat exploits a vulnerability, combined with how much harm that would do.

That is why most risk reduction comes from removing vulnerabilities and limiting impact: those are the parts you control. A validated vulnerability assessment finds and ranks the weaknesses (from $1,500 for up to 250 devices; see vulnerability scanning and assessment pricing), a penetration test proves which ones an attacker could use, and a risk assessment weighs the results against the business.

Threat vs vulnerability vs risk at a glance

	Threat	Vulnerability	Risk
What it is	A person, group or event that could cause harm	A weakness a threat could exploit	The likelihood of harm combined with its size
Question it answers	Who or what could hurt us?	Where are we weak?	How likely, how bad, and what first?
Who controls it	Almost never the organization	You: IT, engineering, operations, HR	Leadership decides how much to accept
Example	A ransomware crew scanning for unpatched VPN appliances	A VPN appliance missing a security update	A realistic chance of a network-wide ransomware event this quarter
How you find it	Threat intelligence, advisories, threat modeling	Scanning, vulnerability assessment, penetration testing	A risk assessment combining the other two with asset value
How you reduce it	Rarely possible directly	Patch, reconfigure, redesign, train, add a control, tracked through a vulnerability management program	Reduce, transfer, avoid, or accept in writing

What is a threat?

NIST defines a threat as any circumstance or event with the potential to harm an organization’s operations, assets or people through unauthorized access, destruction, disclosure or modification of information, or denial of service (NIST SP 800-30 Rev. 1). The guide separates the threat source (who or what causes harm: a criminal group, an insider, a failing disk, a storm) from the threat event (what happens: a phishing campaign, a ransomware deployment, a flooded server room).

The four types of threats

SP 800-30 groups threat sources into four types:

1. Adversarial: hostile cyber or physical attacks by outsiders, insiders, partners or nation states.
2. Accidental: human errors, such as a storage bucket left public or a file sent to the wrong person.
3. Structural: failures of resources the organization controls, such as equipment, software or environmental controls.
4. Environmental: natural and man-made disasters outside its control, from floods to a regional power outage.

What makes an attacker a serious threat

For adversaries, NIST judges likelihood on intent, capability and targeting. A skilled group with no interest in you is a smaller threat than an opportunistic crew scanning the whole internet for one bug you happen to have.

Threats also adapt. NIST calls it threat shifting: harden one path and capable attackers change target, timing or technique.

What is a vulnerability?

NIST defines a vulnerability as a weakness in an information system, system security procedures, internal controls or implementation that could be exploited by a threat source. That is deliberately broader than software bugs. For assigning owners, it helps to sort vulnerabilities into six groups:

• Software flaws: a known CVE in a VPN appliance, a library or an operating system.
• Misconfiguration: a public storage bucket, an exposed admin interface, default credentials.
• Design and logic flaws: an API that returns another customer’s record when you change an ID. No CVE describes it.
• Control and process gaps: no MFA on remote access, accounts left active after people leave, untested backups.
• Human factors: staff who approve a sign-in prompt they did not start.
• Physical conditions: a door that does not latch, a server room below the flood line.

The usual “three types of vulnerabilities” answer (technical, human, physical) groups the same items more coarsely. Our guide to network vulnerabilities covers the fifteen most common technical ones in detail.

Weakness vs vulnerability

A weakness is a condition in software, firmware, hardware or a service, such as missing authorization, that could contribute to vulnerabilities. A vulnerability is a specific instance of one or more weaknesses in a specific product that can be exploited (MITRE CWE FAQ). Flaws in your own in-house code rarely get a CVE number, which is one reason scanners built to match known CVEs miss them.

Severity is not risk

NIST notes that a vulnerability’s severity depends on the impact if it is exploited, so it is context-dependent. The industry’s severity score agrees: the CVSS v4.0 user guide says Base scores measure the severity of a vulnerability and should not be used alone to assess risk (FIRST, CVSS v4.0 User Guide). A critical Base score describes the flaw, not your exposure to it.

Vulnerability vs exploit

An exploit is the code or technique that takes advantage of a vulnerability. The vulnerability is the unlocked window; the exploit is climbing through it. Four different statements tend to get merged into one:

Statement	What it means	Evidence
An exploit exists	Someone has published or sold a way to trigger the flaw	Advisories, security research
It is exploited in the wild	Attackers are using it against real victims	CISA’s Known Exploited Vulnerabilities catalog, 1,779 entries on November 11, 2026 (the count rises most weeks; see the October 2026 KEV additions)
It is likely to be exploited soon	A statistical estimate for the next 30 days	FIRST EPSS, a daily probability per CVE
It is exploitable here	It works against your system, as configured, from where an attacker sits	A penetration test

For CISA, scanning, research and proof-of-concept code do not count as exploitation. Public data cannot answer the last row, and it matters: exploitation of software vulnerabilities started 31% of breaches in Verizon’s 2026 Data Breach Investigations Report, now ahead of stolen credentials as the top way in. Our guide to risk-based vulnerability management shows how to combine these signals into a fix order.

CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) is one published way to do that. It takes exploitation status, technical impact, whether the attack can be automated, and how much the affected system matters, and returns one of four decisions: Track, Track*, Attend or Act. The output is an action and an urgency, not a score, which keeps severity and risk from being confused.

What is risk, and how is it different from a threat?

NIST defines risk as a measure of the extent to which an organization is threatened by a potential circumstance or event, typically a function of the adverse impact if it occurs and the likelihood that it occurs. A threat is one input to risk, not the risk itself. ISO is broader: ISO 31000 and its vocabulary standard, ISO 31073:2022 (which replaced ISO Guide 73), define risk as the effect of uncertainty on objectives.

The working formula is:

Risk = Likelihood x Impact

Likelihood is where threat and vulnerability meet: the probability that a given threat can exploit a given vulnerability, given the attacker’s intent and capability and the controls you have in place. Impact is the harm: data exposed, money lost, operations stopped, regulators notified.

You will also see Risk = Threat x Vulnerability x Impact. Treat it as a mental model, not arithmetic: the factors rarely share a scale, and NIST cautions that pairing each threat with each vulnerability can be problematic given how many of both exist, suggesting threat scenarios (chains of events that lead to harm) instead. The multiplication gets one thing right: if any factor is zero, so is the risk.

Risk can be expressed qualitatively (very low to very high), semi-quantitatively (scores in bins) or quantitatively. Open FAIR is the common quantitative model: how often a loss event is likely to occur, and how large the loss would be in dollars.

Inherent risk is the risk before controls; residual risk is what remains after them, and is what leadership formally accepts. Each rated risk is reduced, transferred (insurance or contract), avoided, or accepted in writing with an owner and a review date. Our vulnerability remediation guide covers the “reduce” path.

How threats, vulnerabilities and risk fit together

NIST’s generic risk model reads as a chain: a threat source initiates a threat event, which exploits a vulnerability (its severity shaped by your controls and by predisposing conditions such as location), causing an adverse impact. Risk is the combination of that impact and its likelihood. Laid out link by link, with one running example:

Link in the chain	Example	What you can do about it
Threat source	A ransomware crew	Little; follow advisories so you know what it is using
Threat event	Mass exploitation of a new VPN flaw	Nothing directly; early warning buys patching time
Vulnerability	Your VPN appliance is missing the update	Patch it, or take the interface off the internet
Controls and predisposing conditions	No MFA behind the VPN; a flat network	Add MFA, segment, monitor the appliance
Adverse impact	File servers and backups encrypted	Offline backups and a tested restore limit the damage
Risk	Likelihood of the event succeeding, combined with that impact	Reduce, transfer, avoid or accept in writing

Two lessons follow.

Break any link and the chain fails. NIST’s example is blunt: an organization that runs no database is not susceptible to SQL injection, however many attackers use it. A threat with no matching vulnerability is not a risk to you, and neither is a vulnerability nobody can reach.

Vulnerabilities combine. NIST notes that some vulnerabilities are not exposed to exploitation until others have been exploited. A penetration tester can chain three medium findings into domain admin; a scanner, rating each finding in isolation, cannot see that path.

Threat, vulnerability and risk: eight worked examples

#	Scenario	Threat	Vulnerability	Risk, and why
1	VPN appliance with a KEV-listed flaw, patch released two weeks ago and not applied	Criminal groups that mass-scan edge devices	Missing update on an internet-facing system	Critical. Active exploitation, direct exposure, and the device fronts the whole network
2	The same flaw on an isolated lab appliance with no inbound access and no data	The same groups, with no path in	The same missing update	Low. Same CVSS score as row 1, very different likelihood and impact
3	Push MFA on email that staff can approve with one tap	Phishing and password-spraying crews	Weak MFA design plus users who approve prompts they did not start	High. Mailbox access leads to invoice fraud and password resets elsewhere
4	Customer portal where changing an invoice number shows another customer’s invoice	Any logged-in customer	Missing authorization check (an IDOR vulnerability), a logic flaw with no CVE	High. Easy to find by hand, invisible to most scanners, and a potentially reportable data exposure
5	A former employee’s VPN and SaaS accounts active a month after they left	A disgruntled former employee	Offboarding process gap	Medium to high, depending on what the accounts reach
6	Basement server room in a flood zone, backups in the same room	Flooding (environmental)	Location plus no offsite copy	Medium to high. High impact, lower likelihood; NIST calls the flood-zone location a predisposing condition
7	A group targeting your industry exploits a product you do not run	Capable, motivated, targeting your sector	None that matches	Low for that scenario. Watch for threat shifting toward products you do run
8	Printer admin panel with a default password that stores a domain service account	Anyone on the internal network	Default credentials plus a stored privileged credential	Medium alone, high in a chain. A common first step toward domain admin in internal tests

Rows 1 and 2 show why a list sorted by CVSS misleads. Rows 4 and 8 show why scanning alone understates risk.

Which assessment measures which

Each security activity measures a different link in the chain.

Activity	Measures	Question it answers	Invadel price
Threat intelligence and threat modeling	Threats	Who would attack us, and how?	Threat intelligence: not an Invadel service. Threat modeling: not sold on its own, but built during AI, hardware and code review scoping
Vulnerability scan (raw)	Candidate vulnerabilities	Which known weaknesses might exist?	Not sold raw: every Invadel scan is analyst-validated (next row)
Validated vulnerability scan or assessment	Validated, ranked vulnerabilities	Which weaknesses are real, and which come first?	$1,500 up to 250 devices, $2,500 up to 1,000, free re-scan of fixes
Penetration test	Exploitability and impact	Can an attacker use them, and how far do they get?	From $4,000 (API), $4,200 (external network), $5,200 (web app), $6,000 (internal network)
Red team	Threat realism and detection	Could a realistic adversary reach an objective unnoticed?	From $12,500
Risk assessment	Risk	What matters most, and what do we accept?	Not an Invadel service: your team or a consultant runs it, and our findings feed it

Our security risk assessment guide walks through the steps, and penetration testing vs vulnerability scanning explains the middle rows. If you plan to buy the assessment and the test together, see vulnerability assessment and penetration testing.

Where the three terms show up in compliance

• NIST CSF 2.0 splits them across its Risk Assessment category: ID.RA-01 (vulnerabilities are identified, validated and recorded), ID.RA-03 (threats are identified and recorded), ID.RA-04 (impacts and likelihoods of threats exploiting vulnerabilities are recorded), ID.RA-05 (threats, vulnerabilities, likelihoods and impacts are used to understand inherent risk) and ID.RA-06 (risk responses are chosen and tracked) (NIST CSF 2.0, CSWP 29). Note “validated” in ID.RA-01: an analyst-confirmed finding list is far easier to defend against it than a raw scanner export.
• HIPAA requires an accurate and thorough assessment of potential risks and vulnerabilities to ePHI (45 CFR 164.308(a)(1)(ii)(A)). Our HIPAA security risk assessment guide walks through it, and HIPAA penetration testing supplies the testing evidence.
• ISO 27001 (clause 6.1.2) and NYDFS Part 500 both start from a risk assessment, and NYDFS section 500.5 adds penetration testing at least annually. See ISO 27001 and NYDFS testing.

How Invadel measures the vulnerability side

Invadel does not sell risk assessments or threat intelligence. We measure the two inputs you control: which vulnerabilities exist, and which can actually be exploited.

• Vulnerability assessment. An analyst confirms each scanner finding, removes false positives, merges duplicates and ranks the rest by real risk: $1,500 for up to 250 devices, $2,500 for up to 1,000, with a free re-scan of remediated findings. See the vulnerability assessment service and its pricing page.
• Penetration testing. Senior in-house testers exploit and chain findings by hand, so the report shows impact, not just presence. An external network test starts at $4,200 and an internal network test at $6,000, each with a free retest, an attestation letter, and executive and technical reports. Starting prices for the other core services are on the pricing page.

Every price is fixed in writing from the scope you send, without a sales call, and onboarding begins within 24 hours of a signed proposal; the sample report shows how each finding and its evidence are laid out.

Frequently asked questions

What is the difference between a threat and a vulnerability? A threat is the actor or event that could cause harm, such as a ransomware group or a flood. A vulnerability is the weakness it would use, such as an unpatched server or backups stored on site. You can usually fix a vulnerability; you can rarely remove a threat.

What is the difference between risk and threat? A threat is a possible source of harm. Risk is the likelihood that the threat actually harms a specific asset, combined with how bad that harm would be. A serious threat with no matching weakness, or nothing of value to reach, is low risk.

Is phishing a threat or a vulnerability? Phishing is a threat event: something an attacker does. The vulnerabilities are what let it work, such as users who can be tricked, MFA that can be approved with one tap, and mail filtering that lets the message through. Phishing testing measures how exposed those are.

What are the three components of a threat? Practitioners usually say capability, intent and opportunity; NIST SP 800-30 characterizes adversaries by capability, intent and targeting. Take away any one, for example by removing the opportunity, and the threat to you shrinks.

What is an example of a threat, a vulnerability and a risk together? A criminal group mass-scanning the internet for one VPN flaw is the threat. Your VPN appliance missing the update for that flaw is the vulnerability. The risk is the realistic chance that the group gets in through it and encrypts your network, weighed against what that outage would cost you.

What is the difference between inherent and residual risk? Inherent risk is the risk before any controls are applied. Residual risk is what is left after your controls, such as patching, MFA and backups, have done their work. Residual risk is the figure leadership accepts, reduces further, transfers or avoids.

Does a penetration test measure risk? It measures the two hardest inputs: whether a vulnerability is exploitable in your environment and what an attacker reaches with it. Your risk assessment adds business impact and decides what to accept.

The short version

A threat is who or what could hurt you, a vulnerability is the weakness they would use, and risk is how likely and how damaging that combination is for an asset you care about. You control the vulnerabilities, so that is where risk is cheapest to reduce. Start with a validated vulnerability assessment, priced from $1,500, add a penetration test where you need proof of impact, and scope your engagement for a written fixed price the same day.