Patch Management: A Practical Guide

Why patch management is a process, not a tool

Many security incidents start with a vulnerability that an update could have fixed long ago. Typical cases are an unpatched VPN gateway, an outdated web server or a forgotten line-of-business application. A tool that rolls out software does not solve this on its own. What you need is a workflow with:

• clear ownership
• fixed deadlines
• a full view of what needs patching

The German BSI IT-Grundschutz lists the requirements in module OPS.1.1.3 "Patch and Change Management".

The patch process in six steps

1. Inventory: Without a full asset inventory, gaps go unnoticed. Record servers, clients, network parts, cloud services, business apps and firmware. Note the version and owner of each.
2. Intelligence: Track vendor advisories, BSI security notices and CERT warnings. Microsoft releases its regular updates on Patch Tuesday, the second Tuesday of each month. Other vendors follow their own cycles or publish as needed.
3. Assessment and prioritisation: Not every patch is equally urgent. Priority depends on how severe the flaw is, how likely an exploit is and how important the system is (see below).
4. Testing: Critical systems get updates first in a test setup or on a small group that stands for the rest.
5. Deployment: Roll out in stages using rollout rings. Plan a way to roll back.
6. Verification: A vulnerability scan or an inventory check confirms that the patch is really in place. "Deployed" does not mean "effective". A pending reboot can leave the system exposed.

Prioritisation: combining CVSS, EPSS and CISA KEV

The CVSS (Common Vulnerability Scoring System) rates the technical severity of a vulnerability from 0 to 10. It says nothing about whether the flaw is being attacked right now. If you go by CVSS alone, you soon end up with hundreds of "critical" tasks.

EPSS (Exploit Prediction Scoring System) is run by FIRST. It estimates how likely it is that a flaw will be exploited in the next 30 days. The CISA KEV catalogue (Known Exploited Vulnerabilities) lists flaws that are known to be under active attack. It is a US source. Still, it is a very useful signal for European companies too.

A workable order is:

1. flaws in the KEV catalogue and on internet-facing systems
2. flaws with high EPSS scores
3. flaws with high CVSS scores on business-critical systems

Set an internal deadline for each tier. For example, allow a few days for actively exploited flaws on exposed systems. Use a monthly cycle for routine updates.

Testing and rollout rings

A proven pattern is a series of rings that reach more and more systems:

• Ring 0: IT's own test systems
• Ring 1: a pilot group drawn from different departments
• Ring 2: most of the clients
• Ring 3: very sensitive systems such as production servers

Short watch periods sit between the rings. For emergency patches the rings are shortened. Where the risk allows, they are not skipped entirely.

Third-party software and firmware

Operating system updates are usually well automated. The real gaps tend to show up elsewhere:

• browser plug-ins
• PDF readers
• Java runtimes
• business apps with their own updaters
• libraries in in-house software

Firmware for firewalls, switches, printers, hypervisors and BIOS/UEFI must also be part of the process. For software libraries, a software bill of materials (SBOM) helps you find affected parts fast.

Production and OT environments

In operational technology (OT), you often cannot apply updates right away. Plants run around the clock. Vendors must approve patches. Some controllers are no longer supported at all.

Compensating controls are key here: network segmentation, strict firewall rules, secured remote maintenance access and monitoring. Patches go in during planned maintenance windows. Systems that cannot be patched are tracked as a deliberate, documented residual risk.

Emergency patches

Zero-day flaws under active attack call for an emergency process that is set up in advance. It should answer these questions:

• Who may decide outside the regular change process?
• What is the least testing required?
• Which interim steps apply until a patch is out? Examples are workarounds, turning off a service or blocking at the perimeter.

You should also check whether the flaw was already exploited before the patch went in.

Metrics

• Patch latency: time from a patch's release to its installation, broken down by priority.
• Coverage: share of systems on the current patch level, measured against the full inventory.
• Deadline compliance: share of critical flaws closed within the internal deadline.
• Exceptions: number and age of documented exceptions with formal risk acceptance.

Relevance to NIS2

NIS2 (Directive (EU) 2022/2555) clearly requires risk management measures for security when you buy, build and maintain systems. This includes how you handle vulnerabilities. In Germany, Section 30 of the revised BSIG puts this into law. So entities in scope should document their patch process and use its metrics as evidence. ISO/IEC 27001:2022 also requires such a process through its control on the management of technical vulnerabilities.

Conclusion

Good patch management rests on three things: a full inventory, priorities based on real-world attacks and deadlines you can measure. SecTepe helps build the process and link it to your ISMS and NIS2 evidence.

Frequently asked questions

Should updates be installed automatically?

For clients and standard software, generally yes, combined with rollout rings. For servers and production systems, a controlled approval works better.

What about systems without vendor support?

Plan to replace them. Until then, isolate them and keep access to a minimum. The owners should formally accept the residual risk.