Threats, Vulnerabilities and Risk

Threat, vulnerability and risk

Three words are used constantly in security, and mixing them up leads to bad decisions. A house and a burglar make them concrete.

• A threat is anything that could cause harm to an asset: a burglar, but also a storm or a careless resident. In IT: a criminal group, a malicious insider, a ransomware campaign, a power failure, a flood or an administrator making a mistake.
• A vulnerability is a weakness that a threat could use: a window left open, a weak lock. In IT: an unpatched server, a default password, a misconfigured storage bucket, staff who have never seen a phishing email.
• Risk is the combination of the likelihood that a threat uses a vulnerability and the impact if it does: how likely is a break-in through that window, and what would be lost?

Some related words complete the picture:

The point of separating them: you usually cannot remove threats (criminals exist), but you can remove vulnerabilities and reduce impact. And a vulnerability with no realistic threat, or on an asset that holds nothing of value, is a low risk — even if it sounds alarming. Threats are not only attackers: the U.S. National Institute of Standards and Technology (NIST) guidance on risk assessment, SP 800-30, distinguishes adversarial, accidental, structural (equipment failure) and environmental threat sources. Who the attackers are is covered in Threat Actors and Attack Vectors.

Likelihood and impact

The most common way to express risk is:

risk = likelihood × impact

Likelihood estimates how probable it is that the event happens in a given period, considering how attractive the target is, how easy the vulnerability is to exploit and which controls are already in place. Impact estimates the damage if it does happen: money, downtime, safety, legal consequences, reputation. Both are estimates — a risk score is a tool for comparing and prioritizing, not a precise prediction.

The qualitative risk matrix

In a qualitative assessment, likelihood and impact are each rated on a short scale, often 1 to 5, with a written description per level so that different people rate the same way (for impact, for example, "3 = a department cannot work for a day"). Multiplying gives a score from 1 to 25, and bands turn the score into a level.

This small program scores a list of risks the same way and sorts them from highest to lowest, which is exactly what a risk register does when you sort on the score column:

# Likelihood and impact on a 1-5 scale (1 = very low, 5 = very high)
register = [
    ("Phishing leads to a stolen mailbox", 4, 3),
    ("Ransomware on the file server", 3, 5),
    ("Laptop stolen from a car", 3, 2),
    ("Server room flooded", 1, 5),
    ("Visitor reads screen at reception", 2, 1),
]

def band(score):
    if score >= 12:
        return "High"
    if score >= 5:
        return "Medium"
    return "Low"

scored = [(name, l, i, l * i) for name, l, i in register]
scored.sort(key=lambda row: (-row[3], row[0]))

print(f"{'Risk':36} {'L':>2} {'I':>2} {'Score':>5}  Band")
for name, l, i, score in scored:
    print(f"{name:36} {l:>2} {i:>2} {score:>5}  {band(score)}")

Risk                                  L  I Score  Band
Ransomware on the file server         3  5    15  High
Phishing leads to a stolen mailbox    4  3    12  High
Laptop stolen from a car              3  2     6  Medium
Server room flooded                   1  5     5  Medium
Visitor reads screen at reception     2  1     2  Low

Notice the flood: unlikely but catastrophic, it ends up "Medium", the same as a stolen laptop. Pure multiplication hides that difference, which is why many organizations add a rule such as "every impact of 5 is reviewed by management, whatever its score".

Quantitative risk: putting a price on it

A quantitative assessment expresses risk in money, which makes it easier to compare with the cost of a control. The classic formulas:

• Asset value (AV): what the asset is worth, including the cost of replacing it and of the work lost.
• Exposure factor (EF): the fraction of that value lost in one incident (0.25 = a quarter, 1.0 = everything).
• Single loss expectancy (SLE) = AV × EF: the expected loss from one incident.
• Annualized rate of occurrence (ARO): how often the incident is expected per year (4 = four times a year, 0.02 = once in fifty years).
• Annualized loss expectancy (ALE) = SLE × ARO: the expected loss per year.

A control is worth its money when it reduces the ALE by more than it costs per year. The figures below are invented for illustration:

# Fictitious figures, for illustration only
risks = {
    "Laptop theft": {"asset_value": 1_500, "exposure_factor": 1.0, "aro": 4},
    "Server room flood": {"asset_value": 400_000, "exposure_factor": 0.25, "aro": 0.02},
}

def ale(asset_value, exposure_factor, aro):
    sle = asset_value * exposure_factor   # single loss expectancy
    return sle, sle * aro                 # annualized loss expectancy

for name, r in risks.items():
    sle, loss = ale(**r)
    print(f"{name}: SLE EUR {sle:,.0f} x ARO {r['aro']} = ALE EUR {loss:,.0f}")

# A control (training plus "never leave a laptop in a car") costs EUR 1,200
# a year and is expected to cut thefts from 4 to 1 a year.
_, before = ale(1_500, 1.0, 4)
_, after = ale(1_500, 1.0, 1)
print(f"Control value: EUR {before - after - 1_200:,.0f} a year")

Laptop theft: SLE EUR 1,500 x ARO 4 = ALE EUR 6,000
Server room flood: SLE EUR 100,000 x ARO 0.02 = ALE EUR 2,000
Control value: EUR 3,300 a year

The flood shows the weakness of averages: an ALE of 2,000 a year says nothing about the 100,000 bill in the year it actually happens. Real quantitative analysis is hard because good figures for likelihood are scarce, so most organizations use qualitative scales and add money estimates only for their biggest risks.

Risk assessment

A risk assessment is the process of identifying risks, analyzing their likelihood and impact, and evaluating which ones need treatment. Frameworks such as NIST SP 800-30 and ISO/IEC 27005 describe it in detail; the core steps are the same everywhere:

1. Set the scope and criteria. Which systems or processes, and which scales and bands for likelihood and impact?
2. Identify assets and what they are worth to the business — often the output of a business impact analysis.
3. Identify threats and vulnerabilities relevant to those assets, using threat intelligence, scan results, audit findings and incident history.
4. Analyze likelihood and impact, taking existing controls into account.
5. Evaluate: compare each risk with the organization's risk appetite and decide which need treatment first.
6. Treat, record and communicate the decisions, then monitor and repeat — after major changes, after incidents and at least periodically (often yearly).

An assessment is only as good as the people in the room. The system administrator knows the technical weaknesses; the process owner knows what an outage really costs; the security team knows current threats. Leave any of them out and the scores become guesses.

Risk treatment: four options

Risk treatment (also called risk response) is the decision on what to do about a risk. There are four options:

Two points are often misunderstood. Transferring a risk moves the money, not the responsibility: if a supplier leaks your customers' data, it is still your organization that must inform the regulator and the customers, and that loses their trust. And accepting a risk is a legitimate, documented decision with an owner and a review date — not the same as ignoring it. Doing nothing without a decision is not acceptance; it is negligence.

Residual risk and risk appetite

Inherent risk is the risk before any controls. Residual risk is what remains after the chosen treatment. It is never zero: a patched server can still be hit by a vulnerability nobody knows about yet, and backups can fail. The goal of risk management is not to remove all risk, but to bring residual risk to a level the organization has consciously agreed to.

Risk appetite and risk tolerance

Risk appetite is the amount and type of risk an organization is willing to take in pursuit of its goals, set by top management. A start-up may accept more risk to move fast; a nuclear plant or a bank accepts very little. Some frameworks, including the Security+ objectives, describe an appetite as expansionary, neutral or conservative.

Risk tolerance is the acceptable deviation for a specific risk or objective, often a concrete threshold: "the web shop may be down for at most four hours", or "we accept no risk scored High without a treatment plan". Tolerance turns the general appetite into decisions an IT team can apply.

The risk register

A risk register is the document or tool that lists all identified risks with their description, score, owner, treatment and status. It is the memory of risk management: without it, the same risks are rediscovered at every meeting and nobody knows which were accepted and why.

(EDR is endpoint detection and response, see Endpoint Security; MFA is multi-factor authentication.) Good registers also record the inherent and residual score, the date of the last review and, for accepted risks, who signed off and until when.

Who owns risk?

The risk owner is the person accountable for a risk and with the authority to decide on its treatment — usually the business owner of the process or asset, such as the head of finance for the payment process. IT and security teams identify risks, advise on options and implement controls, but they should not decide alone how much risk the business takes, because they do not own the business consequences.

Ultimate accountability lies with top management. European law makes this explicit: under the NIS2 directive (the European Union's second Network and Information Security directive), the management bodies of covered organizations must approve the cybersecurity risk-management measures and can be held liable for failures. In the Netherlands NIS2 is being implemented through the Cyberbeveiligingswet; check its current status, as it was still in progress at the time of writing (see Governance, Frameworks and Compliance).

For a starter in IT this has a practical meaning: if you find a risk, report it to your lead or the security team so that it reaches the register and its owner. Do not quietly accept it on the business's behalf — and do not quietly ignore it either.