Wenn Sicherheit zum digitalen Blackout führt: Was die aktuelle PHP-Sicherheitslücke über die Krisenfähigkeit unserer Unternehmen verrät

Es gibt Momente, in denen sich die Qualität einer IT-Organisation nicht an ihrer Technologie, ihren Zertifizierungen oder ihren Hochglanzpräsentationen messen lässt. Sie zeigt sich dann, wenn etwas schiefgeht. Wenn eine kritische Sicherheitslücke bekannt wird, die Telefone bei IT-Dienstleistern heißlaufen und innerhalb weniger Stunden Entscheidungen getroffen werden müssen. Genau solche Momente offenbaren, ob Unternehmen auf Krisen vorbereitet sind oder lediglich hoffen, dass es schon irgendwie gut gehen wird.

Am 21. Oktober 2026 sorgten zwei kritische Sicherheitslücken in PHP für erhebliche Unruhe. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) bewertete die Bedrohung als außerordentlich hoch. Zahlreiche Behörden, Universitäten, Krankenhäuser und Unternehmen nahmen ihre Internetangebote vorsorglich vom Netz oder schränkten sie ein. Auch mehrere Universitätskliniken in Baden-Württemberg waren betroffen. Die Sicherheitsmaßnahme war angesichts der möglichen Folgen nachvollziehbar.

Doch damit begann ein zweites Problem, das in der Diskussion über Cybersicherheit leicht untergeht: Was passiert mit den Menschen, die eine Website gerade jetzt benötigen?

Wer eine Klinik sucht, möchte vielleicht eine Telefonnummer nachschlagen, die Adresse einer Fachambulanz finden, sich über Besuchszeiten informieren oder herausfinden, wie eine bestimmte Abteilung erreichbar ist. Wer eine Behörde kontaktieren muss, benötigt möglicherweise eine Durchwahl oder ein Formular. Und wer auf die Website eines Unternehmens angewiesen ist, sucht vielleicht eine Supportnummer, eine Störungsmeldung oder eine wichtige Information zu einem laufenden Vorgang.

Wenn eine komplette Website verschwindet, verschwinden für diese Menschen zunächst auch die digitalen Zugangswege zu diesen Informationen. Eine Klinik kann intern weiterhin hervorragend funktionieren und ihre medizinische Versorgung uneingeschränkt fortsetzen. Trotzdem kann ihre externe Kommunikation erheblich beeinträchtigt sein.

Genau hier liegt der entscheidende Punkt: IT-Sicherheit darf nicht ausschließlich den Schutz technischer Systeme betrachten. Sie muss auch die Verfügbarkeit wichtiger Informationen und die Handlungsfähigkeit der Menschen berücksichtigen, die auf diese Informationen angewiesen sind.

Die PHP-Sicherheitslücke war deshalb nicht nur ein technischer Stresstest. Sie war auch ein Test für das Notfallmanagement, die digitale Kommunikation und die Fähigkeit von Organisationen, Sicherheit und Erreichbarkeit gleichzeitig zu denken.

Was hinter der PHP-Sicherheitslücke steckt und warum die Warnung ernst zu nehmen war

PHP ist eine serverseitige Programmiersprache, die seit Jahrzehnten einen erheblichen Teil des Webs ermöglicht. Sie verarbeitet Anfragen, erzeugt dynamische Webseiten, kommuniziert mit Datenbanken und bildet die technische Grundlage zahlreicher Content-Management-Systeme und Webanwendungen. Auch Systeme, bei denen PHP im Hintergrund kaum sichtbar ist, können entsprechende Komponenten enthalten. Deshalb lässt sich das tatsächliche Ausmaß einer Schwachstelle nicht allein anhand der sichtbaren Website oder ihrer Startseite beurteilen.

Im Oktober 2026 standen zwei kritische Schwachstellen im Mittelpunkt, die unter den Kennungen CVE-2026-109618 und CVE-2026-109619 veröffentlicht wurden. Unter bestimmten Bedingungen konnten sie dazu führen, dass Angreifer ohne vorherige Anmeldung Schadcode auf einem verwundbaren Server ausführen. Technisch geht es dabei um Fehler im Umgang mit Speicherzuständen und Speicherfehlern. Eine erfolgreiche Ausnutzung hätte gravierende Folgen haben können, bis hin zur Übernahme eines betroffenen Systems.

Das ist kein Risiko, das man mit einem Achselzucken und dem Versprechen abtun sollte, irgendwann das nächste Wartungsfenster zu nutzen. Die zuständigen europäischen Cybersicherheitsstellen empfahlen deshalb, betroffene Anwendungen zu identifizieren, die bereitgestellten Sicherheitsupdates einzuspielen und öffentlich erreichbare Systeme zu priorisieren. Wenn eine unmittelbare Absicherung nicht möglich war, sollte die betroffene Anwendung gegebenenfalls vom öffentlichen Netz isoliert werden.

Wichtig ist deshalb eine faire Einordnung: Die vorsorgliche Abschaltung einer verwundbaren Anwendung ist nicht automatisch ein Zeichen für schlechte IT-Arbeit. Wenn ein kritischer Angriff droht und ein Patch noch nicht installiert oder ausreichend geprüft ist, kann die Abschaltung die fachlich richtige Entscheidung sein. Wer in einer solchen Situation den Schutz von Daten und Infrastruktur priorisiert, handelt zunächst verantwortungsbewusst.

Die berechtigte Frage beginnt an einer anderen Stelle: Warum musste bei manchen Organisationen offenbar die gesamte öffentliche Informationsversorgung gemeinsam mit der gefährdeten Anwendung verschwinden? Welche Alternativen waren vorbereitet? Und warum wirkte die Abschaltung nach außen teilweise so, als hätte man zwischen einem verwundbaren Webauftritt und gar keinem Webauftritt nur die Wahl zwischen zwei Extremen?

Die Abschaltung war nachvollziehbar. Der vollständige Informationsverlust war es nicht zwangsläufig.

Besonders deutlich wurde das Problem bei öffentlichen Einrichtungen und Kliniken. Der SWR berichtete am 21. Oktober 2026, dass unter anderem die Universitätskliniken Mannheim und Heidelberg sowie weitere Hochschulen in Baden-Württemberg ihre Internetseiten vorsorglich abgeschaltet hatten. Die Einrichtungen erklärten, dass es sich um Präventionsmaßnahmen handelte und die Patientenversorgung nicht betroffen sei.

Das ist eine wichtige Unterscheidung. Eine abgeschaltete Website bedeutet nicht, dass eine Klinik ihren medizinischen Betrieb eingestellt hat. Ebenso wenig beweist die Abschaltung, dass Angreifer bereits erfolgreich in die Systeme eingedrungen waren. Die verfügbaren Berichte beschrieben die Maßnahmen überwiegend als vorsorglich. Wer daraus unmittelbar auf einen erfolgreichen Angriff oder ein grundsätzliches Versagen der IT schließt, geht zu weit.

Trotzdem bleibt ein organisatorisches Problem bestehen. Für Patientinnen, Angehörige und andere Besucher ist die öffentliche Website häufig der erste Anlaufpunkt. Sie liefert Kontaktdaten, Anfahrtsbeschreibungen, Informationen zu Fachabteilungen, Besuchsregelungen und Sprechzeiten. Je nach Einrichtung kommen Hinweise für Notfallambulanzen, Informationen für zuweisende Praxen oder Erklärungen zum Ablauf bestimmter Behandlungen hinzu.

Wenn diese Informationen nicht mehr erreichbar sind, entsteht eine zusätzliche Hürde. Menschen müssen Telefonnummern anderweitig recherchieren, sich durch Suchmaschinentreffer arbeiten oder hoffen, dass irgendwo noch eine alte PDF-Datei verfügbar ist. Wer die betreffende Einrichtung nicht kennt, steht womöglich vor der simplen Frage, welche Nummer überhaupt die richtige ist.

Gerade bei Kliniken halte ich das für einen vermeidbaren Schwachpunkt. Nicht, weil eine Klinik ihre Sicherheitsmaßnahmen zugunsten einer hübschen Website zurückstellen sollte. Sondern weil die öffentliche Informationsversorgung bei der Planung einer Sicherheitsmaßnahme mitgedacht werden muss.

Meine Kritik richtet sich deshalb nicht gegen das Offline-Nehmen an sich. Sie richtet sich gegen fehlende Alternativen, sofern solche Alternativen technisch und organisatorisch umsetzbar gewesen wären.

Denn eine Website ist nicht nur eine Ansammlung von Softwarekomponenten. Sie ist auch ein Kommunikationskanal zwischen einer Organisation und der Öffentlichkeit. Wer diesen Kanal abschaltet, sollte wissen, wie die wichtigsten Informationen weiterhin zugänglich bleiben.

Die unterschätzte Lösung: Eine statische HTML-Notfallseite

Hier kommt eine Technik ins Spiel, die älter ist als viele der heute eingesetzten Webframeworks und trotzdem erstaunlich aktuell bleibt: die statische HTML-Seite.

Eine klassische HTML-Seite benötigt für die Auslieferung ihres Inhalts nicht zwingend PHP, eine Datenbank oder ein komplexes Content-Management-System. Ein entsprechend konfigurierter Webserver kann vorbereitete HTML-, CSS- und Bilddateien direkt ausliefern. Solange die dafür benötigte Infrastruktur nicht selbst betroffen ist, kann ein solcher Notfallauftritt auch dann Informationen bereitstellen, wenn das dynamische Hauptsystem abgeschaltet werden muss.

Das ist keine universelle Lösung für jede Sicherheitslücke. Es ist aber eine vergleichsweise einfache Möglichkeit, die Verfügbarkeit wichtiger öffentlicher Informationen von der Funktionsfähigkeit einer komplexen Webanwendung zu entkoppeln.

Variante A: Die Notfallseite auf einer getrennten Infrastruktur

Ein separat betriebener Webserver oder ein entsprechend abgesicherter statischer Hosting-Dienst stellt eine reduzierte Informationsseite bereit. Diese Infrastruktur sollte möglichst unabhängig vom gefährdeten Produktivsystem sein. Die Inhalte können bei einer Störung über eine vorbereitete Umschaltung erreichbar gemacht werden.

Variante B: Eine vorbereitete Notfallseite für den bestehenden Webauftritt

Die Organisation hält eine statische, regelmäßig aktualisierte Version der wichtigsten öffentlichen Informationen bereit. Im Krisenfall wird der dynamische Auftritt deaktiviert und der Informationsbereich über einen unabhängigen Auslieferungsweg veröffentlicht. Entscheidend ist, dass dieser Weg nicht von derselben gefährdeten Anwendung abhängt.

Variante C: Eine zusätzliche, unabhängige Informationsquelle

Kontaktdaten, wichtige Telefonnummern und grundlegende Hinweise können zusätzlich über einen anderen kontrollierten Kanal bereitgestellt werden, beispielsweise eine separate Statusseite oder eine geeignete öffentliche Informationsplattform. Diese Möglichkeit ersetzt keine technische Notfallseite, kann aber die Kommunikation während einer Störung ergänzen.

Eine solche Notfallseite muss nicht schön sein. Sie muss funktionieren. Im Zweifel ist eine schlichte Seite mit klaren Überschriften, lesbarer Schrift, Telefonnummern und einer eindeutigen Statusmeldung wesentlich hilfreicher als eine aufwendige Startseite mit Animationen, Videos und einem nicht erreichbaren Kontaktformular.

Für eine Klinik könnte der reduzierte Auftritt beispielsweise folgende Informationen enthalten:

• Zentrale Telefonnummer und Postanschrift.
• Kontaktdaten wichtiger Kliniken, Institute und Ambulanzen.
• Hinweise zur Erreichbarkeit und zu den regulären Öffnungszeiten.
• Eine klare Information darüber, welche Online-Dienste vorübergehend nicht verfügbar sind.
• Hinweise, wie Patientinnen, Angehörige und medizinische Fachkräfte die Einrichtung erreichen können.
• Einen Verweis auf offizielle Notfallinformationen, sofern dies für den konkreten Zweck sinnvoll ist.

Die Seite sollte dabei keine sensiblen Patientendaten, internen Ansprechpartnerlisten oder nicht für die Öffentlichkeit bestimmten Informationen enthalten. Sie ist kein Ersatzsystem für die Patientenverwaltung und kein alternativer Zugang zu internen Anwendungen. Sie dient ausschließlich dazu, wichtige öffentliche Informationen verfügbar zu halten.

Aber Vorsicht: Statisches HTML ist kein automatischer Sicherheitsjoker

Eine statische HTML-Seite ist nur dann eine belastbare Ausweichlösung, wenn sie tatsächlich von der gefährdeten Komponente unabhängig ist. Liegt sie auf demselben verwundbaren Server, hängt sie von derselben kompromittierten Infrastruktur ab oder wird sie weiterhin über eine betroffene PHP-Anwendung ausgeliefert, kann sie das Problem nicht zuverlässig lösen.

Auch DNS, Reverse Proxy, Load Balancer, CDN, Zertifikate und die verwendete Hosting-Umgebung müssen in die Betrachtung einbezogen werden. Ein vermeintlich unabhängiger Notfallauftritt kann wirkungslos sein, wenn seine Erreichbarkeit an einer gemeinsam genutzten Komponente hängt, die im Krisenfall ebenfalls abgeschaltet wird.

Die entscheidende Frage lautet deshalb nicht nur: Haben wir eine HTML-Seite? Sie lautet: Können wir diese Seite sicher und unabhängig veröffentlichen, wenn unser regulärer Webauftritt nicht mehr vertrauenswürdig ist?

Das muss vor einem Vorfall geplant, getestet und dokumentiert werden. Eine Notfallseite, von der niemand weiß, wo sie liegt, wer sie aktivieren darf oder wie ihre Domain umgeschaltet wird, ist im Ernstfall ungefähr so hilfreich wie ein Feuerlöscher, dessen Schlüssel im Büro des abwesenden Facility-Managers liegt.

Business Continuity: Warum die Website ein Teil der betrieblichen Grundversorgung ist

In vielen Unternehmen wird IT-Notfallmanagement noch immer primär aus der Perspektive der internen Betriebsfähigkeit betrachtet. Sind die Server erreichbar? Funktionieren die Anwendungen? Sind Datenbanken konsistent? Können Mitarbeitende weiterarbeiten? Diese Fragen sind wichtig, reichen aber nicht aus, wenn eine Organisation auch gegenüber Kunden, Patienten, Lieferanten und der Öffentlichkeit handlungsfähig bleiben muss.

Genau dafür gibt es Business Continuity Management (BCM). Es beschäftigt sich damit, kritische Geschäftsprozesse bei Störungen aufrechtzuerhalten oder innerhalb definierter Zeiträume wiederherzustellen. Dabei geht es nicht darum, jedes System um jeden Preis weiterzubetreiben. Vielmehr müssen Organisationen unterscheiden, welche Leistungen unverzichtbar sind, welche zeitweise ausfallen dürfen und welche Ersatzverfahren im Krisenfall greifen.

Eine Website kann aus technischer Sicht ein einzelnes System sein. Aus fachlicher Sicht erfüllt sie jedoch mehrere Funktionen: Sie informiert, vermittelt Kontakte, unterstützt Serviceprozesse, ermöglicht Terminbuchungen und schafft Orientierung. Je nach Organisation können einzelne dieser Funktionen geschäftskritisch oder gesellschaftlich besonders relevant sein.

Wer eine Klinik-Website ausschließlich als Marketingkanal betrachtet, unterschätzt daher ihre tatsächliche Bedeutung. Der Bereich für Pressemitteilungen mag einige Tage entbehrlich sein. Die Telefonnummer einer Ambulanz ist es unter Umständen nicht. Ein Online-Shop kann vielleicht auf Bestellfunktionen verzichten, während Lieferstatus und Supportinformationen weiterhin benötigt werden. Bei einer Behörde können allgemeine Informationen verfügbar bleiben, obwohl interaktive Formulare vorübergehend abgeschaltet werden müssen.

Die entscheidenden Fragen gehören auf den Tisch, bevor es brennt

Eine professionelle Business-Impact-Analyse sollte für jede wichtige digitale Leistung klären, welche Folgen ein Ausfall hat, welche Personengruppen betroffen sind und wie lange die Unterbrechung tolerierbar ist. Daraus werden Prioritäten für Wiederanlauf und Ersatzverfahren abgeleitet. Diese Bewertung muss gemeinsam mit den Fachbereichen erfolgen, nicht allein durch die technische Betriebsorganisation.

Dazu gehören insbesondere folgende Fragen:

• Welche Informationen müssen selbst bei einem vollständigen Ausfall der Hauptwebsite öffentlich erreichbar bleiben?
• Welche Kommunikationswege benötigen Patienten, Kunden oder Bürger, um die Organisation weiterhin zu erreichen?
• Welche Systeme müssen dafür zwingend funktionieren und welche können unabhängig davon bereitgestellt werden?
• Wie schnell muss ein Ersatzangebot verfügbar sein, und wer darf dessen Aktivierung veranlassen?
• Wie wird sichergestellt, dass die veröffentlichten Informationen aktuell, korrekt und rechtlich unbedenklich sind?

Das sind keine akademischen Übungen für ein BCM-Handbuch, das anschließend im SharePoint-Archiv verstaubt. Die Antworten müssen in konkrete technische und organisatorische Maßnahmen übersetzt werden.

Hier zeigt sich auch der Unterschied zwischen einer vorhandenen Notfalldokumentation und tatsächlicher Krisenfähigkeit. Ein Dokument kann vollständig sein, ohne dass die Organisation einen Wiederanlauf jemals praktisch erprobt hat. Erst ein Test zeigt, ob Zuständigkeiten funktionieren, Zugangsdaten verfügbar sind, Umschaltungen gelingen und die vorgesehenen Ersatzverfahren tatsächlich erreichbar sind.

Die unbequeme Frage: Warum wird die Ausweichlösung oft erst im Krisenfall gesucht?

Eine statische Notfallseite ist keine revolutionäre Technologie. Die zugrunde liegenden Konzepte sind seit Langem bekannt. Umso interessanter ist die Frage, warum Organisationen bei einem Ausfall ihrer dynamischen Website offenbar nicht immer unmittelbar auf einen vorbereiteten Informationskanal zurückgreifen können.

Eine mögliche Erklärung ist die gewachsene Architektur. Über Jahre werden Content-Management-Systeme, Buchungsfunktionen, Schnittstellen, Tracking, Suchfunktionen und weitere Komponenten miteinander verbunden. Irgendwann hängt die öffentliche Informationsversorgung an einem technisch komplexen Gesamtsystem, dessen einzelne Bestandteile organisatorisch unterschiedlichen Verantwortlichen gehören.

Hinzu kommen Beschaffungs- und Betriebsentscheidungen. Ein Webauftritt wird vielleicht als Projekt umgesetzt, später an einen Dienstleister übergeben und anschließend hauptsächlich über Wartungsverträge verwaltet. Die Frage, wie sich der Auftritt im Krisenfall auf einen sicheren Minimalbetrieb reduzieren lässt, wird dagegen nicht immer als eigenständige Anforderung behandelt.

Auch die Zuständigkeiten können unklar sein. Die IT verantwortet die technische Sicherheit, die Unternehmenskommunikation die Inhalte, ein externer Anbieter das Hosting und ein Fachbereich die Terminbuchung. Wenn eine akute Sicherheitswarnung eintrifft, müssen diese Verantwortungsbereiche plötzlich zusammenarbeiten. Ohne vorbereitete Entscheidungswege kostet allein die Abstimmung wertvolle Zeit.

Das sind mögliche strukturelle Ursachen, keine nachgewiesenen Erklärungen für jede einzelne Abschaltung im Oktober 2026. Von außen lässt sich nicht beurteilen, welche Einrichtungen bereits über Notfallkonzepte verfügten, welche Alternativen technisch ausgeschlossen waren oder welche Abhängigkeiten im konkreten Fall bestanden. Gerade deshalb sollte die Kritik auf die überprüfbare Frage zielen, ob die Informationsversorgung angemessen abgesichert war.

Ein Unternehmen muss nicht jede Krise verhindern können. Es sollte aber vorbereitet sein, die Folgen einer Krise zu begrenzen.

Dazu gehört, eine Sicherheitslücke nicht isoliert als Problem der IT-Abteilung zu behandeln. Sobald eine Maßnahme die Erreichbarkeit öffentlicher Informationen beeinträchtigt, sind auch Geschäftsführung, Fachbereiche, Kommunikation und gegebenenfalls die Verantwortlichen für Patientensicherheit oder öffentliche Dienstleistungen gefragt.

So sollte ein belastbarer Notfallplan für Websites aussehen

Ein guter Notfallplan muss nicht kompliziert sein. Er muss die richtigen Entscheidungen vorbereiten und in einer Stresssituation umsetzbar bleiben. Dafür braucht es eine Kombination aus technischer Vorsorge, klaren Verantwortlichkeiten und regelmäßigen Tests.

Checkliste: Website-Ausfall und Sicherheitslücke

Erstens: Risiken kennen und Systeme priorisieren

Die Organisation muss wissen, wo PHP eingesetzt wird, welche Versionen laufen und welche Anwendungen davon abhängen. Dazu zählen nicht nur die offensichtlich sichtbaren Websites, sondern auch externe Komponenten, eingebundene Software und möglicherweise weniger bekannte Webangebote. Die europäischen Cybersicherheitsstellen haben ausdrücklich dazu geraten, PHP-basierte Anwendungen zu identifizieren und internetexponierte Systeme vorrangig zu behandeln.

Zweitens: Einen sicheren Minimalbetrieb definieren

Für jede kritische öffentliche Leistung sollte feststehen, welche Informationen auch während einer technischen Störung verfügbar bleiben müssen. Das kann eine statische HTML-Seite sein, aber auch ein anderer unabhängig betriebener Informationskanal. Wichtig ist, dass die Ersatzlösung keine unnötigen dynamischen Funktionen enthält und nicht von der gefährdeten Anwendung abhängig ist.

Drittens: Zuständigkeiten und Freigaben regeln

Ein Notfall ist der falsche Zeitpunkt, um herauszufinden, wer die Umschaltung durchführen darf. Die technische Aktivierung, die fachliche Freigabe der Inhalte und die externe Kommunikation benötigen klare Verantwortliche. Ebenso muss feststehen, wer bei Nichterreichbarkeit einzelner Verantwortlicher entscheiden darf.

Viertens: Die Ersatzlösung testen

Ein erfolgreicher Test bedeutet nicht, dass eine Seite im normalen Betrieb aufrufbar ist. Es muss praktisch überprüft werden, ob sie auch dann funktioniert, wenn die Hauptanwendung vollständig abgeschaltet wurde. Dazu gehören DNS-Umschaltung, TLS-Zertifikate, Erreichbarkeit von Mobilgeräten, korrekte Kontaktdaten und die Verständlichkeit der Statusmeldung.

Fünftens: Sicher wieder anlaufen

Nach einem Sicherheitsvorfall reicht es nicht, einfach den Patch zu installieren und den Server wieder freizuschalten. Es muss geprüft werden, ob Hinweise auf eine Kompromittierung vorliegen, ob die relevanten Komponenten vollständig aktualisiert wurden und ob möglicherweise weitere Maßnahmen notwendig sind. Die britische Cybersicherheitsbehörde NCSC empfiehlt ausdrücklich, vor der Aktualisierung beziehungsweise Absicherung auch nach Anzeichen einer Kompromittierung und installierten Hintertüren zu suchen, wenn ein unmittelbares Abschalten oder eine sofortige Mitigation nicht möglich war.

Der wirtschaftliche Blick: Resilienz kostet Geld – Ausfälle ebenfalls

Bei der Frage nach einer Notfallseite geht es nicht nur um Technik. Es geht auch um wirtschaftliche Prioritäten. Unternehmen investieren häufig erhebliche Summen in leistungsfähige Webanwendungen, moderne Benutzeroberflächen und neue Funktionen. Die Frage, wie ein reduzierter Betrieb im Krisenfall aussehen soll, wirkt daneben schnell wie ein nebensächlicher Kostenpunkt.

Dabei kann eine vorbereitete Ausweichlösung helfen, Folgekosten zu begrenzen. Weniger Anfragen landen bei überlasteten Telefonzentralen, weniger Menschen suchen vergeblich nach Kontaktdaten und die Organisation bleibt zumindest teilweise erreichbar. Bei kommerziellen Angeboten können außerdem Kundenservice und wichtige Statusinformationen verfügbar bleiben.

Natürlich muss eine solche Lösung entwickelt, gepflegt und getestet werden. Auch eine statische Seite verursacht Aufwand, und eine getrennte Infrastruktur ist nicht automatisch kostenlos. Entscheidend ist deshalb, den Aufwand in Relation zum möglichen Schaden zu bewerten. Bei einer Klinik oder einer Behörde kann die gesellschaftliche Bedeutung der Informationsversorgung wichtiger sein als eine unmittelbar messbare Umsatzwirkung.

Das Management sollte deshalb nicht nur fragen, was eine Notfalllösung kostet. Es sollte auch fragen, welche Folgen es hätte, wenn die Organisation im entscheidenden Moment keine verlässlichen Informationen bereitstellen kann.

Dazu gehören nicht nur entgangene Einnahmen, sondern auch Vertrauensverlust, zusätzlicher Kommunikationsaufwand, mögliche rechtliche Risiken und die Belastung von Mitarbeitenden. Die tatsächlichen Auswirkungen unterscheiden sich je nach Einrichtung und müssen im Rahmen der jeweiligen Risikoanalyse bewertet werden.

Resilienz ist kein Luxus für Unternehmen mit übergroßem IT-Budget. Sie ist eine Frage bewusster Priorisierung.

Was die PHP-Krise über Führung und IT-Governance verrät

Ein kritischer Sicherheitsvorfall bringt technische, organisatorische und wirtschaftliche Interessen in Konflikt. Die IT möchte verhindern, dass Angreifer Systeme übernehmen. Die Fachbereiche wollen ihre Leistungen aufrechterhalten. Die Kommunikation möchte verlässliche Informationen veröffentlichen. Die Geschäftsführung muss Risiken bewerten und Entscheidungen treffen.

Eine funktionierende IT-Governance sorgt dafür, dass diese Perspektiven nicht erst während der Krise zusammenfinden. Sie definiert Zuständigkeiten, Risikogrenzen und Entscheidungswege im Voraus. Dabei muss klar sein, wer eine Abschaltung veranlassen darf, welche Leistungen als besonders kritisch gelten und welche Ersatzmaßnahmen bereitstehen.

Führung zeigt sich gerade darin, dass Sicherheit nicht gegen die Geschäftsfähigkeit ausgespielt wird. Eine Abschaltung kann erforderlich sein. Ein unvorbereiteter Verlust sämtlicher Informationskanäle sollte jedoch Anlass sein, die eigene Notfallplanung kritisch zu überprüfen.

Das gilt besonders für Organisationen, deren Leistungen für viele Menschen wichtig sind. Bei einer Klinik ist die öffentliche Website kein Ersatz für die medizinische Versorgung. Aber sie ist ein Bestandteil der Kommunikation, über den Menschen die Versorgung erreichen und sich orientieren können. Diese Verbindung zwischen technischer Verfügbarkeit und tatsächlichem Nutzen für die Öffentlichkeit gehört in jede ernsthafte Risikoanalyse.

Die entscheidende Führungsfrage lautet deshalb: Haben wir lediglich dafür gesorgt, dass unsere Systeme sicher abgeschaltet werden können, oder haben wir auch dafür gesorgt, dass unsere Organisation währenddessen handlungsfähig bleibt?

Das ist ein erheblicher Unterschied.

Mein Fazit: Sicherheit bedeutet mehr, als den Stecker zu ziehen

Die PHP-Sicherheitslücke im Oktober 2026 war ernst zu nehmen. Die Möglichkeit, über eine Schwachstelle Schadcode auf verwundbaren Servern auszuführen, rechtfertigte schnelle und entschlossene Maßnahmen. Wer eine potenziell gefährdete Anwendung vorsorglich isoliert, handelt nicht automatisch übervorsichtig, sondern kann damit genau das tun, was verantwortungsvolle IT-Sicherheit verlangt.

Trotzdem darf die Diskussion nicht bei der Frage stehen bleiben, ob eine Abschaltung technisch gerechtfertigt war. Sie muss auch berücksichtigen, welche Auswirkungen diese Entscheidung auf die Menschen hatte, die auf die Informationen der betroffenen Organisationen angewiesen waren.

Dass Kliniken und öffentliche Einrichtungen zeitweise nicht über ihre gewohnten Websites erreichbar waren, ist deshalb ein Anlass für eine ernsthafte Diskussion über digitale Resilienz. Es wäre allerdings nicht sachgerecht, allein aus der Abschaltung auf mangelnde Vorbereitung zu schließen. Dafür fehlen bei den einzelnen Einrichtungen die notwendigen Einblicke in Architektur, Risikoabwägung und vorhandene Ersatzverfahren.

Was sich daraus sehr wohl ableiten lässt: Organisationen sollten ihre Notfallplanung daraufhin überprüfen, ob wichtige öffentliche Informationen unabhängig von ihrer dynamischen Hauptwebsite verfügbar bleiben können. Eine statische HTML-Notfallseite ist dafür eine naheliegende und technisch vergleichsweise einfache Möglichkeit. Sie muss allerdings sicher isoliert, aktuell gehalten und regelmäßig getestet werden.

Es ist geradezu paradox, wenn eine moderne digitale Organisation zwar in der Lage ist, komplexe Webanwendungen zu betreiben, aber für eine grundlegende Informationsversorgung im Krisenfall keine geeignete Alternative bereithält. Die Lösung besteht nicht darin, auf moderne Technologien zu verzichten. Sie besteht darin, ihre Grenzen zu erkennen und bewusst Ausweichmöglichkeiten zu schaffen.

Mein Anspruch an ein professionelles IT- und Krisenmanagement wäre deshalb klar: Wenn ein System aus Sicherheitsgründen abgeschaltet werden muss, sollte die Organisation bereits wissen, welche Leistungen sie trotzdem aufrechterhalten kann.

Bei einer Klinik sollten dazu zumindest die wichtigsten öffentlich zugänglichen Kontaktinformationen gehören, soweit sich diese sicher und unabhängig bereitstellen lassen. Bei einer Behörde sind es möglicherweise Öffnungszeiten, Ansprechpartner und Hinweise zu dringenden Anliegen. Bei einem Unternehmen können es Supportkontakte, Statusinformationen und grundlegende Servicehinweise sein.

Nicht jede Funktion muss im Notfall verfügbar bleiben. Aber die wichtigsten Informationen sollten nicht einfach mit der Hauptanwendung verschwinden.

Denn digitale Resilienz zeigt sich nicht daran, dass eine Organisation niemals offline geht. Sie zeigt sich daran, dass sie auch dann noch für ihre Nutzer da sein kann, wenn der normale Betrieb vorübergehend nicht möglich ist.

Und genau das sollte aus einer solchen Sicherheitskrise gelernt werden.

Wie seht ihr das? War das vorsorgliche Abschalten der Websites aus eurer Sicht alternativlos, oder hätten mehr Organisationen eine statische HTML-Notfallseite mit wichtigen Kontaktinformationen bereithalten müssen?

Mich interessiert besonders die Perspektive aus IT-Betrieb, IT-Sicherheit, Business Continuity Management und Unternehmensführung: Wie stellt ihr sicher, dass eure Organisation auch dann erreichbar bleibt, wenn eure zentrale Webanwendung aus Sicherheitsgründen abgeschaltet werden muss?