If you run vulnerability management, you know the routine.

You close a batch of work. The backlog drops. For a moment, it feels under control. Then the next scan lands, a new service appears, and the list is bigger than it was last week.

It is tempting to assume this is just a resourcing problem. In reality, most vulnerability backlogs keep growing for a simpler reason: a list is not a plan. It is a pile of findings without a reliable way to decide what matters first, get it fixed by the right owners, and prove exposure has actually dropped.

That is what risk-based vulnerability management changes.

Why Vulnerability Management Backlogs Keep Growing

Most teams are not doing anything wrong. They are dealing with forces that naturally push the backlog upward.

Your Attack Surface Keeps Expanding

Cloud resources appear and disappear. Internet-facing components multiply. New applications and identities get created all the time. If discovery is not continuous, you end up scanning yesterday’s estate while today’s estate keeps moving.

Vulnerability Scanning Creates Volume, Not Priorities

Scanners are good at finding issues. They are not built to understand your organisation. They do not know which services keep revenue flowing, which systems are truly exposed, or which weaknesses attackers are actively exploiting right now. So the output arrives as volume, not as a queue anyone can confidently run.

CVSS Severity Alone Does Not Reduce Risk

CVSS has value, but it is not a prioritisation strategy on its own. When everything looks high or critical, teams either chase what feels loudest or pick what is easiest to close. Both create activity. Neither consistently reduces exposure.

Remediation Work Breaks Down at the Handoff

This is where many programmes slow down. Findings sit in security tools while remediation occurs elsewhere. Ownership is unclear. Impact is not stated. The fix path is vague. Exceptions do not expire. Validation is inconsistent. Even when you know what matters, the work does not move cleanly.

Put those pressures together, and the outcome is predictable: the backlog grows, even when teams are working hard.

What Risk-Based Vulnerability Management Changes

RBVM is a shift from counting vulnerabilities to reducing the exposure you can prove.

Instead of asking, “What did we find?” RBVM asks, “What should we fix first to reduce real risk, and how will we confirm it worked?” That shift shows up in a few practical ways.

Add Context to Vulnerability Prioritisation

RBVM prioritises based on what matters most, not just severity.

Start with your most critical systems. Consider how exposed the asset is, especially if it is reachable from the internet. Bring in live exploitation signals, meaning vulnerabilities that are known to be exploited in the real world. Then factor in the controls you already have in place. This is what turns an endless list into a shorter, defensible order of work.

Turn Findings Into Actionable Remediation Work

A finding becomes useful when it turns into a clear work item someone can complete.

At a minimum, every work item should answer four questions:

• Who owns it
• Why it matters
• What to do
• How will you confirm it worked

When those basics are present, remediation stops being a side conversation and becomes part of normal operations.

Validate Remediation Before You Close Work

Many backlogs look healthier than they really are because “closed” often means “someone marked it complete.”

RBVM raises the bar. Closure means you have evidence exposure has dropped. That evidence might be a clean re-scan, a targeted retest, or confirmation that compensating controls are in place and working. The method matters less than the discipline. Discipline is what turns activity into proof.

Run RBVM on a 90-Day Operating Rhythm

High-performing teams do not try to fix everything at once. They run a repeatable cadence that makes progress visible.

A quarterly cycle works well for most organisations: set a baseline, choose a small number of improvements, execute consistently, validate outcomes, and report the trend. The goal is compounding improvement, not heroics.

Why Exposure Management Matters to the Business

If vulnerability management is only discussed as a backlog, it stays abstract. When exposure becomes real, it becomes operational.

In June 2024, the ransomware attack on Synnovis disrupted pathology services supporting major London NHS trusts. NHS England stated that some operations and procedures were postponed, and some blood-testing appointments were cancelled due to the disruption.

Later that month, NHS England also said it had been made aware that a cyber criminal group had published data it claimed was stolen as part of the attack, and that the National Crime Agency and National Cyber Security Centre were working to verify the files.

You do not need those exact circumstances to learn the lesson. When programmes focus on lists rather than outcomes, they struggle to reduce exposure fast enough and struggle to prove what has changed.

RBVM Quick Check: Is Your Programme Built to Reduce Exposure

If your backlog keeps growing, this quick check helps you see whether the issue is volume or operating model.

Answer yes or no. If you cannot show evidence, answer no.

1. We can name the owner of every critical business service.
2. We always know which systems are reachable from the internet.
3. Vulnerabilities known to be exploited in the wild rise to the top on critical assets.
4. Remediation work flows through normal service processes with clear owners and timeframes.
5. Closure requires validation that exposure has dropped.

If most answers are no, the backlog is growing for a reason. The programme is not designed to shrink exposure in a consistent way. That is the gap RBVM closes.

How to Start RBVM in 90 Days

You do not need to transform everything in one go. Start with focus.

Pick one scope where value is obvious, such as internet facing systems or a small set of crown jewel services. Add context beyond severity so the order of work makes sense. Make ownership explicit. Build validation into closure. Run one 90 day cycle and report trends rather than totals.

When RBVM is working, the backlog stops being a source of stress. It becomes a managed queue. It is ordered, owned, validated, and tied to proof that exposure is falling where it counts.

If your vulnerability list keeps growing, the answer is rarely more scanning. It is a better operating model.

Download the eBook Podium-Ready RBVM: What Good Looks Like and How to Get There for the full model, a simple benchmark you can run in minutes, and a practical 90-day rhythm for building momentum and proving progress.

‍