Program Building Vulnerability Management

Patch backlog bankruptcy, a governed reset when the queue stopped meaning anything

September 3, 2026·9 min read·Chris Boker
A large left-side stack of fourteen faded backlog record bars, most stamped with a rust X to mark archival and a few with a green check to mark keep, a bold dashed gold vertical date line down the middle marking the reset boundary, a large green round governance seal stamped over the boundary with three concentric rings and a small gold sub-seal for the audit sign-off, and a small clean right-side stack of five bright working queue rows each fronted by a mint exposure band chip and a gold owner marker

On April 15, 2026 NIST did the thing everyone in vulnerability management has quietly wanted to do for years. It declared bankruptcy on its own backlog. Every CVE published before March 1, 2026 that was still awaiting enrichment, roughly 29,000 records, was moved into a status called Not Scheduled and will not receive a CVSS vector, a CPE, or a CWE going forward. NVD now enriches only entries that appear in the CISA KEV catalog, software used by the federal government, or software designated critical under Executive Order 14028, per the NIST notice. The rationale was arithmetic. CVE submissions rose 263 percent between 2020 and 2025, NVD enriched roughly 42,000 CVEs during 2025 (about 45 percent more than any prior year) and still lost ground, and the program is bracing for 50,000 to 70,000 new CVEs across 2026 (Help Net Security, CSA research note). The most conservative standards body in the field decided linear catch-up was fantasy, drew a date line, and published the criteria for what still gets attention. That is the move most security programs need to make against their own backlogs, and it is the permission structure they now have to bring the same proposal to their auditor.

The physics of a stale patch queue

Every backlog past a certain size decays for structural reasons. Assets get decommissioned but never removed from inventory. Scanners disagree on hostnames, so a single vulnerable machine appears under three identifiers and is triaged three times. Severity only runs one direction, because "downgrade" is not a workflow anywhere in vulnerability management, so a CVSS 9.8 from 2023 that a compensating control neutralised is still catalogued at 9.8 today. Ownership drifts as teams reorganise, and nothing closes because no owner exists to close it against. Per the Edgescan 2026 vulnerability statistics report, 45.4 percent of enterprise vulnerabilities remain unresolved at twelve months, 17.4 percent of those high or critical, with high and critical MTTR of 54.81 days for application and API assets and 39 days for network and device. That is a data-structure problem before it is a program problem.

Per Plerion's field survey, roughly 90 percent of a mature backlog is non-exploitable in the actual environment, which turns the queue into a liability record everyone routes around. The Verizon 2026 DBIR confirms the working queue is not clearing either: across roughly 13,000 organisations, only 26 percent of CISA KEV entries were fully remediated and median time to full remediation climbed to 43 days. The pretence that the rest of the pile is actionable is doing damage.

Why the April 15 move is the template, not the numbers

Standards bodies do not usually publish their own retreat, which is why April 15 is useful. NIST wrote down what it would still cover, in what order, and by what criteria, on a schedule any observer can inspect. That transparency is the whole difference between bankruptcy and quiet deletion. An auditor reviewing the change cannot argue "you hid work you owed"; the criteria are on record, the deprioritised population is enumerated, and the enrichment rules are testable against any single CVE identifier.

A private program declaring backlog bankruptcy needs the same three artefacts at its own scale, and it needs them before the queue actually shrinks. The FAIR Institute's "Patching Faster Is Not the Answer" makes the case for a risk-informed reset, and the Plerion post above makes the case that the pile is mostly fiction. Neither writes down the governance-shaped how. That is the seam this piece lives on.

Five steps a governance function can sign

  1. Declare the reset with criteria on paper. Publish the boundary and the filters before touching any record, and get sign-off from the CISO, the audit lead, and one named business risk owner. The boundary is a date and a scope (say, "findings older than eighteen months on assets first observed before 2024"). The filters are the automatic keep-list mirroring the NIST posture: anything in the current CISA KEV catalogue, anything on an internet-reachable asset, anything on a system carrying regulated data. Nothing in those buckets is eligible for the reset.
  2. Validate every candidate against live inventory. Each record joins to the current asset identity graph. A finding on an asset inventory cannot confirm becomes an archival candidate; a finding on an asset inventory can confirm becomes a re-band candidate. The joins produce the list, so the program stops arguing about it in the abstract.
  3. Re-band the survivors by exposure. Score each survivor with the model the program will use going forward, whether that is CISA KEV plus internet-reachability plus a validated exploit path or another combination. The output is a small working list and a larger deferred list, each carrying an explicit reason on the record.
  4. Archive with evidence. No record is deleted. Each archived record carries a stamped rationale (which filter caught it, which inventory join failed, which validation returned negative) and a link back to the run that produced the decision. The archive is queryable so any future audit can walk the reset backwards.
  5. Sign, publish, and file inside the program. The three named parties sign the document on the day the archive is stamped, and the document is published so remediation, audit, and business owners see the queue changed and why. A one-page summary joins the system of record with dates, counts, and criteria.

The evidence package an auditor will accept

A backlog write-off is an evidence exercise, and three artefacts do the work. The criteria memo is one page: boundary, keep-list filters, sign-offs, date, the equivalent of what NIST published on April 15. The disposition ledger is one row per record, with disposition (kept, re-banded, archived), the rule that placed it there, and the inventory or validation reference that supports the placement, machine-generated and human-readable. The re-admission rules are written before the reset lands and run automatically against every incoming intelligence signal, so any archived record returns when its asset reappears in inventory, when its CVE enters KEV, or when BAS validation demonstrates the exploit path against the current environment. Nothing about re-admission depends on someone remembering.

Get the metaphor lineage right on the auditor call. Microsoft's Zero Bug Bounce, described by Raymond Chen, is a drive-to-zero release milestone, the opposite of a write-off. The bankruptcy metaphor comes from Lawrence Lessig's email bankruptcy (Sherry Turkle described the concept in 2002; Lessig used the word in 2004), and the agile-planning community's backlog bankruptcy, credited to Rob England. What is new here is synthesising those three into a governance shape a vulnerability program can defend to a regulator. The 2022 Rezilion / Ponemon study anchors the history: 634 practitioners, average backlogs of 1.1 million vulnerabilities, 66 percent carrying more than 100,000 open findings, 54 percent patching under half. Four years on, the ratios have only worsened.

What changes on day one after the reset

Three things become visible the morning the new queue goes live, and together they reset the trust deficit around the pile.

  1. Every queue item has an action, not a status. No more "under review, medium priority" hiding in the middle of the ledger. Each survivor carries a named owner, a next step, and a service-level clock (see SLA clock mechanics). Anything missing those three fields lives in a triage lane and is promoted or archived within a week.
  2. Exposure banding replaces severity. Findings are grouped by whether attackers are using the bug class now (KEV), whether the asset is reachable, and whether validation has run, not by a CVSS band alone. That is why exposure debt is a usable accounting unit and a severity count is not.
  3. Exceptions expire. Every risk acceptance carries a date, and when the date arrives the item returns automatically to the same triage everything else runs through. No exception is permanent by default, which is the entire difference between an exception and a resurrected backlog.

None of those three changes are inventions. What is new is that all three land together on reset day, because the disposition ledger, the re-admission rules, and the remediation operating model only make sense as a set.

The trust dividend when the queue stops lying

Remediation teams stop taking the queue seriously because the pile grows faster than their work reduces it, which makes ignoring the queue the professionally survivable move and, once cultural, outlasts any tooling investment. A published, defensible reset ends that story. When Monday's queue is smaller and every item carries an owner and a next step, teams re-engage because their work actually shrinks the pile again. The dividend arrives as SLA attainment before it shows up in raw vulnerability counts.

CVEasy AI's CTEM is the local-first control loop this procedure assumes, so the joins against live inventory, the exposure banding, and the re-admission rules run against the environment they describe. TRIS is how CVEasy ranks the small working queue that survives the reset.