A security scan of a medium-sized application easily returns hundreds of findings. Teams that try to fix them in the order the tool prints them burn weeks on low-value work while the one finding that matters waits in the backlog. The way out is a small set of precise words and one simple formula.

In part 2 we looked at how systems are exposed on the network. This part defines what we are protecting against and how to rank the problems we find. The terms sound similar, and people mix them up constantly, so we will use one running example throughout.

The running example: an internal reporting service built on an old version of a web framework. It has a known remote code execution flaw. It runs in a private subnet, reachable only from the company VPN, and it can read the customer database.

The five words

Threat

A threat is anything that could cause harm to a system, its data or its users. Threats have a source (a criminal group, a careless employee, a storm that floods a data centre) and an action (stealing data, deleting records, taking a service offline).

In the example, threats include an external attacker who already has VPN access through stolen credentials, and a curious employee exploring internal tools.

Vulnerability

A vulnerability is a weakness that a threat could use. It can be in code (an injection flaw), in configuration (a public bucket), in process (no review of access rights) or in people (no phishing awareness).

In the example, the vulnerability is the remote code execution flaw in the old framework version.

Exploit

An exploit is the technique or code that actually uses a vulnerability. A vulnerability with a public, reliable exploit is much more dangerous than one that is theoretical or requires rare conditions.

In the example, suppose a public exploit exists and works with a single HTTP request.

Impact

Impact is the damage if the threat succeeds, measured against confidentiality, integrity and availability, and ultimately in business terms: money, legal exposure, customer trust, downtime.

In the example, code execution on a service that can read the customer database means a possible full customer data breach. The impact is high.

Risk

Risk combines how likely the harm is with how bad it would be. The common working definition is:

risk = likelihood x impact

Likelihood depends on the threat (who would try and how capable they are), the vulnerability (how easy it is to exploit) and the exposure (who can reach it). Impact depends on what the system can touch.

In the example, likelihood is reduced because the service is only reachable from the VPN, but not eliminated, because VPN credentials do get stolen. Impact is high. The overall risk is significant, and it should be fixed soon, but it is not more urgent than the same flaw on an internet-facing service.

Why a CVSS score is not your risk

The Common Vulnerability Scoring System (CVSS) gives each published vulnerability a score from 0 to 10. It is useful, but it describes the vulnerability in general, not your situation. The base score assumes a reasonable worst case and knows nothing about your network, your data or your controls.

Two identical findings with a CVSS base score of 9.8 can carry very different risks:

Factor Service A Service B
Exposure Public internet VPN only, private subnet
Data access Customer database Static test data
Compensating control None Web application firewall rule blocks the exploit pattern
Exploited in the wild Yes Yes
Your priority Fix today Fix this sprint

Two other public signals help with likelihood. The Exploit Prediction Scoring System (EPSS) estimates the probability that a vulnerability will be exploited in the next 30 days. The CISA Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with confirmed exploitation. A finding that is in KEV, on an exposed system, with access to sensitive data, goes to the top of the list regardless of its exact CVSS number.

Four ways to treat a risk

Once a risk is identified, there are only four things you can do with it:

  1. Mitigate: reduce likelihood or impact. Upgrade the framework, restrict network access, remove the database permission the service does not need.
  2. Transfer: move some of the impact to someone else, for example through cyber insurance or by using a managed service whose provider carries part of the responsibility.
  3. Avoid: stop doing the risky thing. Decommission the reporting service if nobody uses it.
  4. Accept: decide consciously to live with it, with a named owner, a reason and a review date.

Acceptance is legitimate. Ignoring a risk is not the same as accepting it; acceptance is written down and signed by someone who has the authority to make that decision.

In the example, a sensible plan is: mitigate immediately by restricting which VPN groups can reach the service and removing its write access, then mitigate fully by upgrading the framework within a week.

A small risk register

You do not need a governance tool to start. A table in your team's wiki works if people keep it current. Use a 1-5 scale for likelihood and impact, so scores range from 1 to 25.

ID Risk Likelihood (1-5) Impact (1-5) Score Treatment Owner Review
R1 RCE in reporting service exposes customer data 3 5 15 Mitigate: upgrade, restrict VPN group Platform team 2026-06-25
R2 Single database without tested restore 2 5 10 Mitigate: monthly restore drill Data team 2026-07-01
R3 Shared admin account on analytics tool 4 3 12 Mitigate: SSO and individual accounts IT 2026-06-30
R4 Legacy marketing site on unsupported CMS 3 2 6 Accept until replatform in Q3 Marketing lead 2026-09-01

Agree on what each number means so different people score consistently. For impact, for example: 1 = no customer effect, 3 = some customers affected or data of low sensitivity, 5 = large-scale breach of sensitive data or a multi-day outage.

Common mistakes

Mistake Why it hurts Do this instead
Sorting findings by CVSS only Misses exposure and data sensitivity Add exposure, data access and KEV status
Calling every finding a risk The register becomes noise Group findings into risks with business impact
Accepting risks verbally Nobody remembers who decided Written acceptance with owner and review date
Scoring impact as technical severity Underrates data and legal damage Score impact in business terms
Never revisiting scores Exposure changes as systems change Review on a schedule and after big changes

Key takeaways

  • A threat is a potential source of harm, a vulnerability is a weakness, an exploit uses the weakness, impact is the damage and risk is likelihood times impact.
  • CVSS describes the vulnerability in general; your risk depends on exposure, data and controls.
  • EPSS and the CISA KEV catalog are good public signals for likelihood.
  • Every risk is mitigated, transferred, avoided or accepted, and acceptance must be explicit.
  • A simple, maintained risk register beats a perfect one nobody updates.

The next part walks through the most common cyber attacks from the defender's side: what they look like and which controls stop them.

References