¶ Backup-, Restore- und Wiederanlauftests
Beispieldokument: Diese Seite beschreibt eine Test- und Nachweisstruktur für die fiktive „Muster GmbH“. Die Mustereinträge bestätigen weder vollständige Sicherungen noch erfolgreiche Restores, eingehaltene RTO-/RPO-Ziele, funktionsfähige Wiederanlaufpläne oder wirksame Notfallvorsorge.
Nachweisgrundsatz: Ein erfolgreicher Sicherungsjob, ein lesbares Medium oder ein gestartetes System ist noch kein vollständiger Wiederherstellungsnachweis. Abhängig vom Testziel müssen Integrität, Konsistenz, Sicherheitszustand, Schnittstellen, fachliche Nutzbarkeit, RTO, RPO und Rückkehr zum vorgesehenen Betrieb praktisch geprüft werden.
Schutzregel: Backup-Kataloge, Wiederherstellungswege, Schlüsselreferenzen, Netzpläne, Systemkonfigurationen, Testdaten und technische Protokolle können hochsensible Informationen enthalten. Originale verbleiben in einer geschützten, auch im Notfall erreichbaren Ablage.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-NW-07-05 |
| Dokumentenart | Nachweisverfahren für Backup-, Restore- und Wiederanlauftests |
| Wiki.js-Pfad | /ISMS/07-Nachweise/Backup-Restore-und-Wiederanlauftests |
| Verantwortlich | IT-Leitung, Backup-Administration und BCM-/Notfallverantwortung |
| Fachlich geprüft durch | Service-/System Owner, Informationssicherheit, Datenschutz, Fachbereiche, ISMS, Audit/QM, Lieferantenmanagement und TISAX-Koordination |
| Freigabe durch | Geschäftsführung beziehungsweise festgelegte befugte Notfall- oder Serviceverantwortung |
| Status | Entwurf – keine realen Restore- oder Wiederanlauftests nachgewiesen |
| Version | 0.1 |
| Stand | 08.08.2026 |
| Gültig ab | Nach fachlicher Prüfung und Freigabe |
| Nächste Prüfung | Nach freigegebenem risikobasiertem Testkalender sowie bei wesentlichen Änderungen, Vorfällen oder fehlgeschlagenen Tests |
| Schutzklasse | Vertraulich; technische Detailnachweise regelmäßig streng vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Kapitel 6, 7.5, 8.1, 9 und 10 sowie Annex A 5.29, 5.30, 8.13 und 8.14 |
| TISAX-Bezug | Maßgebliche ISA-Fassung und zugeordnete Kontrollfragen zu Datensicherung, Wiederherstellung, Betrieb, Notfallvorsorge und Nachweisen |
| Weitere Bezüge | NIS2-Umsetzung, Datenschutz, Verträge, Kundenanforderungen, BIA, BCM, ITSCM und Prototypenschutz, soweit anwendbar |
Testkette von Scope, Szenario und Wiederherstellung über technische und fachliche Abnahme bis zur RTO-/RPO-Bewertung und Nachverfolgung. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Zweck
Dieses Verfahren steuert die Planung, Durchführung, Auswertung und Nachweisführung von Backup-, Restore- und Wiederanlauftests. Es soll sicherstellen, dass:
- Tests aus Risiken, Schutzbedarf, BIA, RTO, RPO und Anforderungen abgeleitet werden,
- Testart, Scope, Szenario und Aussagegrenzen vorab feststehen,
- Wiederherstellungsquellen vollständig und vertrauenswürdig ausgewählt werden,
- technische Wiederherstellung reproduzierbar protokolliert wird,
- Daten, Anwendungen, Schnittstellen und Sicherheitskontrollen geprüft werden,
- Fachbereiche die Nutzbarkeit und das benötigte Mindestbetriebsniveau abnehmen,
- gemessene Zeiten und Datenverluste gegen bestätigte Ziele bewertet werden,
- Abweichungen behandelt und in einem erneuten Test verifiziert werden.
Die Seite ersetzt weder Sicherungskonzept, Backup-System, BIA, Wiederanlaufplan, Service-Runbook noch die geschützten Originalprotokolle.
¶ 2. Geltungsbereich
Der reale Test-Scope kann umfassen:
- Dateien, Datenbanken, Anwendungen und virtuelle Systeme,
- Betriebssysteme, Konfigurationen, Images, Code und Infrastrukturdefinitionen,
- Verzeichnisdienste, Identitäten, Zertifikate, Schlüssel- und Geheimnisabhängigkeiten,
- Netzwerk-, Sicherheits-, Monitoring- und Kommunikationsdienste,
- Cloud-, SaaS-, Hosting- und Managed-Service-Daten,
- OT-, Produktions-, Labor- und Legacy-Systeme,
- mobile Geräte und dezentrale Arbeitsplätze,
- Dokumentation, Protokolle und Notfallunterlagen,
- technische Services sowie abhängige Geschäftsprozesse und Lieferanten.
Nicht getestete Komponenten oder Abhängigkeiten werden ausdrücklich als Scope-Grenze dokumentiert.
¶ 3. Begriffe und Aussagegrenzen
| Begriff | Bedeutung | Aussagegrenze |
|---|---|---|
| Backup | erzeugte Sicherungskopie oder Sicherungsstand | keine automatische Wiederherstellbarkeit |
| Integritätsprüfung | technische Prüfung auf Lesbarkeit oder unveränderten Zustand | keine vollständige Servicefunktion |
| Restore | Rücksicherung definierter Daten, Systeme oder Konfigurationen | kann ohne Fachfunktion enden |
| Recovery Point | tatsächlich gewählter Sicherungszeitpunkt oder Stand | neuester Stand ist nicht zwingend vertrauenswürdig |
| Wiederanlauf | Wiederherstellung eines Services oder Geschäftsprozesses einschließlich Abhängigkeiten | gilt nur für den getesteten Scope und das Szenario |
| RPO | höchstens tolerierter Datenverlust in der Zeitbetrachtung | wird am tatsächlichen Datenstand bewertet |
| RTO | bestätigte Zielzeit bis zum festgelegten Wiederanlaufzustand | Messbeginn und Endkriterium müssen definiert sein |
| MTPD/MTPDO | maximal tolerierbare Unterbrechungsdauer | darf nicht mit technischem RTO gleichgesetzt werden |
| Clean Recovery | Wiederaufbau in vertrauenswürdiger Umgebung nach Kompromittierungsverdacht | erfordert zusätzliche Sicherheitsprüfung |
| Failover | Umschaltung auf vorbereitete Alternative | beweist nicht automatisch Restore aus Backup |
¶ 4. Testarten
| Testart | Hauptaussage | Grenze |
|---|---|---|
| Job-/Katalogkontrolle | vorgesehener Sicherungslauf wurde technisch verarbeitet | Dateninhalt und Restore nicht belegt |
| Lesbarkeits-/Integritätstest | Sicherungsobjekt ist lesbar beziehungsweise technisch konsistent | keine vollständige Wiederherstellung |
| Datei-/Objekt-Restore | einzelnes Objekt kann zurückgesichert werden | keine Anwendungs- oder Prozesskonsistenz |
| Datenbank-Restore | Datenbank kann konsistent geöffnet und geprüft werden | abhängige Dienste können fehlen |
| Konfigurations-Restore | Gerät oder Dienst kann rekonfiguriert werden | Hardware, Schlüssel und Schnittstellen können fehlen |
| System-/VM-Restore | System kann wiederhergestellt und gestartet werden | End-to-End-Geschäftsfunktion nicht belegt |
| Service-Restore | Dienst mit wesentlichen Komponenten funktioniert | abhängiger Geschäftsprozess eventuell nicht vollständig |
| End-to-End-Wiederanlauf | technische und fachliche Leistung einschließlich Abhängigkeiten wird geprüft | gilt für dokumentiertes Szenario |
| Clean-Recovery-Test | vertrauenswürdiger Neuaufbau nach Cyberlage wird geprobt | hoher Aufwand; Vorfallforensik nicht ersetzt |
| Provider-/Exit-Test | Daten und Konfigurationen können exportiert und weiterverwendet werden | vollständiger Anbieterersatz eventuell nicht belegt |
Ein niedrigerer Testtyp wird nicht als höherwertiger Wiederanlauftest dargestellt.
¶ 5. Risikobasierter Testkalender
Testart und Turnus werden aus Kritikalität, Änderungsrate, Technik, Datenvolumen, bisherigen Fehlern, Wiederherstellungszielen, Bedrohungslage, Kunden- und Vertragsanforderungen abgeleitet.
| Test | Beispielrhythmus zur Freigabe | Status |
|---|---|---|
| Job- und Integritätskontrolle | nach jedem vorgesehenen Lauf | Nicht freigegeben |
| Datei-/Objekt-Restore-Stichprobe | monatlich mit wechselndem Scope | Nicht freigegeben |
| Komponenten-/Datenbank-Restore | vierteljährlich bei kritischen Systemen | Nicht freigegeben |
| vollständiger Service-Restore | mindestens jährlich oder nach wesentlicher Änderung | Nicht freigegeben |
| End-to-End-Wiederanlauf | nach BCM-Testkalender | Nicht freigegeben |
| Clean-Recovery-/Ransomware-Szenario | risikobasiert | Nicht freigegeben |
| Provider-Export und Wiederverwendung | risikobasiert und vor kritischer Bindung | Nicht freigegeben |
Die Werte sind Muster und keine pauschalen ISO- oder TISAX-Fristen.
¶ 6. Rollen und Verantwortlichkeiten
| Rolle | Aufgabe |
|---|---|
| Geschäftsführung/BCM-Lenkung | kritische Ziele, Ressourcen und wesentliche Restrisiken entscheiden |
| BCM-/Notfallverantwortung | BIA, Szenario, RTO/RPO, Testkalender und Wiederanlaufabnahme koordinieren |
| Service Owner | Serviceumfang, Abhängigkeiten, fachliche Kriterien und Gesamtfreigabe verantworten |
| System-/Application Owner | Sicherungsobjekte, Konsistenz, Runbooks und technische Abnahme steuern |
| Backup-Administration | Sicherungen, Kataloge, Restore und technische Nachweise bereitstellen |
| Informationssicherheit | Isolation, Vertrauenswürdigkeit, Härtung, Identitäten, Logging und Freigabebedingungen prüfen |
| Fachbereich | Datenstand, Prozessfunktion, Nacherfassung und fachliche Nutzbarkeit abnehmen |
| Datenschutz | Testdaten, Löschung, Berichtigung, Zugriff und Bereinigung prüfen |
| Lieferantenmanagement | Providerpflichten, Unterstützung, Exit und Nachweise koordinieren |
| Audit/QM | Testdesign, Protokoll, Aussagegrenzen und Maßnahmen unabhängig prüfen |
Durchführende und abnehmende Rollen werden für kritische Tests angemessen getrennt.
¶ 7. Testauftrag
| Feld | Mindestinhalt |
|---|---|
| Test-ID | dauerhaft eindeutige Referenz, zum Beispiel REC-TEST-JJJJ-NNN |
| Anlass | Kalender, Änderung, Risiko, Vorfall, Audit, Vertrag oder Providerwechsel |
| Testart | Integrität, Objekt-, System-, Service-, End-to-End- oder Clean-Recovery-Test |
| Scope | Daten, Systeme, Service, Standorte, Abhängigkeiten und ausdrücklich ausgeschlossene Teile |
| Szenario | angenommener Schaden, Ausfall oder Kompromittierungsverdacht |
| Ziele | bestätigte RTO, RPO, Mindestbetriebsniveau und weitere Abnahmekriterien |
| Recovery Point | Auswahlregel und erwarteter Datenstand |
| Zielumgebung | isoliert, Test, Ersatz, Notbetrieb oder produktiv |
| Rollen | Leitung, Durchführung, Sicherheit, Fachabnahme, Protokoll und Beobachtung |
| Risiken | Produktivwirkung, Datenschutz, Testdaten, Beweiserhalt und Rückfall |
| Zeitfenster | Beginn, Abbruchpunkt, Rückbau und maximale Belastung |
| Nachweise | erwartete Protokolle, Messwerte, Screenshots, Berichte und Freigaben |
¶ 8. Eingaben und Voraussetzungen
Vor Testbeginn werden mindestens geprüft:
- freigegebener Service- und Test-Scope,
- Asset-, Daten- und Abhängigkeitsinventar,
- bestätigte oder ausdrücklich offene RTO-/RPO-Werte,
- Sicherungs- und Wiederherstellungsregister,
- aktuelle Runbooks und Kontaktlisten,
- Zugriff auf Backup-System, Katalog, Zielumgebung und Werkzeuge,
- Verfügbarkeit von Schlüsseln, Zertifikaten, Geheimnissen und Lizenzen,
- freie Kapazität, Netzwerk, Namensauflösung und Basisdienste,
- sichere Testdaten und Bereinigungsverfahren,
- Rückfall-, Abbruch- und Eskalationsregeln.
Fehlende Voraussetzungen werden nicht durch Annahmen verdeckt. Der Test kann mit dokumentierter Einschränkung fortgeführt oder abgebrochen werden.
¶ 9. Auswahl des Wiederherstellungspunkts
Der gewählte Recovery Point wird anhand von Ziel, Vertrauenswürdigkeit und fachlichen Bindungen bestimmt.
| Prüffeld | Dokumentation |
|---|---|
| technisch verfügbare Stände | Zeitpunkte, Versionen und Sicherungsketten |
| erwarteter RPO | bestätigter Wert oder offener Status |
| tatsächlicher Datenstand | Zeitstempel und enthaltene Transaktionen |
| Konsistenzpunkt | Anwendung, Datenbank, Dateisystem und abhängige Systeme |
| Vertrauenswürdigkeit | Malware-, Manipulations- und Korruptionsprüfung |
| Rechts-/Fachbindung | Aufbewahrung, Abschluss, Sperren, Löschung und Nacherfassung |
| Auswahlentscheidung | Rolle, Zeitpunkt, Begründung und Freigabe |
Der neueste Sicherungsstand ist nicht automatisch der geeignete Stand, wenn Fehler oder Kompromittierungen bereits enthalten sein können.
¶ 10. Testumgebung und Isolation
Die Zielumgebung wird so gestaltet, dass der Test weder Produktion noch Beweise, Kundeninformationen oder andere Systeme unkontrolliert beeinflusst. Geprüft werden:
- Netzwerk- und Mandantentrennung,
- Identitäten, Rollen und privilegierte Zugänge,
- ausgehende Kommunikation, E-Mail und Schnittstellen,
- Schutz von Testdaten und Protokollen,
- Monitoring und Ereigniserfassung,
- Namens-, Adress- und Zertifikatskonflikte,
- Rückbau, Löschung und Freigabe der Umgebung.
Produktivrestores benötigen eine gesonderte Autorisierung und ein geeignetes Rückfallverfahren.
¶ 11. Durchführungsprotokoll und Zeitlinie
Während des Tests werden in einer einheitlichen Zeitlinie dokumentiert:
| Ereignis | Mindestinhalt |
|---|---|
| Start | autorisierte Startzeit, Testleitung und Ausgangszustand |
| Freigaben | Entscheidung, Rolle und Zeitpunkt |
| Bereitstellung | Infrastruktur, Zugänge, Medien, Katalog und Werkzeuge |
| Restore-Schritte | Runbook-Schritt, Beginn, Ende, Ergebnis und Abweichung |
| Entscheidungen | Auswahl, Änderung, Abbruch, Eskalation und Begründung |
| Prüfungen | technische, Sicherheits- und fachliche Kriterien mit Ergebnis |
| Zielzustand | Zeitpunkt des erreichten Mindestbetriebs oder Servicezustands |
| Rückbau | Bereinigung, Löschung, Rückkehr und Abschlusszeitpunkt |
Pauschale Aussagen wie „Restore erfolgreich“ ersetzen keine prüfbare Zeitlinie.
¶ 12. Technische Wiederherstellungsprüfung
Mindestens geprüft werden, soweit relevant:
- Vollständigkeit der Sicherungskette und benötigten Medien,
- Lesbarkeit und Integrität von Daten und Metadaten,
- Dateisystem-, Datenbank- und Anwendungskonsistenz,
- Betriebssystem, Konfiguration, Images und Infrastrukturdefinitionen,
- Startfähigkeit und stabile Laufzeit,
- Netzwerk, DNS, Zeit, Identitäten und Authentisierung,
- Schlüssel, Zertifikate, Lizenzen und Geheimnisse,
- Monitoring, Logging, Backup und Sicherheitswerkzeuge,
- Fehler, Warnungen, manuelle Schritte und nicht dokumentierte Abhängigkeiten.
¶ 13. Sicherheitsprüfung und Clean Recovery
Vor einer Freigabe wird geprüft, ob die wiederhergestellte Umgebung vertrauenswürdig ist. Dies umfasst abhängig vom Szenario:
- zeitliche Einordnung von Angriff, Fehler oder Manipulation,
- Prüfung von Recovery Point und Images auf bekannte Indikatoren,
- sichere Identitäten, neue Geheimnisse und widerrufene Zugänge,
- aktuelle Härtung, Patches und Konfigurationen,
- aktive Schutz-, Logging- und Monitoringfunktionen,
- Behandlung bekannter Schwachstellen und Persistenzmechanismen,
- Schutz forensischer Beweise und Abstimmung mit Incident Response,
- kontrollierte Verbindung zu noch sauberen oder produktiven Systemen.
Das Einspielen eines Backups beendet keinen Cybervorfall. Die Seite Incident Response bleibt führend für Vorfallbehandlung und Beweissicherung.
¶ 14. Schnittstellen und Abhängigkeiten
Ein Service-Restore prüft nicht nur den Hauptserver. Abhängig vom Scope werden einbezogen:
- Identitäts- und Verzeichnisdienste,
- DNS, Zeit, Netzwerk, Firewall und Load Balancer,
- Datenbanken, Queues, Dateispeicher und APIs,
- Zertifikate, Schlüssel und Geheimnisverwaltung,
- Monitoring, Logging und Alarmierung,
- E-Mail, Druck, Export, Import und Datenaustausch,
- externe Provider, Lieferanten und Kundenverbindungen,
- OT-, Produktions- und Standortabhängigkeiten,
- manuelle Ersatzverfahren und notwendige Personalrollen.
Nicht getestete Abhängigkeiten werden in der Ergebnisgrenze ausdrücklich genannt.
¶ 15. Fachliche Abnahme
Der Fachbereich oder Service Owner prüft anhand vorab festgelegter Kriterien:
- richtiger Datenstand und nachvollziehbarer Datenverlust,
- fachliche Vollständigkeit und Konsistenz,
- kritische Transaktionen und Kernfunktionen,
- Berechtigungen und Funktionstrennung,
- Berichte, Dokumente, Schnittstellen und Exporte,
- notwendige Nacherfassung oder Abstimmung,
- Mindestbetriebsniveau und zulässige Einschränkungen,
- Rechts-, Kunden-, Datenschutz- und Vertragsanforderungen.
Eine technische Startmeldung ersetzt keine fachliche Abnahme.
¶ 16. RTO-Bewertung
Messbeginn und Zielzustand werden vorab festgelegt. Bei einem vollständigen Service-Wiederanlauf kann die gemessene Zeit insbesondere umfassen:
- Erkennung, Entscheidung und Aktivierung,
- Bereitstellung von Personal, Infrastruktur und Zugängen,
- Auswahl und Freigabe des Recovery Points,
- eigentliche Rücksicherung,
- Konsistenz- und Sicherheitsprüfung,
- Wiederherstellung abhängiger Dienste und Schnittstellen,
- fachliche Abnahme und Betriebsfreigabe.
Eine reine Kopier- oder Restore-Dauer wird nicht als End-to-End-RTO ausgewiesen.
¶ 17. RPO-Bewertung
Das RPO wird am tatsächlich wiederhergestellten Datenstand und der erforderlichen Nacherfassung bewertet. Dokumentiert werden:
- Zeitpunkt des Schadens- oder Testereignisses,
- Zeitpunkt des gewählten Recovery Points,
- fehlende oder erneut zu erfassende Daten,
- Inkonsistenzen zwischen abhängigen Systemen,
- fachliche, rechtliche oder vertragliche Auswirkungen,
- Vergleich mit dem bestätigten RPO.
Das geplante Sicherungsintervall allein beweist keine RPO-Einhaltung.
¶ 18. Cloud-, SaaS- und Provider-Tests
Für externe Leistungen wird geklärt:
- was der Provider tatsächlich sichert und wiederherstellt,
- welche Daten, Metadaten, Konfigurationen und Protokolle enthalten sind,
- welche Ziele zugesagt und praktisch nachweisbar sind,
- wie Restore, Export, Exit und Unterstützung ausgelöst werden,
- welche eigenen Identitäten, Schlüssel, Netze und Fachprüfungen erforderlich bleiben,
- welche Nachweise und Auditrechte vertraglich bestehen,
- wie Daten nach Test oder Vertragsende bereinigt werden.
Ein Providerzertifikat oder eine Statusseite ersetzt keinen eigenen Nachweis für die konkret genutzte Leistung.
¶ 19. OT-, Produktions- und Legacy-Systeme
Zusätzlich berücksichtigt werden:
- sichere Betriebszustände und Auswirkungen auf Menschen, Anlagen und Umwelt,
- Herstellerunterstützung und Spezialhardware,
- Firmware, Programme, Parameter, Rezepte und Kalibrierungen,
- lokale oder offline geführte Sicherungen,
- verfügbare Ersatzgeräte und Wiederaufbauzeiten,
- Netzwerk-, Sicherheits- und Freigabestufen,
- Produkt-, Prozess- und Datenintegrität,
- kontrollierte Tests außerhalb kritischer Produktionsfenster.
Ein technisch eingeschränkter Test wird mit Grenze und Kompensationsmaßnahme dokumentiert, nicht als vollständiger Wiederanlauf ausgegeben.
¶ 20. Datenschutz und Testdaten
Bei Test-Restores werden Zweck, Rechtsgrundlage, Datenminimierung, Zugriff, Isolation, Protokollierung, Aufbewahrung und Löschung berücksichtigt. Soweit möglich werden minimierte, pseudonymisierte oder synthetische Daten verwendet.
Wiederhergestellte Daten dürfen:
- nicht unkontrolliert an produktive Schnittstellen gesendet werden,
- keine rechtmäßig gelöschten oder gesperrten Daten unzulässig reaktivieren,
- nicht länger als für Test und Nachweis erforderlich verbleiben,
- nur befugten Rollen zugänglich sein.
Die Bereinigung der Testumgebung ist Bestandteil des Testabschlusses.
¶ 21. Ergebnis- und Statusmodell
| Status | Eintrittskriterium |
|---|---|
| Benötigt | Testbedarf wurde identifiziert, aber nicht geplant |
| Geplant | Scope, Termin, Rollen und Kriterien sind vorgesehen; Durchführung fehlt |
| Durchgeführt | Testaktivitäten wurden ausgeführt; Bewertung kann noch offen sein |
| Teilweise bestanden | definierte Kriterien wurden nur teilweise erreicht; Abweichungen bleiben |
| Nicht bestanden | wesentliches Testziel wurde nicht erreicht oder ist nicht bewertbar |
| Bestanden | alle für den dokumentierten Scope freigegebenen Kriterien wurden erreicht und abgenommen |
| Nachprüfung offen | Korrekturen sind umgesetzt, aber noch nicht erneut praktisch geprüft |
| Wirksam bestätigt | Behandlung wurde in geeignetem Wiederholungstest erfolgreich verifiziert |
Ein Test mit ungeklärter Grundgesamtheit, fehlender Fachabnahme oder offenen kritischen Befunden wird nicht als Bestanden gekennzeichnet.
¶ 22. Abweichungen und Wiederholung
Feststellungen erhalten mindestens:
- Test- und Befund-ID,
- betroffenen Service, Prozess oder Sicherungsstand,
- beobachtetes Ergebnis und erwartetes Kriterium,
- Auswirkung auf RTO, RPO, Integrität, Sicherheit oder Fachfunktion,
- Ursache beziehungsweise Ursachenanalyse,
- Priorität, Owner und Termin,
- Korrektur- und Verbesserungsmaßnahme,
- erwarteten Nachweis und Wiederholungstest.
Maßnahmen werden im Maßnahmen- und Umsetzungsregister gesteuert. Dokumentkorrekturen allein bestätigen keine wiederhergestellte Fähigkeit.
¶ 23. Nachweispaket
| Nachweis | Mindestinhalt | Schutz |
|---|---|---|
| Testauftrag | ID, Scope, Szenario, Ziele, Rollen und Grenzen | Vertraulich |
| Sicherungsreferenz | Backup-ID, Kette, Recovery Point, Katalog und Integritätsangaben | Streng vertraulich |
| Zeitlinie | Schritte, Zeitpunkte, Entscheidungen, Fehler und Eskalationen | Streng vertraulich |
| technische Ergebnisse | Restore, Konsistenz, Konfiguration, Schnittstellen und Messwerte | Streng vertraulich |
| Sicherheitsprüfung | Vertrauenswürdigkeit, Härtung, Identitäten, Logging und Freigabe | Streng vertraulich |
| Fachabnahme | Datenstand, Prozessfunktion, Mindestbetrieb und Einschränkungen | Vertraulich |
| RTO-/RPO-Auswertung | bestätigte Ziele, Messung, Ergebnis und Abweichung | Vertraulich |
| Befund- und Maßnahmenliste | Ursache, Priorität, Owner, Termin und Wiederholung | Vertraulich |
| Abschlussbericht | Gesamturteil, Scope-Grenzen, offene Punkte und Freigaben | Vertraulich |
Kontrollierte Referenzen werden im Nachweisregister geführt; Zugangsdaten, Schlüssel und technische Detailoriginale werden dort nicht eingebettet.
¶ 24. Musterregister ohne positive Nachweisbehauptung
| Test-ID | Service-/Systemklasse | Testart | RTO/RPO | letzter Test | Ergebnis | Wiederholung | Status |
|---|---|---|---|---|---|---|---|
| REC-TEST-2026-001 | kritischer Dateidienst | Datei- und Service-Restore | Nicht bestätigt | Nicht durchgeführt | Nicht bewertbar | Nicht geplant | Benötigt |
| REC-TEST-2026-002 | zentrale Datenbank | Datenbank- und Anwendungsrestore | Nicht bestätigt | Nicht durchgeführt | Nicht bewertbar | Nicht geplant | Benötigt |
| REC-TEST-2026-003 | Identitätsdienst | System- und Service-Restore | Nicht bestätigt | Nicht durchgeführt | Nicht bewertbar | Nicht geplant | Benötigt |
| REC-TEST-2026-004 | Cloud-/SaaS-Dienst | Export- und Wiederverwendungstest | Nicht bestätigt | Nicht durchgeführt | Nicht bewertbar | Nicht geplant | Benötigt |
| REC-TEST-2026-005 | kritischer Geschäftsprozess | End-to-End-Wiederanlauf | Nicht bestätigt | Nicht durchgeführt | Nicht bewertbar | Nicht geplant | Benötigt |
Die Einträge sind offene Musterbedarfe und keine realen Testnachweise.
¶ 25. Kennzahlen und Aussagegrenzen
| Kennzahl | Berechnung | Aussagegrenze |
|---|---|---|
| Testabdeckung | fristgerecht geprüfte / fällige Services oder Systeme | nur mit bestätigter Grundgesamtheit belastbar |
| vollständig bestandene Tests | bestandene / bewertbare Tests | Testarten und Scope getrennt berichten |
| RTO-Erreichung | Tests innerhalb bestätigter RTO / bewertbare Tests | Endkriterium und Messumfang angeben |
| RPO-Erreichung | Tests innerhalb bestätigter RPO / bewertbare Tests | tatsächlichen Datenstand verwenden |
| fachlich abgenommene Tests | fachlich abgenommene / durchgeführte Tests | technische Tests ohne Fachbezug getrennt ausweisen |
| offene kritische Befunde | offene Befunde nach Kritikalität und Alter | Vollständigkeit der Feststellungserfassung beachten |
| Wiederholungserfolg | erfolgreich wiederholte / fällige Nachprüfungen | bezieht sich auf behandelte Lücken |
| Alter letzter geeigneter Test | Zeit seit letztem Test je Service und Testart | einfacher Dateirestore kann ungeeignet sein |
Eine hohe Backup-Jobquote wird nicht als Wiederherstellungs- oder Wiederanlauffähigkeit berichtet.
¶ 26. Audit- und Assessmentprüfung
Vor Bereitstellung wird geprüft:
- Passt der Test-Scope zum ISMS-, Service- und Assessment-Scope?
- Sind RTO, RPO, Mindestbetrieb und Kriterien bestätigt oder klar als offen markiert?
- Ist der verwendete Recovery Point eindeutig und vertrauenswürdig?
- Sind Zeitlinie, technische Prüfung, Sicherheitsprüfung und Fachabnahme nachvollziehbar?
- Wurden Abhängigkeiten und Scope-Grenzen offengelegt?
- Sind Messwerte reproduzierbar und Aussagegrenzen korrekt?
- Wurden Abweichungen, Maßnahmen und Wiederholungstests nachverfolgt?
- Sind technische und personenbezogene Originale angemessen geschützt?
Ein Bericht ohne prüfbare Originalreferenzen genügt nicht als belastbarer Wirksamkeitsnachweis.
¶ 27. Aktueller Entwurfsstatus
| Prüffrage | Status |
|---|---|
| Sind backup-pflichtige Assets und kritische Services vollständig bestätigt? | Nein |
| Sind RTO, RPO und Mindestbetriebsniveaus freigegeben? | Nein |
| Ist der Testkalender organisationsbezogen freigegeben? | Nein |
| Sind reale Restore- und Wiederanlauftests referenziert? | Nein |
| Sind technische und fachliche Abnahmen nachgewiesen? | Nein |
| Wurden Abweichungen praktisch nachgetestet? | Nein |
| Wurde die Nachweisstruktur intern auditiert? | Nein |
Der Musterbestand erlaubt keine positive Aussage über Wiederherstellungs- oder Wiederanlauffähigkeit.
¶ 28. Mitgeltende Seiten
| Thema | Führende Seite |
|---|---|
| Sicherungs- und Restoreverfahren | Datensicherung und Wiederherstellung |
| BCM und Business Impact | Notfallvorsorge und BCM |
| Wiederanlaufprozess und Runbooks | Wiederanlaufplanung |
| Cybervorfälle und Clean Recovery | Incident Response |
| Assets und Services | Asset-Inventar |
| externe Leistungen | Lieferanten und Dienstleister |
| Kryptografie und Schlüssel | Kryptografie und Schlüssel |
| führendes Nachweisregister | Nachweisregister |
| Maßnahmensteuerung | Maßnahmen- und Umsetzungsregister |
| Auditprüfung | Interne Audits |
¶ 29. Weiterführende Informationen von SMCT MANAGEMENT
Unterstützung bei ISO 27001, TISAX, BCM, Notfallvorsorge, Auditvorbereitung und belastbarer Nachweisführung
- ISO-27001-Beratung und Auditvorbereitung
- SMCT MANAGEMENT – Managementberatung mit System
- Erstgespräch unter info@smct-management.de vereinbaren
¶ 30. Offene Punkte vor Freigabe
- reale kritische Services, Assets, Daten und Abhängigkeiten bestätigen,
- BIA, RTO, RPO und Mindestbetriebsniveaus freigeben,
- Sicherungs- und Wiederherstellungsregister vervollständigen,
- risikobasierten Testkalender und Auswahlverfahren festlegen,
- Service-Runbooks, Rollen, Vertretungen und Eskalationen prüfen,
- isolierte Testumgebung, Schlüsselzugriff und Notfallablage praktisch testen,
- technische, Sicherheits- und Fachabnahmekriterien freigeben,
- Pilot-Restore und End-to-End-Test durchführen,
- Abweichungen behandeln und im Wiederholungstest verifizieren,
- fachliche Prüfung und formale Freigabe dokumentieren.
¶ 31. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 08.08.2026 | Erste Fassung für Testplanung, Recovery Point, Restore, technische und fachliche Abnahme, RTO-/RPO-Bewertung, Befunde und Wiederholung | IT-Leitung / BCM-/Notfallverantwortung | Ausstehend | – |
¶ 32. Quellen und fachliche Grundlagen
- BSI-Standard 200-4 – Business Continuity Management
- BSI – Tests und Übungen durchführen und auswerten
- ISO – ISO/IEC 27001 Information security management systems
- ENX – TISAX Downloads und ISA
- SMCT MANAGEMENT – ISO-27001-Beratung
Vor der betrieblichen Nutzung sind die tatsächlich anwendbaren Norm-, ISA-, Rechts-, Vertrags-, Kunden- und Beteiligungsanforderungen sowie die realen Service- und Wiederherstellungsziele zu bestätigen. Lizenzierte Norm- und ISA-Texte bleiben die führenden Quellen und werden nicht in dieser Wiki-Seite reproduziert.