A vulnerability management program that reports “14,320 open findings” every month is reporting a number, not a trend. Backlog size by itself tells a CISO nothing about whether the program is improving, treading water, or losing ground. The only way to answer that question is to compare how fast new findings arrive against how fast existing ones get closed, and to project that ratio forward. This piece walks through the mechanics: which ratio to track, how to calculate a net burn rate, how to build aging cohorts that expose backlog that will never clear on its own, and how to turn the resulting data into a capacity request leadership will actually approve.
Why backlog size alone is a useless headline number
Raw backlog count moves for reasons that have nothing to do with team performance. A new scanner added to the pipeline, a fresh subnet brought into asset inventory, or a scan engine upgrading its plugin set can add thousands of findings in a single week without a single new vulnerability existing in the environment before that week. Conversely, a quiet week with no new scans can make the backlog look flat even though the team closed zero tickets. Reporting the count alone conflates discovery activity with remediation activity, and leadership has no way to tell which one moved.
A backlog number is also silent on severity mix. Ten thousand informational-severity misconfigurations on end-of-life lab hosts is a different risk posture than three thousand findings that include a handful of exploitable, internet-facing critical vulnerabilities. Any burndown program has to split by severity and by exposure, internet-facing versus internal, before the headline number means anything. Track separate backlog counts for critical, high, medium, and low severity, and treat each as its own burndown problem with its own SLA, because a blended average hides the segment that actually drives breach risk.
Discovery rate vs closure rate: the only ratio that predicts whether you are winning
The metric that actually predicts direction is the ratio between new findings opened in a period and findings closed in that same period. Define it over a trailing window, not a single day or a single scan cycle, because scan cadence is lumpy: a monthly authenticated scan against a large subnet can add hundreds of findings on one Tuesday and none for the following three weeks.
Use a trailing four-week window and calculate:
Burn ratio = Closures in period / New findings in period
A ratio above 1.0 means the team is closing more than it is discovering and the backlog is shrinking. A ratio below 1.0 means the backlog is growing even if the raw count of tickets closed each week looks respectable. A ratio sitting at exactly 1.0 for months is a stable backlog, not a healthy one: it means the team never regains the capacity to work down the pre-existing pile, so aged findings simply accumulate underneath the churn of new ones.
Calculate this ratio separately for critical and high severity findings. A program can carry a burn ratio of 1.3 overall while running at 0.6 for criticals alone, because most of the closure volume comes from clearing easy low-severity findings. A blended dashboard that shows one ratio for the whole backlog routinely hides this exact failure mode. Computing the ratio from live scan and remediation events rather than a monthly spreadsheet pull catches the shift within days instead of within a quarter.
Calculating net burn per week and projecting the zero date
Once the ratio is tracked, convert it into an absolute number: net burn per week, meaning closures minus new findings. If a team closes 180 findings a week and 140 new findings arrive, net burn is positive 40 per week.
Divide the current backlog by the trailing average net burn to get a projected zero date:
Weeks to zero = Current backlog / Average weekly net burn
Worked example: a backlog of 3,200 critical and high findings, with a trailing eight-week average net burn of 45 per week, projects to roughly 71 weeks to zero, holding current staffing and discovery rate constant. That number is the one worth putting in front of leadership, not the backlog count itself, because it converts an abstract pile of tickets into a date on a calendar.
Two caveats keep this projection honest. A linear projection assumes discovery rate stays flat, which it will not once new asset classes, new scanners, or a new compliance mandate widen scan scope, so recompute it every reporting cycle rather than treating one number as fixed truth. Net burn concentrated in low-severity findings also produces a flattering zero date with almost no effect on actual risk; always run the projection per severity tier and treat the critical-tier date as the one that matters.
Cohort views: aging buckets that reveal which backlog will never be cleared
A single zero-date projection hides a structural problem: some findings are not aging toward closure, they are aging toward permanence. Break the backlog into age cohorts, measured from first-detected date to today:
- 0 to 30 days: fresh findings still inside a normal triage and remediation cycle
- 31 to 90 days: findings that missed a first-pass fix window and need an owner check
- 91 to 180 days: findings where the original fix attempt likely failed or was deprioritized
- 181 to 365 days: findings that have survived at least one full patch and audit cycle unresolved
- 365+ days: findings that are, in practice, permanent unless a process change forces action
Plot the count in each bucket over time rather than as a single snapshot. A healthy program shows the 0 to 30 bucket carrying most of the volume and each older bucket shrinking. A program in trouble shows the 365+ bucket growing every quarter: that bucket is inherited by whoever holds the ticket queue next, and it will not close through the same triage process that handles fresh findings. Findings that cross the 180 day mark without a documented reason, a compensating control, an accepted risk, a scheduled decommission, should trigger an escalation to the asset owner’s manager.
Segment cohorts by owning team as well as by age. A backlog where one team’s assets consistently populate the 365+ bucket points to a resourcing or ownership gap that a blended organizational metric will never surface.
Deciding what to bulk-accept, bulk-compensate, or archive before you start
Before a team commits engineering hours to a burndown push, separate the backlog into what should actually be fixed versus what should be formally dispositioned some other way. Working every finding as if it needs a code or configuration change wastes the exact capacity the burndown depends on.
Bulk-accept candidates
Findings on assets scheduled for decommission within the next remediation cycle, findings that require a vendor patch with no available release date, and low-severity findings on isolated, non-internet-facing hosts are reasonable risk-acceptance candidates. Document the acceptance with an expiry date and an owner; an acceptance with no review date is a permanent exception in disguise.
Bulk-compensate candidates
A finding with a compensating control, a WAF rule blocking the specific exploit path, network segmentation removing exposure, or an EDR detection rule covering the technique, can be marked mitigated rather than left open indefinitely or force-fixed on an unrealistic timeline. The control has to be verified as actually deployed and functioning, not assumed from a firewall policy that was written but never confirmed active.
Archive candidates
Duplicate findings from multiple scanners flagging the same underlying flaw, and findings on assets that no longer exist in the environment, belong in an archive path, not the active backlog. This is where deduplication quality matters most: if the same CVE on the same host shows up as three separate tickets because three scanners reported it independently, the backlog looks three times larger than the real remediation workload. Platforms that correlate and deduplicate findings across multiple scanner feeds before they ever reach a human queue, such as SITEY, keep the active backlog count honest and stop teams from spending fix cycles on tickets that are really the same underlying flaw reported twice. Check the deduplication logic against the specific scanners in your stack, a network scanner and a container image scanner reporting the same base OS package vulnerability need to be recognized as one finding, not two, before trusting any burndown number built on top of it. This kind of correlation work happens inside vulnerability lifecycle tracking, and the classification that decides which findings actually warrant a fix versus a bulk disposition sits in AI triage.
Presenting burndown to leadership so extra capacity requests land
A capacity request that leads with “we have 8,000 open vulnerabilities” invites the response “prioritize better,” because the number alone gives no evidence that prioritization is the problem. A capacity request that leads with the burn ratio, the projected zero date, and the aging cohort trend gives leadership something they can act on with a budget line.
Structure the presentation around three numbers, each tracked over the trailing two to three quarters so the trend is visible rather than a single snapshot: the burn ratio for critical and high severity findings, the projected zero date at current staffing, and the count of findings in the 180+ day cohort. Follow with the specific ask: “adding two remediation engineers moves the critical zero date from month fourteen to month six, and cuts the 180+ day cohort roughly in half within two quarters.” That framing ties a headcount or tooling request directly to a date leadership can hold the team to, which is a far stronger position than an open-ended request to “reduce the backlog.”
Pair the burndown numbers with evidence that closures are real, not just status changes in a ticketing system. A finding marked “fixed” that was never re-scanned against the original vulnerable condition is a status update, not a remediation. Automated re-testing against the specific check that flagged the finding, the kind of validation that closes the loop instead of trusting a patch command’s exit code, such as the re-test step built into SITEY’s retest and closure phase, is what turns a burndown chart from an optimistic narrative into an auditable one. When a compliance framework sets a fixed remediation SLA, PCI DSS’s requirement to remediate critical vulnerabilities within a defined window is a common example, tie the aging cohort thresholds directly to that SLA clock inside compliance mapping so a missed SLA shows up as a flagged cohort automatically instead of surfacing during an audit.
Keep the burndown dashboard close to the systems that generate the underlying data. A burndown built from a monthly CSV export drifts from reality within days, because new findings keep arriving from active scans and closures keep landing from patch cycles in between exports. A ratio and cohort view that recalculates from the live pipeline, rather than a periodic manual pull, is what makes the projected zero date credible enough to fund.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.