Patch-Management im Mittelstand: Prozess, Priorisierung und Automatisierung

Warum Patching der wichtigste Grundschutz ist

Es gibt eine Statistik, die sich seit Jahren kaum verändert: Über 60 Prozent aller erfolgreichen Cyberangriffe nutzen Schwachstellen aus, für die zum Zeitpunkt des Angriffs bereits ein Patch verfügbar war. Das bedeutet, dass die Mehrheit der Sicherheitsvorfälle hätte verhindert werden können, wenn die betroffenen Systeme rechtzeitig aktualisiert worden wären. Nicht mit einem neuen Produkt, nicht mit einer teuren Lösung, sondern mit einem Update, das der Hersteller kostenlos bereitgestellt hat.

Das klingt einfach, und konzeptionell ist es das auch. In der Praxis sieht es anders aus. Ein mittelständisches Unternehmen mit 200 Mitarbeitern betreibt typischerweise mehrere hundert Systeme: Arbeitsplatzrechner, Server, Netzwerkkomponenten, Drucker, Telefonanlagen, vielleicht Produktionssteuerungen. Jedes dieser Systeme hat ein Betriebssystem und mehrere Anwendungen, die regelmäßig aktualisiert werden müssen. Microsoft allein veröffentlicht am Patch Tuesday jeden Monat zwischen 50 und 150 Sicherheitsupdates. Dazu kommen Patches für Linux-Server, Firmware-Updates für Firewalls und Switches, Updates für Drittanbieter-Software wie Adobe, Java, Chrome, Zoom, und die Liste geht weiter.

Die Herausforderung ist nicht, dass Patches nicht verfügbar wären. Die Herausforderung ist, den Überblick zu behalten, die richtigen Prioritäten zu setzen, vor dem Rollout zu testen und den gesamten Prozess so zu dokumentieren, dass er auditierbar ist. Genau darum geht es in diesem Artikel.

Was ISO 27001 und NIS2 zum Patch-Management verlangen

ISO 27001 adressiert Patch-Management in mehreren Controls. Annex A.8.8 (Management of technical vulnerabilities) fordert, dass Informationen über technische Schwachstellen der genutzten Systeme zeitnah eingeholt, die Exposition gegenüber diesen Schwachstellen bewertet und geeignete Maßnahmen ergriffen werden. Annex A.8.19 (Installation of software on operational systems) ergänzt die Anforderung, dass Software-Installation, einschließlich Updates, kontrolliert und dokumentiert erfolgen muss.

NIS2 ist noch expliziter. Artikel 21, Absatz 2, Buchstabe e listet „Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Umgang mit und Offenlegung von Schwachstellen" als eine der zehn Mindestmaßnahmen. Das BSI interpretiert das in seinen NIS2-Umsetzungshinweisen als Pflicht zu einem dokumentierten Schwachstellen- und Patch-Management-Prozess. Unternehmen, die unter NIS2 fallen, müssen nachweisen können, dass sie Schwachstellen systematisch identifizieren, bewerten und beheben.

Für das ISMS bedeutet das: Du brauchst einen dokumentierten Patch-Management-Prozess mit definierten Rollen, Zeitvorgaben und Eskalationspfaden. Und du musst nachweisen können, dass dieser Prozess tatsächlich gelebt wird, nicht nur auf dem Papier existiert.

Der Patch-Prozess in fünf Phasen

Ein strukturierter Patch-Prozess besteht aus fünf Phasen, die zyklisch durchlaufen werden. Jede Phase hat klare Inputs, Aktivitäten und Outputs.

Phase 1: Identifizieren

In der ersten Phase geht es darum, neue Schwachstellen und verfügbare Patches zu erkennen. Dafür brauchst du drei Informationsquellen:

Hersteller-Advisories: Microsoft Security Update Guide, Cisco Security Advisories, VMware Security Advisories, und die entsprechenden Kanäle aller anderen Hersteller, deren Produkte du einsetzt. Abonniere die RSS-Feeds oder Mailing-Listen, damit du zeitnah informiert wirst.

Schwachstellen-Datenbanken: Die National Vulnerability Database (NVD) des NIST und die CVE-Datenbank (Common Vulnerabilities and Exposures) sind die zentralen Referenzen. Jede bekannte Schwachstelle bekommt eine CVE-Nummer und einen CVSS-Score. Besonders wichtig ist die CISA KEV-Liste (Known Exploited Vulnerabilities), die Schwachstellen enthält, die nachweislich aktiv ausgenutzt werden.

Schwachstellen-Scanner: Tools wie Nessus, OpenVAS, Qualys oder der in Microsoft Defender integrierte Schwachstellen-Scanner prüfen deine Systeme regelmäßig auf bekannte Schwachstellen und fehlende Patches. Ein wöchentlicher Scan ist das Minimum, für exponierte Systeme empfiehlt sich ein täglicher Scan.

Das Ergebnis dieser Phase ist eine Liste offener Schwachstellen mit CVE-Nummer, betroffenen Systemen, CVSS-Score und verfügbaren Patches.

Phase 2: Priorisieren

Nicht jeder Patch hat die gleiche Dringlichkeit. Eine kritische Remote-Code-Execution-Schwachstelle im Webserver, der aus dem Internet erreichbar ist, hat eine völlig andere Priorität als ein lokaler Privilege-Escalation-Bug in einem internen Entwicklungssystem. Die Priorisierung entscheidet darüber, welche Patches sofort eingespielt werden, welche im regulären Wartungsfenster drankommen und welche bewusst zurückgestellt werden können.

Die Grundlage für die Priorisierung ist eine Matrix, die zwei Dimensionen kombiniert: die Schwere der Schwachstelle und die Kritikalität des betroffenen Systems.

Schwere der Schwachstelle (CVSS-Score):

Der CVSS-Score (Common Vulnerability Scoring System) bewertet Schwachstellen auf einer Skala von 0 bis 10. Die Einstufung erfolgt nach einem standardisierten Verfahren, das Faktoren wie Angriffsvektor, Angriffskomplexität, benötigte Berechtigungen und Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit berücksichtigt.

Die Schweregrade sind: Low (0,1 bis 3,9), Medium (4,0 bis 6,9), High (7,0 bis 8,9) und Critical (9,0 bis 10,0). Zusätzlich zum CVSS-Score prüfst du, ob die Schwachstelle auf der CISA KEV-Liste steht, also nachweislich aktiv ausgenutzt wird. Eine Schwachstelle mit CVSS 7,5, die aktiv exploitet wird, hat in der Praxis eine höhere Priorität als eine theoretische Schwachstelle mit CVSS 9,0 ohne bekannten Exploit.

Kritikalität des betroffenen Systems:

Die Kritikalität kommt aus deinem IT-Asset-Inventar und der Schutzbedarfsfeststellung. Ein extern erreichbarer Server hat eine höhere Kritikalität als ein interner Testserver. Ein System, das personenbezogene Daten verarbeitet, hat eine höhere Kritikalität als ein Infodisplay. Die Kombination aus beidem ergibt die Patch-Priorität.

Die Priorisierungsmatrix:

Aus den beiden Dimensionen leitest du vier Prioritätsstufen ab, die jeweils mit einer maximalen Reaktionszeit verbunden sind.

P1 (Sofort, innerhalb von 24 bis 48 Stunden): Kritische Schwachstelle (CVSS 9+) in einem exponierten oder geschäftskritischen System. Oder jede Schwachstelle auf der CISA KEV-Liste, unabhängig vom CVSS-Score. Hier wird sofort gehandelt, auch außerhalb regulärer Wartungsfenster. Falls ein Patch noch nicht verfügbar ist, wird ein Workaround implementiert (z. B. System vom Netz nehmen, betroffenen Dienst deaktivieren, WAF-Regel erstellen).

P2 (Hoch, innerhalb von 7 Tagen): Schwachstelle mit CVSS 7 oder höher in einem internen System mit hoher Kritikalität. Oder Medium-Schwachstelle in einem exponierten System. Patch wird im nächsten regulären Wartungsfenster eingespielt, spätestens innerhalb einer Woche.

P3 (Normal, innerhalb von 30 Tagen): Medium-Schwachstelle in internen Systemen. Patch wird im regulären monatlichen Patchzyklus eingespielt.

P4 (Niedrig, innerhalb von 90 Tagen): Low-Schwachstelle oder Schwachstelle in einem System mit niedrigem Schutzbedarf. Patch wird bei der nächsten geplanten Wartung eingespielt.

Diese Zeitvorgaben musst du in deiner Patch-Management-Richtlinie festschreiben. Der Auditor wird fragen, ob du definierte SLAs für das Patching hast und ob du sie einhältst.

Phase 3: Testen

Patches können Seiteneffekte haben. Ein Windows-Update kann eine Legacy-Anwendung zum Absturz bringen. Ein Firmware-Update kann die Performance einer Netzwerkkomponente beeinträchtigen. Ein Java-Update kann die Kompatibilität mit einer Fachanwendung zerstören. Deswegen werden Patches vor dem produktiven Rollout getestet, zumindest die, die es zeitlich erlauben.

Für P1-Patches (Sofort-Patching) ist ein umfangreiches Testing oft nicht möglich. Hier wiegst du das Risiko des Patchings gegen das Risiko der ungepatchten Schwachstelle ab. In den meisten Fällen überwiegt das Risiko der offenen Schwachstelle deutlich, besonders wenn sie aktiv ausgenutzt wird.

Für P2- und P3-Patches richtest du eine Testumgebung ein. Das muss keine exakte Kopie der Produktion sein, aber sie sollte die kritischen Anwendungen und Konfigurationen widerspiegeln. Mindestens ein Testsystem pro Betriebssystemversion, auf dem du die Patches installierst und anschließend die wichtigsten Anwendungen durchklickst, automatisierte Tests ausführst oder Smoke-Tests fährst.

In der Praxis hat sich ein gestaffelter Rollout bewährt: Erst die Test-Gruppe (5 bis 10 Pilotanwender, die frühzeitig Probleme melden), dann nach 2 bis 3 Tagen ohne Beschwerden der Rollout auf die Breitenmasse.

Phase 4: Ausrollen

Der Rollout ist die eigentliche Installation der Patches auf den Produktivsystemen. Hier kommen die Automatisierungstools ins Spiel, auf die wir im nächsten Abschnitt detailliert eingehen.

Grundregeln für den Rollout:

Wartungsfenster definieren: Server-Patches werden idealerweise in einem definierten Wartungsfenster eingespielt, typischerweise am Wochenende oder in den Abendstunden. Client-Patches können während der Arbeitszeit im Hintergrund installiert werden, mit einem geplanten Neustart in der Mittagspause oder am Feierabend.

Rollback-Plan erstellen: Vor dem Patching erstellst du einen Snapshot (bei virtuellen Servern) oder ein Backup (bei physischen Servern). Falls der Patch Probleme verursacht, kannst du innerhalb von Minuten auf den vorherigen Stand zurückrollen.

Kommunikation: Informiere die betroffenen Anwender vorab über geplante Neustarts oder Ausfallzeiten. Eine kurze E-Mail oder eine Benachrichtigung über das Ticketsystem reicht aus, aber sie muss erfolgen.

Dokumentation: Protokolliere, welcher Patch auf welchem System zu welchem Zeitpunkt installiert wurde. Diese Information ist für das Audit essenziell.

Phase 5: Verifizieren

Nach dem Rollout prüfst du, ob die Patches erfolgreich installiert wurden und ob die Systeme ordnungsgemäß funktionieren. Dafür nutzt du mehrere Kontrollmechanismen:

Patch-Compliance-Report: Dein Patch-Management-Tool erstellt einen Bericht, der zeigt, welche Systeme den Patch erfolgreich installiert haben und welche nicht. Systeme, die den Patch nicht erhalten haben (offline, Fehler, Neustart ausstehend), werden nachverfolgt.

Schwachstellen-Scan: Ein erneuter Schwachstellen-Scan nach dem Rollout bestätigt, dass die Schwachstelle tatsächlich geschlossen wurde. Manchmal schlägt die Patch-Installation fehl, ohne eine Fehlermeldung zu generieren, und die Schwachstelle bleibt offen.

Funktionstest: Die wichtigsten Anwendungen und Dienste werden nach dem Patching auf Funktionsfähigkeit geprüft. Läuft das ERP? Funktioniert der E-Mail-Versand? Sind die Netzwerkfreigaben erreichbar?

Automatisierung: Welche Tools für den Mittelstand taugen

Manuelles Patching funktioniert bis zu einer gewissen Unternehmensgröße, aber ab 50 Arbeitsplatzrechnern und einer Handvoll Servern wird es ohne Automatisierung unpraktikabel. Hier eine Übersicht der gängigen Tools für den Mittelstand.

WSUS (Windows Server Update Services)

WSUS ist das Standardtool für Windows-Umgebungen und in der Windows-Server-Lizenz enthalten. Es ermöglicht das zentrale Management von Microsoft-Updates für Windows-Clients und -Server. Du kannst Patches genehmigen, ablehnen und verzögern, Computergruppen definieren (Pilot, Produktion), Wartungsfenster planen und Compliance-Berichte erstellen.

WSUS hat klare Grenzen: Es kann nur Microsoft-Produkte patchen. Für Drittanbieter-Software wie Adobe, Chrome, Java oder Zoom brauchst du ein zusätzliches Tool. Außerdem ist die Berichterstattung rudimentär und die Benutzeroberfläche in die Jahre gekommen. Trotzdem ist WSUS für viele KMU der pragmatische Einstieg, weil es keine zusätzlichen Lizenzkosten verursacht.

Microsoft Intune / Endpoint Manager

Für Unternehmen, die bereits Microsoft 365 Business Premium oder Enterprise nutzen, ist Intune der logische nächste Schritt. Intune verwaltet nicht nur Windows-Updates, sondern auch macOS, iOS und Android. Es bietet Feature-Updates, Qualitätsupdates, Treiber-Updates und über den Windows Update for Business-Mechanismus auch eine Ring-basierte Rollout-Steuerung.

Der Vorteil gegenüber WSUS: Intune funktioniert auch für Geräte, die nicht im Firmennetzwerk sind, also für Remote-Arbeitsplätze und mobile Geräte. Der Nachteil: Intune ist eine Cloud-Lösung, was für manche Unternehmen aus Compliance-Gründen ein Thema sein kann.

Ansible / Puppet / Chef

Für heterogene Umgebungen mit Linux-Servern, Netzwerkkomponenten und verschiedenen Betriebssystemen sind Konfigurationsmanagement-Tools wie Ansible eine leistungsfähige Option. Ansible ist agentenlos, arbeitet über SSH und kann Patches auf beliebigen Systemen installieren, die über SSH erreichbar sind.

Ein typisches Ansible-Playbook für Patch-Management aktualisiert die Paketquellen, installiert alle verfügbaren Sicherheitsupdates, startet die betroffenen Dienste neu und schreibt das Ergebnis in ein Log. Das Playbook lässt sich zeitgesteuert ausführen und in eine CI/CD-Pipeline integrieren. Der Nachteil: Ansible erfordert Linux-Kenntnisse und initiale Einrichtungsarbeit. Es ist kein Klick-und-fertig-Tool.

Kommerzielle Patch-Management-Lösungen

Produkte wie ManageEngine Patch Manager Plus, Ivanti Patch Management, SCCM (Microsoft Configuration Manager) oder NinjaRMM bieten eine umfassende Lösung für Betriebssysteme und Drittanbieter-Software in einer einzigen Konsole. Sie bringen fertige Patch-Kataloge mit, automatisieren Testing und Rollout und liefern die Compliance-Berichte, die der Auditor sehen will.

Für KMU mit begrenztem IT-Personal sind diese Lösungen oft die beste Wahl, weil sie den manuellen Aufwand deutlich reduzieren. Die Lizenzkosten liegen typischerweise bei 2 bis 5 Euro pro Endpunkt und Monat, was angesichts der Zeitersparnis gut investiertes Geld ist.

Sonderfälle: Legacy-Systeme, OT und Firmware

Nicht alles lässt sich einfach patchen. Einige Systemkategorien erfordern besondere Aufmerksamkeit.

Legacy-Systeme

In fast jedem Mittelstandsunternehmen gibt es mindestens ein System, das auf einem veralteten Betriebssystem läuft: der Windows-Server-2012-Rechner, auf dem die alte ERP-Version läuft, oder der Windows-7-Rechner, der eine Produktionsmaschine steuert. Für diese Systeme gibt es keine regulären Patches mehr.

Die Lösung ist nicht, das Problem zu ignorieren, sondern kompensatorische Maßnahmen zu ergreifen. Isoliere das Legacy-System in einem eigenen Netzwerksegment. Beschränke den Zugriff auf das absolute Minimum. Implementiere Application Whitelisting, damit nur bekannte Programme ausgeführt werden können. Überwache das System besonders engmaschig auf Anomalien. Und plane die Migration auf ein unterstütztes System, auch wenn das Zeit und Budget erfordert. Dokumentiere die Risikobewertung und die kompensatorischen Maßnahmen im ISMS, denn der Auditor wird danach fragen.

Operational Technology (OT)

Produktionssteuerungen, SCADA-Systeme und andere OT-Komponenten können oft nicht im laufenden Betrieb gepatcht werden. Ein Neustart der SPS bedeutet einen Produktionsstillstand. Firmware-Updates für Steuerungen erfordern teilweise einen Vor-Ort-Einsatz des Herstellers. Und manche Hersteller verbieten sogar Patches, weil sie die Funktionsfähigkeit ihrer Systeme nicht garantieren, wenn das Betriebssystem verändert wird.

Für OT-Systeme gilt: Segmentierung ist wichtiger als Patching. Wenn du ein OT-System nicht patchen kannst, musst du es isolieren. Ein eigenes Netzwerksegment mit strikten Firewall-Regeln, kein direkter Internetzugang, kontrollierter Datenaustausch über definierte Schnittstellen. Zusätzlich solltest du OT-spezifische Monitoring-Lösungen einsetzen, die Anomalien im Netzwerkverkehr erkennen, ohne die Steuerungssysteme zu beeinflussen.

Firmware

Firmware-Updates für Netzwerkkomponenten (Switches, Firewalls, Access Points), Drucker, IoT-Geräte und Server-Hardware (BIOS/UEFI, BMC) werden häufig vergessen. Sie tauchen nicht in den üblichen Patch-Management-Tools auf und erfordern separate Prozesse.

Erstelle eine Liste aller Geräte, die Firmware-Updates benötigen, und prüfe regelmäßig (mindestens quartalsweise) die Hersteller-Websites auf neue Firmware-Versionen. Kritische Sicherheitsupdates für Firewalls und exponierte Netzwerkkomponenten haben dieselbe Priorität wie Betriebssystem-Patches. Firmware-Updates für Drucker oder IoT-Geräte können im regulären Quartalszyklus eingespielt werden, sofern keine kritischen Schwachstellen vorliegen.

Dokumentation für den Audit

Ein funktionierender Patch-Prozess, der nicht dokumentiert ist, existiert für den Auditor nicht. Folgende Dokumente brauchst du:

Patch-Management-Richtlinie

Die Richtlinie definiert den Prozess auf Policy-Ebene: Geltungsbereich, Rollen und Verantwortlichkeiten, Priorisierungskriterien, Zeitvorgaben (SLAs) pro Prioritätsstufe, Eskalationspfade, Umgang mit Ausnahmen, Testverfahren, Berichtswesen. Diese Richtlinie wird vom ISB oder CISO freigegeben und regelmäßig überprüft.

Patch-Inventar und Compliance-Reports

Regelmäßige (idealerweise monatliche) Berichte über den Patch-Stand aller Systeme: Wie viele Systeme sind vollständig gepatcht? Wie viele haben offene kritische Schwachstellen? Wie ist die durchschnittliche Time-to-Patch? Welche Systeme haben Ausnahmen? Diese Berichte fließen in das Management-Review ein und zeigen den Trend über die Zeit. In ISMS Lite lässt sich der Patch-Compliance-Status als Kennzahl direkt im Dashboard tracken und für den Auditor als Nachweis exportieren.

Ausnahme-Register

Nicht jedes System kann sofort gepatcht werden. Für jede Ausnahme (Legacy-System, Herstellerrestriktion, Kompatibilitätsproblem) dokumentierst du: betroffenes System, Schwachstelle, Grund für die Ausnahme, kompensatorische Maßnahmen, geplantes Enddatum der Ausnahme, Verantwortlicher, Genehmigung. Ausnahmen ohne Ablaufdatum und ohne kompensatorische Maßnahmen sind im Audit ein Problem.

Nachweis der einzelnen Patch-Zyklen

Für jeden Patchzyklus hältst du fest: welche Patches identifiziert wurden, wie sie priorisiert wurden, ob und wie sie getestet wurden, wann sie ausgerollt wurden, auf welchen Systemen, und ob die Verifizierung erfolgreich war. Das klingt nach viel Aufwand, aber wenn du ein Patch-Management-Tool einsetzt, generiert es die meisten dieser Informationen automatisch.

Kennzahlen für das Patch-Management

Um deinen Patch-Prozess zu steuern und seine Wirksamkeit nachzuweisen, brauchst du Kennzahlen. Die folgenden KPIs sind für den Mittelstand praxistauglich:

Patch-Compliance-Rate: Anteil der Systeme, die alle relevanten Patches installiert haben. Zielwert: über 95 Prozent. Systeme mit offenen Ausnahmen zählen als konform, wenn die kompensatorischen Maßnahmen dokumentiert und umgesetzt sind.

Mean Time to Patch (MTTP): Durchschnittliche Zeit zwischen Veröffentlichung eines Patches und seiner Installation. Getrennt nach Prioritätsstufen messen. Die MTTP für P1-Patches sollte unter 48 Stunden liegen, für P3-Patches unter 30 Tagen.

Anzahl offener kritischer Schwachstellen: Wie viele Schwachstellen mit CVSS 9 oder höher sind aktuell ungepatcht? Diese Zahl sollte möglichst bei null liegen. Jede offene kritische Schwachstelle braucht eine dokumentierte Begründung und einen Zeitplan.

Ausnahme-Quote: Anteil der Systeme mit aktiven Patch-Ausnahmen. Wenn diese Quote stetig steigt, deutet das auf ein strukturelles Problem hin (z. B. zu viele Legacy-Systeme, fehlende Testkapazitäten).

Erfolgsquote bei Patch-Rollouts: Anteil der Patches, die beim ersten Versuch erfolgreich installiert wurden. Eine niedrige Quote deutet auf Probleme mit der Testumgebung, der Netzwerkkonnektivität oder den Client-Konfigurationen hin.

Häufige Fehler im Patch-Management

Auch mit einem definierten Prozess gibt es typische Stolperfallen.

Patching nur für Windows: Microsoft-Patches sind dank WSUS und Intune relativ einfach zu managen. Aber was ist mit den Linux-Servern, den Netzwerkkomponenten, der Telefonanlage, den Drittanbieter-Anwendungen? Ein Patch-Prozess, der nur Windows abdeckt, hat blinde Flecken, die Angreifer gerne ausnutzen.

Kein Rollback-Plan: Patches ohne vorheriges Backup oder Snapshot einzuspielen ist Russisches Roulette. Irgendwann geht ein Patch schief, und ohne Rollback-Möglichkeit steht die Produktion still, bis das Problem manuell gelöst ist.

Fehlende Nachverfolgung: Patches werden genehmigt und freigegeben, aber niemand prüft, ob sie tatsächlich auf allen Systemen angekommen sind. Systeme, die zum Zeitpunkt des Rollouts offline waren, veraltete Notebooks im Homeoffice, Server in der DMZ, die vom internen WSUS nicht erreichbar sind. Ohne Verifizierung bleiben diese Lücken unentdeckt.

Angst vor dem Patchen: Manche Administratoren zögern Patches hinaus, weil sie negative Seiteneffekte befürchten. Diese Angst ist verständlich, aber die Alternative, eine bekannte Schwachstelle offen zu lassen, ist in fast allen Fällen riskanter als der Patch selbst. Ein definierter Testprozess und ein Rollback-Plan nehmen die Angst, weil sie das Risiko des Patchings beherrschbar machen.

Patch-Management ohne Asset-Inventar: Wenn du nicht weißt, welche Systeme du hast, kannst du nicht sicherstellen, dass alle gepatcht sind. Ein vollständiges Schwachstellenmanagement setzt immer ein aktuelles Inventar voraus. Das IT-Asset-Inventar ist die zwingende Voraussetzung für effektives Patch-Management. Jedes System, das nicht im Inventar steht, fällt durch das Raster.

Patch-Management als kontinuierlicher Prozess

Patch-Management ist kein Projekt mit einem Anfang und einem Ende. Es ist ein kontinuierlicher Prozess, der so lange läuft wie dein Unternehmen IT-Systeme betreibt. Jeden Monat kommen neue Schwachstellen hinzu, jeden Monat müssen Patches priorisiert, getestet und ausgerollt werden. Deswegen ist Automatisierung so wichtig: Nur mit automatisierten Tools und definierten Prozessen lässt sich dieser Zyklus dauerhaft aufrechterhalten, ohne das IT-Team zu überlasten.

Der Einstieg muss nicht perfekt sein. Wenn du heute noch gar kein strukturiertes Patch-Management hast, beginne mit dem Offensichtlichen: Windows-Updates über WSUS oder Intune zentralisieren, einen monatlichen Patchzyklus etablieren, kritische Schwachstellen priorisieren. Im zweiten Schritt nimmst du Linux-Server und Netzwerkkomponenten hinzu. Im dritten Schritt implementierst du Schwachstellen-Scanning und Compliance-Reporting. Im vierten Schritt automatisierst du die Drittanbieter-Patches.

Mit jedem Schritt wird dein Patch-Management reifer, dein Risiko geringer und dein Nachweis gegenüber Auditoren überzeugender. Das Ziel ist nicht Perfektion am ersten Tag, sondern ein kontinuierlich verbesserter Prozess, der zu deinem Unternehmen passt und tatsächlich gelebt wird.

Weiterführende Artikel

• Risikobewertung im ISMS: Methoden, Kriterien und Praxis
• IT-Asset-Management für das ISMS: Inventar, Kritikalität und Klassifizierung
• Top 10 Informationssicherheitsrisiken für den Mittelstand
• Netzwerksegmentierung für KMU: Warum und wie du dein Netz aufteilst
• Schutzbedarfsfeststellung: Assets bewerten und priorisieren

Fang mit den Windows-Updates an, denn die machen den größten Anteil aus und sind am einfachsten zu automatisieren. Wenn dieser Grundpfeiler steht, arbeitest du dich zu den Sonderfällen vor und baust deinen Prozess Schritt für Schritt aus.