Die 3 Test­me­tho­den #

Metho­de 1: Table­top Exer­cise (Walk­th­rough) #

Was: Simu­lier­tes Sze­na­rio, alle Rol­len sit­zen zusam­men, durch­spie­len was pas­siert — ohne ech­te Systeme.

Vor­be­rei­tung: 2 – 4 Stunden.

Durch­füh­rung: 2 – 3 Stun­den (Table­top Session).

Bei­spiel-Sze­na­rio: ​“Es ist Mon­tag 9 Uhr. Sie kom­men ins Büro. Der ERP-Ser­ver ist off­line und das Back­up-Sys­tem ant­wor­tet nicht. Was tun Sie?”

Rol­len:

  • Inci­dent Com­man­der: Lei­tet die Diskussion
  • IT-Lei­ter: Dia­gnos­ti­ziert was los ist
  • CFO: Eva­lu­iert geschäft­li­che Konsequenzen
  • Com­mu­ni­ca­ti­ons Mana­ger: Plant exter­ne Kommunikation

Das Team durch­spielt: ​“Was ist der ers­te Anruf? An wen geben wir den Incident?Was sagen wir dem Kunden?”

Nut­zen:

  • Iden­ti­fi­ziert Lücken im IR-Plan
  • Klärt Rol­len und Verantwortlichkeiten
  • Sehr nied­ri­ge Aus­fall­kos­ten (nichts geht wirk­lich down)
  • Good für Kri­sen­kom­mu­ni­ka­ti­on und Entscheidungsfindung

Schwä­che:

  • Tes­tet nicht die tech­ni­schen Wiederherstellungsschritte
  • Oft zu theoretisch

Metho­de 2: Teil­test (Par­ti­al Reco­very Test) #

Was: Ein ein­zel­nes Sys­tem wird tat­säch­lich aus Back­up wie­der­her­ge­stellt — aber nicht in Pro­duc­tion. In Test-Umge­bung oder alter Hardware.

Vor­be­rei­tung: 1 Woche (Pla­nung, Backup-Vorbereitung).

Durch­füh­rung: 4 – 8 Stun­den (ech­te Recovery).

Bei­spiel-Sze­na­rio: ​“Wir tes­ten ERP-Reco­very. Wir neh­men das neu­es­te ERP-Back­up und stel­len es auf einer sepa­ra­ten Test-VM wie­der her. Wir boo­ten die VM, veri­fi­zie­ren dass das Sys­tem funk­tio­niert, und dann löschen wir die Test-VM.”

Das ist ein ech­te Reco­very — aber nicht risi­ko­be­haf­tet, weil Pro­duc­tion nicht berührt wird.

Nut­zen:

  • Tes­tet den ech­ten Recovery-Prozess
  • Misst tat­säch­li­che Reco­very-Zeit (nicht geschätzt)
  • Iden­ti­fi­ziert Feh­ler im Back­up oder Recovery-Software
  • Doku­men­tier­tes Ergeb­nis für Audits

Schwä­che:

  • Nur ein Sys­tem pro Test
  • Tes­tet nicht die Reco­very-Rei­hen­fol­ge (wel­ches Sys­tem zuerst?)

Metho­de 3: Voll­test (Full Dis­as­ter Reco­very Test) #

Was: Alle kri­ti­schen Sys­te­me wer­den gleich­zei­tig aus Back­up wie­der­her­ge­stellt — voll­stän­di­ger Prozess.

Vor­be­rei­tung: 4 Wochen (Pla­nung, Infra­struk­tur-Vor­be­rei­tung, kom­mu­ni­zie­ren mit Teams).

Durch­füh­rung: 1 – 3 Tage (Voll­stän­di­ge Recovery).

Bei­spiel-Sze­na­rio: ​“Wir simu­lie­ren einen kom­plet­ten Dat­a­cen­ter-Aus­fall. Alle Pro­duk­ti­ons-Sys­te­me (AD, ERP, File­ser­ver, E‑Mail) wer­den in der Reco­very-Umge­bung wie­der­her­ge­stellt. Wir tes­ten die Reco­very-Rei­hen­fol­ge, die Inter-Sys­tem-Kom­mu­ni­ka­ti­on, und am Ende: kann der Geschäfts­be­trieb funktionieren?”

Das ist eine voll­stän­di­ge End-to-End Reco­very — unter Testbedingungen.

Nut­zen:

  • Tes­tet gesam­tes Resilienz-System
  • Iden­ti­fi­ziert Abhän­gig­keits­pro­ble­me (z.B. ​“ERP funk­tio­niert nicht ohne Fileserver”)
  • Misst gesam­te RTO (nicht ein­zeln pro System)
  • Vali­diert dass Back­up-Infra­struk­tur funktioniert
  • Größ­te Kon­fi­denz in tat­säch­li­che Recovery-Fähigkeit

Schwä­che:

  • Gro­ßer Aufwand
  • Erfor­dert dedi­zier­te Infra­struk­tur (oder Production-Ausfallzeitfenster)
  • Teu­er
  • Logis­tisch kom­plex (alle Teams beteiligt)

BSI-Anfor­de­run­gen: CON.3.A11 Test­fre­quenz #

Das BSI IT-Grund­schutz Pro­fil CON.3 (Con­ti­nui­ty Manage­ment) defi­niert Testanforderungen:

CON.3.A11: ​“Wie­der­her­stel­lung kri­ti­scher Infor­ma­tio­nen und Sys­te­me soll­ten regel­mä­ßig getes­tet werden.”

Das ist vage, aber in der Pra­xis wird das so interpretiert:

Kri­ti­k­ali­tät SystemTable­topTeil­testVoll­test
**Kri­tisch**2x p.a.4x p.a.1x p.a.
**Wich­tig**1x p.a.2x p.a.optio­nal
**Nor­mal**1x p.a.1x p.a.optio­nal

Für grö­ße­re Unter­neh­men mit NIS2-Com­pli­ance wird ein jähr­li­cher Voll­test fast erwartet.

Prak­ti­scher Test-Kalen­der #

Ein prag­ma­ti­scher Ansatz für ein mit­tel­stän­di­sches Unternehmen:

Q1 (Jan-Mär):
├── Woche 1-2: Tabletop Exercise (alle)
├── Woche 3-4: Teiltest ERP
└── Dokumentation & Lessons Learned

Q2 (Apr-Jun):
├── Woche 1-2: Tabletop Exercise fokussiert auf Cybersecurity-Szenario
└── Woche 3-4: Teiltest Fileserver

Q3 (Jul-Sep):
├── Woche 1-2: Teiltest E-Mail
└── Woche 3-4: Lessons Learned Session

Q4 (Okt-Dez):
├── Woche 1-4: Volltest (alle Systeme) — inklusive externe Evaluation
└── Management Report & Plan für nächstes Jahr

Das deckt BSI-Anfor­de­run­gen ab ohne Pro­duc­tion zu beeinträchtigen.

Doku­men­ta­ti­on der Test­ergeb­nis­se #

Nach jedem Test soll­te doku­men­tiert werden:

Test Sum­ma­ry:

  • Datum, Test­typ (Tabletop/​Teiltest/​Volltest)
  • Getes­te­te Systeme
  • Teilnehmer/​Rollen
  • Test­ziel

Erkennt­nis­se:

  • Was funk­tio­nier­te?
  • Was funk­tio­nier­te nicht?
  • Kri­ti­sche Feh­ler (mit Remediation-Plan)
  • Erkennt­nis­se für nächs­ten Test

RTO-Mes­sung:

  • Geschätz­te RTO (alt)
  • Tat­säch­li­che RTO (Test-Ergeb­nis)
  • Dif­fe­renz analysieren

Inte­gri­tät-Vali­die­rung:

  • Wur­den Daten kor­rekt wiederhergestellt?
  • Gab es Kor­rup­ti­on oder Datenverlust?
  • Sys­te­me funk­tio­nier­ten nor­mal nach Recovery?

Appr­ovals:

  • Unter­schrift von IT-Lei­ter, CIO, even­tu­ell CRO (Chief Risk Officer)

Die­ses Doku­ment ist spä­ter dein Beweis gegen­über Audi­to­ren, dass Reco­very tat­säch­lich funktioniert.

Häu­fi­ge Feh­ler bei DR-Tests #

Feh­ler 1: Test-Umge­bung ist nicht realistisch ​“Wir haben getes­tet, aber nur mit 10% der ech­ten Daten­men­ge. Rea­ler Test wür­de 10x län­ger dauern.”

Lösung: Nut­ze ech­te Back­up-Daten und ech­te Hardware-Dimensionierung.

Feh­ler 2: Nur die IT tes­tet, nicht die Business ​“Das IT-Team hat die Reco­very durch­ge­führt, aber wir haben nicht getes­tet ob das Busi­ness damit arbei­ten kann.”

Lösung: Bring Busi­ness-Rol­len in den Test (nicht nur durch­le­sen, son­dern tes­ten dass ihre Anwen­dun­gen funktionieren).

Feh­ler 3: Test-Daten wer­den nicht gelöscht ​“Nach dem Test bleibt ein Shadow-Sys­tem online, das wird ver­ges­sen, und irgend­wann ist es out-of-sync zur Production.”

Lösung: Expli­zi­te Cle­a­nup. Nach Test: Sys­te­me löschen, Doku­men­ta­ti­on archivieren.

Feh­ler 4: Tests zei­gen Pro­ble­me, wer­den nicht remedied ​“Der Full­test hat gezeigt, dass Reco­very 10 Stun­den dau­ert, nicht 4 wie RTO vor­sieht. Aber wir haben nichts gemacht.”

Lösung: Reco­very-Fin­dings müs­sen in einen Reme­dia­ti­on-Back­log gehen. Eska­lie­ren bis fix.

RTO-Mes­sung im Test #

Das ist der kri­tischs­te Punkt eines -Tests: RTO tat­säch­lich mes­sen.

Das bedeu­tet nicht nur ​“Reco­very dau­er­te 2 Stun­den”. Es bedeutet:

  1. Start-Zeit doku­men­tie­ren (wann wur­de Reco­very gestartet)
  2. Ers­te Daten ver­füg­bar (wann war das Sys­tem online, aber noch nicht getestet)
  3. Veri­fi­zie­rung abge­schlos­sen (wann wis­sen Sie, dass das Sys­tem sau­ber ist)
  4. Full func­tion­a­li­ty (wann kön­nen User nor­mal arbeiten?)

Typi­scher­wei­se: RTO = Full Func­tion­a­li­ty Zeitpunkt.

Ein Bei­spiel:

  • 10:00 Uhr: Reco­very gestartet
  • 11:45 Uhr: Ser­ver bootet
  • 12:00 Uhr: Ers­te Log­in funktioniert
  • 12:15 Uhr: Inte­gri­tät-Check ok
  • 12:30 Uhr: User kön­nen wie­der arbeiten

RTO gemes­sen: 2.5 Stun­den (10:00 — 12:30).

Die­se Mes­sung ist wert­voll für Zukünf­ti­ge Recovery-Planung.

Häu­fi­ge Fra­gen #

Müs­sen wir Pro­duc­tion-Sys­te­me für Voll­test abschalten? Tech­nisch nicht — wenn Sie dedi­zier­te Test-Infra­struk­tur haben. Aber oft ist ein Aus­fall­zeit­fens­ter sauberer.

Wie oft müs­sen wir Voll­test machen? Min­des­tens 1x pro Jahr. Aggres­si­ve Resi­li­enz-Pro­gram­me machen 2x pro Jahr.

Kön­nen wir Tests mit exter­ne Con­sul­tant outsourcen? Ja, aber nur wenn Ihr Team auch dabei ist und lernt. Ein Test, bei dem nur eine exter­ne Fir­ma teil­nimmt, hilft wenig.

Disclaimer

Dieser Beitrag wurde redaktionell erstellt und mit KI-Unterstützung aufbereitet. Er gibt einen allgemeinen Überblick und stellt keine Rechtsberatung dar – für Ihre konkrete Situation empfehlen wir professionellen Rat.