FAST LTA und eperi

Ein Business Continuity Plan (BCP) ist nicht nur ein IT-Dokument. Es ist die schriftliche Strategie, wie eine Organisation ihre kritischen Geschäftsprozesse aufrechthält (oder schnell wiederherstellt), wenn eine Störung eintritt. Eine Cyberattacke, ein Naturkatastrophe, ein Gebäudeausfall — der BCP deckt alles ab.Viele IT-Leiter verwechseln BCP mit DR-Plan (Disaster Recovery Plan). Das ist ein Fehler. Der DR-Plan ist technisch (wie bringen wir Systeme wieder hoch?). Der BCP ist geschäftlich (welche Prozesse sind kritisch, und wie lange können sie ausfallen?).

Ein DR-Plan, der nie getestet wurde, ist Fiktion. Das ist nicht Überreaction — das ist IT-Realität. Backups, die nicht getestet wurden, sind nicht wiederherstellbar. Recovery-Runbooks, die nicht durchgespielt wurden, enthalten tausend Fehler. RTOs, die nicht gemessen wurden, sind Fantasie.Die gute Nachricht: Regelmäßige DR-Tests sind nicht unmöglich. Es gibt drei praktische Methoden, je nach Aufwand und Tiefe.

RTO (Recovery Time Objective) und RPO (Recovery Point Objective) sind die kritischsten Kennzahlen einer Resilienz-Strategie. Sie beantworten zwei Fragen:RTO: Wie lange darf mein System ausfallen? RPO: Wie viel Datenverlust kann ich tolerieren?Das Problem: Viele Organisationen "schätzen" RTO/RPO basierend auf Bauchgefühl oder IT-Tradition. Das ist falsch. RTO/RPO müssen aus der Business Impact Analysis (BIA) abgeleitet werden — nicht umgekehrt.

RTO ist eines der wichtigsten Konzepte im Backup- und Disaster-Recovery-Management. Aber die meisten Unternehmen schätzen es falsch. Sie sagen "RTO ist 4 Stunden", aber wenn ein Angriff kommt, dauert die Recovery 2 Tage. Dieser Artikel erklärt, wie Sie RTO realistisch berechnen — und vor allem, wie Sie es testen.

Ein Recovery-Runbook ist keine IT-Philosophie — es ist ein operatives Handbuch. Es ist das Dokument, das Ihr IT-Team während eines tatsächlichen Disaster an die Hand nimmt und sagt: "Schritt für Schritt, wie bringen wir die Systeme wieder hoch?"Ein gutes Runbook ist so spezifisch, dass auch jemand, der das System normalerweise nicht wartet, es wiederherstellen könnte. Das ist das Qualitäts-Merkmal.

Eine Isolated Recovery Environment (IRE) ist nicht ein einzelnes Gerät — es ist eine Infrastruktur-Zone, die völlig vom Production-Netzwerk isoliert ist. Sie ist der Ort, wo Sie kompromittierte Systeme wiederherstellen, verifizieren und bereinigen, bevor Sie sie zurück in Production gehen.Ohne IRE ist Recovery in einem kompromittierten Netzwerk ein Risiko: Der wiederhergestellte Server wird sofort wieder infiziert, bevor Sie ihn nutzen können.

"Assume Breach" ist nicht nur ein Sicherheits-Slogans. Es ist ein fundamentales Designprinzip, das die komplette Architektur einer Organisation umgestaltet. Wenn Sie diesen Gedanken konsequent durchdenken, müssen Sie Ihre IT neu bauen.Das Konzept ist einfach: Nicht ob, sondern wann wird Ihre Organisation angegriffen und kompromittiert?Das ist keine Frage von Pessimismus. Die Daten sagen eindeutig: 76% der Unternehmen werden Opfer von Ransomware (Veeam 2024). Für viele Branchen (Financial Services, Healthcare, Manufacturing) ist 100% Angriffs-Wahrscheinlichkeit realistisch. Die Frage ist nur: Wann?

Viele deutsche Unternehmen befinden sich auf Resilienz-Stufe 2 oder 3. Sie haben Backups, aber keine nachgewiesene Wiederherstellungsfähigkeit. Sie haben einen DR-Plan, aber er ist veraltet und wurde nie getestet. Bei einem Ransomware-Angriff, der auch die Backup-Infrastruktur trifft, ist das kein Recovery-Plan. Es ist eine Hoffnung.Stufe 4 ist der Punkt, an dem Resilienz aufhört, Hoffnung zu sein, und anfängt, eine nachgewiesene Fähigkeit zu werden. Dieser Artikel beschreibt, was den Unterschied ausmacht und welche Maßnahmen am effizientesten dorthin führen.---

Die meisten Organisationen wissen nicht, wo sie auf der Resilienz-Reife stehen. Sie sagen "Wir haben Backups" — aber das könnte alles sein: von "jemand kopiert Daten sporadisch auf einen USB-Stick" bis zu "professionelle 4-Tier Backup-Architektur mit Quarterly Tests".Das Capability Maturity Model (CMM) für IT-Resilienz definiert 5 Reife-Stufen. Mit diesen Fragen können Sie selbst bewerten, wo Sie stehen — und wo der wirkungsvollste nächste Schritt ist.

IT-Resilienz ist längst keine technische Frage mehr — sie ist eine Vorstandsfrage. Spätestens seit NIS2 und DORA haben Geschäftsführer und Vorstandsmitglieder persönliche Haftungsrisiken bei unzureichender Resilienz. Doch nicht nur Compliance treibt die Diskussion voran. Fünf harte Business-Argumente zeigen, warum Resilienz-Investment sich rechnet und warum Unterlassung kostspielig wird.

Eine robuste IT-Resilienz-Strategie ruht nicht auf einer einzelnen Säule — sondern auf fünf. Jede Säule hat spezifische Technologien, Prozesse und Verantwortlichkeiten. Viele Organisationen investieren schwer in Säule 1 (Prävention) und vergessen die anderen vier. Das ist ein klassischer Fehler, der zur Anfälligkeit führt.Hier ist ein praktisches Framework, das zeigt, was zu jeder Säule gehört und wie man sie umsetzt.

Cyber-Resilienz ist keine Alternative zu IT-Sicherheit. Sie ist eine Spezialisierung von IT-Resilienz, fokussiert auf Cyberangriffe. Der Unterschied ist wichtig, weil er zeigt: Sie können nicht eine der beiden vernachlässigen und hoffen, dass die andere ausreicht.IT-Resilienz ist breit — sie umfasst Naturkatastrophen, Hardware-Ausfälle, Software-Bugs, menschliche Fehler und Cyberangriffe.Cyber-Resilienz ist eng — sie befasst sich spezifisch mit der Wiederherstellung nach bösartigen, intelligenten Angriffen, die darauf abzielen, Ihre Backups zu zerstören und Ihre Recovery zu sabotieren.Das macht Cyber-Resilienz schwächer: Sie braucht mehr Verteidigungsschichten, weil der Gegner intelligent reagiert.