A vulnerability backlog does not send an invoice, so most security teams never total up the cost of unpatched vulnerabilities sitting in it. The bill still arrives: in expected breach losses, in audit remediation letters, in the hours analysts burn re-triaging the same finding for the fourth month running, and in deals that stall because a questionnaire answer says “in progress” next to a critical CVE. None of those costs require guesswork to estimate responsibly. This piece walks through four cost buckets, a defensible way to size expected loss without inventing false precision, a method for quantifying the hours a backlog consumes, and how to turn all of it into a one-slide number finance will not argue with.
The four cost buckets a backlog actually taps
Before you can price a backlog, you need to know where the money leaves the building. Four buckets absorb nearly all of it, and they behave differently enough that lumping them into a single “risk” line item hides where the biggest gains are.
Breach expectancy
This is the bucket most conversations jump to, and the hardest one to defend if you present it as a single number. Breach expectancy is a probability-weighted loss: how likely a given class of finding is to be exploited in your environment, and what that exploitation would cost in incident response, downtime, notification, and contractual penalties. It moves with exposure, not with backlog age alone. A critical finding on an internet-facing asset with no compensating control has a materially different exploitation probability than the same CVE sitting on an internal host behind network segmentation. Treat this bucket as a distribution, not a point estimate.
Audit findings
Every open finding that overlaps a control tested during a SOC 2, ISO 27001, PCI DSS, or BDDK audit becomes a documented exception. Auditors rarely charge you for the finding itself. They charge you in remediation timelines, in re-audit fees when a fix is not verified before the assessment window closes, and in the qualified opinion that follows a repeat finding. If your findings are already mapped to specific controls through compliance mapping, you can pull this number directly instead of estimating it.
Operational drag
This is the least visible bucket and often the largest. Every open finding that sits past its SLA gets touched again as it moves back through the same stages of the vulnerability lifecycle: reassigned when an owner leaves, re-triaged when a scanner re-reports it, re-explained in the next steering committee. None of that work reduces risk. It is pure overhead generated by the backlog’s own existence, and it scales with age, not severity.
Deal friction
For any company selling into enterprise or regulated buyers, unresolved vulnerabilities surface in security questionnaires and vendor risk assessments. A backlog with aging criticals turns a two-week procurement cycle into a two-month one, or kills the deal outright when a buyer’s third-party risk policy carries a hard SLA threshold you cannot meet. Questionnaires increasingly ask for evidence of a running remediation process, not just a policy document. Programs that can point to a logged trail of discovery, triage, and retest, such as SITEY, give sales a concrete answer instead of a promise, which shortens exactly this kind of review.
Estimating expected loss without pretending to know the exact number
Security teams that try to produce a single breach-cost dollar figure usually get laughed out of the finance meeting, and rightly so. Nobody has that number with confidence. What you can defend is a range built on a simple, auditable formula: annualized loss expectancy (ALE) equals single loss expectancy (SLE) multiplied by annualized rate of occurrence (ARO). Apply it per finding class, not per CVE, because pricing thousands of individual CVEs is both impossible and unnecessary.
Group open findings into a small number of exposure classes: internet-facing critical with known exploit code available, internet-facing critical without known exploitation, internal critical on a segment with a lateral-movement path to a crown-jewel asset, and everything else. For each class, estimate SLE from your own incident history or from your cyber insurance underwriting questionnaire, which already forces a price on these scenarios. Estimate ARO from exploit availability, such as a CISA KEV listing or an EPSS score above a threshold you pick, for example 0.5, combined with your own compensating controls. Multiply, sum across classes, and present the total as a range with the assumptions attached, not as a single number with false precision. A CFO trusts a range with visible assumptions more than a point estimate with none.
Quantifying analyst and engineer hours consumed by an unmanaged backlog
Operational drag is the easiest bucket to measure and the one teams measure least. Pull three numbers from your ticketing system for the last quarter: the average number of times a finding is reassigned before it closes, the average number of times a closed finding reopens because the fix did not hold, and the average time an analyst spends re-validating a finding that a scanner re-reported without any real change in state.
Multiply each by a fully loaded hourly rate for the role involved (analyst, patch engineer, on-call engineer pulled into an unplanned change window) and you get a defensible operational cost per finding, independent of any breach scenario. This number tends to surprise people, because it does not require a breach to matter. It accrues whether or not anything is ever exploited.
The reopen and re-report categories are where most of the waste concentrates, because that work carries zero risk reduction. A retest step that actually re-validates the specific finding, rather than trusting a patch command’s exit code or waiting on the next full scanner sweep, is what collapses that number. Platforms that automate this phase, such as SITEY, re-test the exact finding right after a fix is applied instead of waiting for the next scheduled scan, which removes most of the reopen cycles this bucket is paying for.
Sales and procurement cost: the questionnaires you keep failing
If your company sells to other businesses, the backlog has a second customer: whoever fills out security questionnaires for prospects and renewals. Track two things over a quarter: how many questionnaire responses required a caveat or a promised remediation date because of an open finding, and how many deals had their close date pushed specifically because of a security review finding.
Attach a dollar figure using your own average deal size and your own cost of a month of sales cycle delay, with the interest on delayed revenue recognition as a reasonable proxy if you do not have a better one. This bucket is often the fastest way to get budget approved, because it speaks directly to revenue rather than to avoided loss, and revenue-facing arguments tend to move faster through a budget committee than risk-avoidance arguments do.
Building a defensible one-slide cost figure your finance team will accept
Combine the four buckets into a single slide with one row per bucket, a range instead of a point estimate for breach expectancy, and a cited source for every number. A structure that survives scrutiny looks roughly like this:
| Bucket | What it measures | Source of the number |
|---|---|---|
| Breach expectancy | ALE range across exposure classes | SLE from incident history or insurance underwriting; ARO from EPSS or KEV status |
| Audit findings | Cost of open findings mapped to failed controls | Compliance mapping plus the last audit’s remediation letter |
| Operational drag | Reassignment, reopen, and re-validation hours | Ticketing system export at a loaded hourly rate |
| Deal friction | Delayed or lost deals tied to questionnaire answers | CRM data and average deal size |
Do not average the four buckets into one number. Finance teams trust a broken-out figure because it shows the work and lets them challenge individual assumptions instead of the whole argument at once. A reporting layer that already rolls findings up by asset, control, and age turns this from a quarterly fire drill into an export you generate the morning of the meeting, which is the difference between a credible report and a rushed guess.
Use the number to request capacity, not to assign blame
The most common way this analysis gets wasted is turning it into an argument about whose fault the backlog is. That framing gets you a defensive engineering team and no budget. The useful framing is capacity: given this quarter’s intake rate and this quarter’s closure rate, the backlog grows by some number of findings per month, and each month of growth adds a roughly known amount to the four buckets combined.
State the ask as a rate problem, not a blame problem. If you close 40 findings a month against an intake of 65, closing that gap needs either more engineering hours each month or a change in how findings get triaged and assigned before they ever reach an engineer. Tie the ask to a specific mechanism, such as ownership-and-skill based routing through task management instead of manual assignment, or an approval gate that keeps low-risk findings from consuming senior engineer time. If a filtering step already screens out low-confidence duplicates before a human sees them, cite the before-and-after hours directly rather than describing the mechanism in the abstract.
Present the number once a quarter, on the same slide, with the same four buckets, so the trend becomes the argument rather than any single quarter’s total. A number that climbs two quarters in a row is a stronger capacity argument than any single large figure presented once and never revisited.
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.