You will never reach zero findings, and a programme that pretends otherwise slowly loses credibility. Scanners, audits, penetration tests and threat models all generate work faster than any team remediates it. The mature response is not to hide the gap but to manage it as a portfolio.
Where the debt comes from
- Vulnerability scans, continuously.
- Audit and assessment findings.
- Penetration test and purple team results.
- Architectural compromises made under deadline pressure.
- Inherited estate from acquisitions.
- Deprecated technology that works and nobody will fund replacing.
The failure mode is backlog bankruptcy: the list grows so large that nobody can navigate it, so nobody looks at it, so genuinely urgent items sit alongside trivia for months. At that point the backlog is actively harmful - it creates the appearance of tracking while guaranteeing nothing gets tracked.
Triage on two axes, not one
Severity alone produces a queue ordered by theory. Combine it with:
- Exploitability - is this actively exploited, is it reachable from outside, is there a public exploit?
- Asset criticality from your business impact analysis.
- Effort, banded roughly. A one-hour fix on a medium finding often beats a two-month fix on a high one for total risk reduced per week.
- Recurrence - does this class of issue keep reappearing? That points at a systemic fix worth more than the individual items.
Accept explicitly, or it accepts itself
The most important discipline: anything you are not going to fix should be explicitly accepted with a named owner, a reason, a compensating control and a review date - not left ageing silently in a backlog.
An untriaged backlog is not risk acceptance. It is risk acceptance without anyone deciding, without anyone accountable, and without any record. Auditors treat the two very differently, and so should you.
Track findings, owners and acceptances in one place
GRC Copilot tracks findings against the controls they affect, with owners, due dates and the evidence of closure your auditors ask for.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Age is a signal
Track how long items have been open by severity. Rising age on high-severity items means your intake exceeds your capacity, which is a resourcing conversation rather than a prioritisation one - and it is far more persuasive to leadership expressed as a trend than as a list.
Set a policy: anything above a defined age either gets fixed, gets formally accepted, or gets escalated. Nothing simply persists.
Fix classes, not instances
Forty instances of the same misconfiguration is one problem. Remediating each one individually guarantees it returns with the next deployment. The durable fix is the golden image, the pipeline check, the policy guardrail - and it converts a recurring backlog item into a closed one.
Reporting it honestly
Leadership does not need the list. They need: what is outside our stated risk tolerance, what is the trend, what is blocked on funding or a decision, and what would change if we resourced it differently. Presenting a raw count of open findings invites the wrong conversation - the number always looks alarming and never actionable.
Frequently asked questions
Is a growing backlog always bad?
Not necessarily - better scanning coverage increases intake. What matters is the age and severity distribution, not the raw count.
Can we just close old low-severity findings?
Only as an explicit, documented acceptance decision with an owner. Silent deletion is what auditors object to.
How do we stop recurrence?
Fix the class - image, pipeline check or policy guardrail - rather than the instances.
What do auditors expect?
A triage process, evidence that severity drives timelines, and documented acceptance for what is not being fixed.
Key takeaways
- Zero findings is not the goal; managed debt is.
- An untriaged backlog is acceptance with nobody accountable.
- Track age by severity - rising age is a resourcing signal.
- Fix classes rather than instances, or they return.