How to prioritise vulnerabilities when you have a backlog of unprocessed reports
By Kike Gandia · Co-Founder & CEO, OSCP
An unprioritised vulnerability backlog is one of the most silent risks in security management. The company believes it is managing the situation because the reports are logged, but in reality there may be a critical vulnerability waiting in the queue behind 30 low-severity reports. The backlog needs an urgent prioritisation process, not just more time.
Why the backlog accumulates
The most common causes of unprocessed report accumulation:
- Lack of resources: the security team has more tasks than time.
- Absence of process: reports arrive but there is no clear flow of who processes them and when.
- Incomplete coverage: triage only works during office hours and weekend reports wait until Monday.
- Fear of volume: when the backlog grows, the team avoids it instead of tackling it with judgment.
The first step is to recognise that the backlog is an active risk, not just technical debt.
Methodology for tackling a backlog in 3 phases
Phase 1 — Quick classification (1-2 days):
Review all pending reports and classify them into four categories without going into technical detail: possibly critical, possibly high, possibly medium/low, clearly out of scope or duplicate. This requires 5-10 minutes per report.
Phase 2 — Validation by criticality (1 week):
Start with reports classified as possibly critical. Reproduce the attack, confirm the impact and escalate those confirmed as critical immediately. Only when you have processed all the possibly critical ones should you move on to the high ones.
Phase 3 — Systematic processing:
Once the critical and high reports are processed, establish a processing rhythm for the rest: X reports per day until the queue is empty.
Prioritisation criteria beyond CVSS
The base CVSS score is a starting point, not the definitive criterion. Factors that should inform prioritisation:
- Exposure: is the affected system exposed to the internet or internal?
- Data processed: are personal, financial or health data at stake?
- EPSS: is this vulnerability actively exploited in the wild?
- Compensating controls: are there WAF, monitoring or other controls that reduce the real risk?
- Business context: is it a critical system for company operations?
A vulnerability with CVSS 7.0 on an internal server without sensitive data can wait. The same vulnerability on your payments API needs immediate attention.
How to prevent the backlog from growing again
Tackling the current backlog does not solve the structural problem. To prevent it from growing again:
- Establish triage SLAs: each report must have a maximum processing time according to its initial classification.
- Define a process owner: someone must be responsible for ensuring triage happens.
- Implement regular cycles: if you cannot process in real time, establish daily or bi-weekly review cycles.
- Consider external triage: if the volume exceeds the team's capacity, outsourcing triage is cheaper than ignoring the backlog.
FAQ
How many unprocessed reports is too many?
There is no absolute number, but any report that has gone more than 7 days without a first response is a problem. If you have reports more than 30 days old without validation, that is an active risk situation that needs urgent attention, regardless of the total number.
What do I do with very old reports I cannot validate?
If a report is more than 90 days old and you cannot reproduce it, communicate the status to the researcher and close it if there is no response. If the system has changed significantly, the vulnerability may no longer exist. Document the closure process.
Can I ask someone external to process my backlog?
Yes. An external triage service can process a backlog on a one-off or ongoing basis. For processing a large backlog urgently, it is usually the fastest option: the provider already has the process and tools running.