Vulnerability Management: How to Prioritise

A vulnerability scanner in a mid-sized organisation typically returns thousands of findings, hundreds of them rated "critical" or "high". Nobody can work through that, and the most common consequence is that the list stops interesting anyone.

The answer is not more resource but better prioritisation. This article covers how to select, from thousands, the few dozen that genuinely matter.

Why CVSS is not enough

The CVSS score measures the theoretical severity of a vulnerability under laboratory conditions. What it does not tell you:

• whether it is actually being exploited in the wild,
• whether the system is even reachable by an attacker,
• what the system is worth commercially,
• whether compensating controls surround it.

This is why a CVSS 9.8 flaw on an isolated test system unreachable from the internet can be less urgent than a CVSS 6.5 in a public web application under active attack.

Three data sources that restore order

1. KEV: what is actually exploited

The CISA Known Exploited Vulnerabilities catalogue lists vulnerabilities with confirmed active exploitation in the wild. That is a few thousand entries out of hundreds of thousands of CVEs.

If a finding appears in KEV, it is immediate priority, regardless of its CVSS score. This single filter reduces most organisations' lists to a manageable size straight away.

2. EPSS: the probability of exploitation

The Exploit Prediction Scoring System estimates the likelihood that a given vulnerability will be exploited in the next 30 days, on a scale from 0 to 1.

Practical experience: the overwhelming majority of CVEs score below 0.01, meaning they are essentially never exploited. High CVSS combined with low EPSS is the most common pairing, and it is precisely what floods the list.

3. Your own context

This is what no external database can supply:

• Reachability: exposed to the internet, reachable internally, or isolated?
• Business criticality: what happens if this system fails or is compromised?
• Data: does it handle personal or commercially sensitive data?
• Compensating controls: is there a WAF, IPS or segmentation in front of it that prevents exploitation?

A practical prioritisation order

The P5 category matters: not every vulnerability must be fixed. Documented risk acceptance is a legitimate answer when somebody makes and signs the decision. What is not legitimate is tacit neglect.

OT environments work differently

In industrial environments patching is often not an option. Vendor support has expired, an update would invalidate certification, or the downtime window comes once a year.

That does not mean nothing can be done. The order is different:

1. Know what you have. Passive discovery, precise recording of firmware versions. Without it there is no vulnerability matching.

2. Filter by reachability. A vulnerable PLC in a well-segmented zone reachable only from the engineering workstation is a materially smaller risk than the same device on a flat network.

3. Apply compensating controls. Network-level virtual patching (an industrial IPS blocking traffic targeting that specific vulnerability) is often the only realistic answer. It does not fix the flaw but prevents its exploitation.

4. Plan for the downtime window. The list of items genuinely to be patched should be ready when the window arrives, because you will have hours, not days.

5. Document. NIS2 measure five and IEC 62443-2-3 both ask for the process, not for zero vulnerabilities. A working, documented risk acceptance is an adequate answer.

Elements of a working process

Discovery. Continuous automated scanning across the full asset inventory. Active in IT, passive in OT.

Prioritisation. Per the order above, automated where possible. The goal is that the list reaching the team has ten items, not two thousand.

Ownership. Every item needs an owner. "IT will handle it" is not an owner.

Deadline and tracking. A fixed deadline per priority level, and measurement of whether it is met.

Verification. Rescan after remediation. Surprisingly often it emerges that the patch installed but the service was not restarted, so the old version is still running.

Exception handling. Written, time-bound, reviewed risk acceptance for items not being fixed.

What to measure

Three indicators suffice:

• Mean time to remediate (MTTR) by priority level. This shows whether the process works.
• Number of open KEV-listed items. This should trend to zero.
• Coverage: what percentage of the asset inventory is scanned at all.

The third usually produces the biggest surprise. In many organisations scanning is limited to servers, while workstations, network devices and edge appliances are omitted. Those are precisely where attackers enter.

If you want to assess where you stand, our IT security services include establishing the vulnerability management process, and on the OT side OT vulnerability assessment. We covered penetration testing and the IEC 62443 framework in separate articles.