Patch-Management: Patch-Management bezeichnet den systematischen, dokumentierten Prozess, mit dem ein Unternehmen Sicherheitsupdates für Betriebssysteme und Software zeitnah bewertet, priorisiert und einspielt, um bekannte Schwachstellen zu schließen, bevor sie ausgenutzt werden.
Der Prozess beginnt mit der Erfassung, welche Patches für welche Systeme überhaupt verfügbar sind – ein Inventar aus Hard- und Software ist dafür Voraussetzung. Anschließend wird jeder Patch nach Kritikalität eingestuft, häufig anhand des CVSS-Score der zugrunde liegenden Schwachstelle, und in eine Reihenfolge gebracht: kritische Sicherheitslücken werden typischerweise deutlich schneller geschlossen als unkritische Funktionsupdates.
ISO 27001:2022 verankert das Thema in Anhang A gleich zweifach: A.8.8 verlangt, dass Informationen über technische Schwachstellen zeitnah beschafft, die Gefährdung des Unternehmens bewertet und geeignete Maßnahmen ergriffen werden. A.8.19 regelt ergänzend die kontrollierte Installation von Software auf Systemen im Betrieb, damit Patches nicht unkoordiniert und ungetestet ausgerollt werden.
In der Praxis bewährt sich ein zweistufiges Vorgehen: Patches werden zunächst in einer Testumgebung geprüft, bevor sie produktiv ausgerollt werden, und jeder Schritt wird dokumentiert – wer hat wann welchen Patch auf welchem System eingespielt.
- Inventar aller Systeme als Voraussetzung für vollständiges Patch-Management
- Priorisierung nach Kritikalität, oft anhand des CVSS-Score
- ISO 27001:2022 Anhang A.8.8 (Schwachstellenhandhabung) und A.8.19 (Softwareinstallation)
- Test vor Produktivsetzung sowie lückenlose Dokumentation jedes Patch-Vorgangs
Fehlt ein strukturierter Prozess, bleiben bekannte Lücken oft monatelang offen – ein Einfallstor, das nicht technisches Unwissen, sondern schlicht fehlende Organisation offenlegt.
Relevanz für die Zertifizierung
Patch-Management ist kein IT-Selbstzweck, sondern für die ISO-27001-Zertifizierung ein konkret geprüfter Nachweis: Der Auditor verlangt einen dokumentierten Prozess, der zeigt, wie Schwachstellen erkannt, nach Kritikalität priorisiert und innerhalb definierter Fristen geschlossen werden – reine Absichtserklärungen ohne Nachweis über tatsächlich eingespielte Patches reichen für Anhang A.8.8 und A.8.19 nicht aus. Wer noch keinen festen Patch-Rhythmus hat, sollte vor dem Zertifizierungsaudit zumindest eine einfache Liste führen: welches System, welcher Patch, welches Datum, wer verantwortlich war. Auch der Umgang mit Systemen, die aus betrieblichen Gründen nicht sofort gepatcht werden können, muss im ISMS nachvollziehbar begründet und mit Kompensationsmaßnahmen versehen sein.
Häufige Fragen zu Patch-Management
Ja, indirekt. ISO 27001:2022 verlangt in Anhang A.8.8 den zeitnahen Umgang mit technischen Schwachstellen und in A.8.19 die kontrollierte Softwareinstallation im Betrieb. Ein eigenständiges Kapitel „Patch-Management“ schreibt die Norm nicht vor, der Auditor prüft aber, ob beide Controls durch einen dokumentierten Prozess mit Fristen und Verantwortlichkeiten tatsächlich umgesetzt sind.
Eine feste gesetzliche Frist gibt es nicht. Üblich ist eine Priorisierung nach Kritikalität: kritische, aktiv ausgenutzte Schwachstellen werden meist binnen weniger Tage geschlossen, unkritische Updates im nächsten planmäßigen Wartungsfenster. Entscheidend im Audit ist nicht eine bestimmte Zahl, sondern dass das Unternehmen eigene Fristen definiert, dokumentiert und nachweislich einhält.
Manche Altsysteme lassen sich aus betrieblichen Gründen nicht sofort aktualisieren. In diesem Fall verlangt ISO 27001 keine sofortige Lösung, aber eine dokumentierte Risikobewertung und Kompensationsmaßnahmen, etwa Netzwerksegmentierung oder zusätzliche Überwachung. Der Auditor prüft, ob dieses Restrisiko bewusst und nachvollziehbar von der Geschäftsführung akzeptiert wurde, statt schlicht unbeachtet zu bleiben.