Building Vulnerability Management: Scanners, Prioritization, and Patch Workflow

Why Vulnerability Management Is More Than a Scanner

Every week, the NIST National Vulnerability Database (NVD) publishes hundreds of new CVEs (Common Vulnerabilities and Exposures). In 2025 alone, over 30,000 vulnerabilities were registered. For a mid-market company with several hundred systems, this means: the probability that a known vulnerability exists somewhere in the infrastructure isn't "maybe" — it's guaranteed.

That alone isn't a disaster. Vulnerabilities are a normal part of software, and not every vulnerability poses an acute risk. The disaster begins when you don't know which vulnerabilities you have, which of them are critical, and whether they've been fixed. These are exactly the three questions that structured vulnerability management answers.

Differentiation: Vulnerability Management vs. Patch Management

The two terms are often used interchangeably but describe different disciplines that work closely together.

Vulnerability management is the overarching process. It encompasses identifying, assessing, and prioritizing vulnerabilities across the entire IT infrastructure. This includes not just missing patches, but also misconfigurations, insecure default settings, outdated protocols, or architectural weaknesses. Vulnerability management answers the question: where are we vulnerable and how great is the risk?

Patch management is a specific measure within vulnerability management. It deals with the technical implementation of software updates and security patches. Patch management answers the question: how do we get the fix onto the affected systems?

The difference becomes particularly clear with non-patchable vulnerabilities. When a vendor provides no patch, when a system has reached end-of-life, or when a patch can't be installed due to compatibility issues, patch management ends. Vulnerability management continues: it must define compensating controls that reduce the risk to an acceptable level.

In your ISMS, both processes should be documented, with vulnerability management providing the framework and patch management embedded as an operational sub-process.

Vulnerability Scanners: Choosing the Right Tools

A vulnerability scanner is the central tool in vulnerability management. It automatically searches systems for known vulnerabilities, misconfigurations, and outdated software. The results form the basis for all subsequent steps.

Nessus (Tenable)

Nessus is the market leader in vulnerability scanning and is considered a reference by many auditors. The Professional version costs around 3,500 euros per year and covers an unlimited number of IPs. Its strengths are the broad plugin database (over 200,000 checks), reliable detection, and detailed reports. The weakness: license costs increase significantly once you want to use the Tenable.io platform with agent-based scanning and dashboards.

For mid-market companies with up to 500 systems, Nessus Professional is a solid tool that reliably gets the job done and is recognized in audits.

OpenVAS / Greenbone

OpenVAS is the open-source alternative, available as the Greenbone Community Edition at no cost. The scan engine uses the Greenbone Vulnerability Feed with over 100,000 checks. Its strength lies in the absence of license fees and the ability to run the solution entirely self-hosted, which is relevant for companies with strict data privacy requirements.

The weaknesses: setup and maintenance require more technical expertise than commercial solutions. Scan speed is typically lower than Nessus, and reporting functions are less polished. For companies with limited budgets and existing Linux know-how, OpenVAS is nonetheless a serious option.

Qualys VMDR

Qualys is a cloud-based platform offering Vulnerability Management, Detection and Response (VMDR) as a service. Its strength lies in the combination of vulnerability scanning, asset inventory, and automated prioritization. The Qualys agent can be installed on endpoints and also scans systems not reachable within the network, such as notebooks in home offices.

Costs range from 5,000 to 30,000 euros per year depending on scope, making Qualys more economical for companies with 200+ employees. In return, you get a platform that combines vulnerability management, patch management, and compliance reporting in a single tool.

Additional Options

Beyond the three mentioned above, there are other relevant scanners. Rapid7 InsightVM offers similar capabilities to Qualys with a focus on risk-based prioritization. Microsoft Defender Vulnerability Management is interesting for companies with a Microsoft 365 E5 license, as it's available at no additional cost and integrates seamlessly into the Microsoft security landscape. Nuclei is an open-source scanner particularly suited for web application and API vulnerabilities.

Which Scanner for Which Scenario?

For a company with 50 to 200 employees and a limited security budget, starting with OpenVAS or Nessus Professional is recommended. Once the infrastructure becomes more complex, many remote workers are present, or SIEM integration is desired, it's worth looking at Qualys or Rapid7.

More important than the choice of scanner is that you scan regularly at all. A weekly scan with OpenVAS is better than an annual scan with the most expensive product on the market.

CVSS, EPSS, and Asset Criticality: Prioritizing Correctly

The scanner typically delivers hundreds to thousands of findings per scan cycle. Without thoughtful prioritization, your team drowns in vulnerabilities and doesn't know where to start.

CVSS: The Industry Standard

The Common Vulnerability Scoring System (CVSS) rates each vulnerability on a scale from 0.0 to 10.0. The current version is CVSS v4.0. The score is composed of multiple metrics: how easy is the vulnerability to exploit? Over the network or only locally? Does the attacker need authentication? What impact does a successful attack have on confidentiality, integrity, and availability?

The common classification: 0.0 is no vulnerability, 0.1 to 3.9 is low, 4.0 to 6.9 is medium, 7.0 to 8.9 is high, and 9.0 to 10.0 is critical.

CVSS is useful as a common language and initial classification but has a fundamental weakness: the score describes the theoretical severity of a vulnerability, not the practical danger. A CVSS 9.8 in a system that is isolated from the internet and contains only test data is less urgent than a CVSS 6.5 in a publicly accessible system with customer data.

EPSS: How Likely Is an Exploit?

The Exploit Prediction Scoring System (EPSS) supplements CVSS with a crucial piece of information: how likely is it that this vulnerability will actually be exploited in the next 30 days? EPSS uses machine learning, evaluating data from exploit databases, darknet forums, and real-world attack data.

The EPSS score ranges from 0 to 1 (0% to 100% probability). Experience shows that only about 5% of all CVEs have an EPSS score above 0.1 (10%), and fewer than 2% have a score above 0.5 (50%). This means: most vulnerabilities are never exploited in practice.

This information is invaluable for prioritization. A vulnerability with CVSS 7.5 and EPSS 0.95 is significantly more urgent than one with CVSS 9.0 and EPSS 0.01, because the first is being actively exploited while the second is only theoretically dangerous so far.

Asset Criticality: Context Makes the Difference

The third factor in prioritization is the criticality of the affected system. Not all systems are equally important. Your ERP system with customer data has a different criticality than the printer in the hallway.

To systematically assess asset criticality, you need an IT asset inventory in which every system is assigned a criticality level. A simple three-tier classification suffices to start: High for business-critical systems with sensitive data or external access, Medium for internal systems with business data, and Low for isolated systems without sensitive data.

The Prioritization Formula

A practical prioritization can be derived from these three factors. A simple approach: multiply the CVSS score (normalized to 0-1), the EPSS score, and an asset criticality factor (e.g., 3 for high, 2 for medium, 1 for low). The result is a context-aware risk value that is significantly more meaningful than the CVSS score alone.

Alternatively, you can use a decision matrix: anything with CVSS 9.0+ and EPSS above 0.1 on business-critical systems is fixed immediately (within 24-48 hours). CVSS 7.0+ with a confirmed exploit gets a one-week deadline. CVSS 4.0+ without a known exploit is addressed in the next regular patch cycle. Anything below CVSS 4.0 is assessed in the quarterly cycle.

However you prioritize: document the methodology in your vulnerability management policy so decisions are traceable and consistent.

The Workflow: From Discovery to Verification

A functioning vulnerability management follows a clearly defined workflow with five steps. Each step has defined inputs, outputs, responsibilities, and deadlines.

Step 1: Scan

Regular scans form the foundation. Frequency depends on the criticality of the systems. External systems (web servers, VPN gateways, mail servers) should be scanned at least weekly. Internal servers and network components at least every two weeks. Endpoints (clients) at least monthly. After every significant infrastructure change, an ad-hoc scan is mandatory.

Beyond automated scans, annual manual penetration tests should be conducted for critical applications. Automated scanners find known vulnerabilities reliably, but they don't detect logic errors, permission issues, or complex attack chains.

Scan timing should be chosen to minimize impact on production operations. Authenticated scans (credentialed scans) deliver significantly more results than unauthenticated ones, as they can also check installed software versions and local configurations.

Step 2: Assess

Scan results are reviewed and cleaned up. This step identifies and marks false positives, consolidates duplicates, and adds context — such as whether the affected system is externally accessible, what data it processes, and whether compensating controls exist.

The assessment should be performed by someone who understands both the technical details and the business context. In many companies, this is the ISO in collaboration with the responsible system administrator.

Step 3: Prioritize

Based on the assessment, each vulnerability is assigned a priority and a remediation deadline. The criteria were defined in your prioritization methodology. The result is an ordered list: what needs to happen immediately, what can wait until next week, and what goes into the regular patch cycle?

For prioritization, it's helpful to consult the CISA KEV database (Known Exploited Vulnerabilities). If a vulnerability is listed there, it's being actively exploited and should be treated with the highest priority regardless of the CVSS score.

Step 4: Remediate

The actual remediation can take various forms. Most common is installing a security patch. Beyond that, there are configuration changes when the vulnerability is caused by an insecure setting, workarounds when no patch is available (such as disabling an affected feature), and compensating controls when the vulnerability can't be directly fixed.

Every measure must be documented: what was done, by whom, when, and on which systems. This documentation is important not only for audits but also for traceability in case the measure has unintended side effects.

Step 5: Verify

After remediation, a follow-up scan is conducted to verify that the vulnerability has actually been closed. This step is frequently skipped in practice but is critical. A patch that wasn't installed correctly, a configuration change that gets overwritten at the next reboot, or a workaround that doesn't cover all attack vectors — all of this can only be detected through verification.

The verification scan should take place within one week of remediation. If the vulnerability is still detected, the issue goes back to Step 4.

Handling Non-Patchable Vulnerabilities

Not every vulnerability can be fixed with a patch. The most common reasons: the vendor has discontinued support (end-of-life), the patch isn't compatible with a business-critical application, the vendor hasn't yet released a patch (zero-day or delayed release), or the vulnerability is architectural and can't be fixed without a fundamental rebuild.

For such cases, the policy must provide for compensating controls. The goal is to reduce the risk to an acceptable level even though the vulnerability itself persists.

Typical compensating controls include network segmentation — isolating the affected system into a separate network segment and restricting access to the minimum. Web Application Firewalls (WAF) can block specific exploitation attempts targeting the vulnerability for web applications. Enhanced monitoring means intensively monitoring the affected system and setting up alerts for suspicious activity. Access restriction means reducing the number of users and systems that can communicate with the vulnerable system. And finally, planning a system replacement: when a system is end-of-life with critical vulnerabilities, a replacement must be planned in the medium term.

Every compensating control must be documented and regularly reviewed for effectiveness. In the ISMS, this is treated as an accepted residual risk with an action plan.

Reporting and KPIs: Measuring Progress

Without metrics, you don't know if your vulnerability management is working. The following KPIs have proven effective in practice and are regularly requested by auditors.

Mean Time to Remediate (MTTR): The average time from discovering a vulnerability to remediation, broken down by criticality. Target values: Critical under 48 hours, High under 7 days, Medium under 30 days, Low under 90 days.

Scan coverage: Percentage of IT assets that are regularly scanned. Target: over 95%. Gaps in scan coverage are a common audit finding.

Number of open vulnerabilities by criticality: Shows the current state and trend over time. If the number of critical open vulnerabilities is rising, something in the process is off.

Overdue rate: Percentage of vulnerabilities that have exceeded their remediation deadline. This metric shows whether defined SLAs are being met.

Recurrence rate: Percentage of vulnerabilities that reappear after remediation. A high recurrence rate indicates problems in patch management or configuration management.

False positive rate: Percentage of findings that turn out to be false alarms. A high rate wastes the team's time and undermines trust in the scanner.

Reporting should go to IT management monthly and to executive management quarterly. For the C-suite, a management summary with key KPIs, the trend, and a risk assessment is sufficient. The details are only needed by the operational team.

Audit Evidence: What Auditors Want to See

During an ISMS audit or NIS2 review, vulnerability management is regularly scrutinized. Auditors look for specific aspects you should have prepared.

The policy itself: A documented process for vulnerability management with defined roles, scan frequencies, prioritization criteria, and remediation deadlines.

Scan logs: Evidence that scanning occurs regularly. Auditors like to review the last six months and check whether defined frequencies were maintained.

Vulnerability tracking: Traceable documentation of every relevant vulnerability: when discovered, how assessed, what measure was taken, when remediated, when verified. Whether you do this in a ticket system, a spreadsheet, or a specialized tool is secondary — as long as traceability is ensured.

Handling of critical vulnerabilities: Auditors look especially closely at vulnerabilities with high CVSS scores. How quickly was the response? Was the deadline met? If not, why not, and what compensating controls were implemented?

Non-patchable vulnerabilities: For every vulnerability that is deliberately not fixed, a documented risk acceptance with justification and compensating controls must exist.

KPIs and trends: Monthly or quarterly reporting that shows how the vulnerability landscape is developing. Auditors want to see that you have oversight and improvements are visible.

Integration into the ISMS

Vulnerability management doesn't exist in isolation but is linked to several other ISMS processes. Asset management provides the inventory of systems to scan and their criticality classification. Risk management takes over non-patchable vulnerabilities as identified risks. Incident management is activated when an actively exploited vulnerability is discovered where compromise cannot be ruled out. Change management ensures patches and configuration changes are carried out in a controlled manner. And supplier evaluation asks third-party vendors about how they handle vulnerabilities in their products.

These linkages should be described in the policy so it's clear where vulnerability management provides information and from which processes it receives information.

Getting Started: A Pragmatic Approach

If you don't yet have formal vulnerability management, building it can feel overwhelming. The good news: you don't have to do everything at once. A pragmatic start in three phases can look like this.

Phase 1 (Months 1-2): Install a scanner (OpenVAS is sufficient to start), run an initial scan of the most critical systems, and fix findings with CVSS 9.0+. Document what you do.

Phase 2 (Months 3-4): Expand the scan to the entire infrastructure, define prioritization criteria and remediation deadlines, set up a regular scan schedule, and begin KPI tracking.

Phase 3 (Months 5-6): Formalize the policy, integrate the process into your ISMS, establish reporting to executive management, and conduct the first verification cycle.

After six months, you have a functioning process that you can continuously improve. In ISMS Lite, vulnerability findings can be directly captured as risks, linked to measures, and tracked through to verification. The tool costs 500 Euro pro Jahr for all modules, with no per-seat licenses. That's the core of an ISMS: don't start perfectly — start and improve.

Further Reading

• Patch Management for Mid-Market Companies: Planning, Testing, and Deploying Updates
• IT Asset Management in the ISMS: Knowing What You Need to Protect
• Protection Needs Assessment: Systematically Evaluating What Needs Protection
• Network Segmentation for SMEs: Simple, Effective, Affordable
• NIS2 Checklist: All Requirements at a Glance