Backup ist nicht Recovery: Was Mittelständler für echte Business Continuity brauchen
Es gibt zwei Arten von Unternehmen: Die, die Backups haben. Und die, die ihre Wiederherstellung auch wirklich getestet haben. Der Unterschied klingt akademisch – er ist es aber nicht. Es ist der Unterschied zwischen der Illusion von Sicherheit und tatsächlicher Handlungsfähigkeit. Und er zeigt sich spätestens dann, wenn ein Cyberangriff, ein Hardwareausfall oder eine Naturkatastrophe die IT-Infrastruktur trifft.
Warum Backup nicht gleich Recovery ist
"Online" ist nicht gleich "arbeitsfähig." Diese Unterscheidung ist zentral für das Verständnis von Business Continuity. Ein Backup sichert Daten. Recovery stellt den Betrieb her. Viele Unternehmen investieren erheblich in Backup-Lösungen – und vernachlässigen dabei das Entscheidende: die nachgewiesene Fähigkeit, aus diesem Backup den Betrieb in akzeptabler Zeit wiederherzustellen.
Recovery ist ein Prozess, kein Speicherplatz. Dieser Prozess muss definiert, regelmäßig geübt und kontinuierlich verbessert werden. Nur dann ist ein Unternehmen nach einem Vorfall wirklich handlungsfähig. Ein Backup-System, dessen Wiederherstellbarkeit nicht regelmäßig getestet wurde, ist eine Annahme – keine Garantie.
Die vier Mindestanforderungen für echte Business Continuity
RTO und RPO pro Kernsystem, realistisch definiert: Recovery Time Objective (RTO) und Recovery Point Objective (RPO) müssen für jedes kritische System definiert sein – und diese Werte müssen realistisch sein. "Wir können alles in zwei Stunden wiederherstellen" ist eine politische Aussage, solange sie nicht durch Testergebnisse belegt wird. Realistische RTOs und RPOs entstehen durch Messung, nicht durch Wunschdenken. Unrealistische Zielwerte geben ein falsches Sicherheitsgefühl und führen im Ernstfall zu Überraschungen.
Getestete Wiederanläufe, mindestens quartalsweise für kritische Systeme: Nur ein getesteter Recovery-Prozess ist ein verlässlicher Recovery-Prozess. Jeder Test deckt Schwachstellen auf, die im laufenden Betrieb entstehen: ungültige oder inkonsistente Backup-Sets, veränderte Systemkonfigurationen, fehlende Abhängigkeiten zwischen Systemen. Diese Schwachstellen sollten im Test ans Licht kommen – nicht im Ernstfall.
Eskalation und Verantwortlichkeiten: Wer entscheidet was, wann? Im Ernstfall ist keine Zeit für Diskussionen über Zuständigkeiten. Die Entscheidungsstruktur für einen Recovery-Fall muss vorab klar definiert sein: Wer gibt das Signal zum Recovery-Start? Wer entscheidet über den Umfang der Wiederherstellung? Wer kommuniziert nach außen? Wer trifft die Entscheidung, im Notbetrieb weiterzuarbeiten?
Nachweis durch Testdatum, Ergebnis und Maßnahmenliste: Business Continuity endet nicht beim Plan – sie endet beim Nachweis. Jeder Recovery-Test muss dokumentiert werden: wann wurde getestet, was war das gemessene Ergebnis, welche Schwachstellen wurden identifiziert, welche Maßnahmen wurden eingeleitet? Dieser Nachweis ist im Rahmen von NIS-2 und anderen regulatorischen Anforderungen zunehmend explizit gefordert und wird in Audits und Prüfungen verlangt.
Die drei schwierigen Diskussionen, die Unternehmen führen müssen
Realistische RTOs vereinbaren: Wie ehrlich sind wir bereit zu sein über das, was tatsächlich erreichbar ist? Ein RTO von vier Stunden klingt attraktiv im Bericht. Wenn der letzte Test zwölf Stunden gedauert hat, ist der Zielwert entweder ein Investitionsauftrag oder eine Fehlinformation. Ehrlichkeit hier erfordert Mut – und manchmal die Bereitschaft, in zusätzliche Infrastruktur oder Prozesse zu investieren.
Klare Verantwortlichkeiten benennen: Wer trägt die Verantwortung für Business Continuity? Wenn die Antwort "irgendwie alle" lautet, trägt sie de facto niemand. Klare Eigentümerschaft – eine benannte Person oder Funktion, die BCM verantwortet – ist die Voraussetzung für funktionierende Prozesse. Ohne Verantwortung gibt es keine Verbindlichkeit.
Den Mut zum Recovery-Test aufbringen: Ein Test kann scheitern – und das ist gut so. Ein gescheiterter Test in einer kontrollierten Umgebung ist die günstigste Lernmöglichkeit, die ein Unternehmen haben kann. Die Alternative – einen ungeplanten Ausfall im echten Betrieb zu erleben, ohne vorherige Tests – ist erheblich teurer, zeitkritischer und reputationsschädigender. Jeder Testmisserfolg ist ein Erfolg des BCM-Programms.
Business Continuity als Ausdruck von Unternehmensreife
Ein funktionierendes BCM-Programm ist kein reines IT-Thema. Es ist ein Ausdruck von Unternehmensreife und strategischer Verantwortung. Unternehmen, die ihre Recovery-Fähigkeit regelmäßig testen, dokumentieren und verbessern, treffen bessere Entscheidungen über Technologie, Prozesse und Risikotragfähigkeit. Sie sind nicht nur besser gegen Cyberangriffe gewappnet – sie sind als Organisation verlässlicher geführt.
Backup haben ist das Minimum. Wiederherstellung können ist das Ziel. Zwischen diesen beiden Punkten liegt ein strukturierter Prozess: definierte RTOs und RPOs, quartalsweise Tests, klare Verantwortlichkeiten und lückenlose Dokumentation. Unternehmen, die diesen Weg konsequent gehen, werden nicht nur resilient – sie werden handlungsfähig in dem Moment, in dem es darauf ankommt.