Skip to content
Cyber Resilience & Data Security

Evidence Over Hope: Can Your Recovery Plan Hold Up Under Pressure?

Why testing, communication, and operational discipline – not assumptions – determine whether recovery can actually work when it matters most.


Jahrelang folgte die Recovery-Planung einem vertrauten Muster: Man erstellte den Plan, dokumentierte die Schritte und ging davon aus, dass er im Ernstfall funktionieren würde. Lange Zeit hat sich dieser Ansatz bewährt. Hardwareausfälle, vereinzelte Ausfälle, sogar Naturkatastrophen – das waren Szenarien, die Unternehmen mit einer gewissen Sicherheit vorhersehen und einplanen konnten. Doch die Lage hat sich geändert.

In dieser Folge von STRIVE habe ich mich mit Jason Cray, Principal Product Experience bei Commvault, unterhalten, um eine Tatsache zu beleuchten, die wir in Unternehmen jeder Größe immer wieder beobachten: Die meisten scheitern nicht, weil ihnen ein Wiederherstellungsplan fehlt. Sie scheitern, weil sie nie nachgewiesen haben, dass dieser Plan unter echtem Druck auch wirklich funktioniert. Sehen Sie sich dasgesamte Folge.

Die wichtigsten Erkenntnisse: Warum Sanierungspläne scheitern

  • Ein dokumentierter Plan ist nicht dasselbe wie ein bewährter Plan. Wenn er nicht unter realistischen Bedingungen getestet wurde, handelt es sich immer noch um eine Annahme.
  • Die Wiederherstellung ist eine Teamleistung. Sicherheit, Infrastruktur und Betrieb müssen aufeinander abgestimmt sein – sonst verlangsamt sich die Wiederherstellung.
  • Die meisten Investitionen erfolgen nach wie vor „vor dem Aufschwung“. Prävention ist wichtig, doch die Vorbereitung auf die Erholung wird oft übersehen.
  • Tests decken Schwachstellen auf und stärken das Vertrauen. Ohne sie verlassen sich Unternehmen nur auf Hoffnung.
  • Resilienz ist eine operative Disziplin. Sie erfordert iteratives Vorgehen, Kommunikation und kontinuierliche Verbesserung.

Das Problem mit „Es sollte funktionieren“

Auf dem Papier erscheint die Wiederherstellung unkompliziert. Man legt fest, zu welchem Zeitpunkt die Wiederherstellung erfolgen soll, welche Daten wiederhergestellt werden müssen und wo sie wiederhergestellt werden sollen. Der Prozess wirkt logisch, strukturiert und überschaubar. Doch wie Jason betont, hält diese Einfachheit den realen Bedingungen nur selten stand.

Pläne werden in kontrollierten Umgebungen erstellt, aber sie werden im Chaos umgesetzt. Wenn ein Vorfall eintritt, gehen Teams nicht ruhig die Dokumentation durch – sie reagieren, beheben Probleme und versuchen, sich in Echtzeit abzustimmen. Hier entsteht die Lücke. Nicht zwischen Tools und Technologie, sondern zwischen Erwartung und Umsetzung.

Ein kleiner Einblick: Warum Pläne unter Druck scheitern

In diesem Ausschnitt aus unserem Gespräch erläutern Jason und ich, warum ein Plan allein nicht ausreicht – und was tatsächlich nötig ist, um sicher zu sein, dass ein Plan auch dann funktioniert, wenn es darauf ankommt.

Das haben wir schon einmal gesehen

Das Interessante daran ist, dass es sich hierbei nicht um ein neues Problem handelt, sondern um ein bekanntes – nur in einem anderen Kontext. Wenn man auf die Anfänge der Notfallwiederherstellung zurückblickt, folgten Unternehmen einem ähnlichen Muster. Pläne gab es zwar, aber die Tests waren bestenfalls lückenhaft. Jason erzählte von einem Beispiel, bei dem er eine ganze Nacht damit verbrachte, einem Kunden dabei zu helfen, einen Notfallwiederherstellungstest zu bestehen, für den dieser sich bereit glaubte. Der Plan sah solide aus. Die Umsetzung erzählte eine andere Geschichte.

Im Laufe der Zeit passten sich die Unternehmen an. Sie führten häufiger Tests durch, führten Failover-Übungen ein und betrieben in einigen Fällen den Produktivbetrieb sogar über sekundäre Umgebungen, um ihre Bereitschaft unter Beweis zu stellen. Genau dieser Wandel von der Annahme zur Überprüfung ist es, wasCyber-Resilienzheute erfordert.

Die erste Störung: Kommunikation

Wenn es ein Thema gibt, das immer wieder auftaucht, dann ist es die Kommunikation. In vielen Organisationen sind die Zuständigkeiten klar definiert – die Sicherheitsabteilung kümmert sich um die Prävention, die Infrastrukturabteilung verwaltet die Systeme und der Betrieb ist für die Wiederherstellung zuständig. Für sich genommen erfüllt jedes Team vielleicht genau die Aufgaben, die ihm obliegen. Aber die Wiederherstellung erfolgt nicht isoliert. Sie hängt davon ab, wie gut diese Teams zusammenarbeiten, wenn etwas schiefgeht.

Wie Jason beschreibt, wird daraus allzu oft ein „Stabwechsel“-Modell: „Wir haben unseren Teil erledigt, jetzt ist jemand anderes an der Reihe.“ Dieser Ansatz führt zu Verzögerungen, Verwirrung und letztendlich zu Risiken. Während eines Cybervorfalls ist Koordination wichtiger als Zuständigkeit.

Das „Left-of-Boom“-Problem

Ein weiteres Muster, das wir immer wieder beobachten, ist das Ungleichgewicht hinsichtlich der Schwerpunkte, auf die Unternehmen ihre Bemühungen richten. Es werden erhebliche Investitionen in die Prävention getätigt – in Sicherheitstools, Erkennungsplattformen und Abwehrstrategien, die darauf ausgelegt sind, einen Angriff zu verhindern, bevor er stattfindet. Diese Investitionen sind notwendig und spielen eine entscheidende Rolle. Was jedoch nach der Veranstaltung geschieht, findet weitaus weniger Beachtung.

Man geht davon aus, dass Recovery zweitrangig wird, wenn genügend Aufwand in die Prävention gesteckt wird. In Wirklichkeit ist das Gegenteil der Fall. Irgendwann kommt etwas durch. Und wenn es soweit ist, wird Recovery zum entscheidenden Faktor dafür, wie ein Unternehmen reagiert.

Von der Hoffnung zur Evidenz

Genau hier muss sich die Denkweise ändern. Es geht nicht darum, weitere Tools hinzuzufügen oder die Dokumentation neu zu verfassen. Es geht darum, von einem auf Hoffnung basierenden Modell zu einem Modell überzugehen, das auf Fakten beruht.

Jason hebt eine wichtige Erkenntnis hervor: Die Unternehmen, die gut mit Störungen umgehen können, sind nicht diejenigen, die Vorfälle vermeiden – es sind diejenigen, die weniger stark davon betroffen sind, wenn solche Vorfälle eintreten. Sie haben ihre Prozesse getestet. Sie haben ihre Annahmen überprüft. Sie wissen, wo ihre Schwachstellen liegen. Vor allem aber haben sie Vertrauen geschaffen – nicht indem sie daran glaubten, dass der Plan funktionieren würde, sondern indem sie es unter Beweis gestellt haben.

Fang klein an, baue Schwung auf

Für viele Teams besteht die Herausforderung nicht darin, das Problem zu verstehen, sondern darin, zu wissen, wo sie anfangen sollen. Die Lösung besteht nicht darin, alles auf einmal umzukrempeln. Man sollte klein anfangen und darauf aufbauen.

Konzentrieren Sie sich auf ein oder zwei kritische Dienste. Machen Sie sich klar, was für deren Recovery erforderlich ist. Bringen Sie die für diese Systeme verantwortlichen Teams zusammen und testen Sie den Prozess durchgängig. Erweitern Sie von dort aus den Umfang und verfeinern Sie den Prozess weiter. Dieser Ansatz verbessert nicht nur die Erholung – er sorgt auch für mehr Abstimmung, stärkt die Kommunikation und schafft die Grundlage für eine umfassendere Widerstandsfähigkeit.

Die Realität: Kein Plan übersteht den ersten Kontakt

Einer der ehrlichsten Momente in unserem Gespräch war folgender: Selbst der beste Plan funktioniert nicht genau so, wie er aufgeschrieben ist. Das ist kein Misserfolg – das ist zu erwarten. Jason bringt es auf den Punkt: Wer keinen Plan hat, wird scheitern. Aber selbst wenn man einen hat, wird er im Moment nicht perfekt verlaufen.

Entscheidend ist, wie gut deine Teams darauf vorbereitet sind, sich anzupassen. Durch Tests wird diese Anpassungsfähigkeit geschaffen. Sie baut das Muskelgedächtnis auf, das erforderlich ist, um effektiv zu reagieren, wenn die Bedingungen nicht den Erwartungen entsprechen.

Die ganze Folge ansehen

In diesem STRIVE-Gespräch behandeln wir noch viele weitere Themen, darunter:

  • Warum Wiederherstellungspläne oft scheitern, obwohl sie gut dokumentiert sind.
  • Was zeichnet Organisationen aus, die sich effektiv erholen?
  • Wie sich Kommunikationslücken auf die Umsetzung auswirken.
  • Wo soll man bei der Verbesserung der Wiederherstellungsbereitschaft ansetzen?
  • Warum das Testen die Grundlage für Resilienz ist.

Jetzt anschauen. Wenn Sie sich schon einmal gefragt haben, ob Ihr Sanierungsplan tatsächlich funktionieren würde, ist dieses Gespräch Ihre Zeit wert.

FAQs

F: Warum reicht ein Notfallplan allein nicht aus?

A: Weil die meisten Pläne nie unter realen Bedingungen überprüft werden. Ohne Tests bleiben sie bloße Annahmen und keine bewährten Strategien.

F: Was führt dazu, dass Wiederherstellungspläne fehlschlagen?

A: Die häufigsten Probleme bei Wiederherstellungsplänen sind fehlende Tests, mangelhafte teamübergreifende Kommunikation sowie Diskrepanzen zwischen den dokumentierten Prozessen und der tatsächlichen Umsetzung.

F: Was bedeutet “links vom Ausleger”?

A: „Left of Boom“ bezieht sich auf den Schwerpunkt, Vorfälle zu verhindern, bevor sie eintreten. Viele Organisationen investieren hier stark, vernachlässigen jedoch die Wiederherstellungsfähigkeiten.

F: Wie oft sollten Wiederherstellungspläne getestet werden?

A: Notfallpläne sollten regelmäßig und unter unterschiedlichen Bedingungen getestet werden. Die Tests sollten realistische Szenarien simulieren und nicht nur kontrollierte Übungen sein.

F: Wo sollten Unternehmen ansetzen?

A: Beginnen Sie mit einer kleinen Auswahl kritischer Dienste, stimmen Sie die zuständigen Teams ab und testen Sie die Wiederherstellung durchgängig, bevor Sie den Umfang erweitern.

F: Was ist der entscheidende Umdenkprozess?

A: Der Übergang von einer auf Hoffnungen basierenden Planung zu einer evidenzbasierten Validierung.

Chris Mierzwa ist Senior Director für Portfoliomarketing bei Commvault.

More related posts


Thumbnail_Blog-Testing-Once-a-Year-2026

Testing Once a Year Is Not a Resilience Strategy

Read more about Testing Once a Year Is Not a Resilience Strategy
Thumbnail_Blog-IDC-Resops-2026

From Recovery to ResOps™: Building Enterprise Resilience That Scales

Read more about From Recovery to ResOps™: Building Enterprise Resilience That Scales
Readiverse-Featured-Image-888-x-500

Ready Is Good. Resilient Is Better.

Read more about Ready Is Good. Resilient Is Better.