← ZurĂŒck zum Fachleitfaden
Format: DIN A4 Druckvorlage
🔒 Exklusives Arbeitsmittel

Mandanten-Login erforderlich

Dieses druckfertige Arbeitsmittel steht Kunden und Mandanten der DKSchV zur VerfĂŒgung. Melden Sie sich an, um das Arbeitsblatt zu nutzen, zu drucken oder als PDF zu speichern.

DKSchV Schweiz · Dokumentiertes Arbeitsmittel

Arbeitsvorlage

1.2 · Zielgruppe: Schweizer KMU GeschÀftsleitungen & IT

DKSchV Schweiz

Version 1.2 · Quellenstand: 1. November 2026. Die Standangabe bezeichnet die Quellenpflege und keine Fach-, Rechts- oder Nutzungsfreigabe.

⚖
⚖ FachprĂŒfung erforderlich Die rechtlichen Hinweise und die organisationsspezifische DurchfĂŒhrung eines Wiederanlaufs mĂŒssen vor Verwendung durch zustĂ€ndige Fachpersonen geprĂŒft werden.

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

FeldEintrag
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ĂŒfpunktEintrag
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ĂŒfpunktSollwert / FestlegungIstwert / ErgebnisErfĂŒ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 / DienstleisterVerantwortliche PersonReihenfolgeVorbedingung / FreigabeErgebnis
1☐ OK ☐ Abweichung
2☐ OK ☐ Abweichung
3☐ OK ☐ Abweichung
4☐ OK ☐ Abweichung
5☐ OK ☐ Abweichung
6☐ OK ☐ Abweichung

3. Rollen, Kommunikation und Unterlagen

RolleNameStellvertretungErreichbarkeit / 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

â„č
Erfassen Sie jede wesentliche Entscheidung und Übergabe mit Uhrzeit. Die RTO-Messung endet erst mit der fachlichen Abnahme der vereinbarten Mindestfunktion.
UhrzeitSchritt / EntscheidungVerantwortliche PersonNachweis / ErgebnisAbweichung 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

KontrollpunktErgebnis / NachweisErfĂŒ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 MindestfunktionErwartetes ErgebnisTatsĂ€chliches ErgebnisAbnahme 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

KennzahlSollIstDifferenzBewertung
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 / UrsacheRisiko / AuswirkungMassnahmeVerantwortliche PersonTerminNachtest nötig?
1☐ Ja ☐ Nein
2☐ Ja ☐ Nein
3☐ Ja ☐ Nein
4☐ Ja ☐ Nein
5☐ Ja ☐ Nein

Nachtest und Dokumentenpflege

PrĂŒfpunktEintrag
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]

Quellen

DKSchV Dini · Bammattenweg 19, CH-3904 Naters · www.dkschv.ch
Vertrauliche Arbeitsunterlage · Rechts- & FachprĂŒfung vorbehalten