Threat vs Vulnerability vs Risk: Definitions and Examples

A threat is anything that could harm your systems or data, a vulnerability is a weakness that a threat could exploit, and risk is the likely harm that results when a threat meets a vulnerability, measured as a combination of likelihood and impact. Put simply: the burglar is the threat, the unlocked window is the vulnerability, and the risk is how likely a break-in is and how much it would cost you. Teams that blur the three terms end up patching by severity score alone, filling risk registers with vague entries like "hackers", and asking boards to fund fixes nobody can tie to business harm. This guide gives the formal definitions from NIST SP 800-30 Rev. 1 and the ISO 31000 and ISO/IEC 27005 framing, then shows how practitioners turn them into risk decisions, including a worked example with an exposed API key. It is written for security analysts, risk and GRC teams, and engineering leads who need a shared vocabulary that holds up in an audit.

Key takeaways

Three different things, not synonyms. A threat is a potential cause of harm, a vulnerability is a weakness, and risk is the combination of how likely harm is and how bad it would be.
No threat or no exposure means little risk. A critical vulnerability on an isolated, unreachable system can be lower risk than a medium one on an internet-facing login page.
CVSS measures severity, not risk. The CVSS Base score describes a vulnerability's intrinsic characteristics; your exposure, asset value and business impact are outside its scope.
Write risks as scenarios. "Threat source exploits vulnerability against asset, causing impact" is assessable and ownable; "ransomware" on its own is not.
Every risk gets a decision. Accept, avoid, mitigate, share or transfer, with a named owner, a residual rating and a review date.

The definitions: what the standards actually say

NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments (September 2012), is the reference most security teams use, and its definitions are reproduced in the NIST CSRC glossary. ISO 31000:2018 and ISO/IEC 27005:2022 use slightly different language but the same logic.

Term	NIST definition (paraphrased from the CSRC glossary)	Plain-language meaning	Example
Threat	Any circumstance or event with the potential to adversely impact organisational operations, assets, individuals, other organisations or the Nation through an information system, via unauthorised access, destruction, disclosure or modification of information, or denial of service (SP 800-30 Rev. 1, from CNSSI 4009).	Something or someone that could cause harm.	A criminal group that scrapes public code repositories for cloud keys.
Threat source	Characterised by the intent and method targeted at exploiting a vulnerability, or by a situation and method that may accidentally exploit one (SP 800-30 Rev. 1).	Who or what is behind the threat: adversarial, accidental, structural or environmental.	An opportunistic attacker; a developer who commits a secret by mistake; a failed disk.
Threat event	An event or situation caused by a threat source that could cause harm (SP 800-30 Rev. 1).	The thing that actually happens.	The attacker uses the scraped key to call the cloud API.
Vulnerability	A weakness in an information system, system security procedures, internal controls or implementation that could be exploited or triggered by a threat source (SP 800-53 Rev. 5, derived from SP 800-30 Rev. 1).	A gap or flaw that lets the threat succeed.	A long-lived access key hardcoded in source code, with no expiry.
Predisposing condition	A condition within an organisation, mission or business process that affects the likelihood that threat events, once initiated, result in adverse impact (SP 800-30 Rev. 1).	Something about your environment that makes harm more likely, without being a bug.	No central secrets inventory; flat network; one shared service account.
Risk	A measure of the extent to which an entity is threatened by a potential circumstance or event, typically a function of the adverse impact if it occurs and the likelihood of occurrence (SP 800-30 Rev. 1).	How likely, how bad.	"High: likely within 12 months; impact is customer data exposure and regulatory notification."
Residual risk	The portion of risk remaining after security measures have been applied (SP 800-30 Rev. 1, from CNSSI 4009).	What is left after your controls.	Risk after the key is rotated and secret scanning is enabled.

ISO 31000 frames risk more broadly as the effect of uncertainty on objectives, which allows for positive as well as negative outcomes. ISO/IEC 27005:2022 (edition 4) applies that model to information security in support of an ISO/IEC 27001 ISMS, covering risk assessment, treatment, communication, monitoring and review. In practice the two framings meet in the middle: ISO asks what could stop you meeting objectives, and NIST asks which threat events could exploit which weaknesses to cause which impacts. ISO/IEC 27005 accepts either an event-based approach (starting from scenarios) or an asset-based approach (starting from assets, threats and vulnerabilities). See the ISO/IEC 27005 Information Security Risk Guide and the ISO 31000 Risk Management Guide.

How the three relate: likelihood and impact

SP 800-30 Rev. 1 states that risk is a function of the likelihood of a threat event occurring and the potential adverse impact should it occur. Likelihood itself depends on two things: whether a threat source will initiate the event (its capability, intent and targeting, or for accidents the frequency), and whether the event, once initiated, succeeds against your vulnerabilities and predisposing conditions given the controls in place.

Threat without vulnerability: attackers constantly probe your login portal, but phishing-resistant MFA and rate limiting mean the attempt rarely succeeds. Threat is high, likelihood of a harmful event is lower.
Vulnerability without threat exposure: an unpatched library sits in an internal batch job with no network listener and no untrusted input. Severity may be high, likelihood is low.
Vulnerability plus threat, low impact: a defacement flaw on a static marketing microsite with no data and no credentials. Likely, but the impact is minor and recovery is quick.
Vulnerability plus threat plus high impact: an internet-facing application with a known exploited flaw that holds customer records. This is where the risk lives and where effort should go first.

SP 800-30 Rev. 1 supports qualitative scales (very low, low, moderate, high, very high) and semi-quantitative ones, for example bins of 0 to 15, 16 to 35, 36 to 70, 71 to 85 and 86 to 100, or a 1 to 10 scale. Its appendices give worked tables: threat sources (Appendix D), threat events (E), vulnerabilities and predisposing conditions (F), likelihood (G), impact (H) and risk determination (I). Quantitative approaches such as FAIR express the same idea in loss event frequency and loss magnitude; see the Cyber Risk Quantification Guide.

Likelihood \ Impact	Very low	Low	Moderate	High	Very high
Very high	Very low	Low	Moderate	High	Very high
High	Very low	Low	Moderate	High	Very high
Moderate	Very low	Low	Moderate	Moderate	High
Low	Very low	Low	Low	Low	Moderate
Very low	Very low	Very low	Very low	Low	Low

The matrix is an illustrative example of a risk determination table of the kind SP 800-30 Rev. 1 describes in Appendix I. Use it as a starting point and calibrate it: define each impact level in your own terms (for example "High: regulatory notification, more than 10,000 records, or more than one day of outage of a tier 1 service") so that two assessors reach the same answer.

Worked examples

Example 1: an exposed cloud API key (non-human identity)

A contractor pushes application source code to a public repository. The code contains a long-lived cloud access key for a service account that can read a customer database. This is close to what happened in the Toyota T-Connect key exposure, where an access key to a customer data server sat in a public GitHub repository from December 2017 until September 2022, and Toyota could not rule out third-party access to email addresses and customer management numbers for 296,019 customers.

Asset: the customer database and the trust of its data subjects.
Threat source and event: opportunistic attackers who scan public repositories for credentials (MITRE ATT&CK T1552.001 Credentials In Files), then use the key to access cloud resources as a valid account (T1078.004 Cloud Accounts).
Vulnerabilities: a hardcoded, long-lived key; no secret scanning on commits; the service account has read access to the whole database rather than one table.
Predisposing conditions: no inventory of machine credentials and their owners; third-party developers with repository access and no offboarding of their tokens.
Likelihood: very high. Public repositories are scanned continuously, so exposure time, not attacker interest, is the deciding factor.
Impact: high. Personal data exposure, regulatory notification and phishing of customers.
Risk: very high on the matrix above. Treatment: mitigate now (revoke and rotate the key, review cloud audit logs for its use, enable pre-commit and push-time secret scanning), then reduce future likelihood by replacing static keys with short-lived workload identity and scoping the account to least privilege.

Note that no CVE is involved. Many of the most damaging non-human identity risks are configuration and process weaknesses that a vulnerability scanner never reports, so they only appear in a risk register if someone writes them down. See the API Key Management Guide and the NHI Risk Scoring Guide.

Example 2: a critical CVE on two different systems

The same remote code execution flaw (CVSS Base 9.8, Critical) exists on two servers. Server A is an internet-facing VPN appliance and the flaw is listed in the CISA Known Exploited Vulnerabilities catalog (MITRE ATT&CK T1190 Exploit Public-Facing Application). Server B is a test host on an isolated lab network with no inbound access. The vulnerability and its severity are identical; the risk is not. Server A is a very high risk that needs emergency patching or isolation. Server B can follow the normal patch cycle, documented as a lower risk with the exposure assumption recorded so it is revisited if the network changes.

Example 3: a threat with no specific vulnerability yet

Threat intelligence reports a group targeting your sector through help desk social engineering to reset privileged accounts. You have no identified flaw, but your help desk verifies callers with information found on social media. That process is the vulnerability, and once written down it can be assessed and treated like any other: stronger caller verification, and no MFA resets for privileged accounts without a second approver.

Severity is not risk: CVSS, EPSS and KEV

The CVSS v4.0 specification says the Base score reflects the severity of a vulnerability according to its intrinsic characteristics, and that factors such as regulatory requirements and monetary losses are outside the scope of CVSS. A CVSS number is an input to a risk decision, not the decision.

Signal	What it measures	What it does not tell you	Use it for
CVSS v4.0 Base (CVSS-B)	Intrinsic severity of the flaw: attack vector, complexity, privileges required, impact on the vulnerable and subsequent systems. Ratings: Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9, Critical 9.0 to 10.0.	Whether anyone is exploiting it, whether it is reachable in your estate, what the asset is worth.	Comparing flaws on a common scale.
CVSS-BT, CVSS-BE, CVSS-BTE	Base adjusted with Threat metrics (exploit maturity) and Environmental metrics (your security requirements and modified base metrics).	Business impact in money or regulatory terms.	Getting a score closer to your context; few teams populate Environmental metrics at scale.
EPSS (FIRST)	Estimated probability that a published CVE will be exploited in the wild in the next 30 days, a value from 0 to 1 with a percentile, updated daily.	Your exposure or impact; it covers only published CVEs.	The threat side of likelihood.
CISA KEV catalog	CVEs with evidence of active exploitation.	Whether you are reachable; absence from KEV is not proof of safety.	A hard trigger for short remediation deadlines.
Asset criticality and exposure	Internet-facing or internal, data classification, business service tier, compensating controls.	Anything about the flaw itself.	The impact side and the success side of likelihood.

A practical rule: severity tells you how bad a flaw could be, exploitation data tells you how likely someone will try, and your asset and exposure data tells you how much it matters to you. Risk needs all three. See the Vulnerability Prioritisation Guide, the Risk-Based Vulnerability Management Guide and the CVSS v4 Guide.

Running a risk assessment that uses the terms properly

SP 800-30 Rev. 1 describes four steps: prepare for the assessment, conduct it, communicate the results, and maintain it. A lightweight version that works for a single system or a whole programme:

Frame the scope: the system, business process or service, its owner, the assumptions and constraints, and the risk appetite that applies (NIST SP 800-53 PM-28 Risk Framing; CSF 2.0 GV.RM-01).
Identify threat sources and events: use threat intelligence and a threat model, not a generic list. Record adversarial, accidental and environmental sources (CSF ID.RA-02, ID.RA-03). See the Threat Modelling Guide.
Identify vulnerabilities and predisposing conditions: scanner findings (RA-5, ID.RA-01), configuration reviews, penetration test results, and process weaknesses such as missing credential ownership.
Determine likelihood: combine threat initiation (intent, capability, exploitation data) with the chance of success given current controls.
Determine impact: on confidentiality, integrity and availability of the asset, and through them on operations, people, finances, legal position and reputation (CSF ID.RA-04).
Determine risk and record it: inherent and residual ratings, owner, treatment and review date in the register (ID.RA-05, RA-3). See the Risk Register Template.
Decide and track the response: chosen, prioritised, planned and communicated (ID.RA-06, RA-7).
Maintain: re-assess on material change (new internet exposure, new data, a new exploited CVE, an incident) and on a fixed cycle, with continuous monitoring feeding it (CA-7).

Small vs large organisations: a small team can run this in a workshop per critical service with a five by five matrix and a spreadsheet register. A large organisation needs a shared taxonomy of threat events and impact definitions, risk aggregation across business units, and automation that links scanner and identity posture data to register entries so ratings move when the evidence does. See the NIST SP 800-30 Risk Assessment Guide.

Risk treatment options and how to choose

NIST SP 800-39, reflected in SP 800-30 Rev. 1 and SP 800-53 Rev. 5, names five risk responses: accept, avoid, mitigate, share and transfer. ISO/IEC 27005 uses similar options under the names modify, retain, avoid and share.

Response	What it means	Choose it when	Exposed API key example
Mitigate (ISO: modify)	Apply controls to reduce likelihood or impact.	The activity is needed and controls are affordable.	Rotate the key, add secret scanning, move to short-lived federated credentials, restrict scope.
Accept (ISO: retain)	Formally keep the risk as it is.	Residual risk is within appetite, or the cost of treatment exceeds the expected loss.	A low-privilege read-only key to public data, documented with an owner and expiry date.
Avoid	Stop the activity that creates the risk.	The risk is beyond appetite and the activity is not essential.	Decommission the legacy integration that needed the static key.
Share or transfer	Move part of the financial or operational consequence to another party.	Residual impact is still high and a contract or insurance can absorb part of it.	Contract terms that make the developer partner liable for credential hygiene; cyber insurance for notification costs.

Two rules keep treatment honest. First, transferring or sharing moves consequences, not accountability: a regulator will still look to you. Second, acceptance is a decision by someone with authority under the risk appetite, recorded with a review date, not the default when nobody acts. See the Cyber Risk Appetite Statement Template and the Remediation SLAs and Vulnerability Exceptions Guide.

Where identity fits

Identity weaknesses rarely carry a CVE, so they are often missing from risk assessments that start from scanner output. Treat these as vulnerabilities or predisposing conditions in their own right: secrets in code and CI logs, service accounts with no owner, tokens with no expiry, over-scoped OAuth grants to SaaS integrations, and credentials left active after a vendor relationship ends. Each can be written as a risk scenario and measured. NIST SP 800-53 IA-5 (Authenticator Management) and CSF 2.0 PR.AA-01 are the natural control anchors. See the Secrets Management Guide.

Detection and measurement

Risk management that works produces evidence. Track:

Register coverage: percentage of tier 1 business services with a current risk assessment (reviewed in the last 12 months or since the last material change).
Scenario quality: percentage of register entries that name a threat source, a vulnerability or condition, an asset and an impact, rather than a single word.
Time to treat: median days from a risk being rated high or very high to an agreed treatment plan, and from plan to residual rating within appetite.
Exposure on exploited flaws: count and age of KEV-listed vulnerabilities on internet-facing assets.
Machine credential exposure: secrets detected in repositories per month and median time from detection to revocation.
Acceptance hygiene: number of accepted risks past their review date.

Common failure patterns

Patching by CVSS alone: teams chase every Critical on unreachable hosts while a Medium on the internet-facing login page, with active exploitation, waits weeks.
Threats listed as risks: entries such as "ransomware", "insider" or "nation state" with no vulnerability, asset or impact cannot be rated, owned or closed.
Configuration and identity weaknesses missing: the register is generated from vulnerability scans, so leaked keys and orphaned service accounts never appear. The Cloudflare Thanksgiving breach turned on one service token and three service accounts left unrotated after the Okta breach because they were believed to be unused.
Uncalibrated scales: "High impact" means different things to different assessors, so ratings reflect who filled in the form.
Silent acceptance: overdue remediation becomes de facto accepted risk without an owner or appetite check.
Static assessments: risk is rated once at project launch and never revisited after the system becomes internet-facing or starts holding personal data.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	ID.RA-01 to ID.RA-06; GV.RM-01; GV.OV-01	Vulnerabilities, threats, likelihood and impact used to understand inherent risk and choose responses; risk objectives and strategy review.
NIST SP 800-53 Rev. 5	RA-3 Risk Assessment; RA-5 Vulnerability Monitoring and Scanning; RA-7 Risk Response; PM-9 Risk Management Strategy; PM-28 Risk Framing; CA-7 Continuous Monitoring; SI-2 Flaw Remediation	Control requirements for assessing, responding to and monitoring risk.
NIST SP 800-30 Rev. 1	Chapters 2 and 3; Appendices D to I	Risk model, assessment process and example scales.
ISO/IEC 27001:2022 and 27005:2022	Clauses 6.1.2 (risk assessment) and 6.1.3 (risk treatment) of 27001; 27005 guidance	ISMS risk assessment and treatment requirements.
MITRE ATT&CK	T1552.001, T1078.004, T1190	Describing threat events concretely in scenarios.

Practitioner checklist

Adopt one set of definitions (SP 800-30 Rev. 1 or ISO/IEC 27005) and publish it in your risk methodology.
Rewrite every register entry as a scenario: threat source, threat event, vulnerability or condition, asset, impact.
Define each likelihood and impact level in concrete business terms and test that two assessors agree.
Prioritise vulnerabilities with CVSS plus EPSS, KEV status, exposure and asset criticality, never CVSS alone.
Add identity and secrets weaknesses to the register even when no scanner reports them.
Record inherent and residual risk, a named owner, the chosen response and a review date for every entry.
Require accepted risks to be signed by someone with authority under the risk appetite, with an expiry date.
Trigger re-assessment on material change: new exposure, new data, a new exploited CVE or an incident.
Report the metrics above to the risk committee each quarter.

Threat vs Vulnerability vs Risk Guide: Definitions, Differences and Risk Decisions