TL;DR

Most organisations have two distinct vulnerability challenges:

A stream of new vulnerabilities that need quick triage and action
A backlog of old, often low-priority vulnerabilities that never seem to move

Treating them the same way — with one workflow, one SLA, one dashboard — leads to confusion, burnout, and missed risk. This Playbook outlines how to separate them operationally and build tailored processes for both.

Why This Matters

A “vulnerability backlog” isn’t just technical debt — it’s operational risk that’s been deprioritised, ignored, or lost in translation.

At the same time, new vulnerabilities (especially KEV-listed or zero-day ones) demand rapid action with clear ownership.

Without separation, two things happen:

New vulnerabilities drown in noise
Old vulnerabilities never get fixed

Organisations need two lanes:

One for new vulnerabilities, triaged and actioned in real time
One for backlog burndown, handled in cycles or sprints

Define the Two Tracks

1. New Vulnerabilities (Day 0–30)

These are vulnerabilities discovered:

In the last 30 days
Through regular scanning or new CVE feeds
Often include KEVs, vendor criticals, or internal intel priorities

Primary goal: Fix or risk-accept before they age out

Process focus:

Triage fast: is it real, relevant, and exploitable?
Prioritise using business impact and exposure
Assign and track within SLA
Report status weekly

This is your real-time operations lane.

2. Backlog (Vulnerability Debt)

These are vulnerabilities:

Older than 30 days
Often low/medium severity or historically “too hard to fix”
Accumulated over months or years

Primary goal: Reduce the overall volume and risk — without disrupting BAU

Process focus:

Group by common root causes (e.g., old OS versions, missing configs)
Target based on business service, platform, or team
Run structured remediation sprints (e.g., 4-week cycles)
Track reduction trends, not just absolute counts

This is your programmatic cleanup lane.

What Good Looks Like

Category	New Vulnerabilities	Backlog
SLA	30 days to resolve (or risk accept)	Rolling targets (e.g. 10% reduction/month)
Dashboarding	Current exposure by priority and business risk	Trend over time and remediation progress
Team cadence	Weekly triage and progress checks	Biweekly/monthly backlog check-ins
Leadership view	What’s been found and fixed this week	How are we trending toward risk reduction?

Common Pitfalls

Lumping everything into one SLA report – makes teams look like they’re always failing
Expecting urgent response to old vulnerabilities – sets up unrealistic pressure
No defined backlog owner – leads to passive accumulation

Your Next Actions

Audit your current vulnerability list: Split into “New” and “Backlog” based on age
Define separate workflows and reporting views for each
Launch a time-boxed backlog sprint (e.g., 4 weeks per platform)
Make backlog targets achievable and report on trendlines, not just volume

Coming Soon

Future Playbooks will go deeper into:

Triage models for new vulnerabilities
Structuring a 4-week backlog burndown sprint
Setting up realistic reporting and KPIs

If this helped, subscribe for future Playbooks or connect with me on LinkedIn.

Two Tracks, One Goal: Separating New Vulnerabilities from the Backlog