How to Prioritise Vulnerabilities Using Evidence

Prioritisation is not the act of sorting a spreadsheet by one number. It is a decision process that should produce a manageable queue, a clear reason for urgency and an accountable next action.

1. Confirm presence

Start by validating that the vulnerable product and affected version exist. Scanner confidence, authenticated evidence and software inventory quality matter. Remove false positives and stale assets before they consume remediation time.

2. Establish exposure

Determine whether the vulnerable component is internet-facing, reachable from an untrusted network, accessible through identity paths or isolated behind effective controls. Exposure changes priority more directly than a severity label.

3. Apply exploitation evidence

Confirmed exploitation, KEV inclusion and reliable incident observations deserve the strongest weighting. Public proof-of-concept code matters, but distinguish a demonstration from a stable weaponised exploit.

4. Use probability to rank the remainder

EPSS helps order vulnerabilities that lack confirmed exploitation. Watch the probability and percentile, but also watch movement. A material increase can be more operationally useful than a fixed threshold.

5. Understand consequence

Use the CVSS vector, weakness class and vendor advisory to understand what successful exploitation enables. Remote unauthenticated code execution on edge infrastructure is a different proposition from a local availability issue requiring user interaction.

6. Add organisational context

Only the organisation can supply service criticality, data sensitivity, control effectiveness, recovery capability and change constraints. Keep this context separate from universal public scores so the reasoning remains transparent.

7. Assign a next action

Every priority should end with an action: patch, mitigate, remove, isolate, investigate exposure, accept temporarily or validate. Include an owner and a deadline. A priority with no owner is only a report.

8. Verify the outcome

Rescan, retest or inspect configuration after treatment. Confirm that the vulnerable version, exposed service or attack path has gone. Closure evidence is part of remediation, not optional administration.