# Vulnerability Backlog Burn-Down Calculator

> Source: https://netray.co/tools/vulnerability-backlog-burn-down-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Model open findings against remediation capacity to see when the backlog clears and how many people you need to hit a target date.

## Category

erp-operations

## Industry

Manufacturing

## Audience

- IT security lead
- Vulnerability manager
- IT manager

## Tool

**Kind:** calculator

**Inputs:**

#### Open vulnerabilities in scope

**Key:** backlog

**Type:** number

**Default:** 1800

**Min:** 0

**Step:** 50

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

#### New findings per month

**Key:** new_month

**Type:** number

**Default:** 220

**Min:** 0

**Step:** 10

#### Fixes per engineer per month

**Key:** fix_rate

**Type:** number

**Default:** 45

**Min:** 1

**Step:** 1

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

#### Engineers on remediation

**Key:** engineers

**Type:** slider

**Default:** 4

**Min:** 1

**Max:** 12

**Step:** 1

#### Target to clear backlog

**Key:** target_months

**Type:** number

**Default:** 9

**Min:** 1

**Step:** 1

**Unit:** months

**Outputs:**

#### Monthly fix capacity

**Key:** capacity

**Expr:** fix_rate * engineers

**Format:** number

#### Net backlog reduction per month

**Key:** net_burn

**Expr:** capacity - new_month

**Format:** number

**Primary:** true

**Description:** Zero or negative means the backlog is not shrinking.

#### Months to clear (0 if never)

**Key:** months_to_clear

**Expr:** if(gt(net_burn, 0), backlog / net_burn, 0)

**Format:** months

**Primary:** true

#### Engineers needed for the target date

**Key:** needed

**Expr:** ceil((backlog / target_months + new_month) / fix_rate)

**Format:** integer

#### Backlog after 12 months at current staffing

**Key:** backlog_12

**Expr:** max(backlog - net_burn * 12, 0)

**Format:** number

**Chart:**

#### Backlog after 12 months vs engineers

**Type:** bar

**X:** engineers

**From:** 1

**To:** 12

**Steps:** 12

**Series:**

- backlog_12

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

## Content

**Intro:** 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.

**Sections:**

#### How to use it

**Body:** 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.

**Bullets:**

- 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

**Body:** 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

**Body:** 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

**Body:** 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.

**Cta:** 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.

**Faq:**

#### Should I include low severity findings?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

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

## Search terms

vulnerability backlog calculator, vulnerability remediation capacity planning, burn down rate vulnerabilities, how many security engineers do I need, vulnerability management metrics, remediation sla capacity, security backlog forecast

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json