Security debt behaves like technical debt and compounds the same way
Most technology leaders understand technical debt well enough to have a plan for managing it. They know it accumulates, they know it slows them down, and they have at least a mental model of what it would cost to clear it.
Security debt is less well understood, and that asymmetry is dangerous. Because security debt does not behave like technical debt. It compounds differently. It is harder to quantify. And a single unaddressed vulnerability can produce a catastrophic rather than a gradual failure.
What security debt actually is
Security debt is the accumulated shortfall between the security posture your organisation should have and the one it actually has. It includes unpatched systems, unsupported software, missing controls, inadequate access management, undocumented integrations, and architectural decisions that prioritised delivery speed over defence in depth.
Like technical debt, it accumulates when short-term decisions are made without accounting for their long-term security cost. Unlike technical debt, it does not just slow you down. It creates the conditions for a breach.
Why you cannot patch your way out
Patching vulnerabilities is necessary. It is not sufficient. Organisations that treat security as a patching function are managing symptoms rather than debt. The underlying security architecture (access controls, network segmentation, logging and detection, incident response capability) is either sound or it is not. Patching an application running in an architecture with insufficient segmentation does not eliminate the risk that vulnerability represents. It just removes one vector.
The organisations that have the most significant security debt are frequently the ones with the most active patching programmes, because they have confused activity with posture.
Quantifying security debt
Start with a control gap analysis against a recognised framework: NIST CSF, ISO 27001, or CIS Controls, depending on your regulatory context. This gives you a structured view of where your controls are absent, partial, or not validated.
Map those gaps to your critical business processes and data assets. The combination of control gap and business impact gives you a risk-weighted view of your security debt that is far more useful for prioritisation than a flat vulnerability list.
Then build a remediation roadmap that treats security as a capability you are building, not a list of tickets you are clearing. The distinction matters for how you communicate to the board, how you budget for it, and how you know when you are actually making progress.
The question every CTO should be able to answer
If your most critical system were breached tomorrow, how long would it take you to detect it, contain it, and recover from it? If the answer is uncomfortable, that discomfort is your security debt speaking.