Every Monday morning, a vulnerability management team receives a 4,000-line report. Critical, high, medium, low. The scanner did exactly what it was purchased to do. What happens in the hours that follow determines whether that report reduces risk or merely fills up an archive.
The main challenge for a vulnerability management team rarely lies in detection. The tools are in place, the license has been paid for, and the scans are running on schedule. However, the decision about what to patch today and what can wait isn’t formally assigned to anyone. The result is predictable: anything marked red gets attention, orange items get pushed aside, and after two quarters, the tally stands at thousands of findings that no one is accountable for.
Scanning is a technical skill; prioritizing is a matter of organization
The NCSC describes vulnerability management as a cyclical process consisting of five phases: assess, prioritize, address, evaluate, and improve. Two of these are technical in nature. The remaining three revolve around decision-making, mandate, and follow-up. A vulnerability management team focused solely on scanning and patching therefore generates activity without direction.
The case study developed by the NCSC in this regard gets to the heart of the matter. For years, a set of network printers had been left out of the asset inventory, running outdated firmware and using weak passwords. No scanner could have resolved this, because the devices weren’t registered anywhere. The root cause of the problem was organizational.
You see that pattern in virtually every vulnerability management process. The technology works. Decision-making is the problem. We described exactly the same dynamic earlier in the context of SIEM investments that fail without trained analysts: the tool is rarely the bottleneck.
The four roles that drive the process
Roles carry more weight here than job titles. In a team of three, one person can easily fulfill two roles. What doesn’t work is a role that isn’t assigned to anyone, because then decision-making grinds to a halt as soon as things get tense. The same consideration applies when putting together a security team.
The vulnerability analyst
This role puts scan results into context. Is the vulnerable component in your environment accessible? Is the affected version actually running? Is public exploit code circulating? That’s the kind of analytical work that’s closely related to threat intelligence and requires someone who can read an advisory without blindly relying on the CVSS score. A vulnerability management team without this role passes the interpretation on to administrators who have neither the time nor the context to handle it.
The asset owner
The asset owner understands what a system means for the business process. What operations would come to a halt if it went offline overnight? Without that input, a vulnerability management team cannot assess the business impact, and without that assessment, any prioritization is a guess. It’s no coincidence that the NCSC emphasizes that the risk owner should be at the table during the prioritization process.
The Patch Engineer
Deployment is a craft in its own right: testing before rollout, coordinating maintenance windows, and preparing rollback scenarios. A patch engineer who simply applies updates and hopes for the best causes more downtime than the vulnerabilities themselves. In OT environments, this tension becomes even more acute, as we described when discussing the difference between OT and IT security.
The Risk Owner
Acceptance is a fully valid treatment option alongside updating and mitigating. However, that decision should not arise implicitly simply because a ticket has been left unresolved. Someone with the authority to do so must sign off on it, specifying an end date and a review date. This is the role that is most often missing in practice, and it is precisely the role a vulnerability management team needs to be able to say no to its own backlog.
A patch prioritization framework that does more than CVSS
CVSS provides insight into the theoretical severity of a vulnerability but says nothing about your specific environment. A score of 9.8 behind three network layers without any business data warrants less urgency than a score of 6.5 on an internet-facing application containing customer data. A useful patch prioritization framework therefore combines multiple indicators that a vulnerability management team can weigh independently of one another.
The NCSC uses four components to score each vulnerability: exposure, system criticality, current threat, and impact if exploited. The average of these scores determines the ranking. Two international sources supplement this picture. CISA’s KEV catalog includes vulnerabilities with reliable evidence of active exploitation in the wild and a clear remediation action. FIRST’s EPSS publishes daily estimates of the likelihood that a CVE will be exploited within thirty days.
| Signal | What it tells you | Who supplies it? |
| CVSS score | Theoretical seriousness, regardless of your surroundings | Supplier or NVD |
| KEV entry | Evidence of active abuse in the field | CISA Catalog |
| EPSS value | Risk of misuse within thirty days | FIRST |
| Exposure | Whether the system can be accessed via the Internet | Network and Asset Management |
| Business Essence | What stops working as soon as the system goes down | Asset owner |
| Recovery Effort | Downtime, test load, and rollback risk | Patch Engineer |
CISA translates similar indicators into SSVC, a decision tree with four outcomes: Track, Track*, Attend, and Act. Whereas a score triggers a discussion, a decision tree resolves it. A vulnerability management team that has predefined which combination of exposure and evidence of exploitation leads to “Act” does not need to schedule a meeting on Tuesday morning.
A framework must be realistic about capacity. If it generates more work than the team can handle, it will be ignored within a quarter. Calculate how many patch actions per week are feasible before you set your thresholds. That’s the same calculation that applies when allocating your security budget.
The SLA Discussion with Dev and Ops
This is where the vulnerability management process stumbles in most organizations, and it’s where a vulnerability management team gains or loses its credibility. Security promises senior management that critical vulnerabilities will be patched within seven days. Operations enforces a change freeze around the end of the quarter. Development is in the middle of a release, and the library update in question breaks the build. All three are right from the perspective of their own objectives.
An SLA that promises seven days on paper but takes six weeks in practice is more harmful than having no SLA at all, because management believes the risk is under control. Three agreements are more helpful here than a stricter standard.
Classify the timeframe by exposure class rather than by severity label. An internet-facing component is assigned a different timeframe than an internal system, regardless of the scanner's assessment.
Schedule maintenance windows in the development release calendar, not in a separate security schedule. Anything that falls outside the build team’s schedule tends to be delayed.
Designate a single escalation path and give it a name. If a deadline is about to pass, the decision goes to the risk owner, who either accepts it or allocates additional resources. Without that path, silence is considered de facto acceptance. In preparation for that meeting with senior management, we drafted an approach to get your management team on board.
In organizations where this approach works, something else stands out: the vulnerability management team is involved in architecture and procurement decisions from the very beginning. Patchability then becomes a selection criterion, which saves dozens of conflicts down the line. The same logic applies to suppliers, as we outlined when discussing the detection of supply chain risks.
Measuring Without Vanity Metrics
The number of closed findings per month is virtually meaningless. A vulnerability management team that resolves a thousand low-severity findings but leaves one actively exploited vulnerability unaddressed would score exceptionally well on that chart. The NCSC puts it bluntly: a KPI that does not lead to a decision, regardless of whether the result is good or bad, is not a useful KPI.
Four metrics are particularly useful for a vulnerability management team: the turnaround time from discovery to remediation, broken down by exposure class. The percentage of KEV-reported vulnerabilities that are patched within the agreed-upon timeframe. The age distribution of the backlog, because an average hides outliers. And the proportion of accepted risks with a designated owner and an expiration date. We wrote a framework for fair team assessment covering the broader scope of this.
Be sure to measure the workload as well. A vulnerability management process that churns out hundreds of tickets every week has the same effect as a SOC that’s drowning in alerts. We described that exhaustion in the sections on alert fatigue and burnout prevention, and the mechanism is identical.
The skills this requires
The roles listed above require people who can assess exploitability. That’s a different skill set than someone who closes tickets. The distinction between the two determines how quickly a vulnerability management team can move from scan results to a decision.
For those interested in the analyst side, the SOC T1 + T2 Analyst course is a good fit, as triage and context determination form the core of the program. Those who want to focus more on the threat side should consider the SOC T3 Analyst course, where hypothesis formation and investigation take center stage. This ties directly into what we wrote about setting up threat hunting with your existing team.
The fastest way to assess actual exploitability is from the attacker’s perspective. The Penetration Testing course provides a vulnerability management team with the framework to determine when a theoretical vulnerability becomes practically exploitable by an attacker. This saves a lot of time during the prioritization phase.
If you don’t have those people yet, training them in-house is often faster than recruiting. The Cyber Security Specialist training program brings career changers up to a level where they can work independently within a vulnerability management team in just fifteen weeks. We’ve detailed what that means for team building and costs in our comparison of outsourcing versus building a team in-house, as well as in our breakdown of what a cyber incident actually costs.
Employers who wish to set this up for an entire team can find the in-company options on the page for employers. The full range of training courses is organized by level, and the calendar shows the start dates.
Start with what you have now
You can’t build a complete vulnerability management process in a single quarter. But you can build a working version on a small scale. Choose your twenty most important systems, designate an asset owner for each system, and identify who the risk owner is. Then run a single full cycle on just those twenty: assess, prioritize, address, and evaluate.
For every decision you make, document why you made it. That documentation is the true output of a vulnerability management team, because it speeds up the next cycle and frees knowledge from individual minds. If that goes wrong, the same problem arises as with playbooks that don’t work under pressure. Then scale up to the next layer of systems. This approach aligns with the growth path outlined in the five-level maturity model and supports the structural improvement of information security through training.
The difference between organizations that manage their vulnerabilities effectively and those that don’t rarely lies in the scanner itself. It comes down to whether someone has the authority to make decisions, and whether the vulnerability management team can implement those decisions within a reasonable timeframe. If you’d like to discuss how to set this up for your team, please schedule an introductory meeting.
