How do we decide what to fix first when the scanner shows thousands of findings?

Start

The scan returns thousands of findings

A large backlog is normal, especially after a first authenticated scan or a new cloud account. The volume is not the problem. Ranking it by CVSS score alone is, because the score measures the weakness in isolation. It does not know whether attackers use it or whether anyone can reach the system.

• Then: Count one finding per weakness per system

Step

Count one finding per weakness per system

The same vulnerability on twenty systems is twenty findings, and each may end with a different priority. A web server and a test box with the same flaw are not the same risk. Drop informational results with a score of 0.0: they are not findings.

• Then: Record the four inputs and the date first seen

Step

Record the four inputs and the date first seen

Record exploitation evidence, exposure, technical severity and asset criticality. Also record the date the finding was first detected on that system, because every deadline counts from it. When exposure or criticality is unknown, take the more urgent value: unknown exposure counts as internet-facing, and unknown criticality as Critical. Gaps in the asset inventory then cost the people who can close them. Unknown exploitation counts as not known exploited, and is checked again at the next weekly triage.

• Then: Is the weakness being used in real attacks?

Decision

Is the weakness being used in real attacks?

Yes when there is reliable evidence of exploitation anywhere: the CISA Known Exploited Vulnerabilities catalogue, a vendor advisory saying so, a national CSIRT or sector feed, or an incident of your own. Public proof-of-concept code alone is not enough; it is an early-warning signal, handled later. If you don't know, treat it as not exploited and check again at the next weekly triage.

• Yes: Is the system internet-facing, or rated Critical?
• No, or not known: How severe is the weakness technically?

Decision

Is the system internet-facing, or rated Critical?

Internet-facing includes anything reachable from networks you do not fully control, such as partner links and guest Wi-Fi, not only the public internet. Critical means failure or compromise would stop a core business service or expose highly sensitive data. If either is unknown, answer yes.

• Yes, or not known: Priority 1 — Emergency
• No: Priority 2 — High

Decision

How severe is the weakness technically?

Take the severity the scanner reports, or the vendor's rating where the scanner gives none. With neither, treat it as High. The bands follow FIRST's CVSS ratings: Critical 9.0–10.0, High 7.0–8.9, Medium 4.0–6.9, Low 0.1–3.9. Rescoring a finding by hand to a lower severity is a lowering, and needs the same approval as any other.

• Critical or High: Can it be reached from the internet?
• Medium: Can it be reached from the internet?
• Low: Priority 4 — Low

Decision

Can it be reached from the internet?

An attacker who can reach the service from outside needs one step. One who must first get inside your network needs two. A laptop counts as internal unless a vulnerable service on it accepts connections from the internet. Browser and email-client flaws are attacked through the user, and the exploitation question catches them when they are used.

• Yes, or not known: Priority 2 — High
• No: Is the system rated Critical?

Decision

Is the system rated Critical?

A Critical system raises a finding by one priority level, but never to Priority 1. Only evidence of real attacks creates a Priority 1. High-criticality systems do not raise the priority; they decide the order of work within it.

• Yes, or not known: Priority 2 — High
• No: Priority 3 — Medium

Decision

Can it be reached from the internet?

The same test as for severe weaknesses. A Medium flaw that anyone on the internet can reach is more urgent than the same flaw behind your network defences.

• Yes, or not known: Is the system rated Critical?
• No: Is the system rated Critical?

Decision

Is the system rated Critical?

A Critical system raises the finding one level, from Priority 3 to Priority 2.

• Yes, or not known: Priority 2 — High
• No: Priority 3 — Medium

Decision

Is the system rated Critical?

A Critical system raises the finding one level, from Priority 4 to Priority 3. This is how a modest flaw in the database behind your customer records gets a 30-day deadline instead of 90.

• Yes, or not known: Priority 3 — Medium
• No: Priority 4 — Low

Outcome

Priority 1 — Emergency

Exploited, and reachable from the internet or on a Critical system. In the pack's defaults: mitigate within 72 hours, fix within 7 days, and tell the standard owner at once. Treat it as a possible incident. If there is any sign the weakness has already been used against you, follow “If a vulnerability affects a business-critical service, what happens next?” instead of waiting for the fix.

• Then: Does anything justify changing the priority?

Outcome

Priority 2 — High

Exploited on an internal, non-critical system; severe and internet-facing; or raised because the system is Critical. The pack's default deadline is 14 days, with escalation to the asset owner's manager if the finding is still open on day 10.

• Then: Does anything justify changing the priority?

Outcome

Priority 3 — Medium

Severe but internal, or Medium and internet-facing. A Medium flaw on an internal Critical system is also raised here from Priority 4. The pack's default deadline is 30 days. Where the payment card standard applies, it sets its own clock as well: patches for critical vulnerabilities installed within one month of the patch's release. That month runs from release, not from detection, so check both.

• Then: Does anything justify changing the priority?

Outcome

Priority 4 — Low

Low severity anywhere, or Medium on an internal, non-critical system. The pack's default is 90 days, usually met through the normal patch cycle. These can be tracked in bulk, but still carry the deadline.

• Then: Does anything justify changing the priority?

Decision

Does anything justify changing the priority?

Two things can, and they are treated differently on purpose. Making a finding more urgent never needs approval, because it only makes the rule stricter. Making it less urgent needs the standard owner, a recorded reason, and a control that actually changes one of the four inputs.

• Early-warning signal: Raise it, and record why
• Accepted control: Lower it only if a control changes an input
• Neither: Work the queue in order

Step

Raise it, and record why

Early-warning signals can justify a raise before exploitation is confirmed: working public exploit code, a high EPSS score (FIRST's estimate of the chance of exploitation in the next 30 days), a vendor marking the flaw 'exploitation more likely', or reports of ransomware groups using it. The triage chair decides and records the reason.

• Then: Work the queue in order

Step

Lower it only if a control changes an input

Taking the service off the internet, confirmed by an external scan, changes exposure, so it qualifies. So does disabling the vulnerable feature, or isolating the system to named management hosts. 'The web application firewall should block it', 'it is monitored' and 'the patch is scheduled' change nothing, and do not qualify. Re-read the priority with the changed input. The clock does not restart. A lowering is never made to rescue a missed deadline.

• Then: Work the queue in order

Step

Work the queue in order

Within a priority, fix in this order: earliest deadline first, then exploited before not exploited, then Critical, High and Standard systems, then stronger early-warning signals. This is how thousands of findings become a list a team can start on this week.

• Then: At this week's triage, has any input changed?

Decision

At this week's triage, has any input changed?

Check open findings against the exploitation sources every week. When a finding becomes more urgent, for example because it has just been added to the Known Exploited Vulnerabilities catalogue, re-rate it that week. Its new deadline is the earlier of its old deadline and the date the change became known plus the new priority's period. If a control you relied on to lower a priority stops working, the finding returns at once to its original priority and deadline.

• Yes: re-rate: Is the weakness being used in real attacks? (back to an earlier step)
• No: Will the fix be made by the deadline?

Decision

Will the fix be made by the deadline?

Deadlines are calendar days from first detection. Ask before the deadline, not after: once it has passed, the finding is overdue and escalates, first to the asset owner's manager, then to the approver.

• Yes: Fixed, then confirmed by a rescan
• No: Request an exception before the deadline

Outcome

Request an exception before the deadline

If the fix genuinely cannot be made in time, request an exception while the finding is still in date. Controls that do not qualify for a lowering, such as a firewall rule or extra monitoring, still count as evidence in the request. The exception is time-limited and has its own approver.

Outcome

Fixed, then confirmed by a rescan

A finding is closed when the fix is verified, normally by a rescan that no longer finds it, not when the ticket says 'patched'. Keep the closure evidence with the finding: an auditor typically picks a handful of findings and asks for each one's detection date, owner, deadline and the scan that proved it fixed.