Wiederanlaufplan für KRITIS-Software: Praxisleitfaden für Betreiber

Ein Wiederanlaufplan für KRITIS-Software entscheidet, wie schnell der Normalbetrieb nach einem Vorfall zurück ist — und ob die Aufsicht den Recovery-Nachweis abnimmt. Dieser Praxisleitfaden richtet sich an KRITIS-Betreiber, die ein belastbares Disaster Recovery KRITIS aufbauen oder beauftragen wollen — mit RTO/RPO-Festlegung, Restore-Reihenfolge, getesteten Verfahren und audit-fester Dokumentation als verbindlichem Liefergegenstand des Software-Dienstleisters.
Eine Grafik mit gelben Hintergrund: Eine kleine, bunte Rakte startet aus einem Noteboo-Display. Ein Symbolbild für einen Wiederanlaufplan für KRITIS-Software.
© TenMedia

Was ist ein Wiederanlaufplan für KRITIS-Software?

Ein Wiederanlaufplan für KRITIS-Software ist das softwarespezifische Drehbuch zur Wiederherstellung des Normalbetriebs nach einem Vorfall. Er regelt Reihenfolge, Verantwortlichkeiten, RTO und RPO pro Anwendung, listet Kontakte und beschreibt Testpflichten.

Laut Cyber-Schadenstatistik des GDV liegt die durchschnittliche Ausfalldauer nach einem Cybervorfall in deutschen Unternehmen häufig bei mehreren Stunden bis Tagen — mit direkten Wiederherstellungskosten, die sich schnell sechsstellig summieren. Diese Zahlen treffen KRITIS-Betreiber besonders hart, weil Versorgungsausfälle dort nicht nur wirtschaftlich, sondern auch regulatorisch gemessen werden. Genau hier setzt der Wiederanlaufplan für KRITIS-Software an: als technisches Drehbuch, das Ausfallzeiten messbar verkürzt. Unser Leitfaden Softwareentwicklung für KRITIS zeigt den übergeordneten Rahmen, in den der Plan einrückt.

Wie unterscheidet sich der Wiederanlaufplan vom IT-Notfallplan?

Der IT-Notfallplan ist das organisatorische Dachdokument, der Wiederanlaufplan KRITIS-Software das technische Drehbuch je Anwendung. Beide gehören zusammen, sind aber nicht austauschbar.

Der IT-Notfallplan beschreibt, wer im Krisenstab sitzt, wer Meldungen verschickt und wie die Kommunikation läuft. Der Wiederanlaufplan für KRITIS-Software liefert die zweite Schicht: konkrete Restore-Schritte, Abhängigkeiten zwischen Komponenten, exakte Wiederherstellungsstrategie pro Sektor. Wer beides zusammen denkt, vermeidet die typische Lücke zwischen organisatorischer Krisenführung und technischer Ausführung. Im Audit prüft das BSI beide Ebenen unabhängig voneinander, weshalb beide getrennt dokumentiert werden müssen.

Ein Recovery-Plan für KRITIS-Software ohne Verbindung zur organisatorischen Krisenführung bleibt im Ernstfall stumm — und umgekehrt. Eine vorgelagerte Kritikalitätsanalyse der Software liefert die Reihenfolge der zu betrachtenden Anwendungen und sortiert die Pflegetiefe pro System.

Pflichtelemente eines Wiederanlaufplans

Disaster Recovery für KRITIS in der Praxis

Disaster Recovery für KRITIS ist mehr als Backup-Management. Es umfasst Architektur, Verfahren, Werkzeuge und Übung — von der Datenwiederherstellung bis zum getesteten Failover ganzer Anwendungs-Stacks.

In der Praxis steht selten die Frage, ob ein Restore funktioniert, sondern wie lange er dauert und ob die Daten danach konsistent sind. Disaster Recovery für KRITIS folgt einer klaren Risikohierarchie und verbindet damit Backup-Architektur, Wiederherstellungsverfahren und gelebte Test-Kultur zu einem belastbaren Gesamtwerk. Der DR-Plan für KRITIS bündelt die Restore-Verfahren je Anwendung in einem konsolidierten Dokument, das gemeinsam mit dem Wiederherstellungsplan der laufenden IT-Wartung gepflegt wird. Genau diese Pflege entscheidet, ob das Verfahren im Ernstfall greift oder ob die Datenkopie nutzlos im Tresor liegt.

Wie werden RTO und RPO für KRITIS-Anwendungen festgelegt?

RTO ist die Zeit, in der eine Anwendung wieder verfügbar sein muss. RPO ist der maximal akzeptierte Datenverlust gemessen am letzten Backup. Für KRITIS-Anwendungen sind beide Werte sektorabhängig festzulegen.

Klinische Patientensoftware verträgt Stunden Ausfall schwerer als ein Standard-Reporting; Pumpwerks-Steuerung muss in Minuten zurück sein. RTO und RPO werden im Sicherheitskonzept dokumentiert und im Vertrag fixiert, sonst entsteht Streit über Geld und Verantwortung im Ernstfall. In der akuten Vorfallsphase übernimmt parallel die 24/7-Bereitschaft für KRITIS-Software die Erstreaktion und schaltet auf das Recovery-Drehbuch um.

Hier hilft eine grobe Faustregel: lieber konservative Werte fixieren und übertreffen, als ehrgeizige Werte verfehlen. Die Festlegung gehört zu den kaufkritischen Entscheidungen für jeden Wiederanlaufplan KRITIS-Software, weil sich daran Architektur und Betriebsmodell ausrichten.

Welche Reihenfolge gilt beim Wiederanlauf einer KRITIS-Software?

Der Wiederanlauf folgt einer technischen Reihenfolge: erst Infrastruktur, dann Datenbanken, dann Anwendungs-Server, danach Frontends und Schnittstellen. Jeder Schritt unterliegt einer Plausibilitätsprüfung.

Diese Reihenfolge spart wertvolle Minuten, weil Komponenten erst dann gestartet werden, wenn ihre Vorgänger bereit sind. Welche Komponenten und Abhängigkeiten überhaupt im Spiel sind, beantwortet eine aktuell gehaltene SBOM-Pflege für KRITIS im Tagesbetrieb. Eine Anwendung, deren Datenbank halb gefüllt ist, liefert keine korrekten Antworten — und produziert Folgeschäden. Erfahrene Software-Architekten dokumentieren diese Reihenfolge bereits im Design, nicht erst im Krisenfall. Welche Tests die Reihenfolge nach jedem Patch verifizieren, vertieft der Beitrag zu Regressionstests in der KRITIS-Wartung.

Komponenten-Reihenfolge im Wiederanlauf

Wiederanlauftest für KRITIS — Methodik und Nachweis

Ein Wiederanlauftest KRITIS prüft, ob das dokumentierte Verfahren in der Realität greift. Ohne Tests bleibt der Plan eine Behauptung — und im Audit wirkt er auch genau so.

Der erste Wiederanlauftest KRITIS deckt fast immer Lücken auf, die Theorie und Praxis trennen: fehlende Zugänge, vergessene Abhängigkeiten, falsche Konfigurationen. Genau das ist der Sinn der Übung. Reife Disaster-Recovery-Programme testen jährlich zumindest stichprobenartig — und alle paar Jahre vollständig. Eine durchdachte IT-Compliance-Strategie ordnet diese Tests in den Gesamtrahmen aus DSGVO, BSIG und Branchenrecht ein. Die Resultate fließen in das Risikoregister, wo sie bei jedem Audit Stichproben standhalten müssen. Eine belastbare Disaster Recovery KRITIS lebt vom Wechselspiel aus Übung, ehrlicher Befundlage und konsequenter Nachsteuerung.

Wiederanlauftests auditfähig dokumentieren

Auditfähig dokumentieren bedeutet, jeden Test nachvollziehbar mit Datum, Beteiligten, Ablauf und Ergebnis abzulegen. Abweichungen vom Soll werden eingestuft und Korrekturen nachgehalten.

Die Aufsicht erwartet keine perfekten Tests, sondern ehrliche Befunde mit klarer Folgemaßnahmen-Liste. Wer Lücken offen dokumentiert und schließt, gewinnt im Audit. Eine versionierte Test-Akte mit jährlicher Fortschreibung ist der saubere Nachweispfad. Sie zahlt sich besonders bei Lieferantenwechseln aus, weil sie den Reifegrad belegbar macht. Auch ein Restore-Test für KRITIS gehört in diese Akte, sonst verliert die Wiederherstellungsstrategie ihre Aussagekraft. In der Praxis hat sich ein dreischichtiges Format bewährt: Stichprobentest pro Quartal, Vollübung jährlich, Lessons-Learned-Runde direkt im Anschluss. Diese Rhythmik baut Routine auf — und Routine ist beim Wiederanlaufplan KRITIS-Software die wirksamste Versicherung gegen Audit-Findings.

Pflichtnachweise im Restore-Test

Wiederanlaufplan für KRITIS-Software extern beauftragen

Wiederanlaufplan KRITIS-Software extern beauftragen heißt, das Drehbuch nicht intern improvisieren, sondern als verbindlichen Liefergegenstand mit Methodik, Tests und Audit-Mappe einzukaufen.

Externe Anbieter bringen Standard-Methodik, Sektor-Erfahrung und Wiederherstellungs-Werkzeuge mit, die intern selten in der Tiefe vorhanden sind. Disaster Recovery für KRITIS in dieser Tiefe ist Vergabe-Standard für Anwendungen der höchsten Kritikalitätsklasse. Outsourcing ohne Wissensbrücke wird zur Black Box und erschwert spätere Audits — Wissens-Transfer und Übergabe-Dokumentation gehören in jeden Vertrag. Bei der Auswahl gilt: nicht das billigste, sondern das übergabefähigste Angebot wählen, wenn ein Wiederanlaufplan KRITIS-Software erstellt werden soll. Für die laufende Pflege liefert der Service Maintenance, Wartung und Support den passenden Rahmen, in den ein Wiederanlaufplan KRITIS-Software organisch eingebettet wird.

Wiederanlauftests für KRITIS in Vergaben verankern

Vergabestellen sollten Wiederanlauftests für KRITIS als Mindestinhalt der Eignungsanforderungen aufnehmen — Methodik, Frequenz, Reporting-Tiefe und Eskalationsregeln im Klartext.

Schwammige Klauseln führen zu Streit über Test-Tiefe und Pflege. Präzise Klauseln definieren, wie oft getestet wird, welche Szenarien abzudecken sind und welche Berichte standardmäßig geliefert werden. Eine reife Wiederherstellungsstrategie wird im Vertrag wie ein Liefergegenstand behandelt, nicht wie ein Anhang.

So entsteht ein Recovery-Plan für KRITIS-Software, der Aufsicht, Geschäftsführung und Betrieb gleichermaßen entlastet. Ein Restore-Test KRITIS pro Jahr schlägt am Ende jeden gut formulierten Absatz im Lastenheft, weil nur die Übung die Realität spiegelt. So wird das Vergabeverfahren zur Qualitätssicherung in eigener Sache, weil jede Forderung im Lastenheft am späteren Wiederanlauftest KRITIS gemessen wird.

Mindestinhalte einer Wiederanlauf-Klausel

FAQs

Wie wird Datenkonsistenz nach dem Wiederanlauf einer KRITIS-Software sichergestellt? keyboard_arrow_down keyboard_arrow_up
Datenkonsistenz nach dem Wiederanlauf wird durch Backup-Validierung, Konsistenz-Checks der Datenbank, Abgleich mit Vorsystemen und Stichproben aus dem fachlichen Datenbestand gesichert. Inkonsistenzen werden protokolliert, eingestuft und vor der Freigabe entweder behoben oder dokumentiert akzeptiert. Diese Schritte gehören in jedes Restore-Protokoll für KRITIS-Anwendungen.
Welche Anforderungen stellt das BSI an den Wiederanlaufplan einer KRITIS-Software? keyboard_arrow_down keyboard_arrow_up
Das BSI verlangt einen dokumentierten, getesteten und mit definierten Verantwortlichkeiten hinterlegten Wiederanlaufplan, der RTO und RPO pro Anwendung, Restore-Reihenfolge, Backup-Quellen und Eskalationsketten enthält. Die Tests müssen mindestens jährlich nachweisbar sein und ihre Ergebnisse in das Risikoregister einfließen, wo sie Audit-Stichproben standhalten.
Wie unterstützt TenMedia bei Wiederanlaufplänen für KRITIS-Software? keyboard_arrow_down keyboard_arrow_up
TenMedia begleitet KRITIS-Betreiber beim Aufbau eines anwendungsspezifischen Wiederanlaufplans, von der Abhängigkeitsanalyse über die Festlegung von RTO und RPO bis zur Restore-Choreografie pro Komponente. Tests werden in segmentierten Stages aufgesetzt, beobachtet und revisionssicher dokumentiert. Übergaben und Wissens-Transfer sind vertraglich verankert, damit interne Teams jederzeit übernehmen können. Reporting-Pakete liefern monatliche Übersichten zu Test-Stand, offenen Maßnahmen und Reifegrad. Aufwandsbasierte Verträge passen die Leistung flexibel an Sektor, Lebenszyklus und Audit-Termine an. So entsteht ein belastbarer und auditfester Wiederanlaufplan für KRITIS-Software.