Threat, vulnerability, and risk
Separate the possible source of harm, the weakness, and the potential consequence.
The idea
A threat is a potential cause of harm. A vulnerability is a weakness that could be used or triggered. Risk concerns the possibility and consequences of harm in a particular context. These terms answer different questions. A published software flaw is not enough to prioritize work: you also need to know whether the affected service exists, who can reach it, and what would happen if it failed.
In practice
An attacker is a threat source; an unpatched internet-facing service is a vulnerability; interruption of customer bookings is a business consequence used in assessing risk.
A common misunderstanding
A vulnerability score is not the same as your organization’s risk. Exposure, business importance, and existing controls change the decision.
Check your understanding
Two servers share a flaw. Why might one be fixed first?
Think it through: It may be exposed to the internet or support a more critical service.
A risk statement connects cause and consequence
A fictional travel company discovers an outdated booking component. The software weakness is a vulnerability. A malicious actor exploiting it, or another relevant triggering event, represents a threat scenario. Interrupted reservations and exposed customer records are possible consequences. Risk assessment connects those elements in the company's actual environment instead of treating the software name as a complete conclusion.
Exposure changes the scenario. A public booking service and an isolated training instance may contain the same flaw but present different opportunities and consequences. Existing controls, recoverability, and business timing also matter. A peak-season booking outage can have a different impact from the same interruption during planned maintenance.
Uncertainty should be explicit. The team may know the affected version but not whether a required feature is enabled. It may know the service is reachable but lack evidence of exploitation. Record those gaps and decide which evidence would change the priority. False precision in a numeric score can hide uncertainty rather than resolve it.
Write two competing scenarios
For the travel example, describe one scenario involving unauthorized data access and another involving service interruption. Identify the asset, threat event, relevant weakness, current safeguards, and business consequence for each. State the assumptions without inventing incident facts.
Then choose an action: patch, reduce exposure, apply a temporary safeguard, or investigate an uncertainty. Assign an owner and a review point. The decision should be understandable to someone responsible for the service, not only a vulnerability scanner. Distinguishing threat, vulnerability, and risk helps teams choose an appropriate response and explain why one weakness deserves attention before another.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
NIST: Guide for Conducting Risk Assessments