Wie erstelle ich einen Disaster Recovery Plan?

Wenn ein ERP-System ausfällt, Backups nicht sauber einspielbar sind und der Betrieb stillsteht, hilft keine allgemeine Sicherheitsrichtlinie mehr. Genau an diesem Punkt wird die Frage "wie erstelle ich einen Disaster Recovery Plan" zur Managementfrage - nicht nur zur IT-Aufgabe. Für kleine und mittelständische Unternehmen geht es dabei um Geschäftsfortführung, Haftungsreduktion und um die belastbare Vorbereitung auf einen Vorfall, der technisch, operativ und versicherungsseitig sauber beherrscht werden muss.

Was ein Disaster Recovery Plan leisten muss

Ein Disaster Recovery Plan beschreibt nicht einfach, wie Systeme wieder hochgefahren werden. Er legt fest, welche kritischen Prozesse zuerst wiederhergestellt werden, wer Entscheidungen trifft, welche Abhängigkeiten bestehen und welche Notmaßnahmen bis zur vollständigen Stabilisierung greifen. Das Ziel ist nicht Perfektion, sondern kontrollierte Wiederanlaufbarkeit innerhalb definierter Zeit- und Datenverluste.

Gerade im Mittelstand liegt hier ein häufiger Denkfehler. Viele Unternehmen haben Backups, Monitoring und einen IT-Dienstleister. Das ist sinnvoll, ersetzt aber keinen belastbaren Wiederanlaufplan. Ein Backup beantwortet noch nicht die Frage, in welcher Reihenfolge Anwendungen, Berechtigungen, Netzsegmente, Kommunikationswege und externe Dienstleister koordiniert werden müssen.

Ein guter Plan ist deshalb immer geschäftsorientiert. Er startet bei den Kernprozessen und erst danach bei der Technik. Wer nur Infrastruktur betrachtet, baut oft an den eigentlichen Prioritäten vorbei.

Wie erstelle ich einen Disaster Recovery Plan - der richtige Ausgangspunkt

Der erste Schritt ist eine ehrliche Bestandsaufnahme. Welche Systeme sind für Umsatz, Leistungserbringung, Kundenkommunikation, Produktion oder regulatorische Pflichten wirklich kritisch? In vielen Unternehmen zeigt sich dabei, dass nicht das sichtbar größte System das wichtigste ist, sondern ein unscheinbarer Dienst mit vielen Abhängigkeiten - etwa Identitätsmanagement, Dateifreigaben, Telefonie oder E-Mail.

Anschließend brauchen Sie zwei Kennzahlen, die im Alltag oft verwechselt werden: die maximale tolerierbare Ausfallzeit und den maximal tolerierbaren Datenverlust. Die Ausfallzeit beschreibt, wie lange ein Prozess oder System stehen darf. Der Datenverlust beschreibt, auf welchen Wiederherstellungspunkt Sie zurückfallen können. Beides ist keine rein technische Entscheidung. Wenn die Geschäftsführung vier Stunden Ausfall für akzeptabel hält, die IT aber nur tägliche Backups vorhält, besteht eine Lücke, die offen benannt werden muss.

Ein tragfähiger Disaster Recovery Plan entsteht genau aus dieser Abstimmung zwischen Fachbereich, IT und Leitungsebene. Das ist auch aus Sicht der Versicherbarkeit relevant. Versicherer erwarten zunehmend nachvollziehbare Notfall- und Wiederanlaufstrukturen, nicht nur einzelne Sicherheitsmaßnahmen.

Kritische Prozesse vor Systemen priorisieren

Beginnen Sie mit den Geschäftsprozessen. Welche Leistungen müssen innerhalb weniger Stunden wieder laufen? Welche können einen Tag warten? Welche sind zwar unangenehm, aber nicht existenziell? Erst wenn diese Reihenfolge steht, ergibt die technische Priorisierung Sinn.

Typischerweise gehören dazu Finanzprozesse, Warenwirtschaft, Produktionssteuerung, Kundenservice, Zugriffsverwaltung und Kommunikationskanäle. Je nach Unternehmen kommen branchenspezifische Pflichten hinzu, etwa Dokumentation, Fristen oder vertraglich zugesicherte Verfügbarkeiten. Ein Disaster Recovery Plan muss diese Realität abbilden und darf nicht als generisches IT-Dokument enden.

Rollen und Entscheidungen klar festlegen

Im Ernstfall scheitern viele Unternehmen nicht an fehlender Technik, sondern an Unklarheit. Wer darf Systeme isolieren? Wer entscheidet über externe Kommunikation? Wer priorisiert Wiederherstellungsmaßnahmen, wenn mehrere Bereiche gleichzeitig Druck machen? Wer spricht mit dem Versicherer, dem IT-Dienstleister und gegebenenfalls mit betroffenen Kunden?

Diese Rollen müssen vorab benannt sein. Dazu gehören mindestens die technische Einsatzleitung, eine geschäftliche Entscheidungsinstanz, ein Verantwortlicher für interne Kommunikation und ein Ansprechpartner für externe Stakeholder. Wenn einzelne Personen ausfallen, brauchen Sie Stellvertretungen. Ein Plan, der an einer Person hängt, ist kein belastbarer Plan.

Die Kernbestandteile eines belastbaren Plans

Ein Disaster Recovery Plan muss nicht unnötig lang sein. Er muss aber vollständig genug sein, um unter Stress anwendbar zu bleiben. In der Praxis haben sich einige Bausteine bewährt.

Zunächst benötigen Sie ein Systeminventar mit Priorisierung. Nicht als Excel-Friedhof, sondern als Arbeitsgrundlage: Anwendungen, Server, Cloud-Dienste, Identitätsdienste, Schnittstellen, Standorte, externe Provider und die jeweils verantwortlichen Ansprechpartner.

Ebenso wichtig ist die Abhängigkeitslogik. Ein zentrales Fachsystem bringt wenig, wenn Authentifizierung, Netzwerkzugang oder Datenbankdienste noch nicht verfügbar sind. Viele Wiederanlaufpläne wirken auf dem Papier plausibel, brechen aber in der Reihenfolge auseinander. Genau deshalb sollten technische Teams und Prozessverantwortliche gemeinsam prüfen, was tatsächlich zuerst benötigt wird.

Dann folgen die Wiederherstellungswege. Wo liegen Backups, wie wird ihre Integrität geprüft, welche Wiederherstellungsumgebungen stehen bereit, welche Mindestkonfiguration ist für den Notbetrieb ausreichend? Hier zeigt sich oft der Unterschied zwischen dokumentierter Hoffnung und realer Umsetzbarkeit. Was nie getestet wurde, ist kein verlässlicher Wiederanlaufpfad.

Schließlich braucht der Plan klare Kommunikationsregeln. Ein Vorfall ist nicht nur ein Technikereignis. Mitarbeitende müssen wissen, welche Kanäle im Notfall genutzt werden, Führungskräfte brauchen belastbare Lagebilder und externe Aussagen müssen konsistent sein. Wer improvisiert kommuniziert, erzeugt zusätzlichen Schaden.

Wie erstelle ich einen Disaster Recovery Plan mit realistischen Wiederanlaufzielen

Der häufigste Fehler liegt in unrealistischen Zielwerten. Unternehmen formulieren sehr ambitionierte Wiederherstellungszeiten, ohne dafür die nötige Architektur, Redundanz oder personelle Verfügbarkeit zu haben. Das ist operativ riskant und kann auch bei der Beurteilung von Sicherheitsreife oder Versicherervoraussetzungen problematisch werden.

Realistisch heißt nicht bequem. Realistisch heißt, Zielwerte so festzulegen, dass sie fachlich notwendig und technisch belegbar sind. Für ein zentrales Vertriebssystem kann ein Ziel von wenigen Stunden angemessen sein. Für ein Archivsystem genügt möglicherweise ein längerer Zeitraum. Diese Unterschiede sind normal. Nicht jedes System braucht denselben Schutzgrad.

Ein weiterer Punkt: Der beste Plan nützt wenig, wenn Dienstleister nicht eingebunden sind. Viele mittelständische Unternehmen arbeiten mit Systemhäusern, Managed Service Providern oder spezialisierten Cloud-Anbietern. Dann muss eindeutig geregelt sein, welche Leistungen im Notfall tatsächlich geschuldet sind, zu welchen Zeiten Ansprechpartner verfügbar sind und welche Vorarbeiten intern erfolgen müssen. Sonst entsteht eine gefährliche Erwartungslücke.

Tests sind Pflicht, aber mit Augenmaß

Ein Plan ohne Test ist eine Annahme. Gleichzeitig muss nicht jedes Unternehmen hochkomplexe Notfallübungen fahren. Sinnvoll ist ein gestufter Ansatz: zuerst Dokumentenprüfung, dann Tabletop-Übungen mit Verantwortlichen, danach technische Wiederherstellung einzelner kritischer Systeme und schließlich realitätsnahe Szenarien.

Wichtig ist, dass aus jedem Test Maßnahmen abgeleitet werden. Wenn Passwörter fehlen, Verantwortlichkeiten unklar bleiben oder Wiederherstellungszeiten verfehlt werden, gehört das nicht in die Schublade, sondern in einen konkreten Verbesserungsplan. Disaster Recovery ist kein einmaliges Projekt, sondern ein betrieblicher Reifegrad.

Typische Schwachstellen im Mittelstand

In der Praxis wiederholen sich bestimmte Probleme. Häufig sind Backups vorhanden, aber nicht regelmäßig auf Wiederherstellbarkeit geprüft. Oder es existiert eine Notfalldokumentation, die technisch geschrieben ist, aber den Geschäftsprozess nicht berücksichtigt. Ebenfalls verbreitet ist die Annahme, dass der IT-Dienstleister alle Entscheidungen im Ernstfall automatisch übernimmt. Das ist selten der Fall und sollte weder organisatorisch noch haftungsseitig unterstellt werden.

Kritisch ist auch, wenn Recovery-Pläne und Cyberversicherung nebeneinander laufen, ohne aufeinander abgestimmt zu sein. Wer Meldewege, Dienstleistersteuerung, Forensik, Betriebsunterbrechung und Wiederanlauf nicht zusammen denkt, riskiert Reibungsverluste genau dann, wenn Zeit der knappste Faktor ist. CyberShield begleitet Unternehmen gerade an dieser Schnittstelle zwischen technischer Vorbereitung, Versichererwartung und belastbarer Dokumentation.

So bleibt der Plan praxistauglich

Ein Disaster Recovery Plan muss aktuell bleiben. Neue Software, geänderte Verantwortlichkeiten, Migrationen in die Cloud oder neue Compliance-Anforderungen verändern die Ausgangslage schnell. Deshalb sollte der Plan mindestens jährlich und zusätzlich nach wesentlichen IT- oder Prozessänderungen überprüft werden.

Praxistauglich bleibt er nur, wenn er verständlich ist. Keine endlosen Textblöcke, keine theoretischen Begriffe ohne Handlungswert. Entscheidend sind klare Entscheidungswege, verfügbare Kontaktdaten, priorisierte Wiederanlaufschritte und dokumentierte Annahmen. Der Plan muss unter Druck lesbar bleiben.

Wer sich fragt, ob der eigene Stand bereits ausreicht, sollte nicht nur auf vorhandene Technik schauen. Die bessere Frage lautet: Können wir den Ausfall unserer wichtigsten Prozesse innerhalb vertretbarer Zeit kontrolliert bewältigen - und ist das auch dokumentiert, getestet und gegenüber Dritten nachvollziehbar? Genau dort trennt sich formale Vorsorge von echter Krisenfähigkeit.

Ein belastbarer Disaster Recovery Plan ist kein Papier für Audits, sondern ein Führungsinstrument für den schlechtesten Tag des Jahres. Je klarer die Vorbereitung, desto kleiner der Spielraum für teure Improvisation.