Vulnerability Management

Vulnerability scanning is an automated detection process: a tool searches defined hosts, IP ranges, or applications for known CVEs and misconfigurations and produces a report. This can happen once – before an audit, after a system change – or be scheduled on a regular basis. The result is a list of findings. Vulnerability management, by contrast, is the structured, continuous process that uses scanning as a data source but goes far beyond it: who is responsible for remediation? Within what timeframe? What happens if the deadline is not met? How is it documented that a vulnerability has been closed or accepted as an exception?

The decisive difference lies in operationalisation: a vulnerability scan generates data. Vulnerability management turns that data into decisions and actions. Concretely this means: risk-based prioritisation, where CVSS score alone is insufficient – asset criticality, network exposure, and active exploitability (EPSS, CISA KEV) are at least equally important. Defined SLA classes: critical vulnerabilities within 24–72 hours, high-severity within 7–14 days. Automated ticket workflows in ITSM systems (Jira, ServiceNow). Structured exception management for vulnerabilities that cannot be remediated immediately. And KPIs – Mean Time to Remediate, Patch Compliance Rate – that make progress measurable and demonstrable to auditors.

When do you need which? A one-time vulnerability scan makes sense as a starting point, before and after major infrastructure changes, or when a point-in-time audit evidence is required. A full VM programme is needed when continuous security improvement is the goal – and when regulatory requirements demand it: NIS2 Article 21 requires risk-based measures with measurable effectiveness, ISO 27001 Annex A.8.8 mandates documented vulnerability management with remediation evidence, and DORA requires financial entities to maintain a formal ICT risk management process. In all three cases, periodic scanning alone is insufficient as evidence.

Vulnerability Management (VM) is the structured, continuous process for identifying, classifying, prioritising, and remediating security vulnerabilities in IT systems. The difference from a one-time penetration test is fundamental: a penetration test is a snapshot that shows how the system looks today. VM is a sustained process that ensures new vulnerabilities are identified – with every new CVE, every configuration change, every new system component.

A complete VM programme encompasses far more than subscribing to a vulnerability scanner. It requires complete asset visibility (you cannot scan what you do not know about), a defined scan cadence (continuous for critical systems, weekly or monthly for others), clear prioritisation criteria, responsibilities for remediation, SLAs for different vulnerability classes, exception management for vulnerabilities that cannot be immediately remediated, and KPIs to measure programme effectiveness.

Many organisations have vulnerability scanners in place but no VM programme: scans run irregularly, results are not prioritised, tickets are created but not consistently tracked, and exceptions are agreed verbally. The result is a growing backlog with no clearly measurable risk reduction. We help you turn a scanning practice into a functioning programme.

CVSS (Common Vulnerability Scoring System) is a useful tool for assessing the technical severity of a vulnerability – but insufficient as the sole prioritisation criterion. A CVSS 9.8 on an isolated internal system is less urgent than a CVSS 6.5 on a publicly accessible web server. And a vulnerability with CVSS 7.0 for which an exploit kit exists and which is actively exploited in ransomware campaigns is more critical than a theoretical CVSS 9.0 with no known exploitation.

We develop risk-based prioritisation models that combine multiple factors: CVSS score as a base indicator, EPSS (Exploit Prediction Scoring System) for the probability of active exploitation, CISA KEV (Known Exploited Vulnerabilities) as a signal for vulnerabilities actively being used in the wild, asset criticality (what would the damage be if this system were compromised?), network exposure (internal vs. DMZ vs. internet-facing), and compensating controls (is a WAF or IPS in front of the system?).

The result is a prioritised work list that directs resources towards the genuinely riskiest vulnerabilities – rather than treating all equally. In a typical enterprise environment there are thousands of open CVEs; with risk-based prioritisation, effort concentrates on the 1–5% that dominate the actual risk profile.

VM does not function as an isolated process. Close integration with patch management is essential: VM identifies vulnerabilities, patch management closes them. Both processes need the same asset inventory, and the ticketing system connects them. We ensure that the data flow between the VM platform (Tenable, Qualys, Rapid7) and patch management tools (SCCM, Intune, Ansible) is automated and frictionless.

The effectiveness of a VM programme is made measurable through KPIs. Important metrics include: Mean Time to Remediate (MTTR) by vulnerability class, patch compliance rate (percentage of systems without open critical vulnerabilities), scan coverage (percentage of inventoried systems that are actually scanned), and exception backlog (how many vulnerabilities are accepted as exceptions, and why). These KPIs make the programme transparent to management and evidenceable to auditors.

VM programmes often fail not because of technology but because of organisation: when responsibilities are unclear, SLAs are not met, and escalation paths do not work, vulnerabilities accumulate rather than being remediated. We help establish not only the technical tooling but also the governance structures that keep the programme effective over the long term.