# IT-Notfallplan für Webserver erstellen

> IT-Notfallplan für Webserver erstellen: Rollen, Kontakte, Systeminventar, Entscheidungsregeln und Meldewege, damit im Ernstfall alles sitzt.

Quelle: https://phpsos.de/compliance/notfallplan-erstellen/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** Ein IT-Notfallplan für Webserver legt vorab fest, wer im Ernstfall entscheidet, wen man erreicht, welche Systeme betroffen sein können und welche Schritte in welcher Reihenfolge folgen. Wer einen IT-Notfallplan erstellen will, braucht kein dickes Handbuch, sondern wenige, aktuelle Seiten, die auch ohne funktionierende IT erreichbar sind. Die Lage um PHP2Shell ist ein guter Anlass, das jetzt zu tun.

## Warum ein Notfallplan Zeit und Schaden spart

Im Ernstfall gehen die ersten Stunden oft mit Suchen verloren: Wer hat Zugang zum Hoster? Wo liegen die Backups? Wer entscheidet, ob der Shop offline geht? Wer muss informiert werden? Ein Notfallplan beantwortet diese Fragen vorher, in Ruhe.

PHP2Shell hat gezeigt, wie kurz die Zeit sein kann. Am 20.10.2026 kündigte php.net die Patches an, am 21.10. um 16 Uhr deutscher Zeit wurden sie veröffentlicht, und das BSI empfahl sofortiges Update oder vorübergehendes Abschalten. Unternehmen mit Plan wussten, wen sie anrufen und welche Server sie prüfen müssen. Andere mussten erst herausfinden, wo überhaupt PHP läuft.

## IT-Notfallplan erstellen: die Bausteine

Ein praxistauglicher Plan für Webserver umfasst diese Teile:

**1. Rollen und Entscheidungen.** Wer leitet im Notfall, wer vertritt, wer darf Systeme abschalten, wer spricht nach außen? Halten Sie Namen und Stellvertretungen fest.

**2. Kontaktliste.** Interne Ansprechpartner, Hoster, Agentur, IT-Dienstleister, Datenschutzbeauftragter, Rechtsberatung, Cyberversicherung mit Versicherungsnummer, zuständige Datenschutz-Aufsichtsbehörde, die Zentrale Ansprechstelle Cybercrime Ihres Bundeslandes. Diese Liste muss ausgedruckt vorliegen.

**3. Systeminventar.** Jede Website, jeder Shop und jedes Portal mit Server, Hoster, Betriebsart, PHP-Version, Anwendung, Verantwortlichem und Art der verarbeiteten Daten.

**4. Entscheidungsregeln.** Unter welchen Bedingungen nehmen wir ein System vom Netz? Wer darf das entscheiden? Was gilt nachts und am Wochenende?

**5. Abläufe.** Kurze Schrittfolgen für typische Fälle: kritische Lücke bekannt, Verdacht auf Einbruch, Website verunstaltet, Daten abgeflossen, Erpressung.

**6. Meldewege.** Wer prüft eine Meldepflicht nach Art. 33 DSGVO, möglichst binnen 72 Stunden ab Bekanntwerden? Wer meldet bei NIS2-Pflicht an das BSI? Wer informiert den Versicherer?

**7. Wiederherstellung.** Wo liegen Backups, wer kann sie zurückspielen, wie lange dauert das, wann wurde das zuletzt getestet?

## Beispiel: Ablauf „kritische PHP-Lücke“

So kann ein Ablauf aussehen, wie er bei PHP2Shell gebraucht wurde:

| Schritt | Wer | Ergebnis |
|---|---|---|
| Meldung bewerten (php.net, BSI) | IT-Verantwortliche | betroffene Systeme laut Inventar |
| Update einspielen, alle Worker neu starten | Admin oder Dienstleister | Nachweis mit Paketstand und Prozesszeit |
| Wo kein Update möglich: Übergangsmaßnahmen oder vom Netz | Leitung entscheidet | dokumentierte Entscheidung |
| Logs sichern, Spuren prüfen | Admin oder Forensik | Befund oder kein Befund |
| Bei Befund: Vorfallsablauf starten | Notfallleitung | Meldewege prüfen |

Wichtig dabei: Ein Patch schließt die Lücke, entfernt aber keine vorher eingeschleuste Schadsoftware. Deshalb gehört die Spurensuche fest in den Ablauf.

> **Tipp:**
> Legen Sie fest, wie lange Webserver-Logs aufbewahrt werden und wo sie außerhalb des Servers liegen. Bei PHP2Shell empfahl die Fachpresse, Logs ab dem 20.10.2026 aufzubewahren. Wer Logs nur wenige Tage behält, kann solche Empfehlungen nicht umsetzen.

## Vorsorge, die den Plan erst wirksam macht

Ein Plan ist nur so gut wie die Voraussetzungen dahinter. Prüfen Sie, ob Backups nach der 3-2-1-Regel vorhanden und getestet sind, siehe [Backups nach der 3-2-1-Regel](https://phpsos.de/ratgeber/backups-3-2-1/). Klären Sie mit Hoster und Agentur schriftlich, wer bei kritischen Lücken was übernimmt. Halten Sie Zugangsdaten für Notfälle sicher, aber erreichbar vor, etwa in einem geschützten Passwort-Tresor mit Notfallzugriff.

Bereiten Sie außerdem Textvorlagen vor: interne Information, Kundenmitteilung, Hinweis auf einer statischen Wartungsseite. Hinweise dazu stehen unter [Krisenkommunikation nach einem Angriff](https://phpsos.de/compliance/krisenkommunikation/).

## Üben und aktuell halten

Ein Plan, der nie geübt wurde, enthält fast immer Lücken. Spielen Sie einmal im Jahr ein Szenario durch, etwa „kritische PHP-Lücke am Freitagnachmittag“, und notieren Sie, wo es hakt. Ein einfacher Test reicht für den Anfang: Kann eine zweite Person ohne Hilfe der ersten den Hoster erreichen, ein Backup zurückspielen und die Website in den Wartungsmodus versetzen? Wenn nicht, fehlt etwas im Plan, meist ein Zugang, eine Telefonnummer oder eine Beschreibung. Genau solche Lücken sollen Übungen sichtbar machen, bevor es ernst wird. Aktualisieren Sie den Plan nach jeder Übung und jeder wesentlichen Änderung. Als methodischer Rahmen eignen sich der IT-Grundschutz des BSI und der BSI-Standard 200-4 zum Business Continuity Management.

Rechtliche Fragen, etwa zu Meldepflichten, klärt der Plan nicht abschließend. Er sorgt dafür, dass die richtigen Personen rechtzeitig eingebunden werden. Diese Seite ist allgemeine Information und keine Rechtsberatung.

## Wie hilft PHP SOS konkret?

- Wir erstellen mit Ihnen das Systeminventar Ihrer Webserver, einschließlich Betriebsart und PHP-Version.
- Wir schreiben die technischen Abläufe für typische Szenarien und stimmen sie mit Hoster und Agentur ab.
- Wir führen eine Übung durch und arbeiten die Erkenntnisse in den Plan ein.
- Im Ernstfall übernehmen wir die technische Seite per [Incident Response](https://phpsos.de/leistungen/incident-response/), auf Wunsch abgesichert durch einen [Security-Wartungsvertrag](https://phpsos.de/leistungen/security-wartungsvertrag/).


## Häufige Fragen

**Wie umfangreich muss ein IT-Notfallplan sein?**  
So kurz wie möglich, so ausführlich wie nötig. Für Webserver reichen oft wenige Seiten mit Kontakten, Systemliste, Entscheidungsregeln und Abläufen. Wichtiger als der Umfang ist, dass er aktuell ist und im Ernstfall gefunden wird.

**Wo bewahre ich den Notfallplan auf?**  
An mindestens einer Stelle, die auch ohne funktionierende IT erreichbar ist, etwa ausgedruckt oder auf einem getrennten Gerät. Ein Plan, der nur auf dem betroffenen Server oder im gesperrten Firmennetz liegt, hilft im Ernstfall nicht.

**Wie oft sollte der Plan geprüft werden?**  
Mindestens einmal im Jahr und nach jeder wesentlichen Änderung, etwa einem Wechsel des Hosters oder neuer Software. Sinnvoll ist eine kurze Übung, bei der ein Szenario durchgespielt wird.

**Gibt es Vorlagen vom BSI?**  
Das BSI behandelt Notfallmanagement im Rahmen des IT-Grundschutzes und im BSI-Standard 200-4 zum Business Continuity Management. Diese eignen sich als Rahmen; für Webserver lohnt eine knappe, praxisnahe Fassung.

## Quellen

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI](https://www.bsi.bund.de/)
- [DSGVO Art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Polizei: ZAC-Übersicht](https://www.polizei.de/)