Vulnerability Management Framework

Five queues, not five severities

September 17, 2026·9 min read·Chris Boker
Five parallel horizontal lanes flow left to right across a paper background, each lane starting with a distinct colored entry block and ending with a surface exit block. The top green lane carries a row of open circles for unowned findings, the mint lane carries a row of hollow diamonds for pending decisions, the middle green lane carries three filled squares then a large gold batch block with a ten-cell grid inside and four more filled squares behind it, the gold lane carries a row of circles each stamped with a green validation check, and the bottom surface lane carries a row of hexagons under a dashed arrow and a dashed exit gate marking accepted-with-control tickets.

For twenty-plus years vulnerability programs have organized work into one giant list sorted by severity color: critical, high, medium, low. That is a sorting habit, not a workflow, and the numbers say it stopped scaling years ago. Edgescan's 2026 stats report puts 45.4 percent of enterprise findings unresolved at twelve months. Verizon's 2026 DBIR looked at more than 13,000 organizations and reported only 26 percent of KEV entries fully remediated. Qualys, whose telemetry fed that DBIR chapter, showed KEV-linked instances rising 7.7 fold in four years, from 68.7 million to 527.3 million. A single severity-sorted queue produces the exact shape those numbers describe, a thin top that moves and a fat middle that never does.

Every neighbouring operational discipline solved this decades ago by splitting work by TYPE. ITSM separated incident, problem, change, and service request so a three-hour outage does not compete with a six-month process fix. Kanban and lean production, popularized in software by Donald Reinertsen, made per-lane work-in-progress limits the point. SRE gave incidents their own paging channel and problem management its own track. Only vulnerability management still routes everything into one severity-sorted list, then wonders why the middle never drains.

The proposal is a small set of purpose-built queues, five of them, each defined not by how bad the finding is but by what it needs to happen next. Each has its own entry rule, owner, definition of done, and failure mode when missing. The action-queue idea appeared briefly in our remediation operating model piece last month, which owns the four-owner model and the ticket contract; none of that material is repeated here. What is new is treating the queues themselves as the object to design.

The five queues, one at a time

1. Needs owner

The finding is confirmed real, enrichment says it matters, and nobody owns the affected asset. This is a routing problem, not a fix problem, and its own queue keeps unowned findings from aging inside the same bucket as work in flight. Entry: an enriched finding exists and asset-to-team mapping fails. Owner: a designated routing steward, often the person who runs the weekly review. Done: a technical owner has explicitly accepted the ticket, timestamped. Failure mode when absent: unowned criticals age at the same rate as assigned ones, buried inside a generic "open" bar.

2. Needs decision

The fix path is unclear because a tradeoff blocks it: a patch requires downtime the business has not approved, a tuning has an unresolved false-positive risk, an exception is being requested. This is where meetings happen, and it is not the technical team's fault the meeting has not been scheduled. Entry: a documented open question only a named non-technical role can resolve. Owner: the business or risk owner tied to the affected system. Done: a decision is recorded in the ticket, with an expiration date if the outcome was to accept risk. Failure mode when absent: tradeoff conversations happen ambiently in Slack and never bind, and the same exception gets re-argued quarter after quarter.

3. Needs fix

Owner is known, fix path is known, the work is ready to be scheduled and done. This is the queue most programs think they already have; it is only useful once the other four stop leaking into it. Entry: owner accepted, fix path documented, change window identified. Owner: the technical service team. Done: the change deployed to every affected instance, with rescan-attached evidence on the ticket. Failure mode when this queue is holding work that belongs in queues 1, 2, or 4: the "high" column looks full, the actual fix rate is small, and the queue serves as a proxy for "we care".

One nuance the Qualys 7.7 fold instance-growth number forces here: the queue holds instances, not CVEs. When a single hardening step retires 400 instances of the same finding across a fleet, treating that as 400 child tickets is bookkeeping theater. Batch remediation belongs inside needs fix as an explicit pattern, one parent change ticket closing many instance children with a rescan sweep as evidence.

4. Needs validation

The technical team believes the fix landed, but there is no proof yet. This is the queue a control-loop program cannot function without, and the one almost every legacy program silently skips. Entry: closure is claimed by the technical team and evidence is not yet attached. Owner: whoever owns validation for that finding class, typically a security engineer, an automated re-enrichment lane, or a BAS run. Done: a rescan, control test, BAS execution, or re-enrichment shows the target state achieved, attached to the ticket. Failure mode when absent: closed tickets do not mean state changed, and the same finding reopens six weeks later while the metric still reports "remediated".

5. Accepted with control

The residual risk will remain in the environment on purpose, a compensating control exists (a WAF rule, a segmentation policy, a detection), and the exception has a documented owner and expiration date. Entry: a decision from queue 2 (or an equivalent risk memo) that names the accepted risk, the control, and the expiration. Owner: the risk owner, jointly with the technical steward of the control. Done: the control is verified working today, and the ticket is scheduled to re-open automatically at the expiration. Failure mode when absent: "risk accepted" becomes a ticket-closure verb with no control and no expiration, and the exception register becomes indistinguishable from a graveyard.

Routing, the queue's queue

Defining five queues is the easy half. The hard half is deciding which queue a new finding enters, and who arbitrates when two rules fire. The rule that survives contact with reality is a short chain, applied in order: is the asset owner known (no, into queue 1), is a tradeoff blocking action (yes, into queue 2), is fix work ready to schedule (yes, into queue 3), is a fix claimed without proof (yes, into queue 4), is this an approved acceptance with a working control (yes, into queue 5). One person arbitrates disagreements, the same steward who runs the weekly review. Without a named arbiter, findings live wherever the last operator dropped them, a subtle version of no queue at all.

BOD 26-04 quietly made the same argument

Federal civilian agencies now operate under CISA's BOD 26-04, which sorts vulnerabilities into five tiers with different timelines: three days with forensic triage, three days without, fourteen days, sixty days, and deferral to the next upgrade, and agencies must be meeting those timelines by December 7, 2026. Read the tiers carefully. Those are not five severities. Three days with triage is an incident-response workflow with its own proof of completion; three days without is an emergency change; fourteen days is a scheduled change; sixty days is routine maintenance; fix-on-next-upgrade is a lifecycle decision that belongs to whoever owns the roadmap. The directive independently converged on the shape this framework does: five KINDS of work cannot share one queue, one owner, and one definition of done.

How the weekly exposure review changes

The weekly exposure review agenda shrinks from "top thirty by CVSS" to a lap around the five queues:

  • Queue 1, what sat unowned longer than 72 hours and who is taking it today.
  • Queue 2, decisions overdue and who owes them.
  • Queue 3, what shipped, how much was batch-consolidated, and where the actuator is saturated.
  • Queue 4, closures without evidence and how the validation lane is catching up.
  • Queue 5, accepted risks expired this week and controls still verifying green.

One hour of concrete signal instead of an hour of severity-color argument.

Adopting this on Monday

None of this needs new tooling. Five Jira labels, five ServiceNow states, or five columns in a Google Sheet get a team started tonight. What matters is the entry rule and definition of done written down where the ticket-facing team can read them. Backfill the current queue against the labels for one week without moving anything. The distribution embarrasses the program into acting: most of what a team calls "needs fix" is actually needs owner or needs decision, and most of what a team calls "closed" is actually needs validation.

Limits worth naming

Splitting queues does not fix a saturated actuator. If the arrival rate into queue 3 exceeds the service rate for long enough, no amount of queue design will drain the backlog; that is a capacity conversation, and the coming queue-economics piece takes up the arithmetic. Splitting queues also does not replace enrichment (queue 3 is only useful when the finding really is fix-ready) or repair bad asset ownership data (queue 1 exists to expose that gap, not close it). The five queues are the operating skeleton the rest of the program hangs off, not the whole program.

Where CVEasy fits

CVEasy AI is the local-first CTEM platform that runs these five queues against your environment on hardware you own, with routing automated and validation wired to rescan and BAS evidence. TRIS is the score routing reads to keep queue 3 sorted by exposure, not color.