Skip to content
ENExplore Calculators

Technical Debt Risk Calculator

Score the security risk carried by end-of-life systems, unsupported versions, long-unpatched hosts, legacy code and thin test coverage.

About Technical Debt Risk Calculator

The two heaviest terms are the ones that cannot be fixed by patching: end-of-support systems have no patch to apply, and long-unpatched systems have one that nobody dares deploy. Test coverage appears in the model inverted because the real reason patches sit undeployed is usually fear of regression, not ignorance of the vulnerability. Technical debt is the reason a patching programme plateaus — beyond a certain share of end-of-life systems, no amount of vulnerability management improves the numbers, and the answer becomes a replacement budget.

Formulas

Technical Debt Risk

Risk = 0.30 × end-of-support share + 0.25 × long-unpatched share + 0.15 × unsupported-component share + 0.15 × unmaintained-code share + 0.15 × (100 − test coverage), all as percentages.

end-of-support share
Systems receiving no vendor patches
long-unpatched share
Systems carrying findings older than 90 days
unmaintained code
Code with no active owner
100 − test coverage
Change risk that makes teams avoid patching

Patchability

Ability to patch safely = 0.6 × test coverage + 0.4 × maintained-code share, graded A–F. It predicts how fast the team can ship a patch without causing an incident.

Worked example

With the default values below, Technical Debt Risk Calculator returns Technical Debt Risk Score of 18.9. Change any input above and every figure here is recalculated in your browser.

Inputs used

Systems in scopeaccepts 1–1,000,000 systems
320 systems
Systems past end of supportaccepts 0–1,000,000 systems
22 systems
Components on an unsupported versionaccepts 0–1,000,000 components
14 components
Systems with findings open over 90 daysaccepts 0–1,000,000 systems
48 systems
Codebase with no active maintaineraccepts 0–100 %
35 %
Automated test coverageaccepts 0–100 %
52 %

Results

Technical Debt Risk Score
18.9 / 100
Risk Band
Informational
End-of-Support Share
6.9%
Long-Unpatched Share
15.0%
Ability to Patch Safely
D — Weak
Biggest Driver
Thin test coverage — the team cannot patch quickly without breaking things

Step by step

  1. 1Values used
  2. 2Technical Debt Risk
  3. 3Patchability
  4. 4Technical Debt Risk Score= 18.9 / 100
  5. 5Risk Band= Informational
  6. 6End-of-Support Share= 6.9
  7. 7Long-Unpatched Share= 15.0
  8. 8Ability to Patch Safely= D — Weak
  9. 9Biggest Driver= Thin test coverage — the team cannot patch quickly without breaking things

Assumptions and limits

  • The result is derived only from the 6 inputs listed above. Anything not among them is not part of the calculation.
  • In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
  • Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is Technical Debt Risk calculated?

Risk = 0.30 × end-of-support share + 0.25 × long-unpatched share + 0.15 × unsupported-component share + 0.15 × unmaintained-code share + 0.15 × (100 − test coverage), all as percentages. The two heaviest terms are the ones that cannot be fixed by patching: end-of-support systems have no patch to apply, and long-unpatched systems have one that nobody dares deploy. Test coverage appears in the model inverted because the real reason patches sit undeployed is usually fear of regression, not ignorance of the vulnerability.

Why does Technical Debt Risk matter?

Technical debt is the reason a patching programme plateaus — beyond a certain share of end-of-life systems, no amount of vulnerability management improves the numbers, and the answer becomes a replacement budget.

What values do I need to enter?

This calculator takes 6 inputs: Systems in scope, Systems past end of support, Components on an unsupported version, Systems with findings open over 90 days, Codebase with no active maintainer, Automated test coverage. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why is end-of-life weighted highest?

Because it caps what vulnerability management can achieve. A system with no vendor support accumulates unfixable findings indefinitely, so its risk grows monotonically until it is replaced, isolated or accepted in writing.

How does test coverage belong in a security metric?

Because it determines patch velocity. Teams with good automated tests deploy a security patch in hours; teams without them wait for a manual regression cycle, which is how a seven-day SLA turns into six weeks.

Related Calculators

Technical Debt Risk Calculator | Calcrivo