Zum Inhalt springen
MARCODES
Abstraktes Relief aus dunklem Papier: ein fallender Block wird von einer Halterung aufgefangen

Notfallplan für Ihre Webanwendung: die erste Stunde

In der ersten Stunde nach einem Ausfall bestätigt eine verantwortliche Person die Störung, grenzt sie ein, informiert Kunden und Mitarbeiter und holt den letzten funktionierenden Stand zurück. Ein Notfallplan für den Website-Ausfall legt diese Schritte vorher fest, damit im Ernstfall niemand improvisieren muss.

10 min Lesezeit Performance & DevOps

Oft meldet sich ein Ausfall auf Umwegen: Ein Kunde ruft an, weil das Portal eine Fehlerseite zeigt, oder die Überwachung schickt eine Mail an ein Postfach, das niemand liest. Die ersten Minuten vergehen dann mit der Frage, wer sich kümmert.

Der Plan unten teilt die erste Stunde in Zeitfenster, jeweils mit dem Ergebnis, das am Ende vorliegt. Er passt für eine Website ebenso wie für ein Portal oder einen Onlineshop, ob die Technik im Haus oder bei einem Dienstleister liegt. Am Ende steht eine Notfallkarte zum Ausdrucken. Wie Sie einen Ausfall überhaupt bemerken, behandeln die Monitoring-Mythen; hier geht es um die Stunde danach.

Vor Minute 0

Eine Person führt, alle anderen wissen, wer

Der Notfallplan nennt eine Person, die den Vorfall leitet, und eine Vertretung. Die Vorfallsleitung repariert nichts selbst; sie protokolliert, entscheidet über Kommunikation und Rückweg und ist die Anlaufstelle für alle. Dazu kommen drei Rollen, in kleinen Unternehmen auf zwei Personen verteilt:

  • Technik: untersucht Server, Anwendung und Datenbank und nimmt Änderungen zurück, im Haus oder beim Dienstleister.

  • Kommunikation: schreibt die Statusmeldungen und gibt sie nach Freigabe heraus.

  • Entscheidung: eine erreichbare Person aus der Geschäftsführung für Geld, Kundenzusagen und Meldungen an Behörden.

Wer diese Aufgaben im Alltag trägt, regelt ein Zuständigkeitsblatt für den Betrieb nach dem Launch. Die erste Handlung der Vorfallsleitung ist eine Notiz mit der Uhrzeit, zu der das Unternehmen vom Ausfall erfahren hat. An diesen Zeitpunkt knüpfen die gesetzlichen Meldefristen an.

Ein Smartphone liegt auf der Notfallkarte, die erste Zeile auf dem Bildschirm ist orange: geprüft wird von außen.

Minute 0 bis 15

Bestätigen und eingrenzen

In den ersten 15 Minuten klären Sie, ob die Anwendung tatsächlich ausgefallen ist und wo die Störung ungefähr liegt.

Bestätigt wird von außen. Im Firmennetz können VPN, Proxy oder DNS-Zwischenspeicher täuschen. Öffnen Sie die Adresse deshalb auf einem Smartphone im Mobilfunknetz. Den Befehl auf der Notfallkarte führen Sie auf einem Laptop aus, der über den Hotspot dieses Smartphones verbunden ist, nicht im Firmennetz. Er ruft die Seite ab und zeigt nur den Statuscode: 200 heißt, der Server liefert aus; 301 oder 302 heißen Weiterleitung, etwa von http auf https, dann wiederholen Sie den Befehl mit -L, um das Ziel zu prüfen; 500 oder 503 heißen, die Anwendung hat ein Problem; 000 heißt, es kam keine Verbindung zustande, dann liegt die Spur bei Netz, DNS oder Server. Ein 200 belegt nicht, dass Bestellungen durchlaufen; prüfen Sie deshalb auch einen Ablauf wie Anmeldung oder Bestellung von Hand.

Zum Eingrenzen:

  • Hoster: Hetzner führt Störungen und Wartungsarbeiten auf einer öffentlichen Statusseite, andere Anbieter im Kundenbereich oder auf eigenen Seiten.

  • Letzte Änderung: Deployment, Update, DNS oder Zertifikat kurz vor dem Ausfall sind die erste Spur.

  • Umfang: alles weg oder nur Anmeldung, Zahlung, Formulare, Mailversand oder eine angebundene Schnittstelle?

Wer einen Dienstleister mit technischem Support hat, eröffnet in diesem Fenster den Vorfall über die vereinbarte Notfallnummer. Wie schnell sich eine Störung eingrenzen lässt, hängt daran, ob vorher gemessen wurde. Beim Taxifahrer-Portal der Taxi-München eG, das seit dem Auftrag im Juli 2025 produktiv läuft, haben wir die Performance-Beobachtung mit Laravel Nightwatch vom ersten produktiven Tag an eingerichtet; Engpässe werden dort sichtbar, bevor Beschwerden kommen.

Am Ende steht ein Satz im Protokoll: was betroffen ist, seit wann, erste Vermutung.

Minute 15 bis 30

Kunden und Mitarbeiter informieren

Spätestens nach 30 Minuten sieht der Plan eine erste Nachricht an alle Betroffenen vor, auch wenn die Ursache noch offen ist. Wer nichts hört, ruft an und bindet jemanden, der bei der Behebung fehlt.

Die Nachricht nennt, was betroffen ist, seit wann, wie man Sie erreicht und wann die nächste Information kommt. Vermutungen zur Ursache und Zusagen zur Dauer gehören nicht hinein. Der Kanal darf nicht vom Ausfall abhängen: Eine Meldung auf dem ausgefallenen Server erreicht niemanden. Geeignet sind eine extern gehostete Statusseite, eine Telefonansage und eine Mail an wichtige Kunden über einen getrennten Versanddienst.

Intern bekommen alle mit Kundenkontakt denselben kurzen Text. Danach folgen Aktualisierungen in festem Takt, etwa jede halbe Stunde, auch ohne Neuigkeit: „Wir arbeiten weiter daran, nächste Information um 11:30 Uhr“ erspart Rückfragen.

Minute 30 bis 60

Zurück zum letzten funktionierenden Stand

Im dritten Fenster ist das Ziel eine laufende Anwendung, notfalls in einem älteren Stand oder mit abgeschalteter Funktion; die Ursachensuche folgt danach. Der IT-Grundschutz des BSI fordert im Baustein OPS.1.1.3, dass beim Einspielen von Patches und Änderungen Rückfall-Lösungen vorhanden sind; in diesem Fenster wird eine davon gebraucht.

Die Wege, geordnet nach ihrem Risiko:

  1. Letzte Änderung zurücknehmen: den vorherigen Stand des Deployments aktivieren oder die geänderte Einstellung zurücksetzen.

  2. Funktion abschalten: Zahlung, Formular oder Schnittstelle vorübergehend aus, der Rest läuft weiter.

  3. Wartungsseite statt Fehlerseite: eine statische Seite, die sagt, was los ist und wie man Sie erreicht.

  4. Backup zurückspielen: der letzte Ausweg, weil er Daten kostet. Liegt das Backup um 2 Uhr nachts und der Ausfall um 11 Uhr, fehlen danach neun Stunden an Bestellungen und Änderungen, die aus Mails, Zahlungsanbieter oder Protokollen nachgetragen werden müssen. Sichern Sie vorher den defekten Stand als Kopie.

Liegt die Störung beim Hoster, entscheidet die Geschäftsführung, ob gewartet oder auf eine vorbereitete Ausweichumgebung gewechselt wird. Deuten unbekannte Administratorkonten, veränderte Dateien oder eine Erpressernachricht auf einen Angriff hin, wird nichts gelöscht oder überschrieben; Protokolle und Datenstände werden gesichert.

Nach der ersten Stunde

Wann aus einem Ausfall ein Meldefall wird

Ein Ausfall allein ist nicht automatisch meldepflichtig. Zwei Regelwerke können greifen, beide rechnen ab dem Zeitpunkt, zu dem Sie vom Vorfall erfahren haben.

Datenschutz-Grundverordnung

Eine Verletzung des Schutzes personenbezogener Daten ist nach Art. 4 Nr. 12 DSGVO eine Sicherheitsverletzung, die zu Vernichtung, Verlust, Veränderung, unbefugter Offenlegung oder unbefugtem Zugang führt. Der Europäische Datenschutzausschuss zählt in seinen Leitlinien 9/2022 auch den vorübergehenden Verlust der Verfügbarkeit durch einen Sicherheitsvorfall dazu, eine geplante Systemwartung nicht. Jede solche Verletzung wird nach Art. 33 Abs. 5 dokumentiert. Der Aufsichtsbehörde gemeldet wird sie unverzüglich und möglichst binnen 72 Stunden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen (Art. 33 Abs. 1). Bei voraussichtlich hohem Risiko werden zusätzlich die Betroffenen benachrichtigt (Art. 34). Als Gegenpole nennen die Leitlinien ein Krankenhaus, in dem fehlende Patientendaten Operationen verzögern, und ein Medienunternehmen, das nach einem Stromausfall einige Stunden keinen Newsletter versenden kann; im zweiten Fall besteht wahrscheinlich kein Risiko.

Der Digital Omnibus der EU-Kommission vom 19.11.2025 (COM(2025) 837) schlägt vor, nur noch bei voraussichtlich hohem Risiko zu melden, mit 96 Stunden Frist und über eine zentrale Meldestelle. Am 29.05.2026 ist das ein Vorschlag im Gesetzgebungsverfahren; es gelten 72 Stunden.

NIS2 und BSI-Gesetz

Das NIS-2-Umsetzungsgesetz wurde am 05.12.2025 verkündet (BGBl. 2025 I Nr. 301), laut BSI gelten die Pflichten seit dem 06.12.2025. Die Meldepflicht trifft besonders wichtige und wichtige Einrichtungen nach § 28 BSIG: vor allem Unternehmen eines in Anlage 1 oder 2 genannten Sektors mit mindestens 50 Mitarbeitern oder mit Jahresumsatz und Jahresbilanzsumme von jeweils über 10 Millionen Euro, dazu Betreiber kritischer Anlagen und einige Anbieter unabhängig von ihrer Größe. Vernachlässigbare Nebentätigkeiten bleiben bei der Zuordnung außer Betracht (§ 28 Abs. 3). Sie melden einen erheblichen Sicherheitsvorfall nach § 32 BSIG an die gemeinsame Meldestelle von BSI und BBK: Erstmeldung spätestens 24 Stunden nach Kenntnis, Meldung binnen 72 Stunden, Abschlussmeldung spätestens einen Monat danach. Ob Ihr Unternehmen dazugehört, sollte vor dem ersten Vorfall geklärt sein.

Vorbereitung

Was vor dem ersten Ernstfall bereitliegen sollte

In den Plan gehören:

  • Notfallkarte: ausgefüllt und ausgedruckt dort, wo sie auch ohne Intranet und Mail erreichbar ist.

  • Zugänge: Hoster, Registrar, DNS und Code-Repository laufen auf Konten des Unternehmens, mit mindestens zwei berechtigten Personen.

  • Überwachung von außen: Alarme gehen an eine Person mit Vertretung, nicht an ein Sammelpostfach.

  • Rückweg: Der vorherige Stand lässt sich in Minuten aktivieren, Backups liegen außerhalb des Servers, die Wiederherstellung wurde mit Stoppuhr geprobt.

  • Zusagen: Reaktions- und Lösungszeiten schriftlich vereinbart und messbar gemacht.

Für die wahrscheinlichsten Ausfälle gehört je ein kurzes Runbook mit den ersten Diagnoseschritten dazu. Für unsere Kunden schreiben wir solche Runbooks, halten sie aktuell und proben sie in Trockenübungen. Für die höchste Stufe P1 gelten ein sofortiger Bridge-Call, halbstündliche Status-Updates und vorab benannte Entscheider, so beschrieben auf unserer Seite zur Vorbereitung auf IT-Notfälle.

Die Notfallkarte zum Ausfüllen und Ausdrucken:

notfallkarte-webanwendung.txt text 
NOTFALLKARTE WEBANWENDUNG                          Stand: __.__.____
Anwendung / Adresse: ..............................................

ROLLEN               Name              Telefon           Vertretung
Vorfallsleitung      ...............   ...............   ...............
Technik/Dienstl.     ...............   ...............   ...............
Kommunikation        ...............   ...............   ...............
Entscheidung (GF)    ...............   ...............   ...............
Datenschutz          ...............   ...............   ...............

NUMMERN UND ABLAGEORTE (keine Passwörter auf diese Karte)
Hoster, Statusseite: .........................  Kundennr.: ..........
Registrar und DNS:   .........................  Notfallnr.: .........
Passwortmanager:     .........................  Backups: ............

MINUTE 0      Uhrzeit notieren, zu der wir vom Ausfall erfahren haben: __:__
MINUTE 0-15   Von außen prüfen: Smartphone im Mobilfunknetz, Laptop am
              Hotspot des Smartphones (nicht im Firmennetz):
              curl -s -o /dev/null -w "%{http_code}\n" -m 10 https://www.ihre-domain.de
              (Windows: curl.exe statt curl, NUL statt /dev/null)
              200 = Server liefert   301/302 = Weiterleitung, mit -L wiederholen
              5xx = Anwendung        000 = keine Verbindung (Netz, DNS, Server)
              Statusseite des Hosters ansehen
              Letzte Änderung? Deployment, Update, DNS, Zertifikat
              Umfang? alles / Anmeldung / Zahlung / Formular / Mail
              Dienstleister über Notfallnummer anrufen, Vorfall eröffnen
MINUTE 15-30  Erste Statusmeldung an Kunden und Mitarbeiter (Vorlage unten)
              Nächste Meldung angekündigt für: __:__
MINUTE 30-60  Rückweg wählen: letzte Änderung zurück / Funktion aus /
              Wartungsseite / Backup (vorher aktuellen Stand sichern)
              Verdacht auf Angriff: nichts löschen, Protokolle sichern
NACH 60 MIN   Meldepflicht prüfen: DSGVO 72 h, NIS2 24 h (falls betroffen)
              Protokoll weiterführen, Nachbesprechung ansetzen

VORLAGE STATUSMELDUNG
Seit __:__ Uhr ist [Dienst] nicht erreichbar / nur eingeschränkt nutzbar.
Betroffen: ...................  Nicht betroffen: ...................
In dieser Zeit erreichen Sie uns unter: ...........................
Die nächste Information folgt spätestens um __:__ Uhr.

Kurz beantwortet

Häufige Fragen

  • Alle, die im Ernstfall handeln oder angerufen werden: Vorfallsleitung und Vertretung, Technik oder Dienstleister, Kundenkommunikation, Geschäftsführung und Datenschutzbeauftragter. Mitarbeiter mit Kundenkontakt brauchen mindestens die Statusvorlage und den Namen der Vorfallsleitung. Eine jährliche Probe zeigt, ob alle ihre Rolle kennen.

  • Über einen Kanal, der vom Ausfall nicht betroffen ist, etwa eine extern gehostete Statusseite oder eine Telefonansage. Die Meldung nennt Umfang, Beginn, Ausweichkontakt und den Zeitpunkt der nächsten Information. Aktualisierungen folgen in festem Takt, bis der Dienst wieder läuft.

  • Macht ein Sicherheitsvorfall personenbezogene Daten unzugänglich, wird das nach der DSGVO dokumentiert und binnen 72 Stunden gemeldet, außer es entsteht voraussichtlich kein Risiko für die Betroffenen; geplante Wartung zählt nicht. Wichtige und besonders wichtige Einrichtungen nach § 28 BSIG melden erhebliche Sicherheitsvorfälle zusätzlich binnen 24 Stunden an BSI und BBK.

Karte ausgefüllt, Rückweg noch nie geprobt?

Wir simulieren mit Ihnen einen Ausfall, schreiben die Runbooks, die dabei fehlen, und üben sie, bevor es ernst wird.

Incident Management ansehen

Nachweise

Quellen und Stand

Stand: 29.05.2026. Dieser Beitrag beschreibt die Rechtslage zum genannten Datum und ist keine Rechtsberatung. Der curl-Befehl der Notfallkarte wurde unter macOS mit dem mitgelieferten curl gegen erreichbare, weiterleitende und nicht erreichbare Adressen geprüft; die Windows-Schreibweise folgt der curl-Dokumentation.

Artikel teilen