Technical Debt Risk Calculator

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.

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.

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.

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.

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.