A scan tells you what might be wrong with a system. It doesn't tell you how to get the problem fixed.
I've worked with engineering and operations teams on vulnerability backlogs that couldn't realistically be cleared all at once. Simply putting the findings in severity order wasn't enough. We needed to understand what was exposed, what could be exploited, which systems mattered most, and which changes could be made without creating a new operational problem.
This is where risk-based prioritization becomes useful, provided it actually changes the work. A critical finding on an isolated test asset may not deserve attention ahead of an actively exploited issue on an internet-facing system. CISA's Known Exploited Vulnerabilities catalog helps establish where exploitation has been observed. Its SSVC guidance is another useful reference for organizing decisions.
But the biggest obstacle is often ownership and capacity. Security may find the vulnerability, but the fix might require a developer, a system administrator, a change window, or an upgrade to a dependency used by several applications. The people doing that work also have product deadlines and reliability commitments.
A workable program brings those people into the plan. Agree on the important risks, decide what can be fixed now, document what must wait, and use temporary mitigations when appropriate. Don't treat every exception as a failure, but don't let an exception become a way to forget the problem either.
Finally, check that the fix worked. Closing a ticket isn't the same thing as removing the exposure. Verify the configuration, package version, or scan result.
A lower vulnerability count is useful. An understood and measurably smaller exposure is better.