Every engineering team has a list of known vulnerabilities that nobody has time to fix. The list is easy to ignore because nothing visibly breaks while it grows. That makes it hard to ask for time or budget to clear it. This guide shows how to put a defensible cost on the backlog using your own data, how to choose what to fix first, and how to present the case so a CEO or a board can decide.
The short answer
A backlog is not free to carry. It costs engineering time when someone investigates the same finding twice, deal time when a buyer asks about your open issues, audit time when the same items are flagged again, and risk when one of them is exploited. Count those costs with your own numbers, then compare them to the cost of fixing the items that matter most.
What a backlog costs
Most of the cost is indirect, which is why it goes unnoticed.
| Cost | How it shows up | How to find your number |
|---|---|---|
| Engineering interruptions | Developers re-read, re-triage and re-discuss the same findings | Ask a few engineers how much time findings take each month |
| Slower enterprise deals | Buyers ask about open vulnerabilities and age of fixes | Count deals where security review added delay |
| Repeat audit findings | An auditor or customer flags the same issues again | Check the last audit report for repeated items |
| Insurance and renewals | Questions about patching speed and unresolved issues | Read the last application you filled in |
| Breach exposure | A known flaw is exploited before it is fixed | Estimate with care, using your own data and counsel |
The last row carries the most uncertainty. Do not invent a breach probability. If you include it, state the assumptions plainly and let the reader adjust them.
Size it with your own data
Start with the work, not the risk. A simple estimate needs three numbers you already have or can sample:
- Open findings at the severity you plan to address, for example critical and high.
- Hours per fix, from first look to merged change. Sample ten recent fixes rather than guessing.
- Loaded hourly cost of an engineer, from your finance team.
Multiply them. The result is the cost of paying the backlog down.
A worked illustration, with made-up round numbers to show the method and not to describe any company: 300 open high and critical findings at 2 hours each is 600 hours. At a loaded cost of $100 an hour, that is $60,000. Replace each number with yours before showing anyone. If automation or a better process cuts the hours per fix, the same arithmetic shows the saving.
Then add what the backlog is already costing you each month: hours spent re-triaging, and deals delayed. Compare both columns.
Decide what to fix first
You do not have to fix everything, and trying to will stall the whole effort. Rank by the chance and consequence of harm:
- Known to be exploited. Check whether a finding appears in a catalog of actively exploited vulnerabilities, such as the CISA Known Exploited Vulnerabilities list. These go first.
- Exposed to the internet. A flaw on a public endpoint matters more than the same flaw in an internal tool.
- Reachable. A vulnerable library that your code never calls is lower priority than one it uses on every request.
- Touching sensitive data. Authentication, payments and customer records raise the stakes.
- Cheap to fix. Dependency upgrades with no breaking change are quick wins that reduce the count.
Findings that fail every test can wait, be accepted in writing with an owner and a review date, or be closed as not applicable.
Ways to pay it down
| Approach | Strength | Weakness |
|---|---|---|
| Reserve a share of each sprint | Steady, low disruption | Easy to cut when deadlines press |
| A rotating owner each sprint | Spreads knowledge | Quality varies between people |
| A short, focused push | Clears the worst quickly | Pulls people off other work, and the backlog regrows |
| Automated fixes reviewed by engineers | Reduces hands-on time per fix | Only as good as the fixes; measure how many are merged |
Most teams combine two: a standing allowance for ongoing work, and automation for repetitive classes such as dependency upgrades. How automation changes the work, and how to measure it, is covered in the security remediation gap.
Present it to a CEO or board
Keep it to one page.
- The ask. State it plainly: "We want two engineers for six weeks," or "We want to add automated fix pull requests on these repositories."
- The cost today. Your own figures for hours, delayed deals and repeat findings.
- The cost of the plan. Hours or money, and what you will not do instead.
- The result. What changes, and how you will measure it: older critical findings closed, time to fix, fewer repeat findings.
- The risk you are accepting. What stays open, and who signed off on it.
Boards respond to trends and decisions. A chart of critical findings by age tells them more than a total count.
Mistakes to avoid
- Aiming for zero. A backlog of zero is not a realistic or useful goal. Aim for no old critical findings and a falling trend.
- Counting findings as progress. A scanner can add a thousand items overnight. Count fixes.
- Treating every severity label as urgency. Reachability and exposure change the real priority.
- Fixing without a closing definition. Decide whether "fixed" means merged, released or confirmed. Report them separately.
- Hiding accepted risk. An item left open on purpose should have a name and a date next to it.
What to measure
- Critical and high findings by age. The shape matters more than the total.
- Median and 90th percentile time to fix. Averages hide the long tail.
- Hours per fix. The main lever on the cost of paying down the backlog.
- Findings closed per month against findings opened. If opened exceeds closed, the backlog is still growing.
A 90-day plan
- Days 1 to 15. Export the open findings. Remove duplicates and anything clearly not applicable. Measure hours per fix on ten recent items.
- Days 16 to 30. Rank by the criteria above. Write the one-page case and agree the target.
- Days 31 to 75. Work the top tier. Track age, time to fix and hours per fix weekly.
- Days 76 to 90. Compare with the starting numbers. Decide whether to keep the allowance, expand automation or stop.
Frequently asked questions
How do we justify the work if nothing has gone wrong? Use the costs you can already see: re-triage time, delayed deals and repeat audit findings. They are real even without an incident.
Should we hire a security person or buy tooling? It depends on what is slow. If findings are not being found, tooling helps. If they are found but not fixed, you need ownership and engineering time, with automation to lower the effort per fix.
Is it acceptable to leave low-severity findings open? Often yes, if the decision is written down with an owner and a review date.
What if we cannot estimate hours per fix? Sample ten recently closed findings and take the median. A rough number with a stated method beats none.
How do we know automated fixes are worth it? Run them on a few repositories for a fixed period and measure how many are merged and how many hours they save. Evaluate on your own code before expanding.
This guide is general guidance. The worked example uses illustrative numbers and is not a benchmark.