Patch Prioritisation: Ranking Vulnerabilities When You Cannot Patch Everything

Most patching teams do not have a prioritisation problem. They have a capacity problem: more vulnerabilities than hours, fewer hours than the maintenance window allows, and a business that notices when the email server goes down but not when a library gets upgraded. The useful question is not "which vulnerability is worst?" It is "which one do we fix first, and can we explain why to someone who wasn't in the room?" A defensible queue is one where any engineer, auditor or incident commander can look at row three and see the reasoning behind it.

Why a Severity Score Is Not a Queue

CVSS rates a flaw in isolation. It answers "how bad is this if exploited, under a set of assumptions?" Those assumptions — network reachable, no authentication, unchanged defaults — frequently do not hold in your environment. A 9.8 in a library that only lives inside an isolated build container is less urgent than a 6.5 authentication bypass sitting on the internet-facing VPN concentrator.

Severity also ignores time. The gap between a working proof of concept appearing and mass scanning is short, and for anything an attacker finds interesting it is measured in hours to days, not quarters. If your queue looks the same this week as last week while the exploit landscape has moved, you are running a backlog with a colour scheme, not a prioritisation process.

Three Inputs That Actually Move the Needle

• Internet exposure. Can an unauthenticated stranger reach the vulnerable service? Not "is the asset important" — can packets get there, and does the vulnerability sit in the code path before authentication? A flaw behind two layers of authenticated access is a different animal from one that answers on port 443 from anywhere.
• Exploit activity. Is this being used, or merely described? Exploitation in the wild, inclusion in a national known-exploited catalogue, a weaponised public proof of concept, or attacker chatter about the specific product all raise the temperature. A theoretical write-up with no working code does not.
• Business impact. If this is exploited, what actually stops? A finance reconciliation system, a customer portal, a factory floor controller and an internal wiki all carry different consequences — not just in downtime, but in data exposure, regulatory notification and manual work that piles up.

Bring the three together and the rankings become obvious. Keep them apart and you get the usual argument in which the loudest asset owner wins.

A Workable Scoring Model

You do not need a platform to do this. A spreadsheet with three columns and a formula works, and it is easy to defend. Score each input from 0 to 4, then weight exploit activity highest because it reflects current reality rather than potential.

1. Exposure: 4 = unauthenticated from the internet; 3 = internet-facing but authenticated, or reachable from a partner network; 2 = internal, reachable from ordinary user devices; 1 = internal, restricted to a small admin segment; 0 = isolated lab, no production data.
2. Exploit activity: 4 = confirmed exploitation in the wild; 3 = public, working exploit code; 2 = credible proof of concept or high predicted exploitation; 1 = technical details only, no code; 0 = no public research.
3. Business impact: 4 = core revenue or safety function, or large regulated data set; 3 = significant service with customer or partner visibility; 2 = internal productivity or reporting; 1 = convenience tooling; 0 = disposable.

Score = (Exposure × 2) + (Exploit × 3) + (Impact × 2), giving a maximum of 28. Treat 18 and above as emergency work with an out-of-band change, 9 to 17 as the next scheduled window, and below 9 as routine maintenance unless something changes.

A worked example

An internet-facing VPN appliance with a disclosed authentication bypass, working exploit code circulating, terminating access to the admin network: exposure 4, exploit 3, impact 4 — score 29, capped by the model's ceiling, straight to emergency change. Now compare a 9.8 remote code execution flaw in a parsing library used only by an internal batch job on a segmented host with no public exploit: exposure 1, exploit 0, impact 2 — score 6. Same severity label, completely different weeks.

Edge Cases and Honest Exceptions

Some things genuinely cannot be patched on your schedule: firmware on embedded devices, software the vendor has stopped supporting, an application certified only against a specific runtime version. When that happens, do not quietly drop the item. Record the compensating control — network segmentation, a WAF rule, disabling the vulnerable feature, added monitoring — assign an owner, and set a review date. An accepted risk with a date is a decision. An accepted risk without one is an oversight waiting to be found.

Also remember that scores do not override obligations. If a contract, a regulator or a customer agreement imposes a fixed remediation deadline, that deadline is a floor, not a suggestion. The model helps you order the remaining work; it does not let you skip it.

Making the Queue Hold Up Under Scrutiny

Defensibility comes from consistency and from writing things down. Put the score and a one-line justification in the ticket, not just in your head. Note which input drove the ranking — "emergency because exploit is in the wild and the host is internet-facing" is a sentence that survives an audit and a post-incident review.

Keep the method to a single page and publish it. Re-score when new exploit information lands, not only when the next scan finishes. Finally, separate emergency work from scheduled work so that urgent items do not quietly consume every maintenance window and leave the routine queue to rot.

Putting It Into Practice

Start with one weekly thirty-minute triage. Pull the current critical and high findings, score them in the spreadsheet, and sort. Expect the top of the list to be shorter than you feared: internet-facing, actively exploited, business-critical is a small intersection in most environments. Everything below it can wait for a window without anyone losing sleep.

Then do two things before the next cycle. First, check that your exposure scores are real — query the asset inventory instead of trusting a CMDB field that was last updated two years ago. Second, tell the business what you are not patching this month and why. Saying that out loud is uncomfortable the first time, and it is exactly the conversation that turns a patch list into a defensible risk position.

Photo: Lalmch / Pixabay