Technical debt gets deferred for a reasonable-sounding reason almost every time: nothing is on fire yet. The problem is that debt of this kind does not stay flat while it waits. It compounds, and by the time it causes a visible incident, the fix is usually larger and more disruptive than it would have been a year earlier.
The scale of this is easy to underestimate. A McKinsey survey of technology leaders found that organisations typically divert 10 to 20 per cent of the budget meant for new work into resolving problems caused by existing technical debt, and separately estimated that unresolved technical debt can represent 20 to 40 per cent of the value of an entire technology estate. Close to half of surveyed organisations named technical debt as a primary driver of technology overspending. This is not a small, ignorable line item — it is a recurring tax on every other initiative an IT budget is meant to fund.
Security debt is the sharpest version of this because the cost of deferral is not just financial inefficiency, it is exposure. A control that was reasonable to postpone when it was first identified does not become less necessary while it waits — it sits there as a live gap, and the businesses that eventually experience an incident tied to that gap are the ones who find out what it would have cost to fix proactively versus reactively. The ACSC's reporting on rising average incident costs is one data point on that gap; the deferred backlog itself, sitting unmeasured in most environments, is the bigger and less visible one.
The reason this keeps happening is structural rather than a failure of judgement: deferred work competes for attention against work that has a deadline, and technical debt rarely has one until it becomes an incident. Fixing that requires making the backlog visible and owned, not just identified. A risk sitting in a spreadsheet from an assessment eighteen months ago is not a managed backlog — it is a forgotten recommendation with a date on it.
A managed backlog looks different in practice: material risks are tracked, prioritised against real impact rather than however loudly they were raised, and worked through on a cadence — reported to leadership as progress, not resurfaced as a surprise finding in next year's audit. The difference is not the existence of a list. It is whether anything happens to the items on it every month, whether or not this month happened to be quiet.
All technical perspectives