Threat assessment: turning a vague worry into a ranked list

A threat assessment answers one question: of everything that could go wrong, which few things should we spend money and attention on first? Its output should be a short ordered list with owners and dates. Anything else — a matrix of coloured squares, a register nobody opens — is documentation rather than assessment.

Threat, vulnerability and risk are not interchangeable

• Threat — something or someone that could cause harm. Ransomware operators. A careless administrator. A flood.
• Vulnerability — a weakness the threat could use. An unpatched VPN appliance. Shared admin credentials.
• Risk — the combination, with consequence. "Ransomware operators exploit the unpatched VPN and encrypt production, halting order processing for a week."

Assessments that list threats without vulnerabilities produce anxiety; ones that list vulnerabilities without consequence produce a patch backlog with no priority.

The steps

1. Establish what you are protecting

Start from business outcomes, not systems. "Customers can place orders" and "we can make payroll" are things the business cares about. Then map which systems each depends on. This ordering matters — an inventory-first approach produces a list of servers with no way to rank them.

2. Identify credible threats

Credible is the operative word. A small e-commerce business is not a realistic target for a state intelligence service, and planning as though it were wastes the budget that should have gone on backups. For most organisations the honest list is short: opportunistic ransomware, business email compromise, credential theft, insider error, and supplier failure.

Published frameworks help ground this — MITRE ATT&CK for techniques, the Verizon DBIR for what is actually happening at your size and sector.

3. Find the vulnerabilities that connect them

For each threat, ask concretely how it would succeed here. Ransomware needs initial access, then privilege escalation, then reachable backups. That gives three questions with real answers: what is exposed, who holds local administrator, and can backups be reached from a compromised domain account.

4. Assess likelihood and impact — and say what the numbers mean

Most assessments score 1 to 5 on each axis without defining the scale, so scores are not comparable between assessors. Define them explicitly:

• Likelihood 5 — expected within a year; similar organisations report it regularly.
• Likelihood 3 — plausible within three to five years.
• Likelihood 1 — no known occurrence in this sector.
• Impact 5 — operations stop for more than a week, or the loss threatens the business.
• Impact 3 — significant disruption, recoverable within days.
• Impact 1 — inconvenience, absorbed by normal work.

Where the money justifies it, expressing impact in currency and likelihood as an annual probability is more useful than a score, because it can be compared directly against the cost of the control.

5. Decide what to do

Four options, and "accept" is a legitimate one when recorded and owned:

• Mitigate — reduce likelihood or impact.
• Transfer — insurance or contract. Note that this moves financial loss, never the operational disruption.
• Avoid — stop doing the thing.
• Accept — with a named owner and a review date.

6. Assign, date and review

Every item gets a person and a date. A risk register without owners is a list of observations. Review quarterly, and re-run the assessment properly after any material change — a new product, an acquisition, a significant incident.

Where these go wrong

• Too many items. Forty risks means none are prioritised. Force a top five.
• Scoring to a predetermined answer. If everything lands on amber, the scale is not discriminating and should be changed.
• Assessing systems rather than outcomes. Produces technically correct findings that nobody funds.
• Treating it as an annual document. The value is in the decisions it forces, not the artefact it produces.