Vulnerability management is a process that can be described and planned relatively easily. In theory, it comes down to recurring scanning (identification, classification, and prioritization) and passing information about discovered vulnerabilities to the IT department together with recommendations to patch, remove, or isolate vulnerable systems and applications (remediation and mitigation). So all you need to do is invest in a vulnerability scanner, run scans regularly, and deliver structured reports (by CVSS and hosts) to IT, which will take care of execution.

We could end this article here. We have a solution that is relatively simple and cheap to implement. We bought a scanner, defined a process, checked off a compliance requirement. Unfortunately, this is one of many aspects of cybersecurity that proves that “in theory there is no difference between theory and practice, while in practice there is,” as American baseball player Yogi Berra once said.

As the SOC360 team, we have many years of experience implementing and maintaining vulnerability management processes across diverse environments in small, medium, and large organizations. In this article, we want to highlight the challenges we encounter in practice.

Vulnerability lifecycle: from discovery to decision

A simple flow? Only in theory

The vulnerability lifecycle seems straightforward. A vulnerability either exists or it doesn’t. That is why detecting a vulnerability should lead to actions aimed at eliminating it. Starting from this assumption, one might handle vulnerabilities in a process similar to incident handling: detection -> response. We can also approach prioritization similarly—the higher the CVSS (Common Vulnerability Scoring System) score, the higher the remediation priority.

Of course, with vulnerabilities we are dealing with risk rather than an immediate threat. Therefore, it is justified to stretch the process over time and respond in batches. We can assume vulnerabilities will be grouped by priority and passed directly to IT for remediation.

Key decisions in the process: three possible scenarios

Unfortunately, this is where the seemingly simple process becomes significantly more complex. Above all, vulnerability management must account for decisions that do not boil down to fixing the vulnerability. There are at least three paths our process can follow:

1. The vulnerability will be remediated.
2. The risk associated with the vulnerability will be accepted.
3. The risk is unacceptable, but the vulnerability cannot be remediated. Other actions will be taken to reduce risk.

Choosing one of these paths requires a decision. That means the process must ensure appropriate resources, and decision-makers must have context and competence.

Moreover, each decision regarding how to handle a vulnerability triggers a completely different handling workflow.

Scenario 1: Remediation

Remediation requires notifying the people responsible for the affected system, obtaining confirmation that they can remediate it (and when they plan to do so), and then rescanning to verify effectiveness. The process must also account for cases where recommendations are not implemented or remediation is delayed—at which point alternative actions may be needed.

Scenario 2: Risk acceptance

When choosing risk acceptance, the process must include reassessing the risk if circumstances change. A vulnerability’s score may change due to new findings or the publication of exploitation methods. In addition, the exposure of the vulnerable system may change. Therefore, accepted vulnerabilities essentially never leave the process and must be continuously monitored.

Scenario 3: Risk reduction

When a vulnerability cannot be remediated and we choose risk reduction in another way—for example, by reducing the exposure of the affected asset or deploying additional controls—our process must include continuous oversight and verification of the effectiveness of these measures. Such actions often go beyond the scope of vulnerability scanning and require additional arrangements.

These challenges may seem relatively easy to address if we describe and implement a good vulnerability management process. But then scale becomes the issue. Handling the above paths for a handful or a few dozen vulnerabilities does not seem difficult. However, when dealing with tens of thousands of disclosed vulnerabilities—which also need grouping and prioritization—this task can grow to an impossible level.

Data analysis as a key aspect of vulnerability management

There are several commercial scanners on the market that are popular among cybersecurity professionals. Despite minor technical differences, the data they return and the filtering/export capabilities are relatively similar.

However, the results visible directly in scanner consoles may not be sufficient to drive real action—especially in large organizations with thousands of assets.

From the console, you can usually learn only that host X has vulnerability Y with CVSS Z. The entire process of tracking the vulnerability lifecycle, patching, and analysis should happen outside the scanner console. Without a process that exports the right data—whether into your own vulnerability management system or into data processing tools (e.g., Power BI) for quantitative analysis—effective vulnerability analysis in an organization is not possible. The key is properly processing thousands, and sometimes even millions, of records coming from each subsequent scan.

Quantitative analysis of detected vulnerabilities—performed in Power BI or with proprietary tooling—makes it possible to monitor the effectiveness of patching processes, identify the most exposed assets, and support strategic risk-management decisions.

Well-designed data visualization enables verification of many important parameters, including:

• comparing the number of unique vulnerabilities detected in consecutive scans,
• identifying what percentage of vulnerabilities repeated compared to the previous scan,
• determining how many new vulnerabilities appeared since the last scan,
• tracking changes in the number of vulnerabilities on individual hosts over time,
• interactively identifying hosts and software with the highest number of vulnerabilities,
• detecting assets or subnets where patching works poorly or does not work at all.

Once you export the right data from scanners, the processing possibilities are unlimited. This is a key aspect of vulnerability management that allows you to define and track metrics needed to improve the process. But it also shows that a scanner alone—implemented in the network infrastructure—is not enough. In addition to the vulnerability management process, you need effective quantitative analysis. Of course, you can use comprehensive vulnerability management platforms, but those solutions are very expensive.

Scope and diversity of the vulnerability management process

The vulnerability management process should cover LAN assets, Internet-facing assets, cloud environments, and industrial automation systems. Each of these areas requires different tools, planning, and competencies, and comes with specific limitations in scanning, mitigation, and remediation.

Vulnerability management vs. real attack surface

A vulnerability management process can only cover assets that have been identified by the organization and are intentionally included in the process. But in most organizations, there are IT assets that remain in the shadows: rogue initiatives by administrators and users, forgotten services spun up and exposed “just for a moment,” assets exposed due to lack of awareness or despite awareness of risk, assets exposed without IT’s knowledge in branches or subsidiaries, cloud assets exposed “only for testing” or development, and third-party service provider assets connected via VPN.

Attack Surface Assessment

Because of the above, vulnerability management should not operate in isolation from attack surface assessment (ASA Attack Surface Assessment) and attack surface management processes, ASM - Attack Surface Management. This is a process similar to vulnerability management but broader in scope. It covers not only software flaws that have assigned CVEs and CVSS scores.

ASM starts by identifying organizational assets and services that constitute an attack surface simply by being accessible. This allows us not only to include those assets in vulnerability scanning, but also to identify gaps that will not be revealed by vulnerability scans—for example: Internet-exposed RDP services, all kinds of admin panels, VPN remote access, or email access that is not protected by 2FA, where passwords have leaked or are vulnerable to brute-force attacks.

Linking vulnerability management to attack surface management is essential—especially for large organizations and those with complex, distributed structures.

Risk analysis in vulnerability management

In theory, vulnerability management should be more effective if the process includes risk analysis. In practice, it looks a bit different.

Very often, we see attempts to tie vulnerability remediation priorities to the broader criticality of the assets where those vulnerabilities exist. The highest priority is assigned to vulnerabilities found on systems that process sensitive or regulated data and on systems connected to business-critical services.

So we have an organization that sets goals for inventorying information and service assets and mapping them to data types and business services. Then the collected information is combined with asset exposure (from a network architecture perspective) and existing controls. On top of all that, vulnerability scan results are added. As a result, we can perform risk analysis and decide priorities based on it. At first glance, it’s hard to argue with the rationale of this approach.

The mismatch between risk analysis and real-world attacks

In practice, however, this methodology can reduce the effectiveness of the entire process.

First, asset inventory and risk assessment are long-running activities, and the pace of change in IT environments often outstrips them. The data these processes rely on is often declarative, and the real state is not verified. As a result, in many organizations, vulnerability management is stalled by a risk analysis that will never be finished and does not provide clear decision grounds. Second, cybercriminals typically ignore risk analysis results entirely and gain access by exploiting vulnerabilities in assets that ended up at the bottom of the “importance” hierarchy.

Once an attacker has early access to the organization’s infrastructure, vulnerabilities in critical assets—or their absence—become less important. That is why when implementing vulnerability management, it is worth focusing on the process’s dynamics and effectiveness first, and postponing risk analysis topics until later, once the situation is under control.

Marvel vs. DC: security vs. IT

Finally, the hardest challenge to handle—misaligned priorities between security teams and IT teams.

IT’s mission is to deliver and maintain systems that support business services and processes. As well as possible, cheaply, and quickly.

The role of security teams is often perceived in the opposite way. Their activities are costly, reduce service quality, and cause delays. IT tasks typically have the highest priority, and staff are often overloaded with projects and their pace. No surprise—deadlines are tight, systems must run, and if they run, it’s better not to touch them.

In many organizations, security and IT teams don’t like each other—often competing, having different goals and different approaches to priorities. In such an atmosphere, implementing and maintaining a vulnerability management process becomes extremely challenging. Reports and recommendations disappear into a void or bounce off a wall.

Importantly, similar difficulties arise even where there is no open conflict and both sides have goodwill and a desire to cooperate. The problem is often purely practical constraints: lack of resources, lack of available maintenance windows, or the need to purchase new hardware or licenses.

As a result, vulnerability management becomes cyclical scanning and reporting—without real impact on improving organizational security.

How to support vulnerability management in practice?

Vulnerability management is much more than scanning and sending reports. It requires real resource engagement, an effective remediation process, and cooperation between teams.

Identifying vulnerable assets is relatively straightforward. Difficulties begin at the decision stage: who will handle the vulnerability and when, whether remediation is feasible, and how to formally organize the overall process. Without an organized patching system, vulnerability management becomes practically impossible. Security teams can analyze data, prioritize risk, visualize results, but without operational action they won’t be able to bridge the gap between insight and real execution.

That is exactly where we come in—bringing experience that translates into real action under constraints, uncertainty, and complexity.

Our SOC360 team has supported organizations for years in designing and improving vulnerability management processes. We work with companies of different sizes and structures, helping to:

• organize processes around detecting and patching vulnerabilities,
• analyze scanner data and set priorities,
• determine which issues are local and which are systemic,
• conduct actions that truly increase security levels.

Contact us to strengthen your organization’s security with the help of our specialists.

This article was prepared entirely by cybersecurity experts—without the support of artificial intelligence tools.