Thema 3.9 — Business Continuity und Disaster Recovery

In Gesundheit und Pflege ist ein größerer Systemausfall ein Ereignis der Patientensicherheit, bevor er ein IT-Problem ist; Ihre Fähigkeit, Versorgung weiter zu erbringen, während ein System ausgefallen ist – und es vollständig und schnell wiederherzustellen –, ist daher eine klinische Kernfähigkeit und eine des öffentlichen Vertrauens, keine technische Fußnote.

Warum das in Gesundheit und Pflege wichtig ist#

Versorgung hört nicht auf, wenn die Technologie aufhört. Wenn eine elektronische Patientenakte, eine E-Verordnungsplattform oder ein Laborergebnissystem über ein Krankenhaus hinweg ausfällt, kann Klinikpersonal die Behandlung nicht pausieren, während Ingenieure arbeiten. Es muss weiter Patientinnen und Patienten sehen, Medikamente verordnen und Entscheidungen treffen – oft ohne die Allergiewarnungen, Dosisprüfungen und Vorgeschichte, die das ausgefallene System normalerweise liefert. Deshalb wird ein Ausfall nicht nur in Ausfallstunden und Service-Gutschriften gemessen; er wird in verzögerten Diagnosen, übersehenen Wechselwirkungen, abgesagten Operationen und dem zusätzlichen Risiko gemessen, das jede blind arbeitende Klinikerin trägt. Business Continuity ist die Disziplin, dafür zu sorgen, dass Versorgung so sicher bleibt, wie sie sein kann, wenn das Schlimmste eintritt.

Der Einsatz ist national und gut dokumentiert. Der WannaCry-Ransomware-Angriff von 2017 legte rund ein Drittel der NHS Trusts in England lahm, erzwang die Absage Tausender Termine und Operationen, leitete Rettungswagen um und sperrte Personal aus genau den Geräten – darunter manche Bildgebungs- und Pathologiegeräte –, die es zur Behandlung von Menschen brauchte. Er kostete den NHS geschätzte 92 Millionen Pfund und zeigte, wichtiger noch, dass ein Cyberangriff auf Gesundheitsinfrastruktur als klinische Krise landet, nicht bloß als Datensicherheitsvorfall. Seither ist Resilienz vom Serverraum an den Vorstandstisch gewandert, und zu Recht.

Dieses Thema erweitert die operative Disziplin von Thema 3.8 — Servicemanagement und Live-Betrieb, verlagert aber den Fokus vom Alltagsbetrieb auf große Störungen: das Feuer, die Flut, den Cyberangriff, den Lieferantenzusammenbruch oder den regionalen Ausfall, der einen kritischen Service für Stunden oder Tage lahmzulegen droht. Es hängt eng mit Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit zusammen (weil die Wiederherstellung nach Ransomware inzwischen ein zentrales Kontinuitätsszenario ist), mit Thema 4.0 — Technische Architektur, Cloud und Altsysteme (weil Resilienz eingeplant, nicht angeflanscht wird) und mit Thema 6.4 — Governance und Assurance (weil jemand den Plan verantworten, testen und dafür rechenschaftspflichtig sein muss). Machen Sie es richtig, und Störung wird ein schlechter Tag; machen Sie es falsch, und sie wird eine öffentliche Untersuchung.

Kernkonzepte#

Business Continuity und Disaster Recovery. Business-Continuity-Planung (BCP) ist die Fähigkeit, Produkte oder Services – in Ihrem Fall sichere Versorgung – während und nach einem störenden Ereignis auf vordefinierten akzeptablen Niveaus weiter zu liefern. IT-Disaster-Recovery (DR) ist die engere, technische Teilmenge, die sich mit der Wiederherstellung der Systeme, Daten und Infrastruktur befasst, die diese Services tragen. Business Continuity ist das weitere Versprechen („Patientinnen und Patienten werden weiter behandelt“); Disaster Recovery ist eines der Mittel („das Ergebnissystem ist binnen vier Stunden zurück“). Sie brauchen beides und dürfen einen wiederhergestellten Server nicht mit einem wiederhergestellten Service verwechseln.

Business-Continuity-Management und Business-Impact-Analyse. Business-Continuity-Management (BCM) ist der laufende Managementprozess – kein einmaliges Dokument –, der Bedrohungen identifiziert und organisatorische Resilienz aufbaut. Seine Grundlage ist die Business-Impact-Analyse (BIA): eine strukturierte Bewertung jedes Services, die fragt, wie schnell sein Verlust inakzeptablen Schaden verursacht, wovon er abhängt und wie weit in der Zeit zurück Sie Datenverlust verkraften können. In der BIA tritt klinisches Urteilsvermögen in das Engineering ein: Klinikpersonal, nicht nur Techniker, muss definieren, was „inakzeptabel“ für ein Mutterschaftssystem im Vergleich zu einem Mitarbeiter-Intranet bedeutet.

Recovery Time Objective und Recovery Point Objective. Zwei Zahlen verankern jeden Wiederherstellungsplan. Das Recovery Time Objective (RTO) ist die maximal akzeptable Zeit, einen Service nach einem Ausfall wiederherzustellen. Das Recovery Point Objective (RPO) ist die maximal akzeptable Datenverlustmenge, als Zeit ausgedrückt – ein RPO von fünfzehn Minuten bedeutet, dass Sie höchstens den Verlust der letzten fünfzehn Minuten an Einträgen verkraften können. Für ein kritisches klinisches System können das Minuten sein; für ein Berichts-Data-Warehouse Tage. Sie je Service ehrlich zu setzen ist die nützlichste Kontinuitätsentscheidung, die Sie treffen werden.

Backups und getestete Wiederherstellungen. Ein Backup ist eine anderswo gespeicherte Kopie von Daten, damit das Original nach einem Verlust wiederhergestellt werden kann. Die Branchen-Basis ist die 3-2-1-Regel: drei Kopien, auf zwei Medientypen, eine davon außer Haus gehalten (und, im Ransomware-Zeitalter, eine unveränderlich oder offline gehalten). Entscheidend: Ein nie wiederhergestelltes Backup ist eine Hoffnung, keine Kontrolle. Ransomware verschlüsselt routinemäßig Backups, die vom Netzwerk erreichbar sind, und ungetestete Wiederherstellungen scheitern routinemäßig am Tag. Die Disziplin lautet nicht „sichern wir?“, sondern „wann haben wir zuletzt erfolgreich Ende-zu-Ende wiederhergestellt, und wie lange dauerte es?“

Hochverfügbarkeit, Redundanz und Failover. Hochverfügbarkeit (High Availability, HA) ist eine Designeigenschaft, die ein System durch Komponentenausfälle am Laufen hält, meist in „Neunen“ der Verfügbarkeit gemessen. Sie wird durch Redundanz erreicht – die bewusste Duplizierung kritischer Komponenten – und Failover, den automatischen Wechsel zu einer Standby-Komponente oder einem Standby-Standort, wenn der primäre ausfällt. Hochverfügbarkeit senkt die Häufigkeit von Ausfällen; Disaster Recovery behandelt die, die durchkommen. Sie sind komplementär, keine Alternativen, und ihre Verwechslung hinterlässt gefährliche Lücken.

Single Points of Failure und kritische Abhängigkeiten. Ein Single Point of Failure (SPOF) ist jede Komponente, deren Ausfall den ganzen Service stoppt – eine Netzwerkverbindung, ein Authentifizierungsdienst, ein Lieferant, eine Datenbank oder eine Person, die allein weiß, wie etwas funktioniert. SPOFs und kritische Abhängigkeiten (die vorgelagerten Services und Dritten, auf die sich Ihr Service still verlässt) zu kartieren ist das analytische Herz der Resilienz. In der modernen Gesundheits-IT sind Abhängigkeiten selten lokal: Ein Single-Sign-on-Dienst, eine Anbindung an die nationale Spine oder eine Cloud-Region kann viele Systeme zugleich lahmlegen.

Klinische Ausfallzeit und Business-Continuity-Verfahren. Gesundheit und Pflege haben eine besondere Kontrolle, die generische IT nicht kennt: das klinische Ausfallverfahren, ein geprobter, sicherer Rückfall – meist Papier – zur Erbringung von Versorgung, wenn ein digitales System nicht verfügbar ist, plus den Nacherfassungs-Prozess, der diese Papierakte nach Rückkehr des Systems wieder abgleicht. Das ist Business Continuity, am Krankenbett konkret gemacht, und der Ort, an dem Kontinuitätspläne am häufigsten auf die Realität treffen.

Ransomware und Cyber-Recovery. Ransomware verschlüsselt Ihre Daten und fordert Zahlung und ist zur prägenden Kontinuitätsbedrohung für Gesundheitssysteme geworden. Der WannaCry-Ransomware-Angriff von 2017 ist der Referenzfall: Deshalb ist Cyber-Recovery – isolieren, aus sauberen Backups neu aufbauen und die Integrität validieren, bevor man wieder verbindet – inzwischen ein erstklassiges Szenario in jedem ernsthaften Plan.

Der Kontinuitätsstandard. ISO 22301 ist der internationale Standard für Business-Continuity-Managementsysteme. Er liefert eine anerkannte Struktur – Kontext, Führung, Planung, Unterstützung, Betrieb, Bewertung, Verbesserung – zum Aufbau und zur Auditierung von Kontinuitätsfähigkeit und ist ein nützliches Rückgrat, ob Sie eine formale Zertifizierung anstreben oder nicht.

Bewährte Praktiken#

1. Beginnen Sie mit einer Business-Impact-Analyse, die Klinikpersonal verantwortet, nicht allein die IT. Ordnen Sie jeden Service nach dem klinischen Schaden, den sein Ausfall verursacht, und danach, wie schnell dieser Schaden untragbar wird, und weisen Sie jedem ein spezifisches RTO und RPO zu. Tun Sie das mit dem Klinikpersonal und den operativen Führungskräften, die die Folgen tragen, denn „wie lange können wir ohne dies sicher laufen?“ ist eine Versorgungsfrage, keine Infrastrukturfrage. Das Ergebnis ist eine priorisierte Liste, die Ihnen sagt, wohin Sie Ihr endliches Resilienzbudget zuerst lenken.

2. Gestalten Sie Resilienz verhältnismäßig zur Kritikalität. Stimmen Sie das Engineering auf die Auswirkung ab: Missionskritische Systeme (Notaufnahme, Patientenverwaltung, E-Verordnung) rechtfertigen Hochverfügbarkeit, geografische Redundanz und automatisches Failover; weniger kritische Systeme können längere Wiederherstellung und einfachere Backups akzeptieren. Widerstehen Sie sowohl dem Unterbauen kritischer Systeme als auch dem Vergolden trivialer. Architektur und Kontinuität müssen gemeinsam entworfen werden (siehe Thema 4.0 — Technische Architektur, Cloud und Altsysteme), denn Sie können Resilienz nicht nachträglich an ein brüchiges Design anflanschen.

3. Spüren Sie Single Points of Failure und verborgene Abhängigkeiten auf. Kartieren Sie systematisch die Abhängigkeiten jedes kritischen Services – Netzwerk, Authentifizierung, DNS, nationale Anbindungen, Strom, Kühlung, Schlüssellieferanten und Schlüsselpersonen – und identifizieren Sie, wo ein Ausfall kaskadiert. Achten Sie besonders auf gemeinsame Services wie Single Sign-on oder eine gemeinsame Integrations-Engine, deren Ausfall viele Systeme zugleich lahmlegt. Eine nicht kartierte Abhängigkeit ist eine, die Sie während des Ausfalls entdecken werden.

4. Sichern Sie so, dass Sie Ransomware überleben, und beweisen Sie Wiederherstellungen durch Testen. Folgen Sie der 3-2-1-Regel und halten Sie mindestens eine Backup-Kopie unveränderlich oder physisch offline, damit ein Angreifer, der Ihr Netzwerk erreicht, Ihre letzte Verteidigungslinie nicht verschlüsseln kann. Testen Sie dann Wiederherstellungen planmäßig, stoppen Sie sie gegen Ihr RTO und validieren Sie die Datenintegrität gegen Ihr RPO – eine Wiederherstellung, die zwei Tage gegen ein Vier-Stunden-Ziel dauert, ist eine gescheiterte Kontrolle, die Sie nur noch nicht bemerkt haben. Behandeln Sie „letzte erfolgreiche vollständige Wiederherstellung“ als Kennzahl, die Sie berichten, nicht als Aufgabe, die Sie annehmen.

5. Schreiben, finanzieren und proben Sie klinische Ausfallverfahren. Halten Sie für jedes kritische klinische System einen getesteten Papier- (oder Offline-)Rückfall vor, der dem Personal erlaubt, während eines Ausfalls weiter sichere Versorgung zu erbringen, plus einen klaren Prozess, diese Daten danach ohne Verlust oder Duplizierung neu zu erfassen. Lagern Sie Ausfallformulare dort, wo sie erreichbar sind, wenn auch Netzwerk und Drucker ausgefallen sind. Proben Sie sie mit dem Personal an der Front, denn ein Verfahren, das nur in einem Ordner lebt, wird um 3 Uhr morgens in einer Krise nicht gefunden, verstanden oder ihm vertraut.

6. Pflegen Sie einen Disaster-Recovery-Plan mit echtem Standort-Failover. Dokumentieren Sie für jedes kritische System genau, wie es sich erholt: was wo läuft, in welcher Reihenfolge, wer über den Aufruf entscheidet und wie Sie danach zurückschalten. Wo die Auswirkung es rechtfertigt, betreiben Sie einen wirklich getrennten Wiederherstellungsstandort oder eine Cloud-Region und beweisen Sie, dass Sie umschalten können – die Wiederherstellungsreihenfolge zählt, weil Systeme Abhängigkeiten haben, die die Sequenz diktieren. Ein ungetesteter DR-Standort ist eine teure Annahme.

7. Üben Sie den Plan; ein nie getesteter Plan ist ein Plan, der scheitert. Führen Sie regelmäßig Übungen über ein Spektrum durch: Tabletop-Durchgänge von Szenarien am Schreibtisch, technische Failover-Tests und gelegentliche vollständige Live-Simulationen einschließlich des klinischen Rückfalls. Übungen legen die Lücken offen – die veraltete Kontaktliste, der Wiederherstellungsschritt, der ein Passwort braucht, das niemand hat, die Annahme, dass Personal den Papierprozess kennt –, solange es sicher ist, sie zu finden. Erfassen Sie die Lehren, beheben Sie sie und testen Sie erneut; eine Übung ohne Nachverfolgung ist Theater.

8. Weiten Sie Kontinuität auf Ihre Lieferanten und die Cloud aus. Ihre Resilienz ist nur so stark wie die Dritten, von denen Ihre kritischen Services abhängen; machen Sie Kontinuität daher zu einer vertraglichen und Assurance-Angelegenheit: Verlangen Sie von Lieferanten, ihr eigenes RTO/RPO, ihre DR-Tests und Cyber-Recovery nachzuweisen, und verstehen Sie das Modell geteilter Verantwortung Ihres Cloud-Anbieters – Verfügbarkeitszonen und Regionen schützen vor manchen Ausfällen, aber nicht vor einer Fehlkonfiguration oder Kontokompromittierung, die Ihnen gehört. Planen Sie den Lieferantenausfall selbst ein, einschließlich des Szenarios, dass ein Schlüssellieferant von Ransomware getroffen wird (siehe Thema 6.3 — Beschaffung und Vertragsgestaltung).

9. Übernehmen Sie einen anerkannten Standard und stellen Sie Kontinuität unter Governance. Nutzen Sie ISO 22301 als strukturiertes Rückgrat und NHS- und nationale Leitlinien als Sektor-Überlagerung und geben Sie einer benannten Führungskraft die Verantwortung für Business Continuity mit Berichtspflicht an den Vorstand. Kontinuität, die niemand verantwortet, finanziert oder überprüft, verfällt still, bis der Vorfall sie offenlegt. Verdrahten Sie sie in Ihren Assurance-Rahmen (siehe Thema 6.4 — Governance und Assurance), damit Pläne routinemäßig gepflegt, getestet und verbessert werden, statt in einer Krise wiederentdeckt zu werden.

Fragen zur Diskussion im Team#

1. Welche RTO und RPO haben wir für jedes unserer kritischen klinischen Systeme tatsächlich mit Klinikpersonal vereinbart – und können wir sie derzeit erfüllen? Diese Frage bringt die Lücke zwischen Anspruch und Fähigkeit ans Licht. Viele Organisationen haben nie explizite Wiederherstellungsziele gesetzt oder sie in der IT ohne klinischen Input gesetzt, sodass die „akzeptable“ Ausfallzeit in Wahrheit nur das ist, was die aktuelle Architektur zufällig liefert. Debattieren Sie, wo klinischer Bedarf (Minuten für ein Notfallsystem) mit dem kollidiert, was Ihre Backups und DR tatsächlich erreichen (vielleicht einen Tag), denn diese Lücke ist ungesteuertes klinisches Risiko, das Sie tragen, ob Sie es benennen oder nicht. Schauen Sie konkret auf Ihre letzte reale oder getestete Wiederherstellung: Wie lange dauerte sie, wie viele Daten hätten Sie verloren und wer hat bestätigt, dass das sicher ist? Eine gute, ehrliche Antwort nennt konkrete Zahlen je System, räumt ein, wo Sie sie noch nicht erfüllen können, und macht aus jeder Lücke eine finanzierte Maßnahme statt bequemen Schweigens.

2. Wenn Ransomware heute Nacht unsere Kernsysteme und unsere Backups verschlüsselte, wie hielten wir morgen Patientinnen und Patienten sicher – und wie lange dauerte es bis zur vollständigen Wiederherstellung? Das ist das Szenario, das reale Gesundheitssysteme getroffen hat; es verdient daher einen konkreten, unerschrockenen Durchgang statt Beruhigung. Ergründen Sie beide Hälften ehrlich: die unmittelbare klinische Kontinuität (sind die Ausfallverfahren so geprobt, ausgestattet und vertrauenswürdig, dass man ein ganzes Krankenhaus tagelang auf Papier betreiben kann?) und die technische Wiederherstellung (sind Backups unveränderlich und offline, haben Sie den Neuaufbau aus sauberen Kopien getestet und kennen Sie die Wiederherstellungsreihenfolge?). Bringen Sie die unbequemen Abhängigkeiten ans Licht – wenn Single Sign-on, die Integrations-Engine oder ein Schlüssellieferant ausgefallen ist, wie viel anderes fällt mit? Überlegen Sie, wer den Major Incident erklärt, wer mit Personal, Patientinnen, Patienten und Medien spricht und wer entscheidet, dass ein System sicher wieder angeschlossen werden kann. Eine starke Antwort beschreibt einen geprobten Plan mit benannten Rollen und getesteten Wiederherstellungen; eine schwache nimmt an, die Backups seien in Ordnung und der Papierprozess werde einfach funktionieren.

3. Wann haben wir unsere Kontinuitäts- und Disaster-Recovery-Pläne zuletzt Ende-zu-Ende getestet, und was haben wir gelernt? Der Zweck hier ist, eine lebendige Fähigkeit von einem Regaldokument zu unterscheiden. Ein Plan, der nicht geübt wurde, ist ungetestet, und ungetestete Pläne scheitern routinemäßig beim Kontakt mit der Realität – die Kontaktliste ist veraltet, der Wiederherstellungsschritt braucht Zugangsdaten, die niemand hat, die Ausfallformulare liegen auf dem System, das ausgefallen ist. Besprechen Sie das Spektrum der Übungen, die Sie tatsächlich durchführen: Tabletop-Szenarien, technische Failover-Tests und vollständige Simulationen, die den klinischen Rückfall an der Front einschließen, nicht nur die Server-Wiederherstellung. Prüfen Sie, ob Lehren aus vergangenen Vorfällen und Übungen tatsächlich behoben und neu getestet oder protokolliert und vergessen wurden. Eine gute Antwort zeigt einen regelmäßigen Übungskalender, Belege für gefundene und geschlossene Lücken und Ehrlichkeit darüber, welche Teile des Plans unbewiesen bleiben.

4. Welche unserer kritischen Abhängigkeiten kontrollieren wir nicht – und was ist unser Plan für den Tag, an dem eine ausfällt? Moderne Gesundheits-IT fällt selten allein aus; sie fällt über die Services und Lieferanten darunter aus. Drängen Sie das Team über die Systeme hinaus, die Sie besitzen, zu denen, auf die Sie sich bloß verlassen: die Anbindung an die nationale Spine, den Single-Sign-on-Anbieter, die Cloud-Region, die Integrations-Engine, das ausgelagerte Rechenzentrum, den Managed-Service-Partner, der die Schlüssel zur Wiederherstellung hält. Fragen Sie für jede, was mit der Versorgung geschieht, wenn sie für einen Tag verschwindet, ob der Vertrag den Dritten auf ein Wiederherstellungsziel verpflichtet, das zu Ihrem klinischen Bedarf passt, und ob Sie je Belege für deren DR-Tests gesehen haben statt eines beruhigenden Absatzes in einem Angebot. Die unbequeme Wahrheit ist, dass Sie Restrisiko tragen können, das Sie nie bepreist haben, weil der Ausfall im Bestand eines anderen sitzt. Eine ehrliche Antwort benennt die spezifischen externen Abhängigkeiten jedes kritischen Services, sagt, welche vertraglich abgesichert und welche einfach vertraut sind, und identifiziert einen Rückfall – auch einen manuellen – für die Abhängigkeiten, die Sie nicht resilient machen können.

5. Wenn ein Major Incident eintritt, wer entscheidet was, wer kommuniziert mit wem, und kennt jede ihre Rolle schon vor dem Tag? Kontinuität hat ebenso mit Führung und Kommunikation zu tun wie mit Backups, und hier laufen geprobte Pläne und improvisiertes Chaos auseinander. Gehen Sie die menschliche Choreografie durch: Wer hat die Befugnis, einen Major Incident zu erklären und den Plan auszulösen, wer führt die operative Reaktion, wer entscheidet, dass ein System sicher wieder angeschlossen werden kann, und wer spricht mit Personal, Patientinnen, Patienten, Presse, Aufsichten und – bei einem Cyberangriff – Strafverfolgung? Bedenken Sie den Ausfall Ihrer eigenen Werkzeuge während des Vorfalls, denn der Ausfall kann das E-Mail-System, das Telefonverzeichnis oder das Intranet lahmlegen, das Sie normalerweise zur Koordination nutzen würden. Bringen Sie die Spannung zwischen schnell und sicher handeln ans Licht sowie die Reputationsrisiken einer falschen öffentlichen Botschaft. Eine starke Antwort verweist auf eine getestete Einsatzleitungsstruktur mit benannten, vertretenen Rollen, Kommunikationskanälen außerhalb des Bandes und vorab vereinbarten Botschaftsvorlagen; eine schwache nimmt an, die richtigen Menschen würden sich einfach versammeln und wissen, was zu tun ist.

6. Wie finanzieren, verantworten und halten wir Kontinuität am Leben, wenn zwei Jahre lang nichts schiefgegangen ist? Resilienz verfällt still in der Lücke zwischen Vorfällen, und diese Frage konfrontiert die organisatorische Disziplin, die sie vor dem Verrotten bewahrt. Kontinuität konkurriert um Geld und Aufmerksamkeit mit sichtbaren, dringenden klinischen und digitalen Prioritäten, und die unreife-und-glückliche Organisation sieht genau wie die reife aus – bis zu dem Tag, an dem nicht. Debattieren Sie, wer Kontinuität auf Führungsebene wirklich verantwortet, ob sie eine finanzierte Zeile statt geliehenen Goodwill hat und wie Pläne, Abhängigkeitskarten und Kontaktlisten aktuell gehalten werden, wenn sich Systeme und Personal ändern. Fragen Sie, was der Vorstand tatsächlich sieht – getestete Assurance und ehrliche Lücken oder eine grüne Bewertung und ein abgelegtes Dokument. Eine gute Antwort beschreibt benannte Verantwortlichkeit, ein wiederkehrendes Budget und einen Übungskalender sowie einen Governance-Rhythmus, der gepflegte, getestete Kontinuität als Routine behandelt statt als etwas, das in der nächsten Krise wiederentdeckt wird.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Die Meadowvale NHS Foundation Trust betreibt ein Akutkrankenhaus mit 600 Betten. An einem Dienstagmorgen finden Mitarbeitende ihre elektronische Patientenakte (EPR), Pathologie- und Radiologiesysteme durch eine Lösegeldforderung gesperrt; die Angreifer waren zehn Tage zuvor über das Fernzugriffskonto eines Lieferanten eingedrungen. Der Chief Information Officer erklärt binnen einer Stunde einen Major Incident, und der Business-Continuity-Plan des Trusts wird aktiviert.

Weil der Trust seine Business-Impact-Analyse durchgeführt hatte, wusste er, dass EPR und Pathologie seine Systeme höchster Kritikalität mit vereinbarten Wiederherstellungszielen waren, und seine Ausfallverfahren waren im vorangegangenen Herbst geprobt worden. Die Stationen wechseln auf Papier-Medikamentenkurven und vorgedruckte Beobachtungsformulare – bewusst in physischen Schränken auf jeder Station gelagert, nicht auf einem gemeinsamen Laufwerk –, und die Notaufnahme fällt auf ihren Papierpfad zurück. Elektive Operationen der Woche werden verschoben und den Patientinnen und Patienten mitgeteilt; Rettungswagen werden in den geschäftigsten Zeiten umgeleitet. Die Versorgung geht weiter, beeinträchtigt, aber sicher, weil das Personal geübt hatte, so zu arbeiten.

Die Wiederherstellung ist schwerer als die Restaurierung. Das Sicherheitsteam isoliert das Netzwerk, um die Ausbreitung zu stoppen, und baut dann kritische Systeme aus unveränderlichen, offline gehaltenen Backups neu auf – Kopien, die die Angreifer nicht erreichen konnten. Diese Backups waren vierteljährlich wiederherstellungsgetestet worden, sodass das Team wusste, dass der Prozess funktionierte und etwa wie lange er dauerte; die EPR ist innerhalb ihres RTO von acht Stunden zurück, während die Pathologie mit komplexeren Abhängigkeiten zwei Tage braucht. Das RPO von fünfzehn Minuten bedeutet, dass nur ein kurzes Datenfenster verloren ging, und das Personal gleicht die Papierakten in einem kontrollierten Nacherfassungsprozess wieder in das System ein und prüft Medikamente und Ergebnisse doppelt.

In der Nachbesprechung findet der Trust echte Lücken: Single Sign-on war ein Single Point of Failure, der den Zugang des Klinikpersonals während der Wiederherstellung verzögerte, und der Fernzugriff des Lieferanten war von der eigenen Kontinuitäts-Assurance des Trusts nicht abgedeckt. Beides kommt mit Verantwortlichen und Terminen auf das Risikoregister des Vorstands, und die nächste vollständige Übung wird terminiert. Es war eine schlechte Woche – aber keine Katastrophe, weil der Plan existierte, mit Ressourcen ausgestattet war und getestet worden war.

Sektorperspektiven#

Startup#

Ein Startup der digitalen Gesundheit hat selten ein Ersatzrechenzentrum; seine Kontinuitätsstrategie stützt sich daher fast ganz auf Cloud-native Resilienz und disziplinierte Backups. Nutzen Sie verwaltete Services mit eingebauter Hochverfügbarkeit über Verfügbarkeitszonen, automatisieren Sie Backups mit unveränderlichen Kopien außerhalb des Kontos, um sowohl Ransomware als auch ein kompromittiertes Cloud-Konto zu überstehen, und proben Sie tatsächlich eine Wiederherstellung in eine saubere Umgebung. Ihre Kunden – NHS Trusts und Integrated Care Systems – werden zunehmend Nachweise für RTO, RPO und DR-Tests über Rahmenwerke wie DTAC und Lieferantenabsicherung verlangen; behandeln Sie Kontinuität daher als Verkaufsargument, nicht als Overhead. Das existenzielle Risiko für einen kleinen Lieferanten ist, dass ein einzelner Vorfall oder die Gründerin, die allein die Bereitstellung versteht, zum Single Point of Failure wird.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim, ein ambulanter Pflegedienst oder eine Einzelstandort-Klinik – trägt dieselbe Pflicht, Patientinnen und Patienten durch einen Ausfall sicher zu halten wie ein großer Trust, aber mit echten Patientinnen und Patienten, knappem Geld und oft überhaupt keinem eigenen IT-Personal. Kontinuität ist hier bewusst pragmatisch: Wissen Sie, welche ein oder zwei Systeme (die Patientenakte, das Abgabe- oder eMAR-System) sichere Versorgung stoppen würden, wenn sie ausfielen, bestehen Sie darauf, dass Ihr Systemlieferant seine eigenen Backups, RTO und RPO belegt, und halten Sie ein einfaches, gedrucktes Ausfallpaket bereit – Papier-Medikamentenkurven, wichtige Telefonnummern, aktuelle Patientenlisten –, wo das Personal es erreichen kann, wenn die Bildschirme dunkel sind. Weil eine einzelne Praxismanagerin oder ein einzelner IT-Auftragnehmer oft die einzige Person ist, die den Aufbau versteht, schreiben Sie die Wiederherstellungsschritte auf und stellen Sie sicher, dass eine zweite Person ihnen folgen kann. Ransomware und eine defekte Breitbandleitung sind die alltäglichen Bedrohungen; eine Offline- oder unveränderliche Backup-Kopie und eine Rückfall-Arbeitsweise zählen daher mehr als jeder aufwendige DR-Standort, den Sie sich nicht leisten oder betreiben können.

Großunternehmen#

Ein großer NHS Trust, ein Integrated Care System oder ein großer Health-Tech-Anbieter trägt einen ausufernden, voneinander abhängigen Bestand, in dem das schwerste Problem das Kartieren von Abhängigkeiten und gemeinsamen Services ist, nicht ein einzelnes System. Investieren Sie in ein formales BCM-Programm nach ISO 22301, eine gepflegte Abhängigkeitskarte, DR-Standorte oder -Regionen für kritische Systeme und einen rollierenden Kalender von Übungen, der den klinischen Rückfall einschließt. Die Größe bedeutet, dass SPOFs oft gemeinsame Services sind – Identität, Integrations-Engines, Netzwerkkerne –, deren Ausfall über Dutzende Systeme kaskadiert. Governance ist die bindende Beschränkung: Bei vielen Teams und Lieferanten hält Kontinuität nur, wenn eine benannte Führungskraft sie verantwortet und der Vorstand getestete Assurance statt Papierpläne prüft.

Regierung#

Eine nationale Stelle – NHS England, ein dezentrales Gesundheitsministerium oder UKHSA – muss Resilienz im Bevölkerungs- und Systemmaßstab denken, wo der Ausfall eines nationalen Services oder eines weit verbreiteten Lieferanten selbst ein Kontinuitätsereignis für den ganzen Sektor ist. Setzen Sie Standards und Erwartungen (Wiederherstellungsziele, Cyber-Recovery, verpflichtende Übungen), finanzieren Sie gemeinsame Schutzfähigkeiten und koordinieren Sie die sektorweite Reaktion auf Major Incidents wie eine nationale Ransomware-Kampagne. Die Reaktion auf WannaCry prägte die nationale Politik gerade deshalb neu, weil die Auswirkung Hunderte Organisationen zugleich überquerte und gemeinsame Schwächen offenlegte. Die Rechenschaft ist hier öffentlich und parlamentarisch; Transparenz über bekannte Risiken und ehrliche Berichterstattung zur Bereitschaft zählen daher ebenso wie die technischen Kontrollen selbst.

Häufige Fehlermuster#

• Backups, die nie wiederhergestellt wurden. „Wir sichern nächtlich“ mit „wir können wiederherstellen“ verwechseln. Ungetestete Wiederherstellungen scheitern routinemäßig oder sprengen das RTO; erfolgreiche Ende-zu-Ende-Wiederherstellungen messen und berichten, nicht den Abschluss des Backups.
• Für Ransomware erreichbare Backups. Jedes Backup online und netzwerkverbunden halten, sodass ein Angreifer sie zusammen mit der Produktion verschlüsselt. Mindestens eine unveränderliche oder Offline-Kopie halten.
• DR, die Server schützt, nicht Services. Eine Datenbank wiederherstellen, aber nicht die Abhängigkeiten, Integrationen und den Zugang, die sie zu einem nutzbaren klinischen Service machen. Ganze Services in Abhängigkeitsreihenfolge wiederherstellen und testen.
• Ausfallverfahren, die nur auf Papier über Papier existieren. Rückfallpläne, die nie geprobt werden, auf dem ausgefallenen System liegen oder dem Personal an der Front unbekannt sind. Sie dort proben, wo Versorgung tatsächlich stattfindet.
• Nicht kartierte Abhängigkeiten und gemeinsame SPOFs. Während des Ausfalls entdecken, dass Single Sign-on, DNS oder ein Lieferant alles trug. Abhängigkeiten vor, nicht während des Vorfalls kartieren.
• Ein für den Prüfer geschriebener Plan, nie geübt. Kontinuität als Compliance-Dokument, das ungetestet verfällt, bis es gebraucht wird. Ein nie getesteter Plan ist ein Plan, der scheitert.
• Lieferanten- und Cloud-Kontinuität ignorieren. Annehmen, Ihre Dritten seien resilient, ohne Belege, und das Modell geteilter Verantwortung vergessen. Kontinuität vertraglich und abgesichert machen.

Reifegradmodell#

Checkliste#

• Eine mit Klinikpersonal verantwortete Business-Impact-Analyse ordnet jeden Service und setzt für jedes kritische System ein explizites RTO und RPO.
• Kritische Systeme haben Hochverfügbarkeit und Redundanz verhältnismäßig zu ihrer klinischen Kritikalität.
• Single Points of Failure und kritische Abhängigkeiten (einschließlich gemeinsamer Services und Lieferanten) sind kartiert und gemildert.
• Backups folgen der 3-2-1-Regel mit mindestens einer unveränderlichen oder Offline-Kopie, die Ransomware nicht erreichen kann.
• Wiederherstellungen werden planmäßig getestet und gegen RTO/RPO gemessen, mit „letzter erfolgreicher Wiederherstellung“ als berichteter Kennzahl.
• Jedes kritische klinische System hat ein geprobtes Ausfallverfahren und einen kontrollierten Prozess zur Nacherfassung der Daten.
• Ein Disaster-Recovery-Plan definiert Wiederherstellungsschritte, Reihenfolge, Entscheidungsbefugnis und Failback, und der DR-Standort/die -Region wird getestet.
• Ein Cyber-Recovery-Szenario (isolieren, aus sauberen Backups neu aufbauen, validieren, wieder verbinden) ist dokumentiert und geübt.
• Lieferanten- und Cloud-Kontinuität sind vertraglich verlangt, belegt und abgesichert, einschließlich des Modells geteilter Verantwortung.
• Kontinuität ist an ISO 22301 ausgerichtet, von einer benannten Führungskraft verantwortet, nach Kalender geübt und an den Vorstand berichtet.

Zentrale Quellen#

• NHS England — Business Continuity Management Toolkit und EPRR-Rahmen (Emergency Preparedness, Resilience and Response) und Core Standards.
• National Cyber Security Centre (NCSC) — Leitlinien zu Offline-/unveränderlichen Backups, Ransomware-Abwehr und Vorfallreaktion.
• ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements (International Organization for Standardization).
• ISO/IEC 27031 — Guidelines for information and communication technology readiness for business continuity.
• Business Continuity Institute (BCI) — Good Practice Guidelines.
• National Audit Office — Investigation: WannaCry cyber attack and the NHS (2017) und Lessons-Learned-Überprüfung des Department of Health.
• NHS England / Data Security and Protection Toolkit (DSPT) — Datensicherheitsstandards einschließlich Business Continuity und Vorfallreaktion.
• GOV.UK Service Manual — Leitlinien zu Resilienz, Überwachung und Wiederherstellung für Live-Services.

Referenzen#

1. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
2. IT disaster recovery — Wikipedia — https://en.wikipedia.org/wiki/IT_disaster_recovery
3. ISO 22301 — Wikipedia — https://en.wikipedia.org/wiki/ISO_22301
4. Backup — Wikipedia — https://en.wikipedia.org/wiki/Backup
5. High availability — Wikipedia — https://en.wikipedia.org/wiki/High_availability
6. Redundancy (engineering) — Wikipedia — https://en.wikipedia.org/wiki/Redundancy_(engineering)
7. Failover — Wikipedia — https://en.wikipedia.org/wiki/Failover
8. Single point of failure — Wikipedia — https://en.wikipedia.org/wiki/Single_point_of_failure
9. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
10. WannaCry ransomware attack — Wikipedia — https://en.wikipedia.org/wiki/WannaCry_ransomware_attack
11. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements — International Organization for Standardization — https://www.iso.org/standard/75106.html
12. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
13. Emergency Preparedness, Resilience and Response (EPRR) — NHS England — https://www.england.nhs.uk/ourwork/eprr/
14. Offline backups in an online world — National Cyber Security Centre — https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/