Wiederanlaufplan erstellen: Anleitung mit Vorlage für den Mittelstand

Warum du einen Wiederanlaufplan brauchst

Freitagmittag, kurz vor dem Wochenende. Die zentrale Datenbank deines ERP-Systems gibt den Geist auf. Die Auftragsabwicklung steht still, die Produktion bekommt keine Freigaben mehr, der Versand weiß nicht, was wohin soll. Dein IT-Team beginnt hektisch, das System wiederherzustellen. Aber in welcher Reihenfolge? Was hat Priorität - die Datenbank, der Mailserver oder das VPN für die Außendienstler? Wer entscheidet das? Und ab wann muss die Geschäftsführung informiert werden?

Genau diese Fragen beantwortet ein Wiederanlaufplan. Er ist das operative Dokument, das beschreibt, wie du nach einem Ausfall den Geschäftsbetrieb systematisch wieder hochfährst. Nicht irgendwie und nicht nach Bauchgefühl, sondern in einer definierten Reihenfolge mit klaren Zuständigkeiten, Zeitvorgaben und Erfolgskriterien.

Für mittelständische Unternehmen hat das Thema in den letzten Jahren an Dringlichkeit gewonnen. NIS2 fordert explizit Business Continuity Management, ISO 27001 verlangt Pläne für die Wiederherstellung nach Sicherheitsvorfällen, und jeder Ransomware-Angriff zeigt, was passiert, wenn diese Pläne fehlen. Die Realität sieht allerdings oft anders aus: Viele Unternehmen haben Backup-Konzepte, aber keinen strukturierten Plan für den Wiederanlauf. Sie können Daten zurückspielen, wissen aber nicht, in welcher Reihenfolge Systeme hochgefahren werden müssen, welche Abhängigkeiten bestehen und wer in welcher Phase was tut.

Was genau ist ein Wiederanlaufplan?

Ein Wiederanlaufplan (englisch: Recovery Plan oder Disaster Recovery Plan) ist ein dokumentierter Prozess, der beschreibt, wie der Geschäftsbetrieb nach einer Störung oder einem Ausfall wiederhergestellt wird. Er gehört zum übergeordneten Business Continuity Management (BCM) und ist eng mit der Business Impact Analyse und den Notfallplänen verzahnt.

Der Wiederanlaufplan unterscheidet sich von anderen BCM-Dokumenten durch seinen operativen Charakter. Während die BIA analysiert, welche Prozesse wie kritisch sind, und der Notfallplan die Erstreaktion regelt, geht der Wiederanlaufplan einen Schritt weiter: Er definiert die konkreten technischen und organisatorischen Schritte, um vom Notbetrieb zurück zum Normalbetrieb zu kommen.

Abgrenzung zu verwandten Dokumenten

Der Wiederanlaufplan setzt also dort an, wo der Notfallplan aufhört. Die Erstreaktion ist abgeschlossen, die unmittelbare Gefahr ist eingedämmt, und jetzt geht es darum, den Betrieb wieder ans Laufen zu bringen.

Der Zusammenhang: BIA, Notfallplan und Wiederanlaufplan

Diese drei Dokumente bilden eine logische Kette, und die Reihenfolge ist entscheidend. Du kannst keinen sinnvollen Wiederanlaufplan erstellen, ohne vorher eine BIA durchgeführt zu haben, denn die BIA liefert die Grundlage für alle Priorisierungsentscheidungen im Wiederanlauf.

Die BIA liefert:

• Welche Geschäftsprozesse sind kritisch?
• Welche IT-Systeme und Assets unterstützen diese Prozesse?
• Wie lange darf ein Prozess maximal ausfallen (RTO)?
• Wie viel Datenverlust ist tolerierbar (RPO)?
• Welche Abhängigkeiten bestehen zwischen Systemen?

Der Notfallplan regelt:

• Wer wird wann informiert?
• Welche Sofortmaßnahmen werden eingeleitet?
• Wie wird der Notbetrieb sichergestellt?
• Wann wird der Wiederanlaufplan aktiviert?

Der Wiederanlaufplan definiert:

• In welcher Reihenfolge werden Systeme wiederhergestellt?
• Wer ist für welchen Wiederherstellungsschritt verantwortlich?
• Welche Ressourcen werden benötigt?
• Was sind die Erfolgskriterien für jeden Schritt?
• Wann gilt der Normalbetrieb als wiederhergestellt?

Wenn du die BIA überspringst, basiert dein Wiederanlaufplan auf Annahmen statt auf Fakten. Vielleicht priorisierst du die Wiederherstellung des Mailservers, während die Produktionssteuerung eigentlich geschäftskritischer ist. Eine saubere Schutzbedarfsfeststellung hilft zusätzlich, die Kritikalität der einzelnen Assets einzuordnen. Oder du planst eine Wiederherstellungszeit von 48 Stunden für das ERP-System, obwohl die Geschäftsleitung erwartet, dass es nach 8 Stunden wieder läuft.

RTO und RPO verstehen

Zwei Kennzahlen sind für jeden Wiederanlaufplan absolut zentral: Recovery Time Objective (RTO) und Recovery Point Objective (RPO). Beide kommen aus der BIA, werden aber im Wiederanlaufplan operativ umgesetzt.

Recovery Time Objective (RTO)

Das RTO gibt an, wie lange ein System, eine Anwendung oder ein Geschäftsprozess maximal ausfallen darf, bevor der Schaden für das Unternehmen inakzeptabel wird. Es ist also die maximale tolerierbare Ausfallzeit.

Ein Beispiel: Dein ERP-System hat ein RTO von 4 Stunden. Das bedeutet, dass die Wiederherstellung des ERP-Systems innerhalb von 4 Stunden nach Eintritt des Ausfalls abgeschlossen sein muss. Alles, was darüber hinausgeht, verursacht Schäden, die das Unternehmen als nicht mehr akzeptabel bewertet hat - sei es durch Umsatzverluste, Vertragsstrafen oder Reputationsschäden.

Recovery Point Objective (RPO)

Das RPO beschreibt den maximal tolerierbaren Datenverlust, gemessen in Zeit. Es beantwortet die Frage: Auf welchen Datenstand kann ich maximal zurückfallen, ohne dass der Schaden inakzeptabel wird?

Ein Beispiel: Dein Buchhaltungssystem hat ein RPO von 1 Stunde. Das bedeutet, du darfst maximal die Daten der letzten Stunde verlieren. Wenn dein letztes Backup 4 Stunden alt ist, erfüllst du das RPO nicht. Die Backup-Frequenz muss also zum RPO passen.

Weitere wichtige Kennzahlen

Wichtig: RTO + WRT darf die MTD nicht überschreiten. Wenn du 4 Stunden für den Restore brauchst und 2 Stunden für die Validierung, liegt dein tatsächlicher Wiederanlauf bei 6 Stunden. Wenn die MTD bei 8 Stunden liegt, hast du noch Puffer. Liegt sie bei 4 Stunden, hast du ein Problem.

Aufbau eines Wiederanlaufplans

Ein guter Wiederanlaufplan folgt einer klaren Struktur. Er muss so geschrieben sein, dass auch jemand, der nicht täglich mit dem Thema arbeitet, die Schritte nachvollziehen und ausführen kann. Denn im Ernstfall ist der verantwortliche IT-Leiter vielleicht gerade im Urlaub, und sein Vertreter muss den Plan umsetzen können.

1. Deckblatt und Metadaten

Jeder Wiederanlaufplan beginnt mit den Grundinformationen:

• Dokumententitel und Version: z. B. "Wiederanlaufplan IT-Infrastruktur v2.3"
• Geltungsbereich: Welche Systeme und Prozesse deckt der Plan ab?
• Verantwortlicher: Wer ist der Planeigner?
• Letzte Überprüfung: Wann wurde der Plan zuletzt aktualisiert?
• Nächste Überprüfung: Wann steht die nächste Revision an?
• Verteilerliste: Wer hat eine Kopie des Plans?

2. Auslösebedingungen

Der Plan definiert klar, unter welchen Umständen er aktiviert wird. Nicht jede Störung erfordert den Wiederanlaufplan. Eine klare Triggerdefinition verhindert, dass der Plan bei kleineren Vorfällen unnötig ausgelöst wird, aber auch, dass er bei einem echten Notfall zu spät aktiviert wird.

Typische Auslöser:

• Totalausfall eines geschäftskritischen Systems für mehr als [definierte Zeit]
• Ransomware-Angriff mit Verschlüsselung produktiver Systeme
• Physischer Schaden am Rechenzentrum (Brand, Wasser, Stromausfall > 4 Stunden)
• Ausfall des primären Rechenzentrums oder Cloud-Providers
• Entscheidung des Krisenstabs nach Bewertung der Lage

3. Rollen und Verantwortlichkeiten

Wer macht was? Diese Frage muss der Plan eindeutig beantworten. Für jeden Schritt im Wiederanlauf ist eine verantwortliche Person benannt, inklusive Vertreter.

4. Die vier Phasen des Wiederanlaufs

Ein Wiederanlaufplan gliedert sich typischerweise in vier Phasen. Jede Phase hat eigene Ziele, Aktivitäten und Abschlusskriterien.

Phase 1: Sofortmaßnahmen (0 bis 2 Stunden)

In dieser Phase geht es darum, die Lage zu stabilisieren und die Grundlagen für den Wiederanlauf zu schaffen.

Aktivitäten:

• Schadensbewertung: Welche Systeme sind betroffen? Welche Daten sind verfügbar?
• Notbetrieb einleiten: Manuelle Prozesse aktivieren, Workarounds kommunizieren
• Recovery-Team zusammenrufen und Aufgaben verteilen
• Backup-Verfügbarkeit prüfen: Sind die Backups intakt? Wann war das letzte erfolgreiche Backup?
• Kommunikationsplan aktivieren: Mitarbeiter informieren, Kunden bei Bedarf benachrichtigen

Abschlusskriterium: Lage ist bewertet, Team ist einsatzbereit, Backup-Status ist bekannt.

Phase 2: Infrastruktur wiederherstellen (2 bis 8 Stunden)

Die technische Basis muss stehen, bevor Anwendungen wiederhergestellt werden können. Diese Phase konzentriert sich auf Netzwerk, Server und Storage.

Aktivitäten:

• Netzwerkinfrastruktur prüfen und wiederherstellen (Switches, Firewalls, DNS, DHCP)
• Hypervisor-Umgebung / Cloud-Infrastruktur hochfahren
• Storage-Systeme und SAN wiederherstellen
• Active Directory / LDAP wiederherstellen (ohne AD funktioniert fast nichts)
• Monitoring aktivieren, um den Fortschritt zu überwachen

Abschlusskriterium: Basisinfrastruktur ist funktionsfähig, VMs können gestartet werden.

Phase 3: Anwendungen wiederherstellen (8 bis 24 Stunden)

Jetzt werden die Geschäftsanwendungen in der durch die BIA definierten Reihenfolge wiederhergestellt.

Aktivitäten:

• Datenbanken aus Backup wiederherstellen und Konsistenzprüfung durchführen
• ERP-System wiederherstellen und Basisfunktionen testen
• E-Mail-System wiederherstellen
• Weitere Anwendungen gemäß Prioritätenliste wiederherstellen
• Fachbereiche validieren lassen: Stimmen die Daten? Funktionieren die Prozesse?
• Schnittstellen zwischen Systemen prüfen

Abschlusskriterium: Alle kritischen Anwendungen laufen, Fachbereiche haben die Funktionsfähigkeit bestätigt.

Phase 4: Normalisierung (24 bis 72 Stunden)

Die letzte Phase überführt den eingeschränkten Betrieb in den Normalbetrieb.

Aktivitäten:

• Nicht-kritische Systeme wiederherstellen
• Aufgelaufene Daten nacherfassen (Bestellungen, Buchungen, die während des Ausfalls manuell bearbeitet wurden)
• Vollständige Funktionstests aller Systeme und Schnittstellen
• Backup-Routinen wieder aktivieren und ersten Sicherungslauf durchführen
• Lessons Learned dokumentieren
• Plan aktualisieren, falls Schwachstellen aufgefallen sind

Abschlusskriterium: Alle Systeme laufen im Normalbetrieb, Backup-Routinen greifen, keine offenen Punkte.

5. Recovery-Schritte pro Asset

Das Herzstück des Wiederanlaufplans sind die detaillierten Recovery-Schritte für jedes kritische Asset. Hier wird es konkret und technisch.

In ISMS Lite kannst du die Recovery-Schritte pro Asset direkt mit den BIA-Ergebnissen und RTO/RPO-Werten verknüpfen, sodass dein Wiederanlaufplan immer auf dem aktuellen Stand bleibt. Für jedes Asset dokumentierst du:

• Asset-Name und -Beschreibung: z. B. "ERP-System (SAP Business One auf SQL Server)"
• Kritikalität: Aus der BIA übernommen (z. B. Hoch)
• RTO / RPO: Ebenfalls aus der BIA
• Abhängigkeiten: Welche anderen Systeme müssen vorher laufen? (z. B. Active Directory, Netzwerk, SQL Server)
• Backup-Typ und -Speicherort: z. B. "Tägliches Full Backup auf NAS + wöchentliches Offsite-Backup"
• Recovery-Schritte: Nummerierte Anleitung mit konkreten Befehlen, Pfaden und Parametern
• Validierungsschritte: Wie prüfst du, ob die Wiederherstellung erfolgreich war?
• Verantwortlicher: Wer führt die Schritte aus?

Beispielplan: IT-Infrastruktur eines Mittelständlers

Nehmen wir ein konkretes Beispiel: Ein Maschinenbauer mit 150 Mitarbeitern, einem lokalen Rechenzentrum mit VMware-Virtualisierung und diesen kritischen Systemen:

Priorisierte Asset-Liste

Recovery-Schritte für das ERP-System (Prio 5)

Asset: SAP Business One auf Microsoft SQL Server 2022 Kritikalität: Hoch RTO: 4 Stunden | RPO: 1 Stunde Backup: Stündliches Transaction-Log-Backup, tägliches Full-Backup (Veeam), wöchentliches Offsite-Tape Verantwortlich: Applikationsbetreuer (Herr Müller), Vertreter: externer SAP-Partner

Voraussetzungen (müssen vorher abgeschlossen sein):

• Active Directory ist verfügbar
• VMware-Host ist betriebsbereit
• Storage ist verfügbar und Datastore gemountet
• Netzwerk-Konnektivität zwischen Servern ist hergestellt

Schritt-für-Schritt-Wiederherstellung:

1. VM aus Veeam-Backup wiederherstellen (Instant VM Recovery für schnellsten Start)
2. VM starten und Netzwerkkonfiguration prüfen (IP-Adresse, DNS, Gateway)
3. SQL Server-Dienst prüfen - läuft der Dienst? Sind die Datenbanken online?
4. Transaction-Log-Backups einspielen, um auf den aktuellsten Stand zu kommen
5. Datenbankintegrität prüfen: DBCC CHECKDB ausführen
6. SAP Business One-Dienste starten (SBO-Common, License Server, DI Server)
7. SAP-Client öffnen und Anmeldung testen
8. Stichprobenprüfung durch Fachabteilung: Letzte Aufträge, offene Posten, Lagerbestände
9. Schnittstellen prüfen (Webshop, Produktionssteuerung, Versand)

Validierung:

• Mindestens 3 Benutzer können sich anmelden und arbeiten
• Die letzten 10 Aufträge vor dem Ausfall sind vorhanden
• Lagerbestände stimmen mit dem letzten bekannten Stand überein
• Schnittstellendaten werden korrekt übertragen

Geschätzte Dauer: 2,5 bis 3,5 Stunden (innerhalb RTO von 4 Stunden)

Recovery-Schritte für Active Directory (Prio 2)

Asset: Active Directory Domain Services (2x Domain Controller, Windows Server 2022) Kritikalität: Kritisch (Abhängigkeit für fast alle Systeme) RTO: 2 Stunden | RPO: 1 Stunde Backup: System State Backup täglich, VM-Backup über Veeam Verantwortlich: IT-Administrator (Herr Schmidt), Vertreter: IT-Systemhaus

Schritt-für-Schritt-Wiederherstellung:

1. Primären Domain Controller aus Veeam-Backup als VM wiederherstellen
2. VM starten, DSRM-Modus (Directory Services Restore Mode) prüfen falls nötig
3. DNS-Dienst prüfen - Forward- und Reverse-Lookupzonen korrekt?
4. AD-Replikation testen (falls zweiter DC noch verfügbar)
5. Falls nur ein DC wiederhergestellt werden kann: FSMO-Rollen prüfen und ggf. übernehmen
6. Testanmeldung mit einem Domänenbenutzer an einer Workstation durchführen
7. Gruppenrichtlinien prüfen: gpresult auf einer Test-Workstation ausführen

Validierung:

• Domänenanmeldung funktioniert
• DNS-Auflösung interner Namen funktioniert
• FSMO-Rollen sind korrekt zugewiesen

Geschätzte Dauer: 1 bis 1,5 Stunden

Vorlage für den Wiederanlaufplan

Die folgende Vorlage kannst du als Ausgangspunkt für deinen eigenen Plan verwenden. Sie deckt die wichtigsten Bereiche ab und lässt sich an deine spezifische Umgebung anpassen.

Abschnitt 1: Allgemeine Informationen

Dokumententitel:     Wiederanlaufplan [Bereich]
Version:             [x.x]
Geltungsbereich:     [Welche Systeme/Prozesse]
Planeigner:          [Name, Funktion]
Erstellt am:         [Datum]
Letzte Überprüfung:  [Datum]
Nächste Überprüfung: [Datum]
Verteiler:           [Wer hat Zugriff]

Abschnitt 2: Auslösebedingungen

Der Wiederanlaufplan wird aktiviert, wenn:
□ Totalausfall eines Kritikalität-Hoch-Systems > [X] Stunden
□ Ransomware-Angriff mit Verschlüsselung produktiver Systeme
□ Ausfall des Rechenzentrums (physisch oder logisch)
□ Entscheidung des Krisenstabs
□ [Weitere unternehmensspezifische Auslöser]

Abschnitt 3: Kontaktliste Recovery-Team

| Rolle              | Name           | Telefon (Mobil)  | E-Mail              | Vertreter      |
|--------------------|----------------|------------------|----------------------|----------------|
| Recovery-Leiter    | [Name]         | [Nummer]         | [Mail]               | [Name]         |
| Infrastruktur      | [Name]         | [Nummer]         | [Mail]               | [Name]         |
| Applikationen      | [Name]         | [Nummer]         | [Mail]               | [Name]         |
| Ext. Dienstleister | [Firma/Name]   | [Nummer/Hotline] | [Mail]               | [Alternativ]   |

Abschnitt 4: Asset-Recovery-Steckbrief (pro Asset)

Asset:              [Name und Beschreibung]
Kritikalität:       [Kritisch / Hoch / Mittel / Niedrig]
RTO:                [Stunden]
RPO:                [Stunden]
Abhängigkeiten:     [Welche Systeme müssen vorher laufen]
Backup-Typ:         [Full/Incremental/Differential, Frequenz]
Backup-Speicherort: [NAS/Band/Cloud/Offsite]
Verantwortlich:     [Name] | Vertreter: [Name]

Recovery-Schritte:
1. [Schritt mit konkreten Details]
2. [Schritt mit konkreten Details]
3. ...

Validierung:
□ [Prüfpunkt 1]
□ [Prüfpunkt 2]
□ [Prüfpunkt 3]

Geschätzte Dauer: [X] Stunden

Abschnitt 5: Kommunikationsplan

| Zeitpunkt           | Empfänger            | Kanal         | Inhalt                              | Verantwortlich |
|---------------------|----------------------|---------------|--------------------------------------|----------------|
| Sofort              | Recovery-Team        | Telefon/SMS   | Aktivierung Wiederanlaufplan         | Recovery-Leiter|
| Innerhalb 1h        | Geschäftsführung     | Telefon       | Lagebericht, voraussichtl. Dauer     | Recovery-Leiter|
| Innerhalb 2h        | Alle Mitarbeiter     | SMS/Intranet  | Status und Workaround-Hinweise       | Kommunikation  |
| Bei Bedarf          | Kunden/Partner       | E-Mail/Telefon| Info über Einschränkungen            | GF/Vertrieb    |
| Nach Wiederanlauf   | Alle Stakeholder     | E-Mail        | Systeme wieder verfügbar             | Kommunikation  |

Typische Fehler beim Wiederanlaufplan

Aus der Beratungspraxis und aus realen Vorfällen lassen sich einige Muster erkennen, die immer wieder zu Problemen führen. Diese Fehler kosten im Ernstfall Stunden oder Tage - Zeit, die du nicht hast.

Fehler 1: Der Plan existiert, aber niemand kennt ihn

Ein 40-seitiges PDF liegt irgendwo auf dem Fileserver, den gerade niemand erreicht. Die IT-Abteilung hat den Plan vor zwei Jahren erstellt, aber weder dem Recovery-Team vorgestellt noch in einer Übung getestet. Im Ernstfall wird improvisiert.

Lösung: Verteilerliste pflegen, Plan physisch ausdrucken und an einem definierten Ort aufbewahren (z. B. im Tresor oder beim Geschäftsführer). Mindestens einmal jährlich eine Tabletop-Übung durchführen, in der das Team den Plan durchspielt.

Fehler 2: RTO und RPO sind nicht mit dem Business abgestimmt

Die IT definiert ein RTO von 24 Stunden für das ERP-System, weil das realistisch erscheint. Die Geschäftsführung geht davon aus, dass nach 4 Stunden alles wieder läuft. Diese Diskrepanz fällt erst im Ernstfall auf - und dann ist es zu spät für Diskussionen.

Lösung: RTO und RPO müssen gemeinsam mit den Fachbereichen und der Geschäftsführung festgelegt werden. Die BIA ist der richtige Rahmen dafür. Die IT liefert die technische Einschätzung, was machbar ist, und die Geschäftsleitung entscheidet, welches Risikoniveau akzeptabel ist.

Fehler 3: Abhängigkeiten werden ignoriert

Der Plan sieht vor, das ERP-System als erstes wiederherzustellen, weil es die höchste Geschäftspriorität hat. Aber das ERP braucht Active Directory für die Authentifizierung, einen laufenden SQL Server und Netzwerkkonnektivität. Ohne diese Voraussetzungen startet das ERP nicht, egal wie schnell du den Restore durchführst.

Lösung: Abhängigkeiten für jedes Asset dokumentieren. Die Wiederherstellungsreihenfolge muss diesen Abhängigkeiten folgen: Erst Infrastruktur, dann Plattformen, dann Anwendungen.

Fehler 4: Der Plan ist zu vage

"Server aus Backup wiederherstellen" ist keine Recovery-Anweisung. Welcher Server? Aus welchem Backup? Wo liegt das Backup? Welche Software wird für den Restore benötigt? Welche Zugangsdaten werden gebraucht?

Lösung: Recovery-Schritte so detailliert dokumentieren, dass ein kompetenter IT-Mitarbeiter, der das System nicht täglich betreut, den Restore durchführen kann. Konkrete Pfade, Befehle, Parameter und Zugangsdaten (Verweis auf Passwortmanager) gehören in den Plan. Eine saubere IT-Dokumentation ist dafür die Grundvoraussetzung.

Fehler 5: Kein Test, keine Aktualisierung

Der Plan wurde vor drei Jahren erstellt. Seitdem hat sich die IT-Infrastruktur grundlegend verändert: neuer Hypervisor, anderes Backup-Tool, andere Netzwerkstruktur. Der Plan beschreibt eine Umgebung, die es so nicht mehr gibt.

Lösung: Den Wiederanlaufplan mindestens einmal jährlich überprüfen und bei jeder wesentlichen Änderung der IT-Infrastruktur aktualisieren. Mindestens einmal jährlich einen Testlauf durchführen - ob als Tabletop-Übung oder als technischer Restore-Test.

So erstellst du deinen Wiederanlaufplan in 7 Schritten

Wenn du noch keinen Wiederanlaufplan hast, hier der pragmatische Weg für den Mittelstand:

Schritt 1: BIA durchführen (oder Ergebnisse nutzen) Ohne BIA kein sinnvoller Wiederanlaufplan. Falls du noch keine BIA hast, starte dort. Falls du bereits eine hast, nutze die Ergebnisse als Input.

Schritt 2: Kritische Assets identifizieren und priorisieren Liste alle IT-Systeme auf, die für die in der BIA identifizierten kritischen Geschäftsprozesse benötigt werden. Ordne ihnen die RTO/RPO-Werte aus der BIA zu.

Schritt 3: Abhängigkeiten kartieren Zeichne die Abhängigkeiten zwischen den Systemen auf. Was muss zuerst laufen, damit andere Systeme funktionieren? Das ergibt die Wiederherstellungsreihenfolge.

Schritt 4: Recovery-Schritte pro Asset dokumentieren Für jedes kritische Asset: Wie wird es wiederhergestellt? Welche Backups gibt es? Wie lange dauert der Restore? Wer führt ihn durch? Schreibe die Schritte so, dass sie ein kompetenter Vertreter ausführen kann.

Schritt 5: Rollen und Verantwortlichkeiten festlegen Wer ist Recovery-Leiter? Wer kümmert sich um Infrastruktur, wer um Applikationen? Wer kommuniziert nach außen? Für jede Rolle brauchst du einen Vertreter.

Schritt 6: Kommunikationsplan erstellen Wer wird wann über was informiert? Mitarbeiter, Geschäftsführung, Kunden, Partner, ggf. Behörden (NIS2-Meldepflicht).

Schritt 7: Testen und iterieren Führe einen ersten Testlauf durch. Das muss kein vollständiger technischer Test sein - eine Tabletop-Übung reicht für den Anfang. Dokumentiere die Erkenntnisse und verbessere den Plan.

Den Plan verfügbar halten

Ein Wiederanlaufplan, der nur digital auf dem Fileserver liegt, ist im Ernstfall möglicherweise nicht erreichbar - genau weil der Fileserver Teil des Ausfalls sein kann. Deshalb gilt die Regel: Der Plan muss über mindestens zwei unabhängige Kanäle verfügbar sein.

Empfohlene Verfügbarkeit:

• Gedruckt: Eine aktuelle Version im Tresor oder am Arbeitsplatz des IT-Leiters. Klingt altmodisch, funktioniert aber, wenn alles andere ausfällt.
• Cloud-Speicher: Eine Kopie in einem Cloud-Dienst, der unabhängig von der eigenen Infrastruktur ist (z. B. SharePoint Online, Google Drive oder ein verschlüsselter Cloud-Storage).
• Mobile: PDF auf dem Firmenhandy des Recovery-Leiters und seines Vertreters.
• Beim Dienstleister: Der externe IT-Dienstleister sollte ebenfalls eine aktuelle Version haben.

Dazu gehört auch, dass die Kontaktdaten im Plan aktuell sind. Wenn Herr Müller seit drei Monaten nicht mehr im Unternehmen ist und sein Name noch als Verantwortlicher für den ERP-Restore steht, hilft der beste Plan nicht weiter.

PDF-Export und Versionierung

Ein Wiederanlaufplan lebt und verändert sich. Jede Änderung an der IT-Infrastruktur kann Auswirkungen auf den Plan haben. Deshalb ist eine saubere Versionierung unverzichtbar.

Best Practices für die Versionierung:

• Versionsnummer im Dokument (z. B. v1.0, v1.1, v2.0)
• Änderungshistorie mit Datum, Autor und Art der Änderung
• Major-Versionen bei grundlegenden Änderungen (neues System, neue Infrastruktur)
• Minor-Versionen bei Aktualisierungen (neue Telefonnummern, angepasste Recovery-Zeiten)

PDF-Export: Exportiere den Plan regelmäßig als PDF für die Offline-Verfügbarkeit. Das PDF sollte alles enthalten, was für den Wiederanlauf nötig ist - keine Verweise auf andere Dokumente, die im Notfall möglicherweise nicht erreichbar sind. Anhänge wie Netzwerkpläne, IP-Adresslisten und Zugangsdaten (verschlüsselt) können als Anlage beigefügt werden.

In ISMS Lite kannst du Wiederanlaufpläne direkt aus den BIA-Ergebnissen generieren. Die RTO/RPO-Werte, Abhängigkeiten und Verantwortlichen werden automatisch übernommen, und der PDF-Export erzeugt ein druckfertiges Dokument, das du an die relevanten Stellen verteilen kannst.

Zusammenhang mit NIS2 und ISO 27001

Falls dein Unternehmen unter NIS2 fällt oder eine ISO-27001-Zertifizierung anstrebt, ist der Wiederanlaufplan kein optionales Dokument. Beide Frameworks fordern ihn explizit.

NIS2 (Artikel 21, Absatz 2c): Fordert "Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement". Ein dokumentierter Wiederanlaufplan ist der Nachweis, dass du dieser Anforderung nachkommst.

ISO 27001 (Annex A, Kontrolle A.5.29 und A.5.30): Die Kontrollen zur Informationssicherheitskontinuität verlangen, dass Pläne zur Wiederherstellung erstellt, implementiert und getestet werden.

In beiden Fällen reicht es nicht, den Plan nur zu haben. Du musst nachweisen können, dass er regelmäßig überprüft und getestet wird. Auditoren fragen gezielt nach Testprotokollen und den daraus abgeleiteten Verbesserungen.

Nächste Schritte

Du hast jetzt einen umfassenden Überblick über Aufbau, Inhalt und Erstellung eines Wiederanlaufplans. Die wichtigsten Punkte:

1. Starte mit der BIA - ohne sie fehlt die Grundlage für alle Priorisierungsentscheidungen.
2. Dokumentiere Recovery-Schritte konkret - vage Anweisungen helfen im Ernstfall niemandem.
3. Berücksichtige Abhängigkeiten - die Wiederherstellungsreihenfolge ist kein Wunschkonzert.
4. Teste den Plan - ein ungetesteter Plan ist eine gefährliche Illusion von Sicherheit.
5. Halte ihn aktuell - ein veralteter Plan richtet im Ernstfall mehr Schaden an, als gar keiner zu haben.

Weiterführende Artikel

• Business Impact Analyse (BIA) durchführen: Geschäftsprozesse bewerten
• Notfallhandbuch für die IT: Aufbau, Inhalt und PDF-Vorlage
• Backup-Strategie und Restore-Tests: Weil Backups allein nicht reichen
• Incident Response Plan erstellen: Vorlage und Praxisbeispiel
• IT-Asset-Management für das ISMS: Inventar, Kritikalität und Klassifizierung

Wenn du die BIA als Grundlage noch nicht hast, lies den Artikel zur Business Impact Analyse als nächsten Schritt. Wenn du nach einer Möglichkeit suchst, den Plan regelmäßig zu testen, hilft dir der Artikel zu Tabletop-Übungen weiter.