How to read a vulnerability scan report and prioritise fixes

What a scan report is actually telling you

A vulnerability scanner looks at your systems over the network, works out which software and versions are running and compares that against a library of known flaws. Every finding is therefore a claim - this looks like something with a known problem - rather than proof that someone could break in.

That distinction matters because scanners get things wrong in both directions. A false positive is a finding that is reported but does not really exist; the NCSC's own example is a scanner claiming patches are missing when you know they have been applied. A false negative is the reverse: a real flaw the scanner never mentions. The NCSC also warns that a clean report can create a false sense of security, so a short list does not mean you are safe and a long list does not mean you are doomed. A report with 400 findings is not 400 emergencies. It is a list nobody has sorted yet.

Most reports give each finding a description, the affected system or service, a severity rating and often a CVE identifier. A CVE is the public reference number for a specific known flaw, which lets you look it up in vendor advisories and other lists later in this article.

What the severity rating does and does not mean

Most severity labels come from CVSS, a 0 to 10 scoring system maintained by FIRST. Both the current CVSS v4.0 and the older v3.1 map scores to the same bands: Low is 0.1 to 3.9, Medium is 4.0 to 6.9, High is 7.0 to 8.9 and Critical is 9.0 to 10.0. If your scanner uses its own labels, check the key at the front of the report to see how they map.

The score describes how serious a flaw is in general: how easily it can be reached and what an attacker gains. Scores published by software makers and by public databases are typically Base scores only, which FIRST says do not reflect your own environment or whether anyone is actually using the flaw. FIRST's advice is that people using CVSS should add threat and environmental information to the Base score. In plain terms, a Critical on a printer that sits on an isolated network and a Medium on your public website are not directly comparable, and the label alone cannot tell you which to fix first.

The NCSC takes the same line: CVSS is a useful input, but you still need to weigh the business impact and risk for your own organisation. The rest of this article is how to do that without needing a security team.

Sort the findings into a priority order

You will need read access to the report and, for the checks in the second step, someone who can see what is installed on the affected systems. If that is your IT provider or the supplier of a firewall or line-of-business system, ask them. Nothing in this section changes any system.

The aim is to end with a short list of jobs, each with an outcome, an owner and a date, rather than a spreadsheet of scores.

1. Group the findings. Findings that share one fix are one job. The NCSC's example is several SSL findings on a service collapsing into a single issue. Grouping by system, or by whether the system is exposed to the internet, also helps. Many reports shrink dramatically at this point.
2. Check each group is real. Look at the affected system and find which version is actually installed, then compare that with what the finding says and with the vendor's advisory. Do not delete a finding on a hunch; the NCSC says suspected false positives should be verified before you remove them. Some appliances and Linux-based devices fix a flaw without changing the version number a scanner reads, so a mismatch is worth checking in the vendor's notes rather than assuming either way. This is our engineering experience of how version-based detection can mislead, not something the scanner vendors guarantee.
3. Ask whether it can be reached from the internet. Internet-facing issues take priority, according to the NCSC. Think firewalls, VPN and remote-access gateways, mail servers and public websites. An internal-only flaw still matters, but an attacker usually has to be inside your network first.
4. Look for evidence of exploitation. Search for the CVE identifier in the CISA Known Exploited Vulnerabilities (KEV) catalogue and in the vendor's advisory. CISA only adds a flaw to KEV when it has a CVE number, there is reliable evidence it has been exploited in the wild and there is a clear fix or mitigation. US federal agencies must act on KEV entries; you are not bound by that, but CISA strongly recommends every organisation prioritise them, and so do we. If an exposed system has a KEV-listed flaw, treat it as urgent. The NCSC says to accelerate updates when a critical flaw is being actively exploited, especially on an internet-facing system. Absence from KEV means only that there is no such public evidence yet, not that the flaw is harmless. If you have a very long list, the EPSS score from FIRST can help you order the middle: it estimates the probability that a published CVE will be exploited in the wild in the next 30 days. Use it as a tiebreaker, not as permission to ignore anything.
5. Ask what you would lose. Business impact is about what the system does: holding client records, taking payments, running the sign-in for everyone or hosting your backups. The NCSC singles out critical shared infrastructure as high priority. Firewalls, identity systems, virtualisation hosts and backup servers usually qualify, because compromising one tends to open up many others.
6. Give every group one of three outcomes, using the NCSC's triage model. Fix means you will update, reconfigure or mitigate; record a target date, and keep any temporary workaround time-limited and tracked until the real fix is in. Acknowledge means you are choosing to leave it for now; write down the reason and a review date. The NCSC describes a decision not to update as a senior-level risk decision, so in a small business that means an owner or director, not whoever happened to be running the scan. Investigate means you cannot yet decide, perhaps because the cost or options are unclear, and the NCSC stresses it should only ever be a temporary status.

A worked example with fictional findings

Take a made-up firm, Harbour Lane Dental, with six grouped findings. The ratings and scenarios are invented for illustration, and the order reflects our judgement rather than any formula.

The point is that the order does not follow the severity labels.

• The VPN gateway on the firewall has a flaw rated High, and the vendor advisory says it is being exploited. It is on the KEV list and reachable from the internet. Fix first, as an emergency change with the supplier.
• The public website has an outdated plugin rated Medium. It is internet-facing and there is no evidence of exploitation. Fix next, in the same week, because exposed web software is where opportunistic attackers look first.
• Three separate TLS findings on the mail gateway are really one configuration job. It is quick, so it is done alongside the website fix.
• The internal file server runs an operating system its vendor no longer supports, and the scanner rates it Critical. It is not exposed, so it is not an emergency, but no patch will ever arrive. Outcome: Fix, meaning a dated replacement project, with the risk acknowledged and reviewed in the meantime.
• A printer with Critical firmware findings sits on an isolated network segment with no evidence of exploitation. It goes into the next routine update window.
• The server banner reveals a software version, rated Low. Acknowledge, with a note and a review date, then move on.

Findings that no patch will fix

Unsupported software is the most common finding that sorting cannot solve, because there is no update to apply. The NCSC's advice is to replace or re-support end-of-life technology, particularly where it is exposed to the internet, since patching alone may not be enough. If replacement will take months, our view is that you should reduce its exposure in the meantime and record the decision as an Acknowledge with a firm review date, rather than leaving it as an open finding that everyone has stopped seeing.

If you hold, or are working towards, Cyber Essentials, the scheme sets its own rules and deadlines for applying security updates. NCSC lists version 3.3 of the requirements as current from 27 April 2026, so read the security update management section of that document rather than relying on a scanner's severity label to tell you whether you are compliant.

Apply the fixes without causing an outage

Fixing is the point at which a tidy spreadsheet turns into a real change on a real system. Updating a firewall, VPN or server can interrupt everyone who depends on it, and you will need administrator rights on the device. Take it one top-priority group at a time.

1. Read the vendor's advisory for the fixed version and any caveats, such as a required restart or a configuration change that goes with the update.
2. Pick a quiet window and tell the people who will notice. Firewalls and VPN gateways drop connections when they restart, and some servers will be unavailable until they are fully back.
3. Make sure you can undo it. Export the device's configuration or take a backup or checkpoint of the server, whichever applies, and know who would restore it if the update misbehaves. For a routine desktop or low-risk update this is overkill; for a firewall or core server it is not.
4. Apply the update and restart if it asks you to. This can take several minutes, and the system is not ready until it has come back and passed a basic test, so stay with it. Then use the service as a normal user would: connect through the VPN, send an email or open the application.
5. If you cannot apply the real fix yet, apply the vendor's recommended mitigation, record it as temporary and set the date by which the proper fix is due.

Check it worked

Re-scan the same systems with the same scanner. The NCSC recommends re-scanning to confirm fixes landed, and suggests assessing your whole estate at least monthly, with more frequent checks for services exposed to the internet. Whether you can re-scan immediately depends on your tool or service, as some run on a schedule instead of on demand.

You have finished when every Fix item has disappeared from the new report, and every Acknowledge and Investigate item has an owner, a reason and a review date written down somewhere other people can find it.

If a fixed finding is still there, the usual explanations are:

• The update reached one system but not another instance of the same software.
• A restart is still pending, so the old version is still running.
• The scanner is reading a version number that the vendor did not change, which makes it a false positive; confirm that in the advisory before closing it.
• A configuration change was needed as well as the update.

When to bring in help

Reading and sorting a report needs judgement, not special rights. Changing firewalls, VPN appliances or core servers is different. If nobody in-house can do that safely, or the system belongs to a supplier, hand those items to your IT provider or the supplier with your ranking and reasons attached. They will do a better job with a prioritised list than with a raw export.