Patch-Management Runbook: CMS-Sicherheit in 6 Schritten

Aktualisiert am 28. Oktober 2026

Ein Patch-Management Runbook ist die operative Antwort auf eine Bedrohungslage, die sich deutlich verschärft hat:

Laut Verizon DBIR 2026 ist die Ausnutzung bekannter Schwachstellen mit 31 % erstmals der häufigste Einstiegspunkt bei Datenschutzverletzungen, noch vor gestohlenen Zugangsdaten.

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 2026 zeigt: Die Ausnutzung bekannter Schwachstellen war in 31 % der analysierten Datenschutzverletzungen der initiale Angriffsvektor, nach 20 % im Vorjahresbericht. Damit liegt sie vor gestohlenen Zugangsdaten.
Geschlossen werden diese Lücken langsamer als zuvor.

Von den Schwachstellen, die als aktiv ausgenutzt gelten, waren im Berichtszeitraum nur 26 % vollständig behoben. Bis eine kritische Schwachstelle vollständig behoben war, vergingen im Median 43 Tage, fast zwei Wochen mehr als im Jahr davor.

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

Wie dringend diese Fragen sind, zeigt die Entwicklung über vier Berichtsjahre. Der Anteil von Schwachstellen-Exploits an allen Datenschutzverletzungen stieg von rund 5 % (Verizon DBIR 2023) über 14 % (DBIR 2024, getrieben durch die MOVEit-Angriffe) und 20 % (DBIR 2025) auf 31 % (DBIR 2026).

Laut dem Report M-Trends 2026 des Sicherheitsunternehmens Mandiant, seit 2022 Teil von Google, lag die durchschnittliche Zeit zwischen dem Erscheinen eines Patches und der ersten Ausnutzung der Lücke 2025 geschätzt bei minus sieben Tagen.

Angreifer nutzen Schwachstellen im Schnitt also aus, bevor der Patch überhaupt verfügbar ist. In den Jahren 2018 und 2019 lag derselbe Wert noch bei 63 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

Executor

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. Er verantwortet den Patch-Stand auch nach außen, also gegenüber Auftraggebern, Versicherern und Prüfern.

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, Gründer und CEO .hyperdigital

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. Laut Mandiant beginnen Angriffe auf eine Schwachstelle im Durchschnitt bereits eine Woche, bevor der Patch erscheint. 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. Welches System zu welchem Setup passt, steht in unserem CMS-Vergleich TYPO3 und WordPress. Patch-Stände nennen wir hier bewusst nicht, weil sie sich alle paar Wochen ändern.

Die Befehle gelten für WP-CLI ab Version 2 und für TYPO3-Installationen mit Composer:

WordPress mit WP-CLI:

# 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:

# 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 14 LTS ist seit dem 21. April 2026 verfügbar. Fehlerbehebungen gibt es kostenlos bis Ende 2027, Sicherheitsupdates bis zum 30. Juni 2029 und danach über kommerzielles ELTS bis zum 30. Juni 2032.

Für TYPO3 13.4 LTS gibt es nur noch Sicherheitsupdates, kostenlos bis zum 31. Dezember 2027 und über ELTS bis zum 31. Dezember 2030. Den aktuellen Patch-Stand und die Supportfristen beider Linien nennt TYPO3 auf get.typo3.org.

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

Für Projekte auf TYPO3 12 LTS ist die Frist abgelaufen. Seit dem 30. April 2026 gibt es Sicherheitspatches nur noch über den kostenpflichtigen ELTS-Service. Wer ohne ELTS-Vertrag noch nicht auf 13 LTS oder 14 LTS migriert ist, betreibt die Installation seitdem ohne Sicherheitsupdates.

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 aus dem Jahr 2019 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 aus demselben Jahr 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.

Beide Erhebungen sind einige Jahre alt. Entspannt hat sich die Lage seitdem nicht: Laut Verizon DBIR 2026 waren von den bekannten, aktiv ausgenutzten Schwachstellen nur 26 % vollständig behoben.

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

Drittanbieter im Patch-Prozess: Plugins und Extensions

Die sechs Schritte oben decken den Core ab. Erweiterungen von Drittanbietern brauchen eine eigene Regelung, weil dort die meisten Lücken entstehen. Patchstack zählte 2025 im WordPress-Ökosystem 11.334 neue Schwachstellen, davon 91 % in Plugins und nur sechs im WordPress-Core.

Wie schnell eine solche Lücke zum Einfallstor wird, zeigt ein Fall aus einer früheren Mandiant-Analyse: Eine Schwachstelle im Plugin WooCommerce Payments (CVE-2023-28121) wurde in automatisierten Kampagnen ausgenutzt, sobald ein öffentlicher Exploit verfügbar war.

Auch der Verizon DBIR 2026 meldet einen deutlichen Anstieg: An 48 % aller Datenschutzverletzungen war ein Dritter beteiligt, etwa ein Anbieter aus der Software-Lieferkette. Das sind 60 % mehr als im Vorjahr.

Ein diszipliniert gepatchter Core mit ungeprüften Erweiterungen deckt nur den kleineren Teil des Risikos ab. Das gilt auch für KI-Erweiterungen. Wie sich ihre Kosten und Rechte steuern lassen, beschreiben unsere Artikel zur Governance für KI-Funktionen in TYPO3 und zur selben Frage für WordPress.

Drei Festlegungen gehören deshalb ins Runbook:

1. Inventar der Plugins und Extensions

Welche Plugins und Extensions laufen produktiv, in welcher Version, mit welchem Zweck? Ohne diese Liste lässt sich nicht bewerten, welches Update dringend ist und welches warten kann.

Bei WordPress liefert wp plugin list --update=available den Stand. Plugins, die nicht aus dem offiziellen Verzeichnis stammen, erscheinen dort nur, wenn der Anbieter seine Updates über die WordPress-Updatefunktion ausliefert.

Bei TYPO3 mit Composer zeigt composer outdated --direct, welche Extensions veraltet sind. In klassischen TYPO3-Installationen ohne Composer lädt der Extension Manager die aktuelle Liste der Releases, danach zeigt die Übersicht alle verfügbaren Updates.

2. Maintainer-Status jeder Erweiterung

Zu jeder Erweiterung gehört die Angabe, wann sie zuletzt aktualisiert wurde und ob sie für die eingesetzte Core-Version freigegeben ist. Eine Erweiterung, die seit zwölf Monaten kein Update erhalten hat, gehört auf die Liste der offenen Punkte, auch wenn sie technisch noch funktioniert.

3. Austauschentscheidung bei verwaisten Erweiterungen

Wer entscheidet, ob eine verwaiste Erweiterung ersetzt, durch Eigenentwicklung abgelöst oder abgeschaltet wird? Diese Entscheidung liegt beim Patch Owner und gehört in dieselbe Rollenmatrix wie das Deployment.

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, Designer und Projektmanager .hyperdigital

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).

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. Kostenlose Sicherheitsupdates gibt es für TYPO3 14 LTS bis zum 30. Juni 2029 und für TYPO3 13.4 bis zum 31. Dezember 2027, danach jeweils über kommerzielles ELTS für drei weitere Jahre.

Die Termine der Maintenance-Releases kündigt TYPO3 vorab an, Wartungsfenster lassen sich danach planen. Patch-Releases innerhalb der LTS-Linie enthalten ausschließlich Bugfixes und Sicherheitspatches und sind in der Regel unkritisch im Deployment.

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 2026 beziffert die durchschnittlichen Kosten eines Datenschutzvorfalls auf 4,99 Millionen US-Dollar global, 12 % mehr als im Vorjahr und so viel wie nie zuvor in der Studie.

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.

Wie weisen wir unseren Patch-Stand gegenüber Auftraggebern nach?

Über die Dokumentation aus Schritt 6. Wer Versionsstände vor und nach jedem Wartungsfenster festhält, kann belegen, welcher Stand wann produktiv war und wer das Deployment freigegeben hat.

Relevant wird das, sobald Auftraggeber, Versicherer oder Prüfer nachfragen. Dazu gehört die Rollenmatrix im Wartungsvertrag, damit im Nachhinein dokumentiert ist, wer den Go-Befehl gegeben hat.

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.