Patchmanagement: Die unterschätzte Pflicht zwischen Alltag und Angriff

The major waves of attacks in recent years had one thing in common: they did not exploit unknown security vulnerabilities, but rather long-known vulnerabilities for which an update was availableWhether it's Exchange vulnerabilities or Log4j — attackers were faster than the victims' update processes. That is why patch management is not a janitorial task, but the most cost-effective defense available.

Why patching fails in practice

• No inventory: What nobody knows, nobody can patch. This applies especially to older servers, printers, firewall appliances, and software that is "running somewhere".
• Fear of downtime: Updates are postponed because a restart during the day is not feasible — and then they are never completed.
• Unclear responsibility: The service provider thinks the customer is doing it; the customer thinks the service provider is doing it.
• No evidence: Patching is being performed, but no one can demonstrate which system was at which version level at any given time.

The minimum standard for a resilient process

• Complete inventory: Every device, every application, every firmware — automatically detected, not maintained via Excel.
• Vulnerability Scanning: regularly and automatically, instead of waiting for vendor emails.
• Prioritization based on exploitability: Not every vulnerability is the same. What matters is whether an attack already exists in the wild (keyword: Known Exploited lists), not just the theoretical assessment.
• Critical updates within 72 hours, everything else within the planned maintenance window — with a test ring prior to the production system.
• Documentation: Date, system, result. This simultaneously serves as your NIS2 evidence.

NIS2 turns "should" into a requirement.

The German implementation of NIS2 requires risk management measures according to the state of the art — this explicitly includes vulnerability management. Affected companies must not only implement the process but also provide proof upon request can. The executive management bears personal responsibility for this.

What a service provider takes off your hands in this regard

A Managed Service Partner takes over exactly those areas where internal efforts often fail: inventory, vulnerability measurement, tested rollouts within maintenance windows, and comprehensive documentation. Your internal IT retains sovereignty over specialist applications and approvals—the rest is managed as a measurable metric, not as a good intention.

Note: This article is not a substitute for legal advice. It serves as an initial orientation; the binding examination of your situation should be handled by experts.

← all guides