Die Notfall-Website: Wie eine einfache HTML-Seite im Ernstfall helfen kann

Kürzlich wollte ich die Website einer Klinik aufrufen. Du öffnest deren Website, doch statt der gewohnten Startseite erscheint eine Fehlermeldung. Keine Kontaktdaten, keine Übersicht der Fachabteilungen, keine Hinweise zu Öffnungszeiten und keine Information darüber, wie du die Einrichtung erreichen kannst. Vielleicht wurde die Website aus Sicherheitsgründen abgeschaltet, weil eine kritische Schwachstelle bekannt geworden ist. Die Maßnahme kann technisch vollkommen nachvollziehbar sein. Für dich als Nutzer bleibt trotzdem ein Problem: Du benötigst Informationen, bekommst aber keinen Zugriff darauf.

Genau dieses Szenario zeigt, warum sich Unternehmen und öffentliche Einrichtungen nicht allein auf die Verfügbarkeit ihrer regulären Webanwendungen verlassen sollten. Eine moderne Website ist häufig ein komplexes Zusammenspiel aus Content-Management-System, Datenbank, Programmiersprache, Erweiterungen, Schnittstellen und externen Diensten. Wird eine dieser Komponenten verwundbar oder besteht der Verdacht auf eine Kompromittierung, kann es notwendig sein, den gesamten dynamischen Webauftritt vorübergehend abzuschalten. Damit verschwinden unter Umständen auch Informationen, die technisch gar nicht von der gefährdeten Funktion abhängig sein müssten.

Dabei existiert eine erstaunlich einfache Möglichkeit, einen Teil dieser Informationsversorgung aufrechtzuerhalten: eine vorbereitete, statische HTML-Notfallseite. Sie benötigt für die Auslieferung ihrer Inhalte keine serverseitige Programmausführung und kann unabhängig von einer komplexen Webanwendung betrieben werden. Voraussetzung ist allerdings, dass auch ihre Hosting- und Auslieferungsinfrastruktur ausreichend geschützt und vom betroffenen System getrennt ist.

Die zentrale Idee lautet: Wenn eine komplexe Webanwendung aus Sicherheitsgründen abgeschaltet werden muss, sollten wichtige öffentliche Informationen nicht zwangsläufig mit ihr verschwinden.

Was ist eine HTML-Notfallseite überhaupt?

Eine HTML-Notfallseite ist eine bewusst reduzierte Website, die im Fall einer technischen Störung oder eines Sicherheitsvorfalls wichtige Informationen bereitstellt. Sie besteht beispielsweise aus HTML-Dateien, Stylesheets, Bildern und gegebenenfalls wenigen weiteren statischen Ressourcen. Im Gegensatz zu einer typischen dynamischen Website muss der Server die Inhalte nicht bei jedem Aufruf durch PHP verarbeiten oder aus einer Datenbank zusammensetzen. Der Webserver liefert stattdessen vorbereitete Dateien aus, die der Browser des Besuchers direkt darstellen kann.

Das Prinzip ist keineswegs neu. Viele einfache Unternehmenswebsites, Informationsseiten und Dokumentationen funktionieren bereits auf diese Weise. Der entscheidende Unterschied liegt im Zweck: Eine Notfallseite ist nicht primär auf Marketing, Komfort oder eine möglichst umfangreiche Nutzerführung ausgelegt. Sie soll unter eingeschränkten Bedingungen einen klar definierten Mindestumfang an Informationen verfügbar halten. Das macht sie zu einem möglichen Baustein einer übergeordneten Strategie für IT-Notfallmanagement und digitale Resilienz.

Dabei sollte man statisches HTML nicht mit vollständiger Sicherheit verwechseln. Auch eine statische Website kann über eine kompromittierte Hosting-Umgebung manipuliert werden, sensible Informationen preisgeben oder durch fehlerhafte Konfigurationen gefährdet sein. Der Vorteil besteht darin, dass bei einer konsequent statischen Umsetzung bestimmte Angriffsflächen entfallen, insbesondere die serverseitige Verarbeitung dynamischer Anfragen durch die betroffene Anwendung. Wie groß der Sicherheitsgewinn tatsächlich ist, hängt jedoch von der konkreten Architektur und dem Betrieb ab.

Was eine Notfallseite leisten sollte

Eine gute Notfallseite konzentriert sich auf wenige, klar definierte Aufgaben. Sie informiert darüber, dass der reguläre Webauftritt vorübergehend eingeschränkt ist, und stellt die wichtigsten öffentlich zugänglichen Kontakt- und Orientierungsinformationen bereit. Sie kann außerdem erklären, welche Dienste momentan nicht verfügbar sind und über welche alternativen Kanäle die Organisation erreichbar bleibt. Bei Bedarf verweist sie auf offizielle Informationsangebote anderer Stellen.

Wichtig ist, dass die Inhalte für Menschen unter Zeitdruck verständlich sind. Niemand möchte sich durch eine komplizierte Navigation arbeiten, während eine Website nicht funktioniert. Eine klare Überschrift, eine kurze Statusmeldung und direkt sichtbare Kontaktinformationen sind deshalb sinnvoller als aufwendige Animationen oder eine große Auswahl an Unterseiten.

Die Notfallseite muss auch nicht den gesamten normalen Webauftritt nachbilden. Ihr Ziel ist nicht, jede Funktion zu ersetzen, sondern die wichtigsten Informationsbedürfnisse während einer Störung abzudecken. Welche Informationen unverzichtbar sind, muss die Organisation vorab anhand ihrer Aufgaben und der Bedürfnisse ihrer Nutzer bestimmen.

Warum gerade einfache HTML-Seiten im Krisenfall interessant sind

Dynamische Websites bieten zahlreiche Vorteile. Inhalte können zentral gepflegt werden, Benutzer erhalten personalisierte Informationen, Formulare verarbeiten Eingaben und Schnittstellen verbinden verschiedene Systeme miteinander. Diese Möglichkeiten sind für viele digitale Geschäftsprozesse unverzichtbar. Gleichzeitig entstehen dadurch technische Abhängigkeiten, die bei einer Sicherheitslücke oder einem Ausfall relevant werden können.

Ein Content-Management-System kann beispielsweise auf PHP, einer Datenbank und verschiedenen Erweiterungen beruhen. Wenn eine kritische Schwachstelle die Ausführung von Schadcode ermöglicht, muss zunächst geklärt werden, welche Komponenten betroffen sind und wie sich das Risiko begrenzen lässt. Je nach Situation kann es erforderlich sein, den betroffenen Dienst vom Internet zu trennen, bis eine sichere Wiederherstellung möglich ist. Eine unabhängig bereitgestellte statische Seite kann dann einen Teil der öffentlichen Informationsversorgung übernehmen.

Der technische Vorteil ist überschaubar, aber wirkungsvoll: Die Notfallseite muss keine Datenbankabfragen ausführen, keine dynamischen Inhalte erzeugen und keine komplexen Geschäftsprozesse verarbeiten. Dadurch reduziert sich der Funktionsumfang auf das, was für die Notfallkommunikation tatsächlich erforderlich ist. Weniger Funktionen bedeuten nicht automatisch Sicherheit, können aber helfen, die Angriffsfläche zu begrenzen und die Ausweichlösung leichter prüfbar zu machen.

Weniger Funktionen, weniger Abhängigkeiten

Bei einer dynamischen Website kann bereits der Ausfall einer zentralen Komponente mehrere Funktionen gleichzeitig beeinträchtigen. Ist die Datenbank nicht erreichbar, funktionieren möglicherweise Suche, Kontaktformulare und die Seitengenerierung nicht mehr. Ist eine notwendige Erweiterung verwundbar, kann ihre Abschaltung wiederum Auswirkungen auf weitere Funktionen haben. Eine statische Notfallseite umgeht viele dieser Abhängigkeiten, sofern sie tatsächlich unabhängig betrieben wird.

Das ist insbesondere dann interessant, wenn die benötigten Informationen selten geändert werden. Telefonnummern, Anschriften, allgemeine Öffnungszeiten, Hinweise zur Erreichbarkeit und grundlegende Wegbeschreibungen lassen sich häufig ohne dynamische Funktionen bereitstellen. Auch eine kurze Statusmeldung kann als statischer Inhalt veröffentlicht werden, wenn ein festgelegter Prozess ihre Aktualisierung ermöglicht.

Für Unternehmen bedeutet das nicht, dass sie auf moderne Webtechnologien verzichten sollten. Es bedeutet vielmehr, dass nicht jede Information zwingend von der vollständigen Funktionsfähigkeit der komplexesten Anwendung abhängen muss. Eine bewusste Trennung zwischen unverzichtbarer Informationsversorgung und zusätzlichen digitalen Funktionen kann die Ausfallsicherheit verbessern.

Der Praxisfall: Wenn eine Klinik ihre Website abschalten muss

Bei Krankenhäusern und Kliniken wird besonders deutlich, warum die öffentliche Erreichbarkeit wichtiger Informationen eine eigenständige Bedeutung besitzt. Menschen suchen nach Telefonnummern, Adressen, Fachabteilungen, Sprechzeiten und Hinweisen zur Erreichbarkeit. Angehörige möchten wissen, wie sie eine Station kontaktieren können. Zuweisende Arztpraxen benötigen möglicherweise die Kontaktdaten einer Fachambulanz. Andere Besucher suchen Informationen über Anfahrt, Parkmöglichkeiten oder Besuchsregelungen.

Wird die reguläre Website wegen einer kritischen Sicherheitslücke abgeschaltet, muss das nicht bedeuten, dass die Klinik ihren medizinischen Betrieb einstellt. Dennoch kann die Informationssuche für Außenstehende erheblich erschwert werden. Besonders ungünstig ist das, wenn wichtige Kontaktdaten ausschließlich über die betroffene Website auffindbar sind und keine vorbereitete Alternative existiert.

Eine statische Notfallseite könnte hier eine sinnvolle Zwischenlösung sein. Sie würde nicht die Patientenverwaltung ersetzen, keine medizinischen Dokumente bereitstellen und keine geschützten internen Systeme zugänglich machen. Stattdessen könnte sie grundlegende Informationen anbieten, mit denen Menschen die Einrichtung weiterhin erreichen und sich orientieren können.

Welche Informationen sollten Kliniken bereitstellen?

Für eine Klinik könnte eine Notfallseite unter anderem folgende Angaben enthalten:

• Zentrale Kontaktdaten: die öffentlich vorgesehene Telefonnummer und die Postanschrift.
• Fachabteilungen und Ambulanzen: ausgewählte Kontaktmöglichkeiten, soweit deren Veröffentlichung vorgesehen und sinnvoll ist.
• Erreichbarkeit: aktuelle Hinweise zu regulären Öffnungszeiten und bekannten Einschränkungen.
• Anfahrt: die wichtigsten Angaben zum Standort und gegebenenfalls zu relevanten Eingängen.
• Statusinformation: eine kurze Erklärung, dass der reguläre Webauftritt vorübergehend eingeschränkt ist.
• Alternative Informationswege: Hinweise auf offizielle Telefonnummern oder andere geprüfte Informationsangebote.

Welche Angaben im Einzelfall geeignet sind, muss die Klinik festlegen. Telefonnummern sollten aktuell sein und keine internen Durchwahlen enthalten, die nicht für die Öffentlichkeit bestimmt sind. Außerdem muss klar zwischen allgemeinen Kontaktinformationen und medizinischer Notfallversorgung unterschieden werden. Eine Notfallseite darf nicht den Eindruck erwecken, sie sei selbst ein medizinischer Notfalldienst.

Das Konzept ist auch für Behörden, Stadtverwaltungen, Versorgungsunternehmen, Bildungseinrichtungen und Unternehmen interessant. Eine Behörde könnte beispielsweise Öffnungszeiten und alternative Kontaktwege veröffentlichen. Ein Energieversorger könnte grundlegende Servicekontakte bereitstellen. Ein Unternehmen könnte Kunden über Supportmöglichkeiten und die eingeschränkte Verfügbarkeit digitaler Dienste informieren.

Der gemeinsame Nenner ist immer derselbe: Wichtige Informationen sollten auch dann erreichbar bleiben, wenn die reguläre digitale Plattform vorübergehend nicht genutzt werden kann.

Wie eine sichere Notfallarchitektur aussehen kann

Die wichtigste technische Entscheidung betrifft nicht das Design der Seite, sondern ihre Unabhängigkeit. Eine statische HTML-Datei, die auf demselben kompromittierten Server liegt wie die reguläre Website, ist keine verlässliche Ausweichlösung. Wird der Server vollständig isoliert, bleibt auch die Notfallseite unerreichbar. Besteht der Verdacht, dass die Infrastruktur manipuliert wurde, können zudem die Integrität und Vertrauenswürdigkeit der bereitgestellten Inhalte infrage stehen.

Eine belastbare Architektur sollte deshalb die gefährdete Anwendung und den Notfallauftritt so weit wie sinnvoll voneinander trennen. Dafür kommen beispielsweise eine separate Hosting-Umgebung, ein unabhängig betriebener statischer Webdienst oder eine vorbereitete alternative Veröffentlichungsinfrastruktur infrage. Die konkrete Lösung hängt vom Schutzbedarf, den bestehenden technischen Abhängigkeiten und den organisatorischen Möglichkeiten ab.

Dabei müssen auch DNS, Domainverwaltung, Zertifikate, Administrationskonten und gegebenenfalls vorgeschaltete Sicherheitsdienste berücksichtigt werden. Wenn dieselben kritischen Komponenten für beide Angebote erforderlich sind, kann eine gemeinsame Störung beide gleichzeitig treffen. Die Architektur muss deshalb anhand realistischer Ausfallszenarien überprüft werden, anstatt lediglich auf dem Papier unabhängig zu wirken.

Drei mögliche Betriebsmodelle

Modell 1: Separate statische Hosting-Umgebung

Die Notfallseite wird unabhängig von der Hauptanwendung betrieben. Ihre Inhalte bestehen aus vorbereiteten Dateien, die über einen dafür vorgesehenen Webdienst ausgeliefert werden. Im Krisenfall kann der reguläre Webauftritt deaktiviert werden, während die alternative Informationsseite weiterhin erreichbar bleibt. Wichtig sind getrennte Zugriffsrechte, abgesicherte Administrationskonten und ein getesteter Prozess zur Aktivierung.

Modell 2: Vorbereitete Umschaltung auf eine Notfallseite

Die Organisation hält einen statischen Ersatzauftritt bereit, der bei einem definierten Ereignis aktiviert werden kann. Das kann beispielsweise über eine vorbereitete Änderung der Routing- oder DNS-Konfiguration erfolgen. Dabei muss berücksichtigt werden, dass DNS-Änderungen nicht überall sofort wirksam werden und dass zwischengespeicherte Inhalte das Verhalten beeinflussen können. Die Umschaltung muss deshalb praktisch getestet werden, und die Organisation benötigt einen Plan für den Fall, dass sie nicht wie vorgesehen funktioniert.

Modell 3: Unabhängige Status- und Informationsseite

Eine separate Statusseite kann den Zustand wichtiger digitaler Dienste erläutern und alternative Kontaktmöglichkeiten nennen. Sie ist besonders hilfreich, wenn nicht nur die Website, sondern auch einzelne Kundenportale oder andere Online-Dienste betroffen sind. Damit sie ihren Zweck erfüllt, muss sie unabhängig genug betrieben werden und darf nicht ausschließlich über die ausgefallene Plattform erreichbar sein.

Alle drei Modelle können sinnvoll sein. Es gibt jedoch keine universelle Architektur, die für jede Organisation gleichermaßen geeignet ist. Entscheidend sind die konkreten Risiken, die Anforderungen an Verfügbarkeit und Integrität sowie die Fähigkeit, den Ersatzweg im Ernstfall zuverlässig zu aktivieren.

Was auf einer guten HTML-Notfallseite stehen sollte

Die Gestaltung einer Notfallseite sollte sich an einem einfachen Prinzip orientieren: Menschen müssen die wichtigste Information möglichst schnell finden. Eine überladene Seite ist ebenso wenig hilfreich wie eine leere Fehlermeldung. Der Inhalt sollte auf die wichtigsten Fragen eingehen: Was ist passiert? Welche Dienste sind betroffen? Wie kann ich die Organisation erreichen? Und wo finde ich weitere verlässliche Informationen?

Dabei sollte die Organisation nur Informationen veröffentlichen, deren Richtigkeit sie verantworten kann. Bei einem laufenden Sicherheitsvorfall sind die Ursachen möglicherweise noch nicht vollständig geklärt. Es wäre deshalb falsch, bereits einen erfolgreichen Angriff zu behaupten, wenn bislang nur eine vorsorgliche Abschaltung bekannt ist. Umgekehrt sollte eine bestätigte Störung nicht mit einer nichtssagenden Formulierung verschleiert werden.

Eine gute Statusmeldung unterscheidet klar zwischen bestätigten Fakten, noch offenen Fragen und den Maßnahmen, die gerade durchgeführt werden. Sie sollte außerdem einen Zeitpunkt der letzten Aktualisierung enthalten. Falls noch keine neuen Erkenntnisse vorliegen, kann auch eine kurze Aktualisierung sinnvoll sein, die erklärt, dass die Untersuchung weiterläuft.

Beispiel für eine einfache Notfallseite

Die folgende Struktur zeigt, wie ein reduzierter Informationsauftritt aussehen könnte:

[Name der Organisation] – wichtige Informationen

Unser regulärer Webauftritt ist derzeit eingeschränkt.

Aus Sicherheitsgründen ist unser reguläres Online-Angebot vorübergehend nicht verfügbar. Wir prüfen die Situation und arbeiten daran, die betroffenen Dienste sicher wieder bereitzustellen.

Kontakt

• • Zentrale: [öffentlich vorgesehene Telefonnummer]
  • Anschrift: [Postanschrift]
  • Allgemeine Anfragen: [alternative Kontaktmöglichkeit, sofern verfügbar]

Wichtige Hinweise

• • Nicht verfügbare Online-Dienste: [konkrete Angaben]
  • Alternative Kontaktwege: [geprüfte Informationen]
  • Letzte Aktualisierung: [Datum und Uhrzeit]

Weitere Informationen veröffentlichen wir, sobald belastbare neue Erkenntnisse vorliegen.

Dieses Beispiel ist bewusst schlicht gehalten. Es enthält keine dynamischen Funktionen und verspricht nicht, dass sämtliche Dienste weiterhin zur Verfügung stehen. Vor einer Verwendung müssen die Platzhalter ersetzt, die Inhalte freigegeben und die Angaben auf ihre Richtigkeit geprüft werden.

Auch der Hinweis auf einen Sicherheitsvorfall sollte sorgfältig formuliert werden. Die Organisation sollte nicht unnötig technische Details veröffentlichen, die die laufende Untersuchung beeinträchtigen könnten. Gleichzeitig sollte sie die Öffentlichkeit nicht mit irreführenden Aussagen abspeisen. Verständlichkeit und Verlässlichkeit sind wichtiger als beschönigende PR-Formulierungen.

Die technische Umsetzung: Einfach, aber nicht nachlässig

Eine statische HTML-Seite lässt sich mit vergleichsweise wenig technischem Aufwand erstellen. Für eine einfache Variante reichen eine HTML-Datei, ein Stylesheet und gegebenenfalls ein Logo oder weitere statische Grafiken. Die Seite kann so gestaltet werden, dass sie auf Smartphones, Tablets und Desktopgeräten lesbar bleibt. Eine aufwendige JavaScript-Anwendung ist für die grundlegende Informationsversorgung in der Regel nicht erforderlich.

Ein wichtiger Vorteil besteht darin, dass die Seite auf serverseitige Skriptausführung verzichten kann. Wenn die Notfallseite tatsächlich ausschließlich statische Dateien ausliefert, ist für deren Bereitstellung kein PHP-Prozess notwendig. Dadurch kann sie von einer Schwachstelle in der PHP-Verarbeitung der Hauptanwendung unabhängig sein, sofern keine gemeinsamen gefährdeten Komponenten bestehen.

Die technische Einfachheit darf allerdings nicht zu falscher Sicherheit führen. Auch statische Inhalte können manipuliert werden, wenn Angreifer Zugriff auf das Hosting-Konto, die Veröffentlichungsumgebung oder die Domainverwaltung erlangen. Ebenso kann eine falsch konfigurierte Infrastruktur sensible Informationen offenlegen oder die Seite ungewollt verändern. Die Notfalllösung benötigt daher einen angemessenen Schutz ihrer Administrationswege und eine klare Kontrolle darüber, wer Inhalte veröffentlichen darf.

Diese technischen Punkte sind wichtig

• Getrennte Infrastruktur: Die Notfallseite sollte nicht von der gefährdeten Anwendung oder deren Serverprozess abhängen.
• Geschützte Administrationszugänge: Zugriffe sollten auf notwendige Personen und Berechtigungen begrenzt sein.
• HTTPS: Die Seite sollte über eine gültige, vertrauenswürdige TLS-Verbindung erreichbar sein.
• Minimale Abhängigkeiten: Externe Skripte, unnötige Tracking-Dienste und zusätzliche dynamische Komponenten sollten vermieden werden.
• Geprüfte Inhalte: Kontaktinformationen und Statusmeldungen müssen vor der Veröffentlichung kontrolliert werden.
• Regelmäßige Tests: Die Erreichbarkeit und der Umschaltprozess sollten in festgelegten Abständen überprüft werden.

Je weniger Funktionen eine Notfallseite enthält, desto leichter lässt sie sich häufig überprüfen und betreiben. Das ist besonders wertvoll, wenn die Lösung im Krisenfall von einem kleinen Team aktiviert werden muss. Trotzdem müssen auch einfache Lösungen in das bestehende Sicherheits- und Betriebsmodell integriert werden.

Die organisatorische Herausforderung: Wer aktiviert die Notfallseite?

Eine vorbereitete HTML-Seite ist nur dann hilfreich, wenn sie im Ernstfall tatsächlich veröffentlicht werden kann. Deshalb gehört die Zuständigkeit für ihre Aktivierung in das Notfallkonzept. Es muss klar sein, wer eine Abschaltung oder Umschaltung anordnen darf, wer die technische Umsetzung durchführt und wer für die Freigabe der öffentlichen Informationen verantwortlich ist.

Diese Rollen müssen nicht zwingend bei einer einzigen Person liegen. Die technische Entscheidung kann bei der zuständigen IT-Sicherheits- oder Betriebsverantwortung liegen, während die Kommunikation gemeinsam mit dem betroffenen Fachbereich abgestimmt wird. Wichtig ist, dass die Organisation nicht erst während des Vorfalls klären muss, wer überhaupt entscheiden darf.

Auch Vertretungsregelungen sind unverzichtbar. Wenn die einzige Person mit Zugriff auf die alternative Hosting-Umgebung nicht erreichbar ist, wird aus einer vermeintlich vorbereiteten Lösung schnell ein weiteres Problem. Zugangsdaten, Berechtigungen und Aktivierungsanleitungen müssen deshalb sicher verwaltet und für autorisierte Vertretungen verfügbar sein.

Der Notfallprozess sollte vorab feststehen

Ein praktikabler Ablauf umfasst mindestens fünf Schritte:

1. Vorfall bewerten: Ist die reguläre Website sicher weiterzubetreiben, oder muss sie isoliert werden?
2. Entscheidung treffen: Wer ordnet die Abschaltung und gegebenenfalls die Aktivierung der Notfallseite an?
3. Ersatzweg aktivieren: Die vorbereitete Infrastruktur wird nach dem festgelegten Verfahren erreichbar gemacht.
4. Informationen prüfen: Die veröffentlichte Statusmeldung und die Kontaktdaten werden auf Richtigkeit kontrolliert.
5. Betrieb überwachen: Die Organisation prüft, ob die Seite erreichbar bleibt und ob Aktualisierungen erforderlich sind.

Diese Schritte sind kein Ersatz für einen umfassenden Incident-Response-Plan. Sie bilden einen klar definierten Teilprozess, der in das übergeordnete Sicherheits- und Notfallmanagement integriert werden sollte.

Business Continuity Management: Die Notfallseite als Teil einer größeren Strategie

Business Continuity Management (BCM) beschäftigt sich mit der Frage, wie eine Organisation ihre wesentlichen Leistungen bei Störungen aufrechterhalten oder innerhalb festgelegter Zeiträume wiederherstellen kann. Dabei geht es nicht nur um Server, Datenbanken oder Backups. Entscheidend ist, welche Leistungen für Kunden, Patienten, Beschäftigte und andere Anspruchsgruppen kritisch sind und welche Alternativen im Notfall zur Verfügung stehen müssen.

Das britische National Cyber Security Centre empfiehlt, kritische Leistungen und ihre technischen Abhängigkeiten zu identifizieren, realistische Ausweichverfahren zu planen und die Wiederherstellung regelmäßig zu testen. Eine solche Betrachtung passt unmittelbar zur Frage, wie wichtige öffentliche Informationen bei einem Website-Ausfall verfügbar bleiben können. Die Notfallseite ist dabei ein möglicher Baustein, aber nicht die gesamte Lösung.

Eine Organisation sollte beispielsweise untersuchen, welche Folgen ein Ausfall ihres Webauftritts hat. Sind wichtige Kontaktdaten anderweitig verfügbar? Können Kunden den Support weiterhin erreichen? Welche digitalen Funktionen müssen möglichst schnell wiederhergestellt werden? Und welche Informationen können auch dann noch bereitgestellt werden, wenn die Hauptanwendung vorübergehend nicht vertrauenswürdig ist?

Aus dieser Analyse ergeben sich konkrete Anforderungen an die Notfallarchitektur. Manche Organisationen benötigen lediglich eine statische Informationsseite. Andere brauchen zusätzlich alternative Kommunikationskanäle, manuelle Ersatzverfahren oder einen umfassenderen Wiederanlaufplan für kritische Anwendungen. Der richtige Umfang hängt von der Bedeutung der jeweiligen Leistung und den möglichen Auswirkungen eines Ausfalls ab.

Die Notfallseite muss regelmäßig getestet werden

Eine Notfallseite, die noch nie unter realistischen Bedingungen aktiviert wurde, ist zunächst nur eine Annahme über die eigene Krisenfähigkeit. Vielleicht funktioniert die Domainumschaltung nicht. Vielleicht ist das Zertifikat abgelaufen. Vielleicht sind die Kontaktdaten veraltet oder die zuständige Person nicht erreichbar.

Deshalb sollte die Organisation regelmäßig prüfen, ob die Ersatzlösung unter den vorgesehenen Bedingungen funktioniert. Dazu gehören sowohl technische Tests als auch organisatorische Übungen. Das NCSC weist ausdrücklich darauf hin, dass Übungen Schwachstellen in Notfallplänen sichtbar machen können, die erst während einer tatsächlichen Störung auffallen würden.

Ein guter Test beantwortet deshalb nicht nur die Frage, ob eine HTML-Datei geladen wird. Er überprüft, ob die Organisation den gesamten Ablauf zuverlässig durchführen kann: von der Entscheidung über die Aktivierung bis zur Veröffentlichung korrekter Informationen und der späteren Rückkehr zum regulären Betrieb.

Die häufigsten Fehler bei der Planung einer Notfall-Website

Der erste Fehler besteht darin, die Notfallseite auf derselben Infrastruktur wie die reguläre Website zu betreiben, ohne deren gemeinsame Abhängigkeiten zu prüfen. Wird der gesamte Server abgeschaltet oder muss die Hosting-Umgebung als kompromittiert gelten, ist die Ausweichlösung möglicherweise ebenfalls nicht erreichbar. Eine Notfallseite ist deshalb nur so unabhängig wie die Infrastruktur, auf der sie bereitgestellt wird.

Der zweite Fehler ist die Vernachlässigung der Inhalte. Telefonnummern können sich ändern, Abteilungen umziehen und Öffnungszeiten angepasst werden. Wenn die Notfallseite seit zwei Jahren nicht aktualisiert wurde, hilft sie im Krisenfall möglicherweise weniger als erwartet. Die Inhalte müssen daher in einen regelmäßigen Pflegeprozess eingebunden werden, der Verantwortlichkeiten und Freigaben klar festlegt.

Der dritte Fehler ist ein unklarer Aktivierungsprozess. Wenn niemand weiß, wann die Notfallseite eingeschaltet werden soll oder wer die notwendigen Berechtigungen besitzt, kann die technische Vorbereitung im entscheidenden Moment wertlos sein. Ein klarer Ablauf mit Vertretungsregelungen und getesteten Zugangsmöglichkeiten ist deshalb genauso wichtig wie der eigentliche Webserver.

Der vierte Fehler ist eine unklare Kommunikation. Ein Besucher muss erkennen können, dass es sich um eine reduzierte Informationsseite handelt und welche Dienste betroffen sind. Die Organisation sollte weder unnötige Details über laufende Sicherheitsmaßnahmen veröffentlichen noch falsche Sicherheit vermitteln. Eine kurze, präzise und regelmäßig aktualisierte Statusmeldung schafft mehr Vertrauen als eine leere Fehlerseite.

Der fünfte Fehler ist die Annahme, dass statisches HTML sämtliche Risiken beseitigt. Die Notfallseite kann bestimmte technische Abhängigkeiten reduzieren, schützt aber nicht automatisch vor kompromittierten Zugangsdaten, fehlerhaften DNS-Konfigurationen oder einem Angriff auf die Hosting-Infrastruktur. Auch sie benötigt ein angemessenes Sicherheitskonzept.

Was kostet eine Notfallseite und wann lohnt sie sich?

Eine einfache statische HTML-Seite kann mit überschaubarem Entwicklungsaufwand erstellt werden. Die eigentlichen Kosten hängen jedoch davon ab, wie unabhängig die Infrastruktur sein soll, welche Sicherheitsanforderungen gelten und wie aufwendig die Aktivierung in den bestehenden Betrieb integriert werden muss. Für eine kleine Organisation kann eine reduzierte Informationsseite ausreichen. Eine Klinik oder ein größerer Dienstleister benötigt möglicherweise zusätzliche Anforderungen an Verfügbarkeit, Freigabeprozesse und Überwachung.

Die wirtschaftliche Betrachtung sollte deshalb nicht nur die Erstellungskosten berücksichtigen. Relevant sind auch die möglichen Auswirkungen eines Ausfalls: zusätzlicher Aufwand im Kundenservice, vergebliche Kontaktversuche, Verzögerungen bei wichtigen Anliegen und ein möglicher Vertrauensverlust. Bei öffentlichen Einrichtungen kommen gesellschaftliche Folgen hinzu, die sich nicht einfach auf entgangene Umsätze reduzieren lassen.

Das bedeutet nicht, dass jede Organisation eine aufwendige zweite Infrastruktur aufbauen muss. Es bedeutet, dass die Entscheidung bewusst anhand des Schutzbedarfs und der möglichen Folgen getroffen werden sollte. Eine einfache, getestete Ausweichlösung kann für bestimmte Informationsangebote bereits einen erheblichen Nutzen bieten.

Die wichtigste Investition ist dabei nicht unbedingt die Entwicklung der HTML-Seite. Sie liegt in der Analyse der Anforderungen, der Pflege der Inhalte, der technischen Trennung und der regelmäßigen Erprobung. Genau diese organisatorischen Aufgaben entscheiden darüber, ob aus einer einfachen Website ein tatsächlich nutzbarer Notfallkanal wird.

Digitale Resilienz beginnt mit der richtigen Frage

Die Diskussion über IT-Sicherheit konzentriert sich verständlicherweise häufig auf die Verhinderung von Angriffen. Unternehmen sollen Schwachstellen schließen, Systeme überwachen, Zugriffe absichern und Sicherheitsvorfälle schnell erkennen. All das ist notwendig. Doch selbst gut organisierte Sicherheitsmaßnahmen können dazu führen, dass bestimmte Systeme vorsorglich abgeschaltet werden müssen.

Deshalb gehört eine zweite Frage in jede ernsthafte IT-Strategie: Welche Leistungen und Informationen müssen verfügbar bleiben, wenn ein System aus Sicherheitsgründen nicht mehr genutzt werden kann? Diese Frage verbindet technische Sicherheit mit Business Continuity Management und der Verantwortung gegenüber den Menschen, die auf digitale Angebote angewiesen sind.

Eine statische HTML-Notfallseite ist dafür kein Allheilmittel. Sie ist aber ein konkreter, verständlicher und in vielen Fällen vergleichsweise einfacher Baustein. Sie kann helfen, grundlegende Kontaktinformationen verfügbar zu halten, Statusmeldungen zu veröffentlichen und den Verlust wichtiger Informationswege zu begrenzen. Voraussetzung ist, dass sie unabhängig genug betrieben, sicher verwaltet und regelmäßig getestet wird.

Gerade bei Kliniken, Behörden und anderen Organisationen mit wichtigen öffentlichen Aufgaben sollte die Verfügbarkeit grundlegender Informationen bewusst in die Notfallplanung einfließen. Das bedeutet nicht, Sicherheitsmaßnahmen zu verzögern oder gefährdete Anwendungen weiterzubetreiben. Es bedeutet, bereits vor einem Vorfall darüber nachzudenken, wie die Organisation während einer notwendigen Abschaltung erreichbar bleiben kann.

Fazit: Eine einfache HTML-Seite kann einen großen Unterschied machen

Eine kritische Sicherheitslücke kann dazu führen, dass eine Organisation ihre reguläre Website vorübergehend vom Netz nehmen muss. In einer solchen Situation hat die Sicherheit der Systeme Vorrang. Daraus folgt jedoch nicht automatisch, dass sämtliche öffentlich zugänglichen Informationen verschwinden müssen.

Eine vorbereitete, statische HTML-Notfallseite kann einen wichtigen Teil der Informationsversorgung aufrechterhalten. Sie benötigt keine serverseitige PHP-Ausführung für ihre statischen Inhalte und kann unabhängig von einer komplexen Webanwendung bereitgestellt werden. Damit sie tatsächlich hilft, müssen allerdings die Infrastruktur ausreichend getrennt, die Inhalte aktuell und der Aktivierungsprozess getestet sein.

Für mich liegt die entscheidende Erkenntnis in einem einfachen Gedanken: Eine Organisation sollte nicht erst während eines Sicherheitsvorfalls überlegen, wie sie erreichbar bleibt. Sie sollte diese Frage beantworten, solange ihre Systeme noch funktionieren und die Beteiligten genügend Zeit haben, eine vernünftige Lösung aufzubauen.

Denn professionelle IT-Sicherheit bedeutet nicht nur, Systeme im Ernstfall sicher abschalten zu können. Sie bedeutet auch, die Auswirkungen dieser Entscheidung zu verstehen und wichtige Leistungen so gut wie möglich aufrechtzuerhalten.

Die beste Notfallseite ist deshalb nicht die schönste. Es ist diejenige, die im entscheidenden Moment erreichbar ist, verlässliche Informationen liefert und Menschen nicht mit einer Fehlermeldung alleinlässt.

Wie ist eure Organisation vorbereitet?

Habt ihr bereits eine statische Notfallseite oder einen unabhängigen Informationskanal für den Fall, dass eure reguläre Website aus Sicherheitsgründen abgeschaltet werden muss? Oder hängt eure gesamte öffentliche Kommunikation an einem einzigen Content-Management-System?

Mich interessiert besonders, welche Erfahrungen ihr mit Notfallplanung, IT-Sicherheit und Business Continuity Management gemacht habt. Welche Informationen müssten bei euch unbedingt erreichbar bleiben, selbst wenn die Hauptwebsite von einer Minute auf die andere offline geht?

Ich selbst war erstaunt darüber, wie viele Websites von Gemeinden, aber auch Kliniken aufgrund der PHP Sicherheitslücke auf einmal nicht erreichbar waren.