What is vulnerability management? Process, lifecycle & best practices

Build a continuous vulnerability management process that finds, fixes and adapts to new threats.

Organizations face an overwhelming volume of newly disclosed vulnerabilities, making it impossible to treat every issue as an equal priority. Vulnerability management provides a structured, continuous approach to discovering, assessing, prioritizing and addressing security weaknesses. This helps organizations reduce risk, improve resilience and meet growing regulatory expectations.

Key points of this article:

• Vulnerability management (VM) is the practice of systematically understanding where your organization’s estate is likely to be attacked, and then closing off those avenues of attack.

  
  

• It often incorporates existing, standalone techniques and orchestrates them into a structured, continuous process that finds, prioritizes and then fixes security weaknesses. 

  
  

• VM can incorporate or make use of both vulnerability scanning and patch management as part of this process. 

• In recent years, legislation, including NIS2, DORA and CRA in the EU, set an expectation of documented vulnerability handling.

Introduction: A bit of backround on CVEs

Tens of thousands of vulnerabilities are identified each year by security researchers:  over 350,000 are currently listed in the Common Vulnerabilities and Exposures (CVE) database. Of the nearly 50,000 CVEs  published in 2025 alone, 3,984 were rated Critical, and they ranged from operating systems like Windows, Linux and macOS to Android and Adobe Experience Manager, a web suite that powers many large websites. 

A forecast by the Forum of Incident Response and Security Teams (FIRST) in February 2026 saw that number expected to increase to nearly 60,000 for the following year, and as at June 2026, the CVE Database, a project tracking CVE trends over time, noted over 41,000 CVEs published. It shows a steady rise in recorded vulnerabilities from 2016 onwards, ramping sharply from 2021 onwards.

Any organization is going to struggle to keep up with that volume of alerts, especially as it comes on top of years‘ worth of other CVEs. 

The good news? Most are not an urgent priority for your organization, or even likely to directly affect it. But it doesn’t mean they can be completely ignored, and this volume and variety does create a further problem: prioritization. 

Vulnerability management is part of the answer: it takes a spider’s nest of reported vulnerabilities and turns it into a prioritized list of actions for your team to work through, all the way to a tick list of remediated vulnerabilities that keep regulators happy and you organization, data and customers incident-free.

What is vulnerability management?

Vulnerability management is a continuous process of finding, assessing, prioritizing and fixing cybersecurity weaknesses in an organization’s IT and OT systems and associated infrastructure. Vulnerability management is not a ‘one and done‘ -type project: done correctly, teams see the process as circular and constant, proactive, and a means to reduce risk and the chances of a cyberattack succeeding.

Vulnerability management vs. vulnerability assessment vs. vulnerability scanning

Let’s clear up a bit of confusion first: most of the big cybersecurity platforms, including ESET PROTECT Platform, offer vulnerability scanning for devices and services. They’re automated scans that help identify assets and compare them against a database of known vulnerabilities – things like unpatched software or risky configurations, and then produces a rundown of what the most urgent problems are. The end result is a snapshot of how secure a system is at that point in time. It doesn’t capture past or future problems or risks. This sort of work is regularly automated using Vulnerability and Patch Management services.

A vulnerability assessment is more involved, and something that organizations often run periodically. Often the schedule for these assessments is set by risk or regulatory requirements.  As well as automated tools used in scanning, these assessments involve a layer of human assessment, and the scope is increased from a single app or device to a whole network, system or organization.

Unlike a scan, which can be run quickly and efficiently, an assessment tends to be more drawn out, comprehensive, and linked in to the organization’s long term security and business strategy.

In contrast, vulnerability management is a continual process. Where it might be argued that a vulnerability scan is short, quick, and tactical, and a vulnerability assessment occasional and strategic, vulnerability management is something else: a proactive, constantly-repeating process that continuously hardens the organization against attack.

Patch management vs. vulnerability management

We’ve already mentioned patch management, and it’s worth removing a bit of ambiguity here. Patch management is a valid and valuable process for protecting organizations. It ensures devices and software used by the organization are up-to date, reducing the workload of security and broader IT teams by (and this is predicated on the quality of vendors’ patches) ensuring the software in use by the organization is as stable, secure and compliant as possible. 

Patch management aims to ensure that all hardware and software is updated in a uniform manner, to an agreed schedule, using updates that have been tested and validated before they’re applied.

While this broadly follows the same philosophy of vulnerability management (a constant process that ensures a baseline) it covers only one facet of organizational cyber vulnerability – and only one element of its resolution. It’s also worth noting that patch management is inherently reactive, depending on the updates vendors release. 

Why vulnerability management matters now

While techniques such as patch management are excellent means to reduce risk, there is now a higher volume of potential vulnerabilities that appears to be increasing significantly year on year, organizations are running increasingly complicated systems and the potential losses from an incident are increasing. 

Lawmakers have taken notice of this; one immediate reason for vulnerability management becoming a priority is that regulations increasingly demand it as a part of the compliance process. 

Frameworks such as FedRAMP in the US, and regulations like NIS2 Article 21, DORA and CRA in Europe all require organizations to demonstrate effective vulnerability handling and risk management practices. These fall into three general categories we’ll get into shortly: Continuous identification, Assessment and Remediation. 

Regulations often exist to oblige best practice – or at least encourage behaviors that produce a benefit to society. Of course, many responsible and/or well-resourced organizations have already invested in vulnerability management as a way to reduce risk to their business.

Types of vulnerabilities

It’s worth setting out what these vulnerabilities look like before we go any further and breaking them down into more easily-digested chunks of information.

Vulnerability management covers four different types of vulnerabilities:

• Operating system and software vulnerabilities are probably what most people think of when the topic of cybersecurity vulnerabilities emerges. Everyone has sat waiting for an OS update to finish installing and there are plenty of stories about default credentials use for critical systems. 

  • Systems and software so outdated they are unsupported can also fit on this list. It’s worth noting that servers, network switches and IoT devices all fit into this category

• Network vulnerabilities include Wi-Fi networks with outdated, poor or badly-configured security are the main areas of interest, but the overall network attack surface should include everything exposed to the internet – or to a savvy attacker in physical proximity.

  • That creaky old firewall protecting a remote office, or routers with the wrong settings or ports left open are one thing, but it’s surprising how often ethernet sockets in public areas of office buildings are live.

• Human beings are just as vulnerable, falling for phishing attacks and other social engineering tactics. They make easy choices of weak passwords, leave smartphones in buses and laptops in cafes, and use unauthorized software or services to process sensitive data.

• Process vulnerabilities sometimes compound these issues. Your people might not know they are letting a security vulnerability happen because there isn’t a  policy for downloading software from random software, or signing up to then latest hot AI trend. 

  • Then there’s incident response, the means by which new systems are added and the way decisions are made about storing, processing and accessing sensitive information and that’s just for starters.

The vulnerability management lifecycle

Handling these vulnerabilities and reducing their potential impact is inherent to vulnerability management, and it’s both desirable and somewhat inevitable that there should be a process to ensure this happens in a manner that is reliable and sustainable.

We’ve already explained how vulnerability management is a continuous process, so let’s get into a bit more detail on how that happens. 

1: Discovery and inventory of assets

Vulnerability management is a continuous cycle, the final step is to return to the first item in the cycle: Discovery. The aim is to build a comprehensive, continually-updated asset inventory of everything in your organization’s estate, and this needs to take into account the addition of new items and the decommissioning of un-needed hardware, software, services and permissions. 

Endpoints, servers and network equipment are the first port of call in the discovery process, but teams also look for cloud services, Internet of Things (IoT) and Operational Technology (OT) equipment and containers. Data captured should include who owns it, how critical it is to the organization’s operations, its location, both physically and on the network, software and OS load and so on. 

A lot of this can be secured via automated discovery rather than manually-updated spreadsheets, and a good Configuration Management Database (CMDB) will either have or will allow integration with network scanning and agent-based discovery.

Two further things: unmanaged devices and shadow IT are both incredibly risky groups. Introduce management for the first and look at a pragmatic policy for the second.

2: Assess and Scan

Now you have an up-to-date understanding of the assets in your estate, the next step is to schedule regular vulnerability scans, as well as a process for scanning at specific points in time such as software releases, new assets coming online or incidents. 

Couple this with scans that simulate an attacker’s approach – unauthenticated scans that test your organization’s exposure at the perimeter. It’s also worth comparing scan results against vendor and open source vulnerability lists such as CVE, and use CIS benchmarks to perform configuration assessments.

3: Set priorities

This is where your team can start to prioritize based on risk: you’ve got a list of assets and an idea of which vulnerabilities they may be exposed to. A raw scoring is not enough. Look to add in measurements of how critical an asset is, whether there is an exploit for it in the wild, the level of its exposure to attackers and its importance in the context of the business. 

Risk Based Vulnerability Management (RVBM) is helpful here to help your team prioritize based on more than just the assets with the highest CVSS (Common Vulnerability Scoring System) score. 

4: Remediate

The next step involves taking the results of the previous three into consideration, and then doing something about it. There are three options for each asset of concern: patch, mitigate, or accept. 

• Patch: using a controlled patch management process apply the appropriate vendor-supplied fix

• Mitigate: build other security controls around the vulnerable asset. This could be as simple as disabling certain services, adding rules to your firewall, or isolating the asset on the network. This is a good option if a patch has yet to be developed and released, or if applying a patch would have a knock-on effect. 

  • One example of this that came to light during the WannaCry ransomware outbreak was MRI scanning suites in the UK’s hospitals. Many of these systems ran on older versions of Windows, which made them particularly vulnerable. Until a fix became available, the only practical mitigation was the approach recommended by the UK's NCSC: reducing the likelihood of compromise by preventing access to untrusted content and limiting the impact by restricting access to sensitive data. Unfortunately, MRI scans are and were critical to urgent patient care, which complicated matters.

• Accept sounds rather fatalistic – but isn’t. If there’s not other option (and if the business case for retaining use of a vulnerable asset is overwhelming or unmoving), then acceptance with documentation is the way to go. 

  • A more acceptable reason is when the risk is well below the cost or impact of fixing the vulnerability. This involves formally documenting the risk acceptance with the owner of the asset and moving on.

5: Verify and report

This last stage (well, until the process starts all over again shortly after) is one of then more critical if your organization has a regulatory obligation under things like NIS2, DORA, FedRAMP and so on.

The first part is  procedural: re-scan to confirm the vulnerability has been removed, and track program metrics like MTTR  (Mean Time To Remediate), performance against SLAs and so on.

The second part is relevant for regulation: use the metrics you’ve gathered to set up and keep audit trails – things like scan history, remediation timestamps and risk-acceptance signoffs. All of this can be used to document correct risk management, incident handling and so on. Where vendors and suppliers ask for documentation for supply chain risk mitigation, this is also a massively helpful block of data to have.

6: Return to Discovery

That’s it. Now you and your team are ready to go back to the discovery and inventory stage and start the process all over again. The good news is that, assuming there are no massive changes to the asset list (for example, a merger, a hardware refresh or similar event) then much of the effort required for the initial cycle is banked, with future iterations concentrating on tackling new vulnerabilities.

Risk-based prioritization: fix what actually matters

A key element of the cycle is working out what needs to be fixed in what order. Building and adjusting that fix list is a constant task that must take organizational and cyber risk into account as both factors change.

We’ve mentioned risk-based prioritization already, but it’s worth going into a little more detail on this. Raw CVSS scoring doesn’t take into account the criticality of the asset, its place within the organization or the further context and impact of it being used in an attack. 

More bluntly: you can’t patch ‘em all, so you need to fix the most urgent and important stuff first, and list everything else in declining order of priority.

CVSS estimates severity and exploitability characteristics, but doesn’t reflect real-world exploitation activity. For example, a vulnerability might require multiple other factors to become a real risk, making it a lower potential risk than other documented vulnerabilities.  CVSS measures severity, while EPSS (Exploit Probability Scoring System) looks at the probability of exploit within the next 30 days. On top of this, the US Cybersecurity and Infrastructure Security Agency (CISA) maintains and publishes a list of Known Exploited Vulnerabilities - the KEV Catalog that can be used to narrow down the list of vulnerabilities to be tackled as a matter of urgency. 

Combine these three scores with your understanding of the context of what matters most to your organization from a cybersecurity and business risk perspective, and you have the beginning of a practical scoring approach.

Building a vulnerability management program

It’s hopefully now clear that a program is required; while one-off scans absolutely have their place, they should not be regarded as the equivalent of, or replacement for, a VM program. 

Bear in mind that VM programs tend to mature over time, from ad-hoc (or, frankly, panic as a result of an incident or other realization) through periodic to continuous and risk-based approaches. It’s critical to understand and anticipate how the maturity of your vulnerability management changes and (hopefully) improves over time.

To set this up, you’ll need to take some generic management steps and some more specific measures.

Roles and responsibilities

First, identify roles and responsibilities for your team, and for other teams expected to be involved in the RACI model (Responsible, Accountable, Consulted, Informed) of this area. RACI is always a good place to start to avoid accountability and stakeholder hell.

Find your optimal cadence

Then, set a cadence by deciding how often should the VM process run. Besides, ask also how long do you expect a full cycle to take? Adjust this, or set bounds, as you learn more about the specific requirements of the organization. 

Prioritize with clear SLAs and frameworks

Next, identify and set Service Level Agreements (SLAs) based on the severity of the issues identified, which helps with the process of setting prioritization. You’ll also want to make this as straightforward for everyone as possible, so adopting a framework like NIST CSF2 is worthwhile, especially for small and midsized organizations. It’s worth noting here that the original CSF was an excellent framework for cyber risk, and that CSF version 2 adds a governance capability. 

CSF 2 is a very acceptable framework to apply for organizations affected by European as well as US regulations on cyber risk management. 

Close the feedback loop

Finally, ensure there is a feedback loop that includes all stakeholders identified in the RACI model. Lessons learned from remediation efforts, incidents, false positives, and patching delays should be used to refine risk scoring, SLAs, scanning coverage, and prioritization. 

Regular reviews of metrics such as vulnerability age, remediation times, and SLA compliance can help identify bottlenecks and continuously improve the program.

Vulnerability management metrics and KPIs

Measuring success (and working out what else needs attention) is critical to the success of VM platforms. Measurements have to be readily-understood by all involved, but also have to drive effort and activity in the right direction.

For many organizations, it’s essential to keep metrics and KPIs reasonably brief and easy to digest, simply because the volume can become overwhelming for all involved. A reasonably sort list of under ten metrics with different directions is workable. Three useful categories are velocity (for example, MTTR), coverage (the percentage of known assets scanned), and risk signal via CVSS, EPSS and presence on the KEV list.

Vulnerability management tools: what to look for

Here’s five things we think you should look for in vulnerability management tools:

1. Unified console management gives you complete visibility across multiple operating systems, preferably at least the main desktop operating systems: Windows, Linux and macOS.

2. Automated scanning and instant reporting: don’t wait for a manual review cycle. Extra points if identified vulnerabilities come with a means to prioritize them based on severity and other factors, which we’ll deal with next.

3. Filtering and prioritization options should be tunable by the team using the management tool so that they can adjust priorities based on all of the other factors we outlined earlier in the management lifecycle. This elevates the ability of the tool, but also takes on a lot of the heavy lifting required by good vulnerability management. 

4. CVE transparency is a must-have: it’s no good having a tool if it’s not immediately obvious which vulnerabilities it can and can’t detect, or which CVEs it can and can’t search for.

5. Automated and manual patch control should work with your set cadence for VM, as well as future adjustments. It also needs to be operated manually as needed.

Vulnerability management best practices

We’ve talked about the vulnerability management life cycle. Its operation and continual refinement as both the practice and the organization it protects matures represents many of the aspects of what would be regarded as best practice. That said, it is important to look beyond the cycle at the wider environment. 

Briefly:

• Maintain a complete asset inventory and updated it at a regular cadence. Update manually and proactively when new assets are introduced – for example, when a generation of laptops is switched out.

• Prioritize by far, far more than severity. Combine measurements and factors to build a specific prioritization that is relevant to your organization’s estate and risk profile. Don’t forget to set SLAs for remediation in the process – and keep to them.

• Track metrics, patch systematically. Measure, adjust, and work methodically, not reactively.

• Define roles and ownership – that RACI model we mentioned earlier will save a lot of pain.

• Integrate with existing workflows such as ticketing, CMDB, patch management and so on. If you operate a SIEM, that should be on the list as well.

• Use a framework or guidance, be it CSF 2, ISO 270001 or specific requirements such as DORA.

• Ensure reporting uses appropriate context and language for the audience. VM is excellent for understanding and communicating cyber risk, so report upwards regularly with a focus on information that informs business risk as well as opportunity.

FAQs

What is vulnerability management? 

Vulnerability management is the continuous process of identifying, prioritizing, fixing and verifying security weaknesses across your systems and software. Unlike a one-off scan, it runs as an ongoing cycle: find vulnerabilities, decide which matter most, remediate them, and check they work.

What are the 5 steps of vulnerability management? 

1. Discover and inventory your assets

2. Assess them by scanning for known vulnerabilities

3. Prioritize by risk, not severity alone

4. Remediate by patching, mitigating or accepting the risk, and 

5. Verify the fix and report. At this point, return to the start and begin again.

What’s the difference between vulnerability management and a vulnerability assessment? 

A vulnerability assessment is a point-in-time evaluation that produces a snapshot of weaknesses. Vulnerability management is the ongoing program that acts on those findings over time,  prioritizing, fixing and re-checking continuously. An assessment is one step within management.

What’s the difference between patch management and vulnerability management?

Patch management is the process of deploying software updates. Vulnerability management takes a holistic approach across a far wider area, and in greater depth. It finds and prioritizes weaknesses and decides how to handle each one, which might be a patch, a configuration change, a compensating control, or an accepted risk. Patching is one outcome of vulnerability management, but not the only one.

What is risk-based vulnerability management? 

Risk-based vulnerability management prioritizes fixes by real-world risk rather than raw severity. It combines a vulnerability’s CVSS severity with its likelihood of exploitation (for example EPSS and CISA’s Known Exploited Vulnerabilities list) and the importance of the affected asset, so you fix the few that genuinely threaten you first, instead of chasing every high-severity score.

How does vulnerability management support NIS2 and CRA compliance? 

NIS2 expects in-scope organizations to manage and handle vulnerabilities as part of their risk measures, and the EU Cyber Resilience Act adds vulnerability-handling and reporting duties for products with digital elements. A documented vulnerability management process is how organizations demonstrate they meet these expectations. It supports compliance; it doesn’t replace legal advice.