Patch Management

Known, patchable vulnerabilities are responsible for the vast majority of successful cyberattacks. This sounds paradoxical: if a patch is available, shouldn't the problem be solved? The reality in enterprise environments looks different. Patch cycles take weeks or months. System dependencies delay updates. OT systems cannot simply be restarted. Legacy systems are no longer supported. And in many organisations, there is no complete overview of which systems even exist.

The numbers are unambiguous: according to the Verizon Data Breach Investigations Report, 40–60% of all data breaches are caused by known vulnerabilities for which patches were already available. This means a substantial portion of security investment is eroded by a lack of basic patch management discipline. Anyone who genuinely wants to improve security must start here.

The challenge is not a lack of awareness but a lack of process. Most organisations lack the structured combination of: complete asset inventory, automated vulnerability scanning, risk-based prioritisation, defined SLAs, staging environments for testing, controlled rollout, and tracking. Individual elements often exist – the structural interplay is missing.

Patch status is a snapshot of the current patch state across all systems in an IT environment: which systems have which patches installed, which are outstanding, and how long have known gaps been open? Without complete visibility into patch status, structured patch management is impossible – and risk assessments remain speculative. The first task in every patch management project is therefore establishing the current state: a complete asset inventory combined with a vulnerability scan that shows the current patch status for every asset.

Methods for assessing patch status vary by infrastructure and operating model. Agent-based scanning (Tenable Agent, Qualys Cloud Agent, Rapid7 Insight Agent) delivers continuous patch status data directly from the endpoint – including systems that are not permanently reachable on the network (laptops, remote devices, cloud instances). Agentless scanning via network scans covers systems by reachability but requires open ports and appropriate credentials. In heterogeneous environments we combine both approaches: agent-based for endpoints and critical servers, network-based for OT systems, network components, and external assets. The result is a consolidated patch status report with complete asset coverage.

From patch status data, the central steering metrics of a patch management programme can be derived: Mean Time to Remediate (MTTR) – how long does it take on average to remediate a known vulnerability? Patch Compliance Rate – what percentage of systems meet the defined patch standard for critical, high, and medium vulnerabilities? Vulnerability Age – how many days are vulnerabilities open on average? These metrics are not only relevant for internal reporting but are explicitly embedded in regulatory frameworks: ISO 27001 Annex A.8.8 requires documented technical vulnerability management, NIS2 Article 21 mandates risk-based measures that presuppose measurable patch status monitoring. Auditors do not ask about the process – they ask for evidence.

An effective patch management process begins with complete asset visibility: you cannot patch what you do not know about. We ensure your system inventory is complete and current – a critical step that in many projects requires more effort than expected. On this foundation, a continuous vulnerability scan is built that identifies new CVEs in your environment within hours.

Prioritising identified vulnerabilities is the heart of the process. CVSS scores alone are insufficient: a critical vulnerability (CVSS 9.8) on an isolated internal system is less urgent than a medium vulnerability (CVSS 6.5) on a publicly accessible web server. We prioritise based on a combination of CVSS score, exploit availability (EPSS), asset criticality, and actual reachability.

Based on this prioritisation we define SLA classes: Critical (CVSS 9+, actively exploited): 24–72 hours. High (CVSS 7–9): 7–14 days. Medium: 30 days. Low: 90 days. These SLAs are anchored in a patch governance process that defines responsibilities, escalation paths, and exception approvals.

The choice of the right tools depends on your infrastructure and operating model. For Windows-heavy environments, Microsoft Endpoint Configuration Manager (MECM/SCCM) or Intune offer structured patch distribution with group-based rollout rings. For heterogeneous Linux/Windows environments, Ansible or Puppet are powerful automation platforms. For continuous vulnerability scanning we use Tenable, Qualys, Rapid7, or OpenVAS depending on requirements.

Critical is the integration of these tools into a coherent workflow: the vulnerability scanner identifies new CVEs, delivers results to a central VM platform, which prioritises and creates tickets (Jira, ServiceNow), the patch management tool distributes updates according to defined ring groups (test, pilot, production), and the scanner verifies successful remediation after deployment. This cycle should run without manual intervention – except for risk decisions.

Emergency patch processes are a frequently overlooked element. When zero-day vulnerabilities or actively exploited critical CVEs become known – as with Log4Shell, ProxyLogon, or PrintNightmare – normal patch cycles are insufficient. We define clear escalation processes and emergency rollout procedures that enable a response time of a few hours.