ERP OperationsFree calculatorPDF, Excel, Word exportManufacturing

Vulnerability Backlog Burn-Down Calculator

A backlog only shrinks when fixes outpace new findings. This calculator makes that arithmetic explicit, so you can answer the question leadership always asks: how long, and how many people.

Your numbers

Findings that must be fixed, after de-duplicating and removing accepted risks.

Count remediation tickets closed, not scanner rows. Many findings share one fix.

4
months

Your results

Net backlog reduction per month
-40
Zero or negative means the backlog is not shrinking.
Months to clear (0 if never)
0 months
Monthly fix capacity
180
Engineers needed for the target date
10
Backlog after 12 months at current staffing
2,280

Assumes steady inflow and capacity. Real backlogs change with scanner coverage, patch releases and competing projects.

Save results:

Backlog after 12 months vs engineers

Sweeps Engineers on remediation from 1 to 12, holding your other inputs fixed.

Remediation planning review

Optional review of your remediation capacity model.

Optional. The tool and every export work without this. No spam.

How to use it

Enter the open findings you intend to fix, the monthly inflow, and how many remediation items one engineer closes in a month. Use closed tickets, because one patch or configuration change often clears hundreds of scanner rows. Set the headcount and the date leadership wants. The result shows net monthly burn, months to clear and the staffing needed to hit the date.

  • Group findings by fix before counting.
  • Remove accepted or compensated risks so they do not distort the number.
  • Use the previous quarter to calibrate fixes per engineer.

The formulas

Capacity equals fixes per engineer times engineers. Net burn equals capacity minus new findings. If net burn is positive, months to clear equals the backlog divided by net burn. To meet a target date, required capacity equals backlog divided by months plus the monthly inflow, and engineers needed is that capacity divided by fixes per engineer, rounded up.

Reading the result

If net burn is zero or negative, the clear date is shown as zero because the backlog never clears at that staffing. In that case the useful number is the engineers needed line. Notice that inflow matters as much as headcount: reducing new findings through hardening baselines, golden images and automatic updates can free more capacity than hiring.

Common mistakes

Treating every finding as equal is the main trap. Prioritize by exploitability and asset criticality, and run this calculator for critical findings separately from the long tail. Another mistake is assuming engineers spend all of their time on fixes when change windows, approvals and production constraints cap what plants allow in a month.

Frequently Asked Questions

Should I include low severity findings?

Model them separately. Running critical and high findings alone gives a clear target, while the long tail of low items can be handled through baselines and patch rollups.

How do I estimate fixes per engineer?

Take tickets closed in the last three months divided by engineer-months spent. Adjust for planned changes such as a new patching tool.

Why does the result show zero months?

It means net burn is not positive, so the backlog does not clear at current staffing. Increase engineers, raise throughput, or reduce inflow.

Does this work for OT findings?

Yes, with a much lower fixes per engineer figure, because OT changes need vendor validation and outage windows. Run OT as its own scenario.

If scanner output, asset data and ERP ownership are in different systems, Netray can help join them privately so findings route to the right owner.