Grundsatz: Systeme, Daten, Anlagen und Geschäftsprozesse werden nach einer Unterbrechung nicht nach spontaner Verfügbarkeit, sondern in einer vorab abgestimmten, abhängigen und freigegebenen Reihenfolge wiederhergestellt.
Sicherheitsregel: Nach einem Cyberangriff darf keine Wiederherstellung in eine möglicherweise kompromittierte Umgebung erfolgen. Vertrauenswürdigkeit, Bereinigung, Identitäten, Wiederherstellungsquellen und Überwachung müssen vor dem produktiven Wiederanlauf angemessen geprüft sein.
Entwurfswarnung: Kritische Services, Abhängigkeiten, RTO, RPO, Wiederherstellungsquellen, technische Schritte, Verantwortliche und Testergebnisse sind noch nicht organisationsbezogen bestätigt. Diese Musterseite ist ohne ausgefüllte Service-Runbooks und erfolgreiche Wiederanlauftests kein Nachweis einer funktionsfähigen Wiederherstellung.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-05-04 |
| Dokumentenart | IKT-/OT-Wiederanlaufverfahren und Runbook-Rahmen |
| Wiki.js-Pfad | /ISMS/05-Vorfaelle-und-Notfallmanagement/Wiederanlaufplanung |
| Verantwortlich | IT-/ITSCM-Verantwortliche/r |
| Fachlich geprüft durch | BCM, ISMS, IT, OT, Fachbereiche, Datenschutz, Lieferantenmanagement und Krisenmanagement |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – Servicekatalog, Zielwerte und Tests nicht freigegeben |
| Version | 0.1 |
| Stand | 23.07.2026 |
| Nächste Prüfung | Mindestens jährlich sowie nach Tests, Vorfällen und wesentlichen Änderungen |
| Schutzklasse | Intern |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.29, 5.30, 7.11, 8.13, 8.14, 8.15 und 8.16 |
| VDA-ISA-Bezug | ISA 6.0.3, insbesondere Kapitel 1.6 und 5.2 sowie verfügbarkeitsbezogene Anforderungen |
| Ergänzende Orientierung | ISO/IEC 27031:2025, ISO 22301:2019 einschließlich Amd 1:2024 und BSI-Standard 200-4 |
Diese Seite legt den Rahmen für den kontrollierten Wiederanlauf von Informations- und Kommunikationstechnik, OT, Daten und den davon abhängigen Geschäftsprozessen fest.
Ziele sind:
Die Wiederanlaufplanung gilt für kritische und wichtige:
Die Notfallvorsorge und das BCM bestimmen Geschäftskritikalität, MTPD, Mindestbetriebsniveau und fachliche Wiederanlaufziele. Die Wiederanlaufplanung setzt diese Anforderungen in technische und organisatorische Wiederherstellungsabläufe um.
Bei einem Informationssicherheitsvorfall steuert Incident Response Analyse, Eindämmung und Bereinigung. Die Wiederanlaufplanung wird erst unter den dort festgelegten Sicherheitsbedingungen ausgeführt.
Datensicherung allein ist keine Wiederanlaufplanung. Ein erfolgreicher Sicherungslauf belegt weder die Wiederherstellbarkeit noch die Funktionsfähigkeit des wiederhergestellten Services.
| Begriff | Bedeutung |
|---|---|
| Wiederanlauf | Kontrollierte Wiederherstellung einer Aktivität, Ressource oder Leistung nach einer Unterbrechung |
| RTO | Zielzeit, innerhalb derer eine Aktivität oder Ressource wieder verfügbar sein soll |
| RPO | Ziel für den maximal tolerierbaren Datenverlust, ausgedrückt als Wiederherstellungspunkt |
| Restore | Rücksicherung von Daten, Konfigurationen oder Systemständen aus einer Sicherung |
| Rebuild | Neuaufbau eines Systems aus vertrauenswürdigen Quellen |
| Failover | Umschaltung auf eine alternative technische Instanz oder einen anderen Standort |
| Failback | Kontrollierte Rückkehr von der Ausweich- in die reguläre Umgebung |
| Recovery Point | Konkreter Daten- oder Systemstand, auf den wiederhergestellt wird |
| Clean Recovery | Wiederherstellung in einer als vertrauenswürdig geprüften beziehungsweise neu aufgebauten Umgebung |
| Mindestkapazität | Erforderliche reduzierte Leistung zur Unterstützung des BCM-Mindestbetriebs |
| Runbook | Servicebezogene, schrittweise und getestete Wiederanlaufanweisung |
| Rückfall | Geplanter Weg zurück in einen sicheren Zustand, wenn ein Wiederanlaufschritt fehlschlägt |
Vor Erstellung eines Service-Runbooks werden mindestens folgende Informationen benötigt:
| Eingabe | Quelle | Mindeststatus |
|---|---|---|
| Prozesskritikalität und Mindestbetriebsniveau | BIA/BCM | fachlich bestätigt oder als offen gekennzeichnet |
| Prozess-RTO und -RPO | BIA/BCM | bestätigt und plausibilisiert |
| Asset- und Servicezuordnung | Asset-Inventar | aktuell und verantwortet |
| technische und fachliche Abhängigkeiten | Service-/Prozessdokumentation | vollständig genug für Reihenfolgeprüfung |
| Schutzbedarf und Sicherheitsanforderungen | Asset-/Risikobewertung | bestätigt |
| Backup-/Replikationskonzept | Datensicherungsverfahren | technisch dokumentiert und geprüft |
| Wiederherstellungsquellen | Backup, Code, Images, Konfiguration und Dokumentation | verfügbar und integritätsgeschützt |
| Rollen und Befugnisse | BCM-/IT-/Krisenorganisation | freigegeben |
| Lieferantenleistungen | Verträge und Servicekatalog | Zusagen und Eskalationen bestätigt |
| Wiederanlaufumgebung | Primär-, Ausweich- oder Clean-Recovery-Umgebung | Kapazität und Sicherheit geprüft |
| Testverfahren | Test-/Übungsprogramm | Erfolgskriterien festgelegt |
Fehlende Eingaben werden nicht durch unbelegte Standardwerte ersetzt. Sie werden als Risiko oder offene Maßnahme eskaliert.
| Rolle | Verantwortung |
|---|---|
| Geschäftsführung/Krisenleitung | Prioritäten bei Ressourcenkonflikten, außergewöhnliche Risiken und geschäftskritische Entscheidungen freigeben |
| BCM-Verantwortung | Geschäftsziele, Mindestbetriebsniveau und Wiederanlaufprioritäten bereitstellen |
| Wiederanlaufleitung | Gesamtkoordination, Reihenfolge, Lagebild, Ressourcen, Freigabepunkte und Abschluss steuern |
| Technische Einsatzleitung | technische Maßnahmen planen, zuweisen, protokollieren und verifizieren |
| Service Owner | Serviceziel, Abhängigkeiten, Runbook, technische Freigabe und Pflege verantworten |
| Prozess-/Product Owner | fachliche Priorität, Mindestkapazität, Funktionstest und Betriebsfreigabe verantworten |
| ISMS/Informationssicherheit | Sicherheitsbedingungen, Clean Recovery, Restrisiken und Überwachung prüfen |
| Backup-/Storage-Verantwortung | Sicherungsstände, Integrität, Rücksicherung und Aufbewahrung unterstützen |
| Netzwerk-/Plattform-/Identitätsteams | Basisdienste in abgestimmter Reihenfolge wiederherstellen |
| OT-/Produktionsverantwortung | Anlagensicherheit, Herstelleranforderungen, sichere Zustände und Produktionsfreigabe steuern |
| Datenschutz/Recht | datenschutz- und vertragsbezogene Grenzen sowie Nachweise prüfen |
| Lieferantenmanagement | Provider, Hersteller und externe Unterstützung aktivieren und nachverfolgen |
| Protokollführung | Zeitlinie, Entscheidungen, Änderungen, Messwerte und Nachweise führen |
Für alle relevanten Services wird ein zentraler Katalog geführt.
| Feld | Beschreibung |
|---|---|
| Service-ID | eindeutige Kennzeichnung |
| Service/Leistung | technische und verständliche fachliche Bezeichnung |
| Service Owner | verantwortliche Rolle |
| unterstützte Prozesse | BIA-/Prozessreferenzen |
| Kritikalität/Priorität | aus BCM und Abhängigkeiten abgeleitete Stufe |
| Service-RTO | bestätigtes Ziel innerhalb des Prozess-RTO |
| Service-RPO | bestätigtes und technisch erreichbares Ziel |
| Mindestkapazität | benötigte Leistung im Wiederanlauf |
| Abhängigkeiten | Vorgänger, Plattformen, Personal, Standort, Provider |
| Wiederanlaufstrategie | Restore, Rebuild, Failover, Ersatzverfahren oder Kombination |
| Runbook | geschützter Link und Offline-Verfügbarkeit |
| letzter Test | Datum, Umfang, Ergebnis und Abweichungen |
| Planstatus | Entwurf, geprüft, freigegeben, getestet oder überfällig |
| Service-ID | Service | Owner | Prozesse | Priorität | RTO | RPO | Vorgänger | Strategie | Runbook | Teststatus |
|---|---|---|---|---|---|---|---|---|---|---|
[SRV-NNN] |
[Bezeichnung] |
[Rolle] |
[BIA/Prozess] |
[P1–P4] |
[bestätigt/offen] |
[bestätigt/offen] |
[Service-IDs] |
[Strategie] |
[Link] |
[Status] |
Diese Vorlage enthält keine Aussage über tatsächlich vorhandene Services oder Fähigkeiten.
| Priorität | Bedeutung | Planungsregel |
|---|---|---|
| P1 – Fundament | Für nahezu alle kritischen Wiederanläufe erforderlich | zuerst oder parallel in gesicherter Reihenfolge |
| P2 – Kritisch | Unterstützt zeitkritische Geschäftsleistungen | nach notwendigen Fundamenten |
| P3 – Wichtig | Erforderlich für erweiterten Betrieb oder nachgelagerte Leistungen | nach P1/P2 gemäß BIA |
| P4 – Nachrangig | Kann länger ausgesetzt oder ersetzt werden | nach Stabilisierung kritischer Leistungen |
Prioritätsstufen sind kein Ersatz für konkrete RTO, RPO und Abhängigkeitsbeziehungen.
Die tatsächliche Reihenfolge wird organisationsbezogen geprüft. Eine typische Abhängigkeitsprüfung betrachtet:
Die Liste ist kein automatisch gültiger Ablauf. Ein Service kann andere Vorgänger benötigen oder selbst Fundament für frühere Schritte sein.
| Service | benötigt zwingend | benötigt für Mindestbetrieb | kann temporär ersetzt werden durch | Reihenfolge bestätigt |
|---|---|---|---|---|
[SRV-NNN] |
[Service/Ressource] |
[Kapazität/Funktion] |
[Ersatzverfahren] |
[Ja/Nein/offen] |
Zirkuläre Abhängigkeiten, nicht verfügbare Basisdienste und konkurrierende Ressourcen werden vor einem Test aufgelöst oder als Risiko behandelt.
| Strategie | Geeignet, wenn | Wesentliche Prüfungen |
|---|---|---|
| Restore | vertrauenswürdige Sicherungen und geeignete Zielumgebung vorhanden sind | Integrität, Alter, Malwarefreiheit, RPO, Abhängigkeiten |
| Rebuild | System aus Code, Images und Konfiguration reproduzierbar aufgebaut werden kann | Vertrauensquelle, Version, Geheimnisse, Härtung, Automatisierung |
| Failover | betriebsbereite alternative Instanz verfügbar ist | gemeinsame Fehlerursachen, Datenstand, Kapazität, Routing, Lizenz |
| Ersatzsystem | alternative Plattform die Mindestfunktion erbringen kann | Kompatibilität, Datenübernahme, Sicherheit, Bedienung |
| manueller Notbetrieb | zeitlich begrenzte fachliche Fortführung möglich ist | Kapazität, Fehlerkontrolle, Datenschutz, spätere Nacherfassung |
| Neuinstallation | vertrauenswürdiger Neuaufbau erforderlich oder schneller ist | Installationsmedien, Lizenz, Konfiguration, Daten und Tests |
| Provider-Recovery | externe Leistung vertraglich wiederhergestellt wird | Kenntniszeit, RTO/RPO, Priorisierung, Nachweise, eigene Abhängigkeiten |
| Feld | Eintrag |
|---|---|
| Service-/Prozessbezug | [Referenz] |
| bestätigte Ziele | [RTO/RPO/Mindestkapazität] |
| geprüfte Strategien | [Optionen und Ergebnisse] |
| ausgewählte Strategie | [Begründung] |
| erforderliche Ressourcen | [Personal, Technik, Standort, Provider] |
| gemeinsame Ausfallursachen | [Prüfung] |
| Restrisiken/Lücken | [Risikoreferenz] |
| Freigabe | [Rolle, Datum] |
| Testmethode | [Umfang und Erfolgskriterien] |
Die Wiederanlaufplanung kann insbesondere aktiviert werden durch:
Vor dem Start werden soweit möglich bestätigt:
| Feld | Eintrag |
|---|---|
| Wiederanlauf-ID | [REC-JJJJ-NNN] |
| Ereignis-/Incident-Referenz | [Referenz] |
| Aktivierungszeitpunkt | [Datum/Uhrzeit/Zeitzone] |
| Wiederanlaufleitung | [Rolle/Name] |
| betroffene Prozesse/Services | [BIA-/Service-IDs] |
| Strategie/Zielumgebung | [Festlegung] |
| angestrebter Recovery Point | [Zeitpunkt/Version] |
| bestätigte RTO/RPO | [Werte oder offen] |
| nächster Lagezeitpunkt | [Datum/Uhrzeit] |
| führendes Protokoll | [geschützter Link] |
| Phase | Ziel | Freigabepunkt |
|---|---|---|
| 0. Vorbereitung | Pläne, Quellen, Zugänge, Umgebungen und Teams bereitstellen | Einsatzbereitschaft bestätigt |
| 1. Lage und Schaden bewerten | Umfang, Priorität, Ziele und Strategie festlegen | Wiederanlaufentscheidung |
| 2. Zielumgebung herstellen | Sichere, ausreichende Recovery-Umgebung bereitstellen | Sicherheits-/Plattformfreigabe |
| 3. Basisdienste wiederherstellen | Fundamente und technische Vorgänger verfügbar machen | Basisdienstprüfung |
| 4. Daten und Services wiederherstellen | Service gemäß Runbook aufbauen oder umschalten | technische Servicefreigabe |
| 5. Fachlich validieren | Daten, Schnittstellen und Mindestfunktion prüfen | fachliche Betriebsfreigabe |
| 6. Stabilisieren und zurückführen | überwachen, Rückstände behandeln und Normalbetrieb erreichen | Abschluss-/Failback-Freigabe |
Ein Zeitdruck rechtfertigt keine stillschweigende Überspringung eines Freigabepunkts. Abweichungen werden mit Risiko, Befugnis, Auflagen und Rückfall dokumentiert.
Vor einem Ereignis müssen abhängig von der Kritikalität vorhanden und gepflegt sein:
| Vorbereitung | Mindestnachweis |
|---|---|
| Servicekatalog und Abhängigkeiten | aktueller Katalog und geprüfte Reihenfolge |
| Runbooks | freigegebene Online- und Offline-Fassung |
| Backups/Replikate | Überwachung, Schutz, Aufbewahrung und Restore-Nachweise |
| Installations- und Build-Quellen | integritätsgeschützte Medien, Images, Code und Konfiguration |
| Lizenzen und Verträge | Notfallnutzung, Support und Zugang geklärt |
| Notfallzugänge | geschützt, getestet, protokolliert und vertretbar |
| Recovery-Umgebung | Kapazität, Netz, Identitäten und Sicherheit geprüft |
| Ersatzhardware/-geräte | Bestand, Kompatibilität, Lagerung und Aktualität |
| Kontaktdaten | interne Teams, Provider, Hersteller und Stellvertretungen |
| Monitoring/Protokollierung | auch in Recovery-Umgebung verfügbar |
| Testdaten und Erfolgskriterien | fachlich und technisch definiert |
Wiederanlaufunterlagen dürfen keine ungeschützten Passwörter, privaten Schlüssel oder anderen Geheimnisse enthalten.
Die Wiederanlaufleitung veranlasst:
| Entscheidung | Optionen | Fakten/Annahmen | Risiko | entschieden durch | Zeitpunkt |
|---|---|---|---|---|---|
[Entscheidung] |
[Alternativen] |
[Grundlage] |
[Restrisiko] |
[Rolle] |
[Zeit] |
Fakten, Annahmen und noch ungeprüfte Angaben werden getrennt ausgewiesen.
Vor der Wiederherstellung wird die Zielumgebung entsprechend dem Ereignis geprüft:
| Prüffeld | Ergebnis/Nachweis |
|---|---|
| Standort/Versorgung | [geprüft/offen] |
| Netzwerk und Segmentierung | [geprüft/offen] |
| Identitäten und Administration | [geprüft/offen] |
| Härtung und Schutzmaßnahmen | [geprüft/offen] |
| Monitoring/Protokollierung | [geprüft/offen] |
| Kapazität | [geprüft/offen] |
| Trennung/Vertrauensstatus | [geprüft/offen] |
| Freigabe Informationssicherheit | [Rolle, Datum, Auflagen] |
| Freigabe Plattformbetrieb | [Rolle, Datum, Auflagen] |
Basisdienste werden anhand der bestätigten Abhängigkeitsmatrix wiederhergestellt. Für jeden Schritt werden dokumentiert:
| Prüfschritt | Ergebnis |
|---|---|
| Vorgänger und Infrastruktur verfügbar | [Ja/Nein/Auflage] |
| Konfiguration aus vertrauenswürdiger Quelle | [Nachweis] |
| notwendige Identitäten/Geheimnisse bereitgestellt | [Nachweis] |
| Härtung und sicherheitsrelevante Einstellungen geprüft | [Nachweis] |
| Zeit, DNS, Zertifikate und Kommunikation funktionieren | [Test] |
| Monitoring und Protokollierung aktiv | [Test] |
| Leistung und Kapazität ausreichend | [Messung] |
| abhängige Teams informiert | [Zeitpunkt] |
| Basisdienst freigegeben | [Rolle/Zeitpunkt] |
Für jeden Service wird das freigegebene Runbook verwendet. Mindestens werden ausgeführt:
| Kriterium | Ergebnis/Nachweis |
|---|---|
| Runbook-Version korrekt | [Version] |
| Recovery Point bestätigt | [Zeitpunkt/Quelle] |
| Restore/Rebuild/Failover fehlerfrei | [Protokoll] |
| Datenintegrität technisch geprüft | [Methode/Ergebnis] |
| Sicherheitsprüfung bestanden | [Methode/Ergebnis] |
| Schnittstellen technisch verfügbar | [Test] |
| Monitoring und Backup aktiv | [Test] |
| Leistung/Mindestkapazität erreicht | [Messung] |
| bekannte Abweichungen/Restrisiken | [Referenz] |
| technische Freigabe | [Rolle/Zeitpunkt/Auflagen] |
Technische Erreichbarkeit allein ist keine Betriebsfreigabe. Die Prozess- oder Produktverantwortung prüft insbesondere:
| Prüffeld | Entscheidung |
|---|---|
| kritische Geschäftsfunktionen | [bestanden/nicht bestanden] |
| Datenstand und Plausibilität | [bestanden/nicht bestanden] |
| Schnittstellen und Folgeprozesse | [bestanden/nicht bestanden] |
| Berechtigungen/Funktionstrennung | [bestanden/nicht bestanden] |
| Mindestkapazität | [erreicht/nicht erreicht] |
| Datenverlust/Nacherfassung | [Umfang/Plan] |
| Auflagen und Restrisiken | [Referenz] |
| fachliche Freigabe | [Rolle/Zeitpunkt] |
| Produktivsetzung | [Rolle/Zeitpunkt] |
Nach der Produktivsetzung wird ein verstärkter Überwachungszeitraum festgelegt. Er umfasst:
Wenn in einer Ausweichumgebung gearbeitet wurde, wird die Rückkehr gesondert geplant:
Der Wiederanlauf wird erst abgeschlossen, wenn:
| Feld | Eintrag |
|---|---|
| Runbook-ID | [RB-SRV-NNN] |
| Service-ID/Service | [Referenz/Bezeichnung] |
| Owner/Stellvertretung | [Rolle] |
| Schutzklasse | [Einstufung] |
| unterstützte Prozesse | [BIA-/Prozessreferenz] |
| Priorität | [P1–P4] |
| bestätigtes RTO/RPO | [Werte/Referenz] |
| Mindestkapazität | [Wert/Funktion] |
| Strategie | [Restore/Rebuild/Failover/sonstige] |
| Offline-Ablage | [geschützter Ort] |
| letzte Prüfung/Test | [Datum/Ergebnis] |
| Voraussetzung | Sollzustand | Prüfung |
|---|---|---|
| Vorgängerservices | [Service-IDs/Status] |
[Test/Befehl ohne Geheimnisse] |
| Zielumgebung | [Standort/Plattform/Kapazität] |
[Prüfung] |
| Wiederherstellungsquelle | [Backup/Image/Code/Version] |
[Integritätsnachweis] |
| Identitäten/Geheimnisse | [benötigte Rollen/Stores] |
[Verfügbarkeitsprüfung] |
| Lizenzen/Verträge | [Anforderung] |
[Prüfung] |
| Provider/Hersteller | [Kontaktrolle/Ticketweg] |
[Erreichbarkeit] |
| Sicherheitsfreigabe | [Bedingung] |
[Nachweis] |
| Nr. | Arbeitsschritt | Verantwortung | Sollzeit | Eingabe/Quelle | Erfolgskriterium | Rückfall |
|---|---|---|---|---|---|---|
| 1 | [Schritt] |
[Rolle] |
[Dauer] |
[Referenz] |
[messbares Ergebnis] |
[Aktion] |
| Test | Methode | erwartetes Ergebnis | tatsächliches Ergebnis | Nachweis |
|---|---|---|---|---|
| technischer Starttest | [Methode] |
[Kriterium] |
[Ergebnis] |
[Referenz] |
| Sicherheitsprüfung | [Methode] |
[Kriterium] |
[Ergebnis] |
[Referenz] |
| Schnittstellentest | [Methode] |
[Kriterium] |
[Ergebnis] |
[Referenz] |
| Fachfunktionstest | [Methode] |
[Kriterium] |
[Ergebnis] |
[Referenz] |
| Kapazitätstest | [Methode] |
[Kriterium] |
[Ergebnis] |
[Referenz] |
Das Runbook enthält ausführbare, eindeutige Schritte, aber keine ungeschützten Passwörter, Tokens, privaten Schlüssel oder personenbezogenen Kontaktdaten.
Die operative Steuerung von Sicherungsumfang, Schutz, Trennung, Aufbewahrung, Jobüberwachung und Restore-Tests erfolgt in Datensicherung und Wiederherstellung.
| Prüfkriterium | Dokumentation |
|---|---|
| technisch verfügbarer Stand | [Zeitpunkt/Version] |
| bestätigter sauberer Stand | [Prüfung/Unsicherheit] |
| Einhaltung RPO | [Ja/Nein/Abweichung] |
| erwarteter Datenverlust | [Zeitraum/Datentypen] |
| notwendige Nacherfassung | [Verfahren/Owner] |
| rechtliche/fachliche Bindungen | [Aufbewahrung, Abschluss, Nachweis] |
| Auswahl und Freigabe | [Rolle/Zeitpunkt/Begründung] |
Eine unveränderbare Sicherung kann vor Löschung oder Manipulation schützen, belegt aber nicht automatisch Malwarefreiheit, Datenkonsistenz oder fachliche Verwendbarkeit.
Nach einem Cybervorfall gelten zusätzlich:
| Gate | Bestätigung |
|---|---|
| Eindämmung ausreichend | [Incident-Leitung] |
| Ursache/Eintrittsweg behandelt oder Restrisiko entschieden | [Incident/ISMS] |
| Zielumgebung vertrauenswürdig | [Informationssicherheit/Plattform] |
| Wiederherstellungsquelle geprüft | [Backup/Forensik/ISMS] |
| Identitäten und Geheimnisse behandelt | [IAM/ISMS] |
| Erkennungs- und Überwachungsmaßnahmen aktiv | [SOC/IT/ISMS] |
| Produktivsetzung mit Auflagen freigegeben | [befugte Rollen] |
Für externe Services werden mindestens geplant:
| Externer Service | benötigtes Ziel | zugesagtes Ziel | eigene Recovery-Option | Eskalation | letzter Nachweis | Lücke |
|---|---|---|---|---|---|---|
[Service/Provider] |
[RTO/RPO] |
[Vertragswert] |
[Export/Ersatz/keine] |
[Rolle/Kanal] |
[Test/Audit/Status] |
[Risiko] |
Eine Statusseite oder Zertifizierung des Providers ersetzt keinen eigenen Wiederanlauf- und Exit-Nachweis für die konkret genutzte Leistung.
Bei OT und Produktionsanlagen haben Personen-, Prozess- und Anlagensicherheit Vorrang.
Zusätzlich werden berücksichtigt:
| OT-Prüfpunkt | Ergebnis/Nachweis |
|---|---|
| Arbeitssicherheit und Anlagenzustand | [Freigabe] |
| Steuerung/Programm/Parameter | [Version/Integrität] |
| Netz- und Schnittstellenfreigabe | [Test] |
| Schutz- und Sicherheitseinrichtungen | [Test/Freigabe] |
| Material/Prüfmittel/Kalibrierung | [Nachweis] |
| Testlauf/Erstteil/Qualität | [Ergebnis] |
| Produktionsfreigabe | [Rolle/Zeitpunkt] |
Während des Wiederanlaufs gelten mindestens:
| Feld | Eintrag |
|---|---|
| Abweichung | [Beschreibung] |
| Grund/Alternativen | [Begründung] |
| Risiko und Betroffenheit | [Bewertung] |
| kompensierende Maßnahmen | [Kontrollen] |
| Freigabe | [befugte Rolle] |
| gültig bis | [Zeitpunkt/Ereignis] |
| Überwachung | [Owner/Methode] |
| Rücknahme/Nachkontrolle | [Schritt/Nachweis] |
Das führende Wiederanlaufprotokoll enthält:
| Kategorie | Mindestinhalt |
|---|---|
| Lage | bestätigte Fakten, Annahmen, Auswirkungen und Prognose |
| Ziele | RTO, RPO, Mindestkapazität und verbleibende Zeit |
| Servicezustand | nicht begonnen, in Arbeit, technisch bereit, fachlich freigegeben, stabil |
| Maßnahmen | Schritt, Owner, Beginn, Ende, Ergebnis und Nachweis |
| Entscheidungen | Inhalt, Optionen, Risiko, Befugnis und Zeitpunkt |
| Änderungen | Konfiguration, Version, Notfall-Change und Rückfall |
| Daten | Recovery Point, Verlust, Nacherfassung und Integrität |
| Kommunikation | Empfänger, Inhalt, Freigabe und Zeitpunkt |
| Abweichungen | Zielverfehlung, Ursache, Auswirkung und Maßnahme |
| Service | Priorität | RTO-Zeitpunkt | aktueller Status | Blocker | nächster Schritt | Owner | Prognose |
|---|---|---|---|---|---|---|---|
[SRV-NNN] |
[P1–P4] |
[Zeitpunkt] |
[Status] |
[Abhängigkeit] |
[Schritt] |
[Rolle] |
[Zeit] |
Nur autorisierte Rollen geben Prognosen oder Aussagen an Kunden, Behörden, Versicherer, Medien, ENX oder Audit-Provider weiter.
Ein Wiederanlaufschritt wird gestoppt oder zurückgenommen, wenn:
| Rückfallfeld | Festlegung |
|---|---|
| Auslösekriterium | [messbares Kriterium] |
| Entscheidungsbefugnis | [Rolle] |
| sicherer Zielzustand | [Beschreibung] |
| technische Schritte | [Referenz] |
| Datenbehandlung | [Sicherung/Verwerfung/Abgleich] |
| Kommunikation | [Empfänger/Kanal] |
| erneuter Start | [Voraussetzungen] |
| Testart | Aussage |
|---|---|
| Dokumentenreview | Runbook ist aktuell, vollständig und zugänglich |
| Komponenten-Restore | Einzelne Daten oder Komponenten können zurückgesichert werden |
| Service-Restore | Vollständiger Service kann technisch wiederhergestellt werden |
| Rebuild-Test | System kann aus vertrauenswürdigen Quellen neu aufgebaut werden |
| Failover-/Failback-Test | Umschaltung und Rückkehr funktionieren kontrolliert |
| Abhängigkeitstest | mehrere Services starten in korrekter Reihenfolge |
| Fachlicher End-to-End-Test | Geschäftsprozess funktioniert mit Daten und Schnittstellen |
| Cyber-Recovery-Übung | Clean Recovery, Identitätsneustart und verstärkte Überwachung werden erprobt |
| OT-Wiederanlauftest | Anlage startet sicher und erfüllt Qualitätskriterien |
| Feld | Eintrag |
|---|---|
| Test-ID | [TST-REC-JJJJ-NNN] |
| Services/Prozesse | [Scope] |
| Testart und Szenario | [Art/Szenario] |
| bestätigte Ziele | [RTO/RPO/Mindestkapazität] |
| Ausgangs- und Zielumgebung | [Beschreibung] |
| Erfolgskriterien | [messbar] |
| Schutz- und Sicherheitsgrenzen | [Festlegung] |
| Rückfall/Abbruch | [Kriterien] |
| Beobachtung/Protokoll | [Rolle/Methode] |
| Freigabe | [Rollen] |
Ein Test wird nicht allein aufgrund seiner Durchführung als erfolgreich bewertet. Mindestens werden geprüft:
Produktive Tests benötigen eine gesonderte Risiko-, Change- und Rückfallplanung.
| Testobjekt | vorgeschlagener Turnus im Entwurf | Status |
|---|---|---|
| P1-Basisdienste | mindestens jährlich und nach wesentlichen Änderungen | Nicht geplant |
| P2-kritische Services | mindestens jährlich, abhängig von Risiko und Änderung | Nicht geplant |
| Backup-Komponenten-Restore | regelmäßig gemäß Backup-Konzept | Nicht geplant |
| End-to-End-Geschäftsprozess | risikoorientiert, mindestens jährlich für kritische Prozesse | Nicht geplant |
| Failover/Failback | nach Architektur, Risiko und Herstelleranforderung | Nicht geplant |
| Cloud-/Provider-Recovery | nach Kritikalität und Vertragsmöglichkeit | Nicht geplant |
| OT-/Produktionswiederanlauf | risikoorientiert und sicher geplant | Nicht geplant |
| Cyber-Recovery-Tabletop/Technik | mindestens jährlich in angemessenem Umfang | Nicht geplant |
Turnus und Umfang gelten erst nach fachlicher Freigabe. Höhere Änderungsrate, kritische Befunde oder neue Risiken können häufigere Tests erfordern.
| Kennzahl | Definition | Zielwert im Entwurf |
|---|---|---|
| Servicekatalog-Abdeckung | kritische Services mit vollständigem Katalogeintrag | [Festzulegen] |
| Runbook-Abdeckung | kritische Services mit freigegebenem Runbook | [Festzulegen] |
| Testabdeckung | fristgerecht getestete kritische Services | [Festzulegen] |
| RTO-Erreichung | Tests/Wiederanläufe innerhalb des bestätigten RTO | [Festzulegen] |
| RPO-Erreichung | Tests/Wiederanläufe innerhalb des bestätigten RPO | [Festzulegen] |
| fachliche Testfreigabe | Tests mit erfolgreicher End-to-End-Validierung | [Festzulegen] |
| überfällige kritische Befunde | kritische Maßnahmen nach Zieltermin | 0 |
| veraltete Runbooks | Runbooks außerhalb des Prüfintervalls | 0 kritische |
| ungeprüfte Abhängigkeiten | kritische Services mit offenen Vorgängern | [Festzulegen] |
| Restore-Fehlerrate | fehlgeschlagene gegenüber durchgeführten Restore-Tests | [Festzulegen] |
Messmethode, Datenquelle, Zeitraum, Ausschlüsse und fehlende Werte werden dokumentiert. Geplante oder teilweise durchgeführte Tests werden nicht als bestanden gezählt.
Für TISAX- und Kundenanforderungen werden insbesondere berücksichtigt:
Alle 46 Informationssicherheitsfragen des ISA-Reiters „Informationssicherheit“ müssen umgesetzt und bewertet werden. Es gibt keine individuelle Auswahl „anwendbar/nicht anwendbar“ wie in der ISO-Statement-of-Applicability. Wiederanlauferkenntnisse werden in allen betroffenen Fragen, Reifegraden und Maßnahmen berücksichtigt und in der VDA-ISA-Selbsteinschätzung sowie im Maßnahmenplan und Reifegrad aktualisiert.
Ein vorhandenes Runbook oder ein erfolgreicher Einzel-Restore belegt nicht automatisch einen angemessenen TISAX-Reifegrad. Umsetzung, Steuerung, Nachweise und Wirksamkeit sind im Gesamtzusammenhang zu bewerten.
| Erkenntnis/Auswirkung | Folgemaßnahme |
|---|---|
| neues/geändertes Asset oder Abhängigkeit | Asset-Inventar aktualisieren |
| Zielwert oder Geschäftskritikalität unklar | Notfallvorsorge und BCM beziehungsweise BIA aktualisieren |
| neues/geändertes Risiko | Risikoregister aktualisieren |
| Behandlung erforderlich | Risikobehandlungsplan ergänzen |
| Kontrollgestaltung geändert | Statement of Applicability prüfen |
| Sicherheitsvorfall | Incident Response einbeziehen |
| Rechts-/Vertragsanforderung | Rechts- und Vertragskataster aktualisieren |
| TISAX-Auswirkung | VDA-ISA-Selbsteinschätzung aktualisieren |
| Testabweichung/Korrektur | Abweichungen und Korrekturmaßnahmen erfassen |
| Managemententscheidung | Managementbewertung vorbereiten |
| Nachweis | Mindestinhalt | Ablage im Entwurf |
|---|---|---|
| Service- und Abhängigkeitskatalog | Owner, Ziele, Reihenfolge, Strategie und Status | [geschützter Pfad] |
| Service-Runbooks | Version, Schritte, Quellen, Tests, Rückfall und Freigabe | [geschützter Pfad/offline] |
| Backup-/Recovery-Nachweise | Sicherungsstatus, Integrität, Restore und Aufbewahrung | [geschützter Pfad] |
| Wiederanlaufprotokoll | Lage, Zeitlinie, Maßnahmen, Entscheidungen und Messwerte | [geschützter Pfad] |
| Testberichte | Scope, Ziele, Ergebnisse, RTO/RPO und Abweichungen | [geschützter Pfad] |
| Freigaben | technische, sicherheitsbezogene und fachliche Entscheidungen | [geschützter Pfad] |
| Verbesserungsmaßnahmen | Owner, Termin, Status und Wirksamkeit | [geschützter Pfad] |
Runbooks und Notfalldokumentation werden so geschützt und verteilt, dass sie im Ereignis verfügbar sind, ohne Angreifern unnötig sensible Architektur- oder Zugangsinformationen bereitzustellen.
| Prüffrage | Status Entwurf |
|---|---|
| Sind kritische Geschäftsprozesse und BCM-Ziele bestätigt? | Nein |
| Sind alle kritischen Services und Owner im Wiederanlaufkatalog erfasst? | Nein |
| Stimmen Service-RTO/RPO mit BIA und Verträgen überein? | Nein |
| Sind technische und fachliche Abhängigkeiten vollständig genug dokumentiert? | Nein |
| Sind Strategien und Recovery Points je Service festgelegt? | Nein |
| Sind Wiederherstellungsquellen geschützt, verfügbar und geprüft? | Nein |
| Sind Clean-Recovery- und Cyber-Recovery-Bedingungen festgelegt? | Nein |
| Sind Rollen, Stellvertretungen und Notfallbefugnisse freigegeben? | Nein |
| Existieren ausführbare, geschützte und offline verfügbare Runbooks? | Nein |
| Sind technische, Sicherheits- und Fachtests definiert? | Nein |
| Wurden kritische Services erfolgreich End-to-End getestet? | Nein |
| Wurden RTO und RPO bei Tests tatsächlich gemessen und erreicht? | Nein |
| Sind Failback, Rückfall und Rückkehr zum Normalbetrieb getestet? | Nein |
| Sind kritische Testbefunde geschlossen oder formal behandelt? | Nein |
| Liegen fachliche Prüfung und formale Freigabe vor? | Nein |
Der Status darf erst auf „freigegeben“ oder „getestet“ gesetzt werden, wenn der konkrete Umfang, die Messergebnisse, Abweichungen und Freigaben dies nachweisbar tragen.
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Musterverfahren und Runbook-Rahmen für den Wiederanlauf erstellt | IT-/ITSCM-Verantwortliche/r | Ausstehend | – |
Maßgeblich bleiben die aktuellen Normfassungen, bestätigten BIA- und Vertragsanforderungen, Hersteller- und Providerangaben sowie die freigegebenen technischen und organisatorischen Runbooks. Dieses Muster ersetzt keine konkrete Wiederanlaufplanung für die tatsächlich eingesetzten Systeme, Anlagen und Dienste.