A useful security debt register has one row per weakness and a handful of fields: what it is, what it exposes, how likely it is to matter, what fixing costs, who owns it, and when you will look again. Anything beyond that tends to go stale. The register exists to support decisions, not to be a museum.
Decide what counts as debt
Not every finding is debt. A defect you plan to fix this sprint is a ticket. Debt is a known weakness you have consciously chosen to carry, or one you found and have not yet scheduled. The distinction matters because debt needs a review rhythm and an owner, while tickets need only a sprint.
Write that definition at the top of the register so contributors apply it the same way.
The fields that earn their place
- Title and description. One sentence in plain words: "Admin API accepts long-lived tokens that are never rotated."
- What it exposes. The asset or data at risk, in terms a product owner understands.
- Likelihood and impact. A coarse low, medium, high for each is enough. False precision invites argument.
- Cost to fix. A rough size, using the same units as your sprint planning.
- Interest. Does the problem get worse over time? A deprecated library grows harder to replace each release. A missing alert does not.
- Owner. A person, not a team name.
- Next review date. The one field most registers lack, and the reason many go dead.
- Decision. Fix by a date, accept until a date, or monitor, with who decided.
Interest is the useful idea
Financial debt has interest, and so does security debt. Some items cost nothing extra to carry for a year. Others compound: the longer you leave a major version behind, the larger the jump, and the fewer people remember how the old code works.
Recording whether an item accrues interest is the fastest way to sort the register. High interest items get scheduled first even when their immediate risk looks similar to a static one.
Keep it where the work happens
Put the register in the same tool as your tickets, using a label or a dedicated type. Each row links to the ticket or pull request that will resolve it. A spreadsheet in a drive nobody opens will be accurate on day one and wrong by day sixty.
For how to present the contents upward, see how to explain security debt to executives.
Review on a schedule
Hold a short review monthly or quarterly. For each item whose review date has passed, answer three questions: is it still true, has the risk changed, and is the decision still right? Retire entries that no longer apply and say so. A register that only grows signals that nobody is reading it.
Sources of entries
Entries come from pentests, scan results, incident follow-ups, audit observations, and engineers who say "we know that is bad." Make it easy to add the last kind. Those candid comments are often the most accurate view of where the risk really sits.
Quick check
What is the most commonly missing field?
The next review date. Without it, accepted risks are never revisited and the register decays.
Should every scanner finding be in the register?
No. Findings you will fix soon are tickets. The register is for weaknesses you carry knowingly or have not yet scheduled.
Last reviewed: 19 October 2026.
