Patch-Management und Vulnerability-Management: Strukturierte IT-Sicherheitsprozesse für den Mittelstand

23. Juni 2026

Artikel teilen

Patch-Management und Vulnerability-Management gehören zu den wirksamsten, aber in vielen mittelständischen Unternehmen auch zu den am stärksten vernachlässigten IT-Sicherheitsprozessen. Studien und Vorfallsanalysen zeigen konsistent, dass ein erheblicher Anteil erfolgreicher Cyberangriffe bekannte Schwachstellen ausnutzt, für die längst Patches verfügbar waren, die aber schlicht nicht eingespielt wurden. Das Problem ist selten fehlende Technik, sondern fehlende Prozessstruktur: Wer ist zuständig? In welchem Zeitfenster muss ein kritisches Update eingespielt werden? Wie wird der Patch-Status dokumentiert? Dieser Beitrag legt die operative Grundlage beider Prozesse dar, erklärt die Unterschiede und Zusammenhänge, benennt typische Stolperfallen und zeigt, wie auch ein mittelständisches Unternehmen ohne dediziertes Security-Team ein funktionsfähiges Programm aufbauen kann.

Grundbegriffe: Patch-Management und Vulnerability-Management im Vergleich

Beide Begriffe werden im Sprachgebrauch häufig synonym verwendet, beschreiben aber unterschiedliche, sich ergänzende Prozesse.

Vulnerability-Management bezeichnet den kontinuierlichen Prozess der Identifikation, Bewertung und Priorisierung von Schwachstellen in der eigenen IT-Infrastruktur. Es umfasst das regelmäßige Scannen aller Systeme (Server, Endpunkte, Netzwerkgeräte, Applikationen), die Bewertung gefundener Schwachstellen nach Schweregrad und Ausnutzbarkeit sowie die Planung von Gegenmaßnahmen.

Patch-Management ist der operative Prozess, mit dem Sicherheitsupdates (Patches) und Softwareaktualisierungen beschafft, geprüft, verteilt und in Betrieb genommen werden. Es ist die primäre Reaktion auf identifizierte Schwachstellen, aber nicht die einzige: Manche Schwachstellen werden durch Konfigurationsänderungen oder Netzwerksegmentierung geschlossen, bevor oder anstatt ein Patch verfügbar ist (sogenannte Workarounds oder Kompensationsmaßnahmen).

Das Vulnerability-Management bestimmt, was gepatcht oder anderweitig behoben werden muss und mit welcher Priorität. Das Patch-Management liefert die operative Umsetzung. Ohne den ersten Prozess fehlt die Grundlage für den zweiten. Ohne den zweiten bleibt das erste ein reines Dokumentationsvorhaben.

Regulatorische Anforderungen: NIS2 und ISO 27001

NIS2-Richtlinie und Pflichten für betroffene Unternehmen

Die NIS2-Richtlinie (EU 2022/2555), die in Deutschland durch das NIS2UmsuCG in nationales Recht umgesetzt wird, verpflichtet Unternehmen aus bestimmten Sektoren (darunter Energie, Transport, Gesundheit, digitale Infrastruktur und weitere) zur Umsetzung von Mindestmaßnahmen für Cybersicherheit. Zu diesen Maßnahmen zählt ausdrücklich das Management von Schwachstellen und der Umgang mit Sicherheitsupdates. Unternehmen, die unter den NIS2-Anwendungsbereich fallen, sind verpflichtet, Schwachstellen-Management-Prozesse einzurichten und nachzuweisen.

Für Unternehmen außerhalb des direkten Anwendungsbereichs entfaltet NIS2 eine mittelbare Wirkung über Lieferkettenanforderungen: Wer als Lieferant oder Dienstleister für NIS2-pflichtige Unternehmen tätig ist, wird zunehmend nach eigenen Sicherheitsstandards bewertet.

ISO 27001: Annex-A-Kontrollen zu Patch- und Vulnerability-Management

ISO 27001:2022 enthält in Anhang A, Kontrollbereich 8 (Technologische Kontrollen) spezifische Anforderungen. Kontrolle 8.8 (Management von technischen Schwachstellen) fordert, dass Informationen über technische Schwachstellen zeitnah beschafft, die Anfälligkeit des Unternehmens bewertet und geeignete Maßnahmen ergriffen werden. Kontrolle 8.19 (Installation von Software auf Betriebssystemen) regelt den kontrollierten Umgang mit Softwareinstallationen und -aktualisierungen. Für zertifizierte Unternehmen sind diese Kontrollen verbindlich auditierbar.

Vulnerability-Scanning: Schwachstellen systematisch erfassen

Der erste operative Schritt im Vulnerability-Management ist die regelmäßige Inventarisierung aller IT-Assets und die anschließende Scan-basierte Schwachstellenerfassung. Dabei gilt: Man kann nur schützen, was man kennt. Ein aktuelles, vollständiges Asset-Inventar (Hardware, Software, Versionen, Netzwerkzuordnung) ist die unverzichtbare Grundlage.

Vulnerability-Scanner prüfen Systeme auf bekannte Schwachstellen, indem sie Softwareversionen, Konfigurationen und offene Dienste gegen öffentlich verfügbare Schwachstellendatenbanken (insbesondere die NVD, National Vulnerability Database, und den CVE-Katalog der MITRE Corporation) abgleichen. Marktgängige Scanner für den Mittelstand sind unter anderem Tenable Nessus, OpenVAS (Open-Source) und Qualys VMDR. Microsoft bietet mit Microsoft Defender Vulnerability Management eine integrierte Lösung für Windows-Umgebungen.

Empfohlen ist mindestens ein vollständiger Scan aller Systeme pro Monat sowie anlassbezogene Scans nach Vorfällen oder größeren Systemänderungen. Kritische Systeme, insbesondere öffentlich erreichbare Server und Systeme mit sensiblen Daten, sollten häufiger gescannt werden.

Schwachstellen bewerten und priorisieren: CVSS und Business Context

Nicht jede gefundene Schwachstelle erfordert sofortiges Handeln. In einem typischen Unternehmensnetzwerk finden Scanner bei einem vollständigen Scan Hunderte bis Tausende von Einträgen, von denen viele entweder geringes Risiko aufweisen oder in der spezifischen Umgebung nicht ausnutzbar sind. Eine strukturierte Priorisierung ist deshalb unerlässlich.

Das Common Vulnerability Scoring System (CVSS) liefert einen standardisierten Schweregrad-Score von 0 bis 10 für jede CVE-Schwachstelle. Die Skala gliedert sich in:

CVSS-Score	Bewertung	Empfohlenes Handlungsfenster
9,0–10,0	Kritisch	24–72 Stunden (außerplanmäßiger Patch)
7,0–8,9	Hoch	7 Tage
4,0–6,9	Mittel	30 Tage (nächster Patch-Zyklus)
0,1–3,9	Niedrig	90 Tage oder nach Risikoabwägung

Der CVSS-Score allein ist jedoch kein hinreichender Priorisierungsmaßstab. Ausschlaggebend ist der tatsächliche Business Context: Eine „mittlere“ Schwachstelle auf einem öffentlich erreichbaren Webserver, der Kundendaten verarbeitet, kann ein höheres Unternehmensrisiko darstellen als eine „hohe“ Schwachstelle auf einem Laborsystem ohne Netzanbindung. Die Priorisierung sollte deshalb CVSS-Score, Exponierung des Systems (intern vs. extern), Ausnutzbarkeit in freier Wildbahn (Known Exploited Vulnerabilities, KEV-Katalog der CISA) und Schutzbedarf der betroffenen Daten kombinieren.

Patch-Management-Prozess: Operativer Ablauf Schritt für Schritt

Patchzyklen definieren

Patch-Management funktioniert am besten mit definierten, regelmäßigen Zyklen, die im Betriebskalender verankert sind. Verbreitet ist ein monatlicher Patch-Zyklus, der sich am „Patch Tuesday“ von Microsoft orientiert (zweiter Dienstag eines jeden Monats), da Microsoft und viele andere Anbieter ihre Updates gesammelt zu diesem Termin veröffentlichen. Ergänzend dazu sollte ein Prozess für außerplanmäßige Notfall-Patches (Emergency Patches) definiert sein, der bei kritischen Schwachstellen mit aktiver Ausnutzung greift.

Test vor Deployment

Patches sollten grundsätzlich nicht ohne vorherigen Test auf Produktionssystemen eingespielt werden. In der Praxis bedeutet das für viele mittelständische Unternehmen: zunächst Einspielen auf Testsystemen oder einer kleineren Referenzgruppe (Pilotgruppe, z.B. IT-Mitarbeitende), Monitoring über 24 bis 72 Stunden, dann breites Rollout. Für kritische Schwachstellen mit aktivem Exploit kann das Testfenster auf wenige Stunden verkürzt werden, sofern die Funktionskritikalität des Patches dies zulässt.

Dokumentation und Nachweis

Jeder eingespielter Patch ist zu dokumentieren: welches System, welcher Patch, wann eingespielt, von wem autorisiert, Ergebnis des Tests. Diese Dokumentation dient nicht nur internen Audit-Zwecken, sondern auch als Nachweis gegenüber externen Prüfern (ISO 27001 Audit, Kundenanfragen, Versicherungsnachweis). Viele Endpoint-Management-Plattformen (WSUS, Microsoft Intune, MECM, Jamf) erzeugen diese Dokumentation automatisch als Patch-Compliance-Bericht.

Umgang mit Systemen, die nicht gepatcht werden können

Eine praktisch bedeutsame Herausforderung sind Systeme, auf denen Patches aus technischen oder betrieblichen Gründen nicht oder nur verzögert eingespielt werden können. Klassische Fälle im Mittelstand sind ältere Produktionsmaschinen mit eingebetteten Betriebssystemen (Windows XP oder Windows 7 in Steuerungsumgebungen), Spezialsoftware, die nur mit einer bestimmten Betriebssystemversion zertifiziert ist, und Drittsystemkomponenten, für die keine Updates mehr bereitgestellt werden (End of Life).

Für diese Systeme sind Kompensationsmaßnahmen zu definieren und zu dokumentieren. Typische Kompensationskontrollen umfassen Netzwerksegmentierung (das System wird in ein isoliertes VLAN verschoben und hat keine direkte Internetverbindung), strikte Zugangskontrolle (nur namentlich benannte Systeme und Nutzer dürfen kommunizieren), erhöhtes Monitoring (anomale Kommunikationsmuster werden aktiv überwacht) und physische Sicherheitsmaßnahmen. Das Risiko aus gepatchten Systemen ist für die Dokumentation festzuhalten und regelmäßig neu zu bewerten.

Typische Stolperfallen im Patch- und Vulnerability-Management

Kein Asset-Inventar: Ohne vollständige Übersicht aller Systeme werden Schwachstellen auf unbekannten Assets nicht identifiziert. Shadow-IT-Systeme, die ohne IT-Abteilung eingeführt wurden, sind ein häufiger blinder Fleck.
Reaktiver statt proaktiver Ansatz: Patches werden erst eingespielt, wenn ein Vorfall oder eine externe Meldung dazu zwingt. Ein proaktiver, zyklischer Prozess ist deutlich effektiver.
Fehlende Zuständigkeiten: Wenn nicht klar definiert ist, wer für Server, Endpunkte, Netzwerkgeräte und Applikationen zuständig ist, entstehen Lücken. Jedes Asset braucht einen benannten Eigentümer (Asset Owner).
Vernachlässigte Drittanbieter-Software: Patches für Betriebssysteme werden oft eingespielt, während Browser-Plugins, PDF-Reader, Office-Suiten und andere Drittanbieter-Software veraltet bleiben. Diese sind häufig Angriffsvektoren.
Keine Erfolgskontrolle: Nach dem Patch-Deployment wird nicht systematisch geprüft, ob der Patch tatsächlich erfolgreich auf allen Zielsystemen eingespielt wurde. Ausstehende Systeme bleiben verwundbar, ohne dass dies bekannt ist.

Reporting und Metriken: Den Prozessreifegrad messen

Ein funktionsfähiges Patch- und Vulnerability-Management erzeugt messbare Kennzahlen, die sowohl die operative Steuerung als auch die Kommunikation gegenüber Geschäftsführung und Revisoren ermöglichen. Wesentliche Metriken sind:

Mean Time to Patch (MTTP): Durchschnittliche Zeit zwischen Veröffentlichung eines Patches und seiner Einspielung auf allen betroffenen Systemen. Ein MTTP von unter 30 Tagen für kritische Patches gilt als angestrebter Zielwert in gut aufgestellten mittelständischen IT-Abteilungen.
Patch Compliance Rate: Anteil der Systeme, auf denen ausstehende Patches eingespielt wurden. Ein Wert über 95 Prozent für kritische Patches sollte angestrebt werden.
Offene Schwachstellen nach Schweregrad: Anzahl kritischer, hoher und mittlerer offener Einträge im Vulnerability-Tracking, je nach Alter (unter 7 Tage, 7 bis 30 Tage, über 30 Tage).
Recurring Vulnerabilities: Schwachstellen, die nach einem Patch-Deployment erneut auftreten, weil der Patch nicht dauerhaft angewendet wurde oder weil das zugrundeliegende Problem struktureller Natur ist.

Diese Metriken sollten monatlich im Rahmen eines kurzen Security-Reports aufbereitet werden. Der Report ermöglicht eine Trendanalyse: Verbesserungen und Verschlechterungen werden sichtbar, bevor sie zu Sicherheitsvorfällen werden. Für die Geschäftsführungskommunikation reichen aggregierte Ampelwerte (grün, gelb, rot) aus, ohne technische Details.

Ein praktischer Einstieg ohne vollständige Tool-Landschaft: Eine strukturierte Tabelle (Excel oder ein einfaches Ticket-System) mit Feldern für CVE-ID, betroffenes System, CVSS-Score, Verantwortlicher, Zieldatum und Status erlaubt bereits eine erhebliche Verbesserung gegenüber unsystematischem Vorgehen. Entscheidend ist nicht die Perfektion der Tools, sondern die Regelmäßigkeit und Konsequenz des Prozesses.

Tool-Unterstützung für den Mittelstand

Der Markt bietet abgestufte Lösungen für unterschiedliche Unternehmensgrößen und IT-Ressourcen. Für Unternehmen mit reiner Windows-Umgebung und Microsoft-Lizenzierung ist Microsoft Intune in Kombination mit Defender Vulnerability Management ein kosteneffizientes Einstiegsszenario. Plattformübergreifende Umgebungen profitieren von dedizierten Vulnerability-Management-Tools wie Tenable.io oder Qualys. Für ressourcenschwache IT-Abteilungen bieten Managed Security Service Provider (MSSP) Patch- und Vulnerability-Management als externen Dienst an, was den internen Aufwand erheblich reduziert, aber eine sorgfältige Auswahl und vertragliche Absicherung erfordert.

FAQ

Wie häufig sollte ein Vulnerability-Scan durchgeführt werden?

Mindestens monatlich für alle Systeme. Kritische und extern erreichbare Systeme sollten wöchentlich oder bei Bedarf kontinuierlich gescannt werden. Nach größeren Infrastrukturänderungen ist ein anlassbezogener Scan obligatorisch.

Was ist der Unterschied zwischen einem Patch und einem Update?

Ein Patch behebt gezielt eine bekannte Schwachstelle oder einen Fehler. Ein Update kann Patches enthalten, umfasst aber häufig auch neue Funktionen und Konfigurationsänderungen. Im Sicherheitskontext wird „Patch“ spezifischer für sicherheitsrelevante Korrekturen verwendet.

Welche Systeme haben Vorrang beim Patchen?

Systeme mit hohem Schutzbedarf und hoher Exposition werden zuerst gepatcht: öffentlich erreichbare Server, Systeme mit personenbezogenen oder besonders schützenswerten Daten, Domain-Controller und Authentifizierungsinfrastruktur. Endpunkte folgen danach.

Was tun, wenn ein kritischer Patch zu einem Systemausfall führt?

Ein vorab definierter Rollback-Plan ist essenziell. Systemimages oder Snapshots (in virtualisierten Umgebungen) ermöglichen eine schnelle Wiederherstellung. Außerhalb der Testphase sollten Patches immer mit Backup und Rollback-Option eingespielt werden.

Müssen auch Cloud-Dienste gepatcht werden?

Bei Cloud-Diensten (SaaS) übernimmt der Anbieter das Patchen der Infrastruktur. Dennoch verbleiben im Shared-Responsibility-Modell Verantwortlichkeiten beim Unternehmen: Anwendungskonfigurationen, Zugriffsrechte, eigene Erweiterungen und Integrationen müssen auf Schwachstellen geprüft und aktuell gehalten werden.

Ab wann lohnt sich ein dediziertes Vulnerability-Management-Tool?

Ab einer Größenordnung von 50 bis 100 verwalteten Systemen wird ein dediziertes Tool effizienter als manuelle Prozesse. Unterhalb dieser Schwelle kann ein einfacher Scanner (z.B. OpenVAS) in Kombination mit einer strukturierten Tracking-Liste ausreichen.