Patch-Management Runbook: CMS-Sicherheit in 6 Schritten

März 4, 2026
Martin Přibyl

Ein Patch-Management Runbook ist die operative Antwort auf eine Bedrohungslage, die sich in den letzten drei Jahren vervierfacht hat:

Laut Verizon DBIR stieg der Anteil von Schwachstellen-Exploits als Angriffsvektor von 5 % (2022) auf 20 % (2025).

Dieser Artikel liefert eine sofort einsetzbare Vorlage für WordPress– und TYPO3-Projekte im Mittelstand: mit Rollenmatrix, konkreten CLI-Befehlen, Rollback-Strategie und einer Checkliste, die sich direkt in bestehende Wartungsverträge integrieren lässt.

Warum Patch-Management im Mittelstand ein operatives Problem ist

Der Verizon Data Breach Investigations Report 2025 zeigt: Die Ausnutzung bekannter Schwachstellen war in 20 % aller analysierten Sicherheitsvorfälle der initiale Angriffsvektor. Das entspricht einem Anstieg von 34 % gegenüber dem Vorjahr.

Ungepatchte Systeme sind damit fast gleichauf mit gestohlenen Zugangsdaten als häufigster Einstiegspunkt für Angreifer.

Parallel dazu explodiert die Zahl bekannter Schwachstellen. 2017 wurden rund 14.700 CVEs veröffentlicht. 2024 waren es knapp 40.000. 2025 wurden 48.185 neue CVEs registriert. Das sind rechnerisch über 130 neue Schwachstellen pro Tag.

2017: ca. 14.700 CVEs
2018: ca. 16.500 CVEs
2019: ca. 17.300 CVEs
2020: ca. 18.300 CVEs
2021: ca. 20.100 CVEs
2022: ca. 25.200 CVEs
2023: ca. 29.000 CVEs
2024: 39.962 CVEs
2025: 48.185 CVEs (neuer Rekord, +20,6 % gegenüber Vorjahr)

Für mittelständische Unternehmen mit 50 bis 250 Mitarbeitenden bedeutet das: Die Corporate Website, das Intranet oder der Onlineshop auf Basis von WordPress oder TYPO3 ist kein isoliertes Marketinginstrument. Es ist eine Angriffsfläche. Und ob diese Fläche geschlossen oder offen ist, hängt nicht von der Technik ab, sondern davon, ob ein Prozess existiert.

Die Realität in vielen Unternehmen sieht anders aus. Updates werden „wenn Zeit ist” eingespielt. Die Frage, wer die Freigabe erteilt, ist ungeklärt. Einen Rollback-Plan gibt es nicht. Das Ergebnis: Entweder werden Updates verschleppt (Risiko) oder übereilt eingespielt (Instabilität).

Was ein Patch-Management Runbook leistet

Ein Runbook ist kein Strategiedokument. Es ist ein operatives Handbuch, das exakt beschreibt, wer wann was tut. Es beantwortet drei Fragen, die in den meisten Wartungsverträgen offenbleiben:

Wer entscheidet, ob ein Patch eingespielt wird?
Wie wird getestet, bevor der Patch auf die Live-Umgebung geht?
Was passiert, wenn nach dem Update etwas nicht funktioniert?

Sie brauchen ein Patch-Management, das zu Ihrem Setup passt?

Sprechen Sie mit unserem Team

Die Dringlichkeit dieser Fragen lässt sich in drei Zahlen ablesen. Der Anteil von Schwachstellen-Exploits an allen Datenschutzverletzungen hat sich innerhalb von zwei Jahren vervierfacht: von rund 5 % (Verizon DBIR 2023) über 14 % (DBIR 2024, getrieben durch MOVEit-Angriffe) auf 20 % (DBIR 2025).

Die durchschnittliche Zeit von der Veröffentlichung einer Schwachstelle bis zum ersten aktiven Exploit lag 2024 bei etwa fünf Tagen.

Wer keinen strukturierten Patch-Prozess hat, gibt Angreifern ein Zeitfenster, das sie zuverlässig nutzen. Und genau hier liegt der Unterschied zwischen einem Runbook und einer Checkliste: Die Checkliste sagt, was zu tun ist.

Das Runbook sagt zusätzlich,

wer es tut,
in welcher Reihenfolge, und
was bei Abweichungen passiert.

Für einen Digital Lead, der gleichzeitig Projektleitung, Qualitätskontrolle und Budget-Verantwortung trägt, ist das der Unterschied zwischen einem Prozess, der läuft, und einem, der an einer einzelnen Person hängenbleibt.

4 Rollen im Patch-Prozess: Wer macht was?

Ein funktionierender Patch-Prozess braucht keine große Organisation. Er braucht klare Zuordnungen. Die folgende Rollenmatrix bildet die Realität in mittelständischen Digital-Teams ab: wenige Personen, mehrere Hüte, aber eindeutige Verantwortlichkeiten.

Patch Owner

Der Patch Owner ist die Person, die den gesamten Update-Zyklus verantwortet. In den meisten Setups ist das der Digital Lead oder die externe Agentur im Rahmen eines Wartungsvertrags. Der Patch Owner entscheidet, welche Updates eingespielt werden, legt das Wartungsfenster fest und gibt den finalen Go-Befehl für die Produktivumgebung.

Entscheidend: Der Patch Owner muss nicht selbst patchen. Er muss die Entscheidungshoheit haben und erreichbar sein, wenn es Probleme gibt.

Executor

Der Executor führt das Update technisch durch. Das ist der Entwickler oder DevOps-Engineer, der auf Staging testet, den Patch deployt und den Funktionstest durchführt.

Bei WordPress-Projekten arbeitet der Executor typischerweise mit WP-CLI.

Bei TYPO3-Projekten mit Composer und dem TYPO3 CLI.

QA-Prüfer

Der QA-Prüfer ist nicht identisch mit dem Executor. Das ist bewusst so. Wer ein Update einspielt, sollte es nicht allein abnehmen. Der QA-Prüfer testet nach dem Deployment die kritischen Pfade:

Kontaktformular
Checkout
Login
Suchfunktion

In kleinen Teams kann das der Patch Owner selbst sein.

Stakeholder

Der Stakeholder wird informiert, entscheidet aber nicht. Das ist typischerweise die Geschäftsführung oder der Fachbereich, der die Website inhaltlich verantwortet.

Der Stakeholder bekommt nach dem Patch eine kurze Zusammenfassung: Was wurde aktualisiert, gab es Auffälligkeiten, ist ein Folge-Update geplant?

"Patches scheitern selten an der Technik. Sie scheitern daran, dass niemand definiert hat, wer den Go-Befehl gibt.“

Christian Koch CEO von .hyperdigital Deutschland

"Ein Runbook zwingt dich, vorher zu klären, was du tust, wenn etwas schiefgeht. Ohne das planst du nur den Erfolgsfall."

Tomáš Rihák Full-Stack Web & App Developer

Wartung mit klaren Rollen statt Ad-hoc-Patches?

TYPO3 und WordPress: Unsere CMS-Expertise

Patch-Management Runbook in 6 Schritten

Das folgende Runbook beschreibt den vollständigen Zyklus eines regulären Patch-Durchlaufs. Es deckt sowohl WordPress als auch TYPO3 ab und ist auf die Realität mittelständischer Projekte zugeschnitten:

ein bis fünf beteiligte Personen
kein dediziertes Ops-Team
gemischte Hosting-Umgebungen

Schritt 1: Patch-Erkennung und Bewertung

Der Patch Owner prüft wöchentlich, ob neue Updates vorliegen.

Bei WordPress bedeutet das: Core-Updates, Plugin-Updates und Theme-Updates.

Bei TYPO3: Core-Patches innerhalb der LTS-Linie und Extension-Updates.

Jedes Update wird in eine von drei Kategorien eingeordnet.

3 Patch-Kategorien: Wie dringend ist das Update?

Kritisch (Sicherheitsupdate)

Innerhalb von 48 Stunden einspielen. Bei aktivem Exploit: sofort. Der Verizon DBIR 2025 zeigt, dass die durchschnittliche Zeit von der Offenlegung einer Schwachstelle bis zum aktiven Exploit 2024 auf etwa fünf Tage gesunken ist. Bei kritischen Patches zählt jeder Tag.

Wichtig (Bugfix, Funktionsupdate)

Im nächsten regulären Wartungsfenster einspielen. Das ist der Regelfall für Minor-Releases.

Optional (Feature-Update, Major-Upgrade)

Bewusst planen, testen, ggf. eigenes Projekt aufsetzen. Ein Upgrade von TYPO3 12 LTS auf 13 LTS ist kein Patch, sondern ein Migrationsprojekt.

Schritt 2: Staging-Umgebung vorbereiten

Kein Patch geht direkt auf Produktion. Ausnahmen bestätigen nicht die Regel, sondern verursachen Downtimes.

Die Staging-Umgebung muss die Produktivumgebung möglichst genau abbilden: gleiche PHP-Version, gleiche Datenbank-Version, gleiche Serverkonfiguration.

Bei WordPress-Projekten heißt das: gleiche Plugin-Konstellation.

Bei TYPO3: gleiche Extension-Konfiguration und gleiches TypoScript-Setup.

Vor dem Patch auf Staging:

Datenbank-Dump der Staging-Umgebung erstellen
Dateisystem-Snapshot oder Git-Commit-Hash dokumentieren
PHP-Error-Log leeren, um neue Fehler sofort zu

Schritt 3: Patch auf Staging einspielen

Hier trennen sich die Wege je nach CMS. Die konkreten Befehle für den Executor:

WordPress mit WP-CLI (Version 2.12):

# Aktuelle Version prüfen
wp core version

# Verfügbare Updates anzeigen
wp core check-update

# Core-Update einspielen (nur Minor-Releases)
wp core update --minor

# Alle Plugins aktualisieren
wp plugin update --all

# Alle Themes aktualisieren
wp theme update --all

# Datenbank-Update ausführen
wp core update-db

# Prüfsummen verifizieren
wp core verify-checksums

TYPO3 mit Composer (LTS 13.4, aktuelle Patch-Version 13.4.26):

# Aktuell installierte Pakete anzeigen
composer info "typo3/*"

# Patch-Level-Update innerhalb der LTS-Linie
composer update "typo3/cms-*" --with-all-dependencies

# Datenbank-Schema aktualisieren
./vendor/bin/typo3 database:updateschema

# Caches leeren
./vendor/bin/typo3 cache:flush

# Upgrade Wizards ausführen (falls nötig)
./vendor/bin/typo3 upgrade:run

Wichtig: Der Composer-Constraint in der composer.json bleibt bei Patch-Updates unverändert. Wer ^13.4 eingetragen hat, bekommt automatisch das neueste Patch-Level innerhalb der LTS-Linie.

TYPO3 13.4 LTS wird bis Dezember 2027 regulär unterstützt, mit kommerziellem ELTS bis 2031.

Parallel dazu erscheint TYPO3 14 LTS am 21. April 2026. Die aktuelle Sprint-Version 14.1.1 (veröffentlicht Februar 2026) eignet sich für Tests und Evaluierung, aber nicht für den Produktivbetrieb.

Ein Upgrade von 13 LTS auf 14 LTS ist kein Patch, sondern ein eigenständiges Migrationsprojekt.

Für Projekte auf TYPO3 12 LTS wird es dringend: Der reguläre Support endet im April 2026. Wer bis dahin nicht auf 13 LTS oder 14 LTS migriert hat, erhält keine Sicherheitspatches mehr, es sei denn über den kostenpflichtigen ELTS-Service.

Schritt 4: Funktionstests auf Staging

Der QA-Prüfer testet nach dem Staging-Deployment die folgenden 5 kritischen Pfade:

1. Kontaktformular und Formulare: Absenden, Bestätigungsmail prüfen, Datenbankeinträge verifizieren.

2. Suche und Navigation: Hauptnavigation, Footer-Links, interne Suche.

3. Medien und Dateien: Bilddarstellung, PDF-Downloads, Video-Einbettungen.

4. Benutzeranmeldung: Login im Frontend und Backend, Rechtevergabe, Sitzungsmanagement.

5. Performance und Fehlerprotokoll: Ladezeiten stichprobenartig prüfen, PHP-Error-Log auf neue Einträge scannen, Browser-Konsole auf JavaScript-Fehler prüfen.

Erst wenn der QA-Prüfer alle fünf Punkte abgehakt hat, meldet er dem Patch Owner: Staging OK. Gibt es Auffälligkeiten, wird der Patch auf Staging zurückgerollt und der Fehler dokumentiert.

Schritt 5: Deployment auf Produktion

Der Patch Owner gibt das Go für die Produktivumgebung. Vorher:

Vollständiges Backup der Produktion erstellen (Datenbank und Dateisystem)
Wartungsfenster kommunizieren (idealerweise Dienstag oder Mittwoch, 6:00 bis 8:00 Uhr, geringstes Traffic-Aufkommen im B2B)
Maintenance Mode aktivieren (bei WordPress: wp maintenance-mode activate)

Dann dieselben Befehle wie auf Staging ausführen. Danach: Maintenance Mode deaktivieren, QA-Schnelltest auf Produktion durchführen (Kontaktformular, Startseite, eine Unterseite), Stakeholder informieren.

Schritt 6: Dokumentation und Rollback-Bereitschaft

Nach jedem Patch-Zyklus dokumentiert der Executor:

Welche Pakete wurden aktualisiert (Version vorher → nachher)?
Gab es Auffälligkeiten auf Staging oder Produktion?
Wie lange hat der gesamte Prozess gedauert?

Die Rollback-Strategie bleibt 72 Stunden nach dem Deployment aktiv. Das bedeutet: Das Backup bleibt vorgehalten, der Executor ist erreichbar, und es gibt einen dokumentierten Weg zurück zum vorherigen Stand.

Bei WordPress: Backup einspielen (Datenbank und wp-content).

Bei TYPO3: composer install aus dem vorherigen composer.lock, Datenbank-Dump zurückspielen.

Wussten Sie, dass ...?

Laut einer Studie des Ponemon Institute im Auftrag von ServiceNow gaben 60 % der befragten Breach-Opfer an, dass der Vorfall auf eine bekannte, aber nicht gepatchte Schwachstelle zurückging.

In einer separaten Erhebung von Tanium berichteten 81 % der befragten CIOs und CISOs, mindestens einmal ein kritisches Patch-Deployment bewusst verzögert zu haben, um den laufenden Geschäftsbetrieb nicht zu gefährden.

Und 80 % der IT-Verantwortlichen stellten nachträglich fest, dass ein Patch, den sie für vollständig ausgerollt hielten, nicht auf allen Systemen installiert war.

Quellen: Ponemon Institute / ServiceNow: „Costs and Consequences of Gaps in Vulnerability Response”, 2019; Tanium: „Global Resilience Gap Study”, 2019

Update-Prozesse für WordPress oder TYPO3 strukturiert aufsetzen?

Unsere Lösungen für den Mittelstand

Patch-Management Checkliste: Vorlage zum Übernehmen

Die folgende Checkliste fasst das Runbook in eine kompakte Form, die sich ausdrucken, in ein Ticket-System überführen oder als Vorlage für Wartungsverträge verwenden lässt.

6 Schritte der Patch-Management Checkliste:

Erkennung: Wöchentlicher Check auf neue Updates (Core, Plugins/Extensions, Themes). Kategorisierung in kritisch, wichtig, optional.
Staging-Vorbereitung: Datenbank-Dump erstellen, Dateisystem-Stand dokumentieren, Error-Logs leeren.
Staging-Deployment: Patch einspielen, CLI-Befehle je CMS ausführen, Prüfsummen verifizieren.
QA-Test: 5 kritische Pfade testen (Formulare, Navigation, Medien, Login, Performance). Staging-OK oder Rollback.
Produktion: Backup erstellen, Wartungsfenster kommunizieren, Patch deployen, QA-Schnelltest, Stakeholder informieren.
Dokumentation: Versionsstände dokumentieren, Auffälligkeiten notieren, Rollback-Bereitschaft 72 Stunden aufrechterhalten.

3 häufige Fehler, die das Runbook verhindert

Fehler 1: Patches ohne Staging einspielen

In der Praxis betrifft das vor allem WordPress-Projekte mit aktivierten Auto-Updates.

WordPress installiert Minor-Releases und Sicherheitspatches standardmäßig automatisch. Das ist auf einer einfachen Unternehmenswebsite akzeptabel.

Bei Projekten mit 20 oder mehr aktiven Plugins, Custom-Code oder WooCommerce-Integration wird es riskant. Ein Plugin-Konflikt nach einem automatischen Core-Update kann den gesamten Shop lahmlegen.

Die Empfehlung: Auto-Updates für Minor-Core-Releases behalten, aber Plugin-Updates auf manuell stellen und über das Runbook steuern. In der wp-config.php: define('WP_AUTO_UPDATE_CORE', 'minor');

Fehler 2: Kein Rollback-Plan

Nach Einschätzung von Branchenexperten erstellen viele Teams zwar Backups, testen aber nie den Wiederherstellungsprozess. Ein Backup, dessen Restore nie geprobt wurde, ist kein Sicherheitsnetz. Es ist eine Hoffnung.

Das Runbook schreibt vor: Mindestens einmal pro Quartal einen Restore-Test auf der Staging-Umgebung durchführen. Dauer messen. Ergebnis dokumentieren. So weiß das Team, ob ein Rollback 15 Minuten oder 4 Stunden dauert.

Fehler 3: Verantwortlichkeiten nicht schriftlich fixieren

In Wartungsverträgen zwischen Agentur und Kunde steht oft: „Regelmäßige Updates sind im Leistungsumfang enthalten.” Was „regelmäßig” bedeutet, wer testet und wer bei Problemen nachts erreichbar ist, bleibt unklar. Das Runbook mit seiner Rollenmatrix schafft genau diese Klarheit und gehört als Anlage in jeden Wartungsvertrag.

"Auto-Updates klingen gut, bis ein Plugin-Konflikt den Shop um 2 Uhr nachts stilllegt und niemand weiß, was sich geändert hat."

Martin Přibyl CEO .hyperdigital CZ | TYPO3 Developer

"Ein Restore-Test pro Quartal klingt nach Aufwand. Aber er kostet zwei Stunden, nicht zwei Tage wie ein echter Notfall."

Alex Fernandez Design & Projektmanagement

Wartungsfenster und Patch-Kadenz: Was realistisch ist

Die Frage, wie oft gepatcht werden soll, hängt vom Risikoprofil ab. Für die meisten mittelständischen CMS-Projekte empfiehlt sich folgende Kadenz:

Wöchentlich: Prüfung auf neue Sicherheitsupdates. Kritische Patches innerhalb von 48 Stunden einspielen.

Monatlich: Reguläres Wartungsfenster für alle ausstehenden Updates (Bugfixes, Minor-Releases). Bei WordPress fällt das natürlich mit dem inoffiziellen „Patch Tuesday” zusammen, an dem Microsoft und viele andere Anbieter ihre Updates veröffentlichen.

Quartalsweise: Review des Runbooks, Restore-Test, Prüfung der PHP- und Datenbankversionen auf Kompatibilität, Bewertung anstehender Major-Upgrades.

Für TYPO3-Projekte ist der Patch-Rhythmus durch die LTS-Zyklen vorgegeben. Die aktuelle LTS-Version 13.4 (Patch-Stand: 13.4.26, Februar 2026) erhält regulären Support bis Ende 2027, mit kommerziellem ELTS bis 2031. Patch-Releases innerhalb der LTS-Linie enthalten ausschließlich Bugfixes und Sicherheitspatches und sind in der Regel unkritisch im Deployment. Ab dem 21. April 2026 steht mit TYPO3 14 LTS die nächste Generation bereit.

Für WordPress-Projekte erscheinen Minor-Releases unregelmäßig, aber typischerweise alle vier bis sechs Wochen. Plugin-Updates können täglich erscheinen. Hier ist die wöchentliche Prüfung besonders wichtig, weil die Plugin-Landschaft die größte Angriffsfläche darstellt.

FAQ - Häufig gestellte Fragen zum Patch-Management Runbook

Was ist ein Patch-Management Runbook?

Ein Patch-Management Runbook ist ein operatives Handbuch, das den gesamten Prozess beschreibt, um bekannte Sicherheitslücken in CMS-Installationen gezielt zu schließen.

Es definiert Rollen, Abläufe, Testschritte und Rollback-Strategien. Im Unterschied zu einer einfachen Checkliste klärt das Runbook auch Verantwortlichkeiten und Eskalationswege.

Wie oft sollten CMS-Updates eingespielt werden?

Sicherheitsupdates sollten innerhalb von 48 Stunden nach Veröffentlichung eingespielt werden.

Reguläre Bugfixes und Minor-Updates werden monatlich im definierten Wartungsfenster deployed.

Major-Upgrades (z.B. TYPO3 12 auf 13) erfordern eine eigene Projektplanung mit mehrwöchiger Vorlaufzeit.

Brauche ich für WordPress ein Staging-System?

Für jedes WordPress-Projekt mit mehr als einer Handvoll Plugins, Custom-Code oder E-Commerce-Funktionalität ist eine Staging-Umgebung unverzichtbar.

Automatische Core-Updates ohne Staging sind nur bei sehr einfachen Websites mit Standardkonfiguration vertretbar.

Was kostet ein fehlender Patch-Prozess?

Der IBM Cost of a Data Breach Report 2025 beziffert die durchschnittlichen Kosten eines Datenschutzvorfalls auf 4,44 Millionen US-Dollar global.

Für KMU liegen die Kosten deutlich niedriger, aber ein mehrtägiger Ausfall einer geschäftskritischen Website mit nachfolgender Forensik und Kommunikation kann schnell fünfstellige Beträge erreichen.

Wie funktioniert ein Rollback bei WordPress?

Ein Rollback bei WordPress besteht aus der Wiederherstellung des Datenbank-Dumps und des wp-content-Verzeichnisses aus dem Backup. Mit WP-CLI lässt sich die Datenbank über wp db import backup.sql zurückspielen.

Das Dateisystem wird über den Hosting-Provider oder ein Backup-Plugin wiederhergestellt.

Wie funktioniert ein Rollback bei TYPO3?

Bei Composer-basierten TYPO3-Installationen wird das vorherige composer.lock mit composer install wiederhergestellt.

Das setzt exakt die Paketversionen ein, die vor dem Update aktiv waren. Zusätzlich wird der Datenbank-Dump zurückgespielt und der Cache geleert.

Wer ist verantwortlich für das Patch-Management?

Die Verantwortung liegt beim Patch Owner. In vielen mittelständischen Setups ist das der Digital Lead intern oder die betreuende Agentur im Rahmen eines Wartungsvertrags.

Entscheidend ist, dass die Rolle schriftlich definiert und im Wartungsvertrag verankert ist.

Nächste Schritte

Runbook aufsetzen

Übernehmen Sie die 6-Schritte-Checkliste aus diesem Artikel als Vorlage, damit Sicherheitslücken nicht wochenlang offenbleiben.

Passen Sie Rollen, Wartungsfenster und Patch-Kategorien an Ihr Setup an. Verankern Sie das Runbook als Anlage in Ihrem Wartungsvertrag.

Staging-Umgebung einrichten

Falls noch nicht vorhanden: Staging aufsetzen, das die Produktivumgebung möglichst genau abbildet. Gleiche PHP-Version, gleiche CMS-Konfiguration, gleiche Plugin- oder Extension-Landschaft.

Ersten Patch-Zyklus durchführen

Offene Updates für Core, Plugins/Extensions und Themes prüfen
Kategorisierung (kritisch, wichtig, optional) vornehmen
Patch auf Staging deployen und QA-Test durchführen
Ergebnis dokumentieren

Restore-Test einplanen

Innerhalb der nächsten 30 Tage einen vollständigen Restore-Test auf der Staging-Umgebung durchführen. Dauer messen und dokumentieren. Das ist die Grundlage für eine realistische Rollback-Planung.

Ihr CMS-Projekt braucht einen strukturierten Patch-Prozess?

Wir setzen Wartungsverträge mit klaren Runbooks, definierten SLAs und Rollback-Garantie auf.