Ein Wiederanlaufplan für IT-Systeme entscheidet im Ernstfall darüber, ob ein Serverausfall, ein Ransomware-Vorfall oder ein Wasserschaden im Rechenzentrum ein beherrschbares Ereignis bleibt oder zum mehrtägigen Produktionsstillstand führt. Während viele mittelständische Unternehmen inzwischen über Firewalls, Virenschutz und Backups verfügen, fehlt häufig ein dokumentierter, getesteter Plan, der beschreibt, in welcher Reihenfolge welche Systeme mit welchen Ressourcen und in welcher Zeit wiederhergestellt werden. Genau das ist die Aufgabe des Disaster-Recovery-Plans, kurz DR-Plan oder Wiederanlaufplan. Er unterscheidet sich bewusst von der Krisenkommunikation, die regelt, wer im Ernstfall informiert wird, und vom Business Continuity Management insgesamt, das auch nicht-technische Prozesse betrachtet. Der Wiederanlaufplan konzentriert sich ausschließlich auf die technische Wiederherstellung von IT-Systemen und Daten nach einem Ausfall. Dieser Beitrag zeigt, wie mittelständische Unternehmen kritische Systeme priorisieren, welche Wiederherstellungsstrategien es gibt, wie ein Wiederanlaufplan strukturiert aufgebaut wird und warum regelmäßige Tests über Erfolg oder Scheitern im Ernstfall entscheiden. Wer sich erst während eines laufenden Vorfalls mit diesen Fragen beschäftigt, verliert wertvolle Zeit und trifft Entscheidungen unter Druck, die sich mit einer vorbereiteten Dokumentation deutlich sicherer und schneller treffen lassen.
Titelbild: Foto von Winston Chen auf Unsplash.
Abgrenzung: Wiederanlaufplan, Notfallhandbuch und Business Continuity
In der Praxis werden die Begriffe Notfallplan, Wiederanlaufplan und Business-Continuity-Plan häufig synonym verwendet, obwohl sie unterschiedliche Ebenen beschreiben. Das Notfallhandbuch bildet den organisatorischen Rahmen mit Meldewegen, Verantwortlichkeiten und Eskalationsstufen. Der Wiederanlaufplan (Disaster Recovery Plan) ist die technische Ausarbeitung darin und beschreibt konkret, wie Server, Datenbanken, Netzwerkkomponenten und Anwendungen nach einem Ausfall wiederhergestellt werden. Business Continuity Management (BCM) wiederum betrachtet die gesamte Betriebsfortführung, also auch Ersatzarbeitsplätze, Lieferantenausfälle oder Personalengpässe, für die die internationale Norm ISO 22301 einen anerkannten Rahmen liefert. Ein Wiederanlaufplan ist damit ein Teilbaustein eines umfassenderen Notfallmanagements, aber ein Baustein, der in vielen Betrieben zuerst fehlt, weil er technisches Detailwissen und eine ehrliche Bestandsaufnahme der eigenen IT-Landschaft voraussetzt. Ohne diese Bestandsaufnahme bleibt jede Aussage zur Wiederherstellungsfähigkeit reine Theorie, die im Ernstfall selten mit der tatsächlichen Situation übereinstimmt.
Kritische Systeme identifizieren und priorisieren
Der erste und wichtigste Schritt bei der Erstellung eines Wiederanlaufplans ist die Business Impact Analyse (BIA). Sie beantwortet die Frage, welche IT-Systeme für die Fortführung des Geschäftsbetriebs unverzichtbar sind und wie schnell sie nach einem Ausfall wieder verfügbar sein müssen. Zwei Kennzahlen stehen dabei im Mittelpunkt: die Recovery Time Objective (RTO), also die maximal tolerierbare Ausfallzeit, und die Recovery Point Objective (RPO), also der maximal tolerierbare Datenverlust gemessen in Zeit seit der letzten Sicherung. Nicht jedes System benötigt die gleiche Wiederherstellungsgeschwindigkeit, weshalb sich eine Klassifizierung in Prioritätsstufen bewährt hat, wie sie die folgende Tabelle beispielhaft zeigt.
| Prioritätsklasse | Beispielsysteme | Ziel-RTO | Ziel-RPO |
|---|---|---|---|
| Kritisch (Klasse A) | ERP-System, Auftragsabwicklung, Zahlungsverkehr | unter 4 Stunden | unter 1 Stunde |
| Wichtig (Klasse B) | E-Mail-Server, Dateiablage, CRM | 4 bis 24 Stunden | bis 4 Stunden |
| Nachrangig (Klasse C) | interne Wikis, Testsysteme, Archivsysteme | bis 72 Stunden | bis 24 Stunden |
Diese Klassifizierung sollte nicht allein von der IT-Abteilung, sondern gemeinsam mit den Fachabteilungen vorgenommen werden, weil erst die Fachbereiche beurteilen können, welche Ausfallzeit betriebswirtschaftlich noch tragbar ist und welche Auswirkungen ein Ausfall auf Kundenverpflichtungen und vertragliche Fristen hat.
Wiederherstellungsstrategien je Systemklasse
Aus der Priorisierung leitet sich ab, welche technische Wiederherstellungsstrategie für welches System wirtschaftlich sinnvoll ist. Je kürzer die geforderte RTO, desto höher in der Regel die Kosten für die Bereithaltung redundanter Infrastruktur.
Cold Standby
Bei Cold Standby existiert keine laufende Ersatzumgebung. Im Ernstfall müssen Hardware oder virtuelle Instanzen erst bereitgestellt, das Betriebssystem installiert und die Daten aus dem Backup zurückgespielt werden. Diese Strategie ist kostengünstig, eignet sich aber nur für Systeme der Klasse C, bei denen eine Wiederherstellungszeit von mehreren Tagen akzeptabel ist.
Warm Standby
Beim Warm Standby steht eine vorkonfigurierte Ersatzumgebung bereit, die im Regelbetrieb nicht aktiv genutzt wird, aber regelmäßig mit aktuellen Daten synchronisiert wird. Die Wiederherstellungszeit reduziert sich auf wenige Stunden, weil lediglich die Umschaltung und ein letzter Datenabgleich erfolgen müssen. Für viele Systeme der Klasse B ist dies ein wirtschaftlich sinnvoller Kompromiss zwischen Kosten und Wiederherstellungsgeschwindigkeit.
Hot Standby und georedundante Systeme
Bei Hot Standby läuft eine vollständig synchronisierte Zweitumgebung parallel mit, sodass im Ausfall nahezu unterbrechungsfrei umgeschaltet werden kann. Diese Strategie verursacht die höchsten laufenden Kosten und wird daher meist auf Systeme der Klasse A begrenzt, etwa auf ein ERP-System oder den Zahlungsverkehr, bei denen bereits wenige Stunden Ausfall unmittelbare wirtschaftliche Schäden verursachen. Viele mittelständische Unternehmen nutzen für Hot- und Warm-Standby-Szenarien inzwischen Cloud-Infrastrukturen, weil sich damit redundante Kapazität ohne eigene Zweitrechenzentren wirtschaftlich abbilden lässt.
Pflichtbestandteile eines strukturierten Wiederanlaufplans
Ein Wiederanlaufplan, der im Ernstfall tatsächlich verwendbar ist, muss so geschrieben sein, dass ihn auch eine Person umsetzen kann, die das betroffene System nicht täglich betreut, weil verantwortliche Mitarbeiter im Ernstfall selbst nicht erreichbar sein können.
- Eine vollständige Übersicht aller IT-Systeme mit Priorität, RTO, RPO und technischer Abhängigkeit zu anderen Systemen.
- Konkrete, schrittweise Wiederherstellungsanweisungen je System, einschließlich Zugriff auf Installationsmedien, Lizenzschlüssel und Konfigurationsdateien.
- Kontaktdaten interner Verantwortlicher und externer Dienstleister, einschließlich Vertretungsregelungen für den Fall der Nichterreichbarkeit.
- Eine dokumentierte Reihenfolge der Wiederherstellung, die technische Abhängigkeiten berücksichtigt, etwa dass ein Datenbankserver vor der Anwendung, die auf ihn zugreift, verfügbar sein muss.
- Angaben zum Speicherort der Backups, zur Verschlüsselung und zu den Zugriffsberechtigungen, die im Ernstfall benötigt werden.
- Ein Protokoll für die Dokumentation des tatsächlichen Wiederanlaufs, das später für die Nachbereitung und für Versicherungs- oder Aufsichtsanfragen genutzt werden kann.
Datensicherung als Fundament: die 3-2-1-Regel
Der beste Wiederanlaufplan ist wirkungslos, wenn die zugrunde liegende Datensicherung lückenhaft ist. Als bewährter Mindeststandard gilt die 3-2-1-Regel: mindestens drei Kopien der Daten, auf mindestens zwei unterschiedlichen Speichermedien, davon mindestens eine Kopie räumlich getrennt vom Produktivsystem. Bei Ransomware-Angriffen hat sich zusätzlich eine vierte Komponente etabliert, die häufig als 3-2-1-1-Regel bezeichnet wird: mindestens eine Kopie muss unveränderlich (immutable) oder physisch vom Netzwerk getrennt (Air Gap) vorliegen, damit Verschlüsselungstrojaner nicht auch die Sicherungskopien kompromittieren können. Gerade dieser letzte Punkt wird in der Praxis häufig vernachlässigt, weil vernetzte Backup-Systeme zwar komfortabel, im Falle eines Netzwerkangriffs aber selbst gefährdet sind.
Ebenso wichtig wie die Sicherung selbst ist die regelmäßige Testwiederherstellung. Eine Datensicherung, deren Rückspielbarkeit nie getestet wurde, ist im rechtlichen und betriebswirtschaftlichen Sinne keine verlässliche Absicherung, sondern lediglich eine unbestätigte Annahme.
In der Praxis empfiehlt sich ein gestaffeltes Testkonzept: eine monatliche Stichprobenprüfung einzelner Dateien oder Datenbanktabellen, eine quartalsweise Wiederherstellung eines kompletten Systems in einer isolierten Testumgebung und mindestens eine jährliche Vollübung, bei der ein realistisches Ausfallszenario mit allen beteiligten Personen durchgespielt wird. Gerade die isolierte Testumgebung ist wichtig, damit ein fehlerhafter Wiederherstellungsversuch nicht versehentlich das Produktivsystem beeinträchtigt. Unternehmen, die diesen gestaffelten Ansatz verfolgen, stellen erfahrungsgemäß deutlich häufiger fest, dass einzelne Sicherungsjobs fehlgeschlagen sind oder Berechtigungen nicht mehr korrekt gesetzt sind, bevor ein realer Vorfall diese Lücken schmerzhaft offenlegt.
Warum Wiederanlaufpläne im Ernstfall häufig scheitern
Die Erfahrung aus realen IT-Sicherheitsvorfällen zeigt wiederkehrende Schwachstellen, die sich mit überschaubarem Aufwand vermeiden lassen. Pläne existieren häufig nur als Dokument auf demselben Server, der im Ernstfall ausfällt, sodass sie im entscheidenden Moment nicht zugänglich sind. Kontaktdaten und Zugangsdaten sind veraltet, weil der Plan seit der letzten größeren Systemumstellung nicht mehr aktualisiert wurde. Und Verantwortlichkeiten sind unklar, weil nie definiert wurde, wer im Ernstfall die Entscheidung zur Aktivierung des Wiederanlaufplans überhaupt treffen darf.
„Unser Wiederanlaufplan war technisch tadellos, aber er lag als PDF ausschließlich auf dem Fileserver, der genau der Server war, der beim Vorfall verschlüsselt wurde. Seitdem drucken wir eine aktuelle Fassung aus und hinterlegen eine digitale Kopie zusätzlich außerhalb unseres Netzwerks.“ Erfahrungsbericht eines IT-Leiters aus einem mittelständischen Produktionsunternehmen nach einem Ransomware-Vorfall.
Schritt-für-Schritt zum eigenen Wiederanlaufplan
- Vollständige Inventarisierung aller IT-Systeme, Anwendungen und ihrer technischen Abhängigkeiten untereinander erstellen.
- Business Impact Analyse gemeinsam mit den Fachabteilungen durchführen und Systeme in Prioritätsklassen mit RTO- und RPO-Zielen einordnen.
- Für jede Prioritätsklasse eine wirtschaftlich passende Wiederherstellungsstrategie festlegen, von Cold bis Hot Standby.
- Konkrete, schrittweise Wiederherstellungsanweisungen je System dokumentieren, verständlich auch für Vertretungspersonal.
- Den Plan an mindestens zwei getrennten Orten hinterlegen, davon einen Ort unabhängig vom eigenen Firmennetzwerk erreichbar.
- Eine Testwiederherstellung mit realistischem Szenario durchführen und die tatsächlich gemessene Wiederherstellungszeit mit der Zielvorgabe abgleichen.
- Den Plan mindestens jährlich sowie nach jeder wesentlichen Systemänderung überprüfen und aktualisieren.
Kosten eines IT-Ausfalls realistisch einschätzen
Viele Unternehmen unterschätzen die tatsächlichen Kosten eines längeren IT-Ausfalls, weil sie nur den direkten Umsatzausfall betrachten, nicht aber Folgekosten wie Vertragsstrafen bei verspäteter Lieferung, zusätzliche Personalkosten für manuelle Notfallprozesse, Reputationsschäden bei Kunden und im Falle eines meldepflichtigen Sicherheitsvorfalls den administrativen Aufwand für die Dokumentation gegenüber Aufsichtsbehörden und Versicherern. Als grobe Beispielrechnung: Ein mittelständisches Unternehmen mit einem Tagesumsatz von 50.000 Euro, das durch einen IT-Ausfall drei Tage lang nicht liefern kann, verliert nicht automatisch 150.000 Euro Umsatz, weil Aufträge häufig nachgeholt werden können, trägt aber in dieser Zeit weiterhin die vollen Fixkosten für Personal und Infrastruktur, ohne dass diesen Kosten Erlöse gegenüberstehen. Diese Fixkostenbetrachtung ist häufig der überzeugendste Ansatzpunkt, wenn intern Budget für redundante Systeme oder eine höhere Backup-Frequenz begründet werden muss, weil sie unabhängig von Marktschwankungen kalkulierbar ist.
Cloud-basierte Wiederherstellung als Alternative zum eigenen Zweitrechenzentrum
Für kleinere und mittlere Unternehmen war ein eigenes Zweitrechenzentrum lange Zeit wirtschaftlich kaum darstellbar, weil sowohl Hardware als auch Betrieb parallel vorgehalten werden mussten, ohne im Regelbetrieb genutzt zu werden. Cloud-basierte Disaster-Recovery-Lösungen (Disaster Recovery as a Service, DRaaS) verändern diese Rechnung, weil Rechenkapazität im Ernstfall nur dann kostenpflichtig hochgefahren wird, wenn sie tatsächlich benötigt wird, während im Normalbetrieb lediglich die kontinuierliche Datenreplikation Kosten verursacht. Für Systeme der Prioritätsklasse A kann so ein Warm- oder sogar Hot-Standby-Niveau erreicht werden, ohne dass eigenes Rechenzentrumspersonal für eine Zweitumgebung vorgehalten werden muss. Wichtig ist dabei, vertraglich klare Wiederherstellungszeiten mit dem Cloud-Anbieter zu vereinbaren und regelmäßig zu überprüfen, da eine reine Verfügbarkeitszusage in der Cloud nicht automatisch mit der im eigenen Wiederanlaufplan geforderten RTO übereinstimmt. Bei der Auswahl eines Anbieters sollte zudem geprüft werden, wo die Daten gespeichert werden und ob dies mit den eigenen Anforderungen an Datenschutz und Datenhoheit vereinbar ist.
Verantwortlichkeiten und Rollen im Wiederanlaufteam
Ein technisch vollständiger Wiederanlaufplan bleibt wirkungslos, wenn im Ernstfall unklar ist, wer welche Entscheidung treffen darf. Bewährt hat sich eine klare Rollenverteilung mit einem Wiederanlaufverantwortlichen, der die Aktivierung des Plans formal auslöst und den Gesamtüberblick behält, sowie technischen Systemverantwortlichen, die für einzelne Systeme oder Systemgruppen die konkrete Wiederherstellung durchführen. Ergänzend sollte für jede Rolle mindestens eine Vertretung benannt sein, da IT-Sicherheitsvorfälle nicht selten außerhalb der Kernarbeitszeit auftreten und die Erreichbarkeit einzelner Personen nicht garantiert werden kann. Auch die Schnittstelle zu externen Dienstleistern, etwa einem IT-Systemhaus oder einem Cloud-Anbieter, gehört in diese Rollenübersicht, einschließlich der vertraglich vereinbarten Reaktionszeiten. Unternehmen, die diese Rollen nicht im Vorfeld dokumentieren, verlieren im Ernstfall wertvolle Zeit allein durch Abstimmungsbedarf darüber, wer überhaupt handlungsbefugt ist.
Regelmäßige Tests und Aktualisierung als Daueraufgabe
Ein Wiederanlaufplan ist kein einmalig erstelltes Dokument, sondern ein lebendes Arbeitsmittel, das mit der IT-Landschaft mitwächst. Bewährt hat sich ein jährlicher Testzyklus mit unterschiedlichen Szenarien, etwa im Wechsel ein vollständiger Ausfall des Rechenzentrums, ein isolierter Datenbankausfall und ein Ransomware-Szenario mit kompromittierten Zugangsdaten. Solche Übungen decken zuverlässiger als reine Papierprüfungen auf, ob Kontaktketten funktionieren, ob Zugangsdaten aktuell sind und ob die tatsächlich gemessene Wiederherstellungszeit der Zielvorgabe entspricht. Der Aufwand für einen jährlichen Testlauf ist überschaubar, verglichen mit den Kosten eines mehrtägigen, unkontrollierten Produktionsausfalls. Orientierung für ein systematisches Notfallmanagement bietet der BSI-Standard 200-4 des Bundesamts für Sicherheit in der Informationstechnik, der speziell auf die Anforderungen von Organisationen jeder Größenordnung zugeschnitten ist.
FAQ
Was ist der Unterschied zwischen Wiederanlaufplan und Notfallhandbuch?
Das Notfallhandbuch regelt Meldewege, Verantwortlichkeiten und Kommunikation im Ernstfall, während der Wiederanlaufplan die konkrete technische Wiederherstellung der IT-Systeme beschreibt.
Was bedeuten RTO und RPO?
RTO (Recovery Time Objective) ist die maximal tolerierbare Ausfallzeit eines Systems, RPO (Recovery Point Objective) der maximal tolerierbare Datenverlust seit der letzten Sicherung.
Reicht ein einfaches tägliches Backup als Wiederanlaufplan aus?
Nein. Ein Backup ist die Voraussetzung für die Wiederherstellung, ersetzt aber nicht die dokumentierte, priorisierte Vorgehensweise, mit der Systeme in der richtigen Reihenfolge tatsächlich wieder in Betrieb genommen werden.
Wie oft sollte ein Wiederanlaufplan getestet werden?
Mindestens einmal jährlich mit einer realistischen Testwiederherstellung sowie zusätzlich nach jeder wesentlichen Änderung an der IT-Infrastruktur.
Was ist die 3-2-1-1-Regel bei der Datensicherung?
Sie ergänzt die klassische 3-2-1-Regel um eine unveränderliche oder physisch vom Netzwerk getrennte Sicherungskopie, um Backups auch bei Ransomware-Angriffen zu schützen.
Wer sollte einen Wiederanlaufplan im Unternehmen erstellen?
Die technische Ausarbeitung liegt bei der IT, die Priorisierung der Systeme sollte jedoch gemeinsam mit den Fachabteilungen erfolgen, da nur sie die betriebswirtschaftliche Kritikalität einzelner Systeme beurteilen können.
