Version 1.2 · Quellenstand: 1. November 2026. Die Standangabe bezeichnet die Quellenpflege und keine Fach-, Rechts- oder Nutzungsfreigabe.
Zweck
Dieses Protokoll hilft Schweizer KMU, einen Wiederherstellungstest als ĂŒberprĂŒfbaren Ablauf zu planen, durchzufĂŒhren und nachzubereiten. Es dokumentiert nicht nur, ob eine Sicherung technisch lesbar ist, sondern ob ein klar bestimmter kritischer GeschĂ€ftsprozess mit sauberen Systemen, einem ausreichenden Datenstand und innerhalb des vereinbarten Zeitrahmens wieder betrieben werden kann.
Die Vorlage stĂŒtzt sich auf die BACS-Phasen Vorbereitung, VorfallsbewĂ€ltigung und Nachbearbeitung sowie auf die Empfehlung, Backups in einem Disaster-Recovery-Szenario auf VerfĂŒgbarkeit und IntegritĂ€t zu testen.[1] [2] Sie ist kein Zertifikat und keine Garantie, dass eine Wiederherstellung in jedem Cybervorfall gelingt.
Anwendung
FĂŒllen Sie die Felder vor dem Test gemeinsam mit IT, Prozessverantwortung und der zustĂ€ndigen FĂŒhrungsperson aus. FĂŒhren Sie den Test nur in einer freigegebenen, vom angenommen kompromittierten Bereich getrennten Umgebung durch. Halten Sie Zeiten, Entscheidungen und Abweichungen unmittelbar fest. Schliessen Sie den Ablauf erst nach Debriefing, Massnahmenplanung und einem Nachtest kritischer Befunde ab.
Wichtige Grenze: Dieses Arbeitsmittel simuliert einen Vorfall. Es darf keine produktiven Daten verschlĂŒsseln, keine Schadsoftware einsetzen und keine Wiederanlaufmassnahmen in der Produktivumgebung auslösen, wenn dies nicht ausdrĂŒcklich freigegeben und risikogerecht abgesichert ist.
1. Testauftrag und Freigabe
| Feld | Eintrag |
|---|---|
| Organisation / Bereich | |
| Testbezeichnung / Version | |
| Testdatum | |
| Geplanter Zeitrahmen | |
| Testleitung | |
| Auftraggebende FĂŒhrungsperson | |
| Freigabe fĂŒr DurchfĂŒhrung erteilt durch / Datum | |
| ProtokollfĂŒhrung | |
| Testtyp | â Tabletop â Technischer Teiltest â End-to-End-Restore-Test â Nachtest |
| Testumgebung | |
| Abbruchkriterien | |
| Besonderer Schutzbedarf / EinschrÀnkungen |
Testszenario
| PrĂŒfpunkt | Eintrag |
|---|---|
| Angenommener Auslöser und Zeitpunkt | |
| Als kompromittiert angenommene Systeme / Datenbereiche | |
| AusdrĂŒcklich nicht betroffene Systeme | |
| Priorisierter GeschÀftsprozess | |
| Mindestfunktion nach Wiederanlauf | |
| Zugelassene Behelfsprozesse | |
| Angenommene AusfÀlle von ZugÀngen, Lieferanten oder Schnittstellen | |
| Wiederherstellungsquelle / Sicherungssatz | |
| Referenzzeitpunkt fĂŒr Datenstand |
2. GeschÀftsprozess und Ziele
Begriffshilfe: Das RTO (Recovery Time Objective) ist die maximal akzeptierte Zeit bis zur vereinbarten Mindestfunktion des GeschÀftsprozesses. Das RPO (Recovery Point Objective) ist der maximal vertretbare Datenverlust, als Zeitspanne gemessen. Ziele werden von der Organisation festgelegt; sie sind keine Eigenschaft eines Backup-Produkts.
| PrĂŒfpunkt | Sollwert / Festlegung | Istwert / Ergebnis | ErfĂŒllt? |
|---|---|---|---|
| Prozessverantwortliche Person | â Ja â Nein | ||
| RTO: Messstart | â Ja â Nein | ||
| RTO: Zielzeitpunkt / zulĂ€ssige Dauer | â Ja â Nein | ||
| RTO: tatsĂ€chlicher Zeitpunkt fachlicher Abnahme | â Ja â Nein | ||
| RPO: maximal zulĂ€ssige DatenlĂŒcke | â Ja â Nein | ||
| RPO: Zeitstempel wiederhergestellter Daten | â Ja â Nein | ||
| Fachliches Abnahmekriterium | â Ja â Nein | ||
| Notwendiger Behelfsprozess bis Wiederanlauf | â Ja â Nein |
AbhÀngigkeiten und Wiederanlaufreihenfolge
| Nr. | AbhÀngigkeit / System / Dienstleister | Verantwortliche Person | Reihenfolge | Vorbedingung / Freigabe | Ergebnis |
|---|---|---|---|---|---|
| 1 | â OK â Abweichung | ||||
| 2 | â OK â Abweichung | ||||
| 3 | â OK â Abweichung | ||||
| 4 | â OK â Abweichung | ||||
| 5 | â OK â Abweichung | ||||
| 6 | â OK â Abweichung |
3. Rollen, Kommunikation und Unterlagen
| Rolle | Name | Stellvertretung | Erreichbarkeit / Zugangsweg geprĂŒft? | Ergebnis |
|---|---|---|---|---|
| Testleitung | â Ja â Nein | |||
| Wiederanlaufleitung | â Ja â Nein | |||
| Systemverantwortung | â Ja â Nein | |||
| Prozessverantwortung | â Ja â Nein | |||
| Sicherheits- / Forensikkoordination | â Ja â Nein | |||
| Lieferantenkoordination | â Ja â Nein | |||
| ProtokollfĂŒhrung | â Ja â Nein |
Kontrollpunkte vor dem Start
- Der Testauftrag, die Testumgebung und die Abbruchkriterien sind freigegeben.
- Die Testumgebung ist von der als kompromittiert angenommenen Umgebung getrennt.
- Notfallkontakte, Eskalationswege und Stellvertretungen sind ĂŒber einen unabhĂ€ngigen Zugang verfĂŒgbar.
- ZugÀnge zu Sicherungen, Systemvorlagen, Installationsmedien, Konfigurationsdokumentation und nötigen Lizenzen sind erreichbar.
- Der Sicherungssatz ist eindeutig bezeichnet; der erwartete Datenstand ist festgehalten.
- Die Prozessverantwortung kennt Testfall und Abnahmekriterium.
- Der Umgang mit Testdaten und Personendaten ist geklÀrt.
- Das Vorgehen gefÀhrdet keine produktiven Systeme oder Daten.
4. DurchfĂŒhrungsprotokoll
| Uhrzeit | Schritt / Entscheidung | Verantwortliche Person | Nachweis / Ergebnis | Abweichung oder Risiko |
|---|---|---|---|---|
| Alarmzeitpunkt gemÀss Szenario / RTO-Messung gestartet | ||||
| Testlage bestĂ€tigt und Grenze der Testumgebung geprĂŒft | ||||
| Wiederanlaufumgebung vorbereitet | ||||
| VertrauenswĂŒrdige Systemvorlage / Installationsquelle geprĂŒft | ||||
| IdentitÀt, Netzwerk und weitere Grundkomponenten bereitgestellt | ||||
| Anwendung wiederhergestellt | ||||
| Daten wiederhergestellt | ||||
| Datenstand gegen RPO geprĂŒft | ||||
| Berechtigungen und Sicherheitskonfiguration geprĂŒft | ||||
| Fachlicher Test durchgefĂŒhrt | ||||
| Mindestfunktion durch Prozessverantwortung abgenommen | ||||
| Freigabe / kontrollierter Abschluss des Tests |
Technische Kontrollpunkte
| Kontrollpunkt | Ergebnis / Nachweis | ErfĂŒllt? |
|---|---|---|
| Wiederherstellungsquelle verfĂŒgbar und eindeutig identifiziert | â Ja â Nein | |
| Zugang zur Sicherung unabhĂ€ngig von der Test-Schadensannahme möglich | â Ja â Nein | |
| Wiederanlaufumgebung sauber und getrennt bereitgestellt | â Ja â Nein | |
| System aus vertrauenswĂŒrdiger Quelle bereitgestellt bzw. neu installiert | â Ja â Nein | |
| Administrations- und Dienstkonten nur im benötigten Umfang aktiviert | â Ja â Nein | |
| Wiederhergestellte Daten lesbar und dem erwarteten Sicherungsstand entsprechend | â Ja â Nein | |
| Anwendungs-, Netzwerk- und Schnittstellenfunktion geprĂŒft | â Ja â Nein | |
| Protokollierung und Ăberwachung nach Wiederanlauf aktiv | â Ja â Nein | |
| RĂŒckfall- oder Abbruchweg verfĂŒgbar | â Ja â Nein | |
| Verwendete Komponenten, Produkt- oder Paketversionen sowie zustĂ€ndige Betreiberin oder zustĂ€ndiger Betreiber dokumentiert | â Ja â Nein | |
| Fixstand der verwendeten Komponenten durch laufende korrigierte Version oder AnbieterbestĂ€tigung nachgewiesen | â Ja â Nein |
Abgrenzung zum Vorfallsbefund: Die beiden letzten Kontrollpunkte dokumentieren nur die Komponenten und Fixnachweise der fĂŒr diesen Test bereitgestellten Wiederanlaufumgebung. Die BACS-Warnung zu PHP empfiehlt bei integrierten und extern betriebenen Komponenten die Kontrolle der tatsĂ€chlich laufenden korrigierten Version oder eines vom Anbieter als behoben bestĂ€tigten Pakets; ein Update beseitigt jedoch keine bereits erfolgte Kompromittierung.[6] Dieses Protokoll beurteilt deshalb weder einen frĂŒheren Daten- oder Kontenkompromiss noch dessen Umfang, Zeitpunkt oder Folgen. Beweise, Logs und betroffene produktive Systeme gehören in einem tatsĂ€chlichen Vorfall in eine gesonderte, fachlich gesteuerte Incident-Response- und Forensikbehandlung.
Fachliche Abnahme
| Testfall fĂŒr Mindestfunktion | Erwartetes Ergebnis | TatsĂ€chliches Ergebnis | Abnahme durch / Uhrzeit |
|---|---|---|---|
| Anmeldung mit vorgesehener Rolle | |||
| Kerntransaktion erfassen oder bearbeiten | |||
| Relevante Daten finden und prĂŒfen | |||
| Erforderliche Ausgabe oder Schnittstelle prĂŒfen | |||
| Behelfsprozess beenden / Ăbergabe dokumentieren |
Abnahmeentscheid: â Mindestfunktion erreicht â Mit EinschrĂ€nkungen erreicht â Nicht erreicht
BegrĂŒndung / EinschrĂ€nkungen:
................................................................................................................................................
5. Messung und Ergebnis
| Kennzahl | Soll | Ist | Differenz | Bewertung |
|---|---|---|---|---|
| RTO: Zeit bis zur fachlichen Abnahme | â ErfĂŒllt â Nicht erfĂŒllt | |||
| RPO: DatenlĂŒcke zum Referenzzeitpunkt | â ErfĂŒllt â Nicht erfĂŒllt | |||
| VollstĂ€ndigkeit der AbhĂ€ngigkeiten | â ErfĂŒllt â Nicht erfĂŒllt | |||
| Fachliche Mindestfunktion | â ErfĂŒllt â Nicht erfĂŒllt | |||
| Rollen und Kommunikation | â ErfĂŒllt â Nicht erfĂŒllt | |||
| Sicherheit der Wiederanlaufumgebung | â ErfĂŒllt â Nicht erfĂŒllt |
Gesamtergebnis: â Bestanden â Bestanden mit Auflagen â Nicht bestanden â Abgebrochen
Entscheid durch / Datum:
................................................................................................................................................
6. Debriefing und Massnahmen
Das BACS empfiehlt ein strukturiertes Debriefing, um aus der BewĂ€ltigung zu lernen und Vorfall-, Notfall- und Krisenplanung fortlaufend zu verbessern.[1] FĂŒhren Sie das Debriefing zeitnah durch und konzentrieren Sie sich auf beobachtbare Fakten.
Leitfragen
- Was hat den Wiederanlauf beschleunigt oder verzögert?
- Welche AbhÀngigkeit, Information, Berechtigung oder Freigabe war nicht vollstÀndig bekannt?
- War die Wiederherstellungsreihenfolge fĂŒr den GeschĂ€ftsprozess richtig?
- Konnten RTO und RPO nachweisbar erreicht werden?
- War die DatenqualitĂ€t fĂŒr die vereinbarte Mindestfunktion ausreichend?
- Welche Rolle, Stellvertretung oder Lieferantenleistung war unklar oder nicht erreichbar?
- Welche Massnahme verhindert eine Wiederholung der kritischen Abweichung?
| Nr. | Befund / Ursache | Risiko / Auswirkung | Massnahme | Verantwortliche Person | Termin | Nachtest nötig? |
|---|---|---|---|---|---|---|
| 1 | â Ja â Nein | |||||
| 2 | â Ja â Nein | |||||
| 3 | â Ja â Nein | |||||
| 4 | â Ja â Nein | |||||
| 5 | â Ja â Nein |
Nachtest und Dokumentenpflege
| PrĂŒfpunkt | Eintrag |
|---|---|
| Kritischer Befund, der nachgetestet wird | |
| Nachtestziel / Abnahmekriterium | |
| Termin Nachtest | |
| Verantwortliche Person | |
| Aktualisierte Dokumente (Notfallplan, Runbook, Kontaktliste, Risikoregister) | |
| Abgenommen und geschlossen durch / Datum |
Grenzen und Eskalation
Dieses Protokoll ersetzt keine forensische Untersuchung, keine Incident Response und keine fachjuristische Beratung. In einem tatsĂ€chlichen Ransomware-Vorfall empfiehlt das BACS, den Infektionsweg zu ermitteln, Neuinfektionen zu verhindern, betroffene Systeme vor der Datenwiederherstellung neu aufzusetzen und allfĂ€llige forensische Sicherungen vor Reparaturversuchen oder Neustarts frĂŒhzeitig durch Fachpersonen zu beurteilen.[3]
Ein einzelnes Anzeichen beweist keine Malware-Infektion. Mehrere ungewöhnliche Beobachtungen rechtfertigen laut BACS jedoch eine genauere Untersuchung; bei einer bestÀtigten Infektion empfiehlt das BACS ein Neuaufsetzen und anschliessende PasswortÀnderungen.[5]
âïž FachprĂŒfung erforderlich Ergibt ein Test Hinweise auf eine reale Kompromittierung oder einen Datenabfluss, stoppen Sie den Test nach dem definierten Sicherheitsverfahren. Melde- und Informationspflichten sind anhand des konkreten Sachverhalts durch Datenschutz- und Rechtsfachpersonen zu beurteilen. Art. 24 DSG verlangt eine Meldung an den EDĂB so rasch als möglich, wenn eine Datensicherheitsverletzung voraussichtlich zu einem hohen Risiko fĂŒr Persönlichkeit oder Grundrechte fĂŒhrt.[4]