Security debt: the quiet risk on the balance sheet

A list is not a liability

Every organization we assessed had a list of known weaknesses. The median list ran to more than 1,400 items. What almost none had was a way to say how much risk the list represented in total, whether it was growing or shrinking, and who was responsible for bringing it down. A list of 1,400 items does not get discussed by a board. A liability with a number does.

How the interest compounds

A weakness left open does not stay the same size. The software around it moves on, so the eventual fix touches more. The people who understood the system leave. The vendor ends support, and a simple patch becomes an upgrade project. Meanwhile the weakness becomes better known to attackers, and the tools that exploit it become cheaper.

3.4xHow much more it cost to fix a weakness after twelve months than within 30 days, across the assessments we analyzed.

Compensating controls, the firewall rule or extra monitoring added instead of a fix, are the minimum payments of security debt. They keep the account in good standing but do not reduce the balance, and each one adds to what the operations team must remember.

“We were paying interest on decisions nobody remembered making. Once we put a number on it, the conversation with the board changed in a single meeting.”

Measuring the debt

We score each known weakness on three things: how severe it is, how exposed the system is, and how long it has been open. Multiplied together and summed across the estate, they give a single figure that can be tracked month by month. It is not a prediction of loss. It is a measure of how much risk is being carried, and whether it is going up or down.

The figure is lopsided. In the median estate, 11% of weaknesses accounted for 80% of the score. Most were on internet-facing systems, and many were on components past their vendor's end of support. That is good news: a small, well-chosen effort removes most of the exposure.

Paying it down

The organizations that reduced their debt fastest did not run large one-off programs. They set aside a fixed share of engineering capacity, typically 10 to 15%, for repayment every sprint, and they stopped adding new debt by making security fixes part of the definition of done.

• Make an inventory of every system, its owner and its exposure to the internet.
• Score the debt and report it monthly, by system and by owner.
• Repay the most exposed 11% first, starting with anything past end of support.
• Reserve a fixed share of every team's capacity for repayment.
• Stop new borrowing: no release ships with a known critical weakness.

Security debt will never reach zero, and it does not have to. The aim is a balance that is known, owned and falling, in the same way a sensible business manages any other liability.