Wiederanlauftest: Was im Protokoll stehen muss, damit RTO und RPO belegt sind
In diesem Gastbeitrag geht Chris Müller von KaitoSec auf den Abgleich der geforderten Verfügbarkeit der IT-Services auf Basis der Business Impact Analyse mit den tatsächlich nachweisbaren Verfügbarkeiten auf der Basis von Wiederherstellungstests ein. Der Beitrag macht die Gefahren durch unklare oder auch unscharfe Definition der Begrifflichkeiten in Unternehmen deutlich.
Problemstellung
Nach einem Angriff überschritten 76 Prozent der Organisationen in einer Befragung ihre Vorgabe für den zulässigen Datenverlust, 64 Prozent ihre Vorgabe für die Wiederanlaufzeit. In den Gap-Berichten derselben Häuser stehen dieselben Werte auf grün oder als kleine, bekannte Lücke. Das passt zusammen, sobald man sieht, woher die Zahlen kommen. Im Bericht steht, was jemand geantwortet hat. Im Ernstfall zählt, was jemand gemessen hat.
Den Messwert können Sie sich vorher besorgen, im Wiederanlauftest. Er ist allerdings nur so viel wert wie die Strecke, die das Protokoll abbildet. Ich zeige, welche Felder dafür hineingehören, und stelle ein vollständig ausgefülltes Beispiel daneben.
Ein Kürzel, drei Aussagen
In der BCM-News-Enzyklopädie ist der RTO die zeitliche Wiederanlaufanforderung für Prozesse und Ressourcen. Dieser Satz ist der Grund für einen guten Teil der irreführenden Werte. Denn dasselbe Kürzel bezeichnet dreierlei: was der Geschäftsprozess braucht, was ein Service dafür leisten muss und was ein System heute leisten kann. Drei Aussagen, eine Abkürzung, am Ende eine Spalte in der Auswertung.
Ich erhebe deshalb in drei Stufen. Das kostet einen Arbeitsschritt mehr. Dafür lässt sich später sagen, woher eine Zahl stammt.
Stufe 1, die Prozess-BIA. Der Fachbereich schätzt den Schaden über die Zeit und legt je Geschäftsprozess fest, wie lange der Ausfall höchstens dauern darf (MTPD), bis wann der Prozess wieder laufen muss (RTO) und auf welchem Niveau er im Notbetrieb arbeitet. Technik kommt hier nicht vor. Wie man diese Werte im Gespräch mit dem Fachbereich erhebt, ohne dass am Ende überall vier Stunden stehen, ist eine eigene Frage; ich habe sie unter RTO, RPO und MTPD mit dem Fachbereich festlegen aufgeschrieben.
Stufe 2, die Prozess-Technik-BIA. Derselbe Fachbereich schaut auf die Anwendungen und Services, die den Prozess tragen, und sagt je Service, was er braucht: Welches RTO und welches RPO muss dieser Service liefern, damit der Prozess seine Zeit hält? Das ist eine Forderung, noch kein technischer Wert.
Stufe 3, die Technik-BIA. Jetzt erst kommen die Leute an den Tisch, die die Systeme betreiben. Sie sagen, welches RTO und welches RPO heute erreichbar ist, mit dem Verfahren, das wirklich läuft, und nicht mit dem, das im Konzept steht. Für diese beiden Werte gibt es eigene Namen: RTA (Recovery Time Actual) für die erreichbare Wiederanlaufzeit und RPA (Recovery Point Actual) für den zugesicherten maximalen Datenverlust. RTO und RPO sind die Vorgabe, RTA und RPA die Fähigkeit.
In ISO 22317 entsprechen Stufe 1 und 2 der Ebene der Prozesse und der Ebene ihrer Ressourcen. Stufe 3 erhebt keine Anforderung, sondern eine Fähigkeit, und gehört damit ins IT-Service-Continuity-Management.
Der Abstand zwischen Stufe 2 und Stufe 3 ist die erste Lücke, und sie ist die billigste von allen. Sie entsteht am Tisch, ohne Test, einfach dadurch, dass Forderung und Auskunft nebeneinander stehen. Fehlt die Trennung, steht je System eine einzige Zahl im Bericht, und ein Jahr später weiß niemand mehr, ob sie ein Wunsch war oder eine Zusage.
Was die Erhebung nicht zeigt
Drei Lücken bleiben auch dann offen, wenn alle drei Stufen sauber gefüllt sind. Sie erklären, warum im Ernstfall Werte reißen, die auf dem Papier gehalten haben.
Beide Seiten meinen etwas anderes. Sie fragen die Technik nach dem RTO, und die Antwort lautet vier Stunden. Gemeint sind vier Stunden ab dem Moment, in dem die Ausweichumgebung steht, die Freigabe vorliegt und jemand Zeit hat. Oder vier Stunden ab der Aufnahme des Tickets, der ersten Fehleranalyse und der Feststellung, dass ein IT-Ausfall vorliegt. Der Fachbereich hat nach einem Service gefragt, mit dem sich arbeiten lässt. Die Zahl ist dieselbe, die Strecke dahinter ist es nicht. Ein Teil davon lässt sich am Tisch klären: Zu jeder Zeitangabe der Technik gehören der Startpunkt, der Endzustand und die Vorbedingungen. Was vor dem Startpunkt liegt, wird als eigene Strecke mit eigener Zeit geführt und dazugerechnet, und erst diese Summe lässt sich mit der Forderung vergleichen. Ob sie stimmt, zeigt der Test, in dem die Uhr über die ganze Strecke läuft.
Die Kette hält nicht, obwohl jedes Glied hält. Systeme laufen nacheinander an, weil eines das andere braucht, und vor dem ersten Handgriff liegen Erkennung, Entscheidung und Beauftragung. Die RTO-Werte der Systeme ergeben zusammen deshalb nicht den RTO des Prozesses, sie reihen sich aneinander. Beim Datenverlust ist die Rechnung noch einfacher: Für den Prozess gilt der schlechteste RPO-Wert der Kette, nicht der Wert der Anwendung, mit der der Fachbereich arbeitet.
Manche Systeme stehen in keiner Stufe. In Stufe 2 nennt der Fachbereich die Anwendungen, mit denen er arbeitet. Der Schnittstellenserver zwischen Kundenportal und ERP, der Verzeichnisdienst, der Druckdienst für die Lieferscheine: Diese Systeme nennt niemand, weil niemand an ihnen sitzt. Sie haben keine Forderung, keine Auskunft und stehen in keinem Gap-Bericht. Systematisch schließt diese Lücke das IT-Service-Continuity-Management nach ISO/IEC 27031, das die Anforderung des Prozesses im Informationsverbund vertikal und horizontal vererbt. Im Wiederanlauf entscheiden sie trotzdem mit, wann der Prozess wieder läuft und wie viele Daten fehlen.
Daraus ergibt sich der Aufbau des Protokolls. Neben Forderung und Auskunft kommt eine dritte Spalte, der gemessene Wert. Daneben stehen die Zeilen, die überhaupt erst im Test auftauchen.
Für welchen Fall die Zahl gilt
Alles bisher Gesagte unterstellt Fall 1: Ein System fällt aus, die Sicherung ist intakt, und die Technik spielt zurück. Für diesen Fall lässt sich eine Zeit zusichern und im Test belegen.
In Fall 2 sind Daten verschlüsselt oder beschädigt, und dann gilt das nicht. Erst muss jemand beurteilen, welcher Stand sauber ist, und Verzeichnis- und Identitätsdienste müssen oft neu aufgebaut werden, bevor die erste Fachanwendung starten darf. Die Erfahrung aus Ransomware-Vorfällen zeigt Wiederherstellungszeiten von Tagen bis Wochen. Ein tragfähiger RTO lässt sich dafür ehrlicherweise nicht zusichern.
Beim Datenverlust ist es ähnlich, und nicht nur nach einem Angriff: Auch ein Fehler in der Produktion, der tagelang unbemerkt mitgesichert wurde, führt zurück auf ältere Stände. Der Verlust bemisst sich dann am letzten sauberen Stand, und wie weit die Sicherungen zurückreichen, entscheidet darüber, ob es ihn noch gibt. Muss ein System der Kette zurück, müssen die anderen dazu passen. Für den Prozess gilt der älteste saubere Stand der Kette.
Fall 1 und Fall 2 im Vergleich, schematisch
Jede Auskunft der Technik braucht deshalb die Angabe, für welchen der beiden Fälle sie gilt. Und ein Protokoll belegt den Fall, der geprobt wurde, und keinen anderen.
Lässt sich für Fall 2 keine Zeit zusichern, verschiebt sich die Aufgabe von der Technik zum Fachbereich. Dann zählt, wie lange und auf welchem Niveau er ohne das System arbeiten kann, mit Formularen, Listen oder einem Ersatzverfahren. Trägt das nicht über die Tage oder Wochen, die eine solche Wiederherstellung dauert, ist die MTPD in diesem Fall nicht zu halten. Das gehört vor die Geschäftsführung. Sie entscheidet, ob sie eine schnellere Wiederherstellung bezahlt, den Betrieb ohne System ausbaut oder das Risiko ausdrücklich trägt. Proben lässt sich Fall 2 in Teilen: den letzten sauberen Stand bestimmen, die Identitätsdienste neu aufbauen, aus einem älteren Stand zurückspielen und den Betrieb ohne System mit dem Fachbereich durchspielen.
Der Startpunkt der Uhr
Ab wann der RTO zählt, legen die Standards nicht eindeutig fest. Die Auslegungen reichen vom Eintritt des Ausfalls über die tatsächliche Unterbrechung des Prozesses bis zur förmlichen Feststellung, worauf BCM-News schon 2011 hingewiesen hat. Für das Protokoll ist zweitrangig, welche Auslegung ein Haus wählt. Wichtig ist, dass sie dransteht und in fünf Jahren noch dieselbe ist. Ich rechne ab dem Eintritt, weil die maximal tolerierbare Ausfallzeit ab dort läuft. Der Schaden beginnt später, nämlich wenn ein Prozess den ausgefallenen Service braucht. Fällt er nachts oder am Wochenende aus und ruht der Prozess, gewinnt die Technik Zeit; fällt er im Monatsabschluss aus, bleibt weniger. Deshalb gehört zum Ergebnis auch das Zeitfenster, in dem der Test lief. In Fall 2 liegt der Eintritt oft vor der Erkennung; ins Protokoll gehören dann beide Zeitpunkte.
Ein technischer Wiederanlauftest fängt später an, meist mit dem Auftrag an das Wiederanlaufteam. Dagegen ist nichts zu sagen, solange das Protokoll die fehlenden Abschnitte ausweist, statt sie stillschweigend zu überspringen.
| Abschnitt | Was gemessen wird | Woher der Wert kommt |
| Eintritt bis Erkennung | Zeit bis zur ersten belastbaren Meldung | Alarmierungsübung oder Auswertung eines echten Vorfalls |
| Erkennung bis Entscheidung | Zeit bis zur Notfall-Aktivierung | Alarmierungsübung, Protokoll des Krisenstabs |
| Entscheidung bis Auftrag | Zeit bis zur Beauftragung des Wiederanlaufteams | Alarmierungsübung |
| Auftrag bis technische Wiederherstellung | Kernstück des funktionalen Tests | dieser Test |
| Technische Wiederherstellung bis fachliche Freigabe | Freigabetest im Fachbereich | dieser Test |
Wenn Sie die ersten drei Zeilen in diesem Test nicht messen können, tragen Sie die Werte der letzten Alarmierungsübung ein, mit Datum, und rechnen sie hinzu. Das Ergebnis heißt dann rechnerisch und nicht gemessen. Wer das Protokoll später liest, sieht damit sofort, welcher Teil der Strecke geübt wurde und welcher aus einer anderen Quelle stammt.
Den Datenverlust in Aufträgen zählen
Das RPO ist der Datenverlust, den Sie nach der Wiederherstellung tatsächlich vor sich haben, gezählt in Aufträgen, Buchungen oder Dokumenten. Das Alter der jüngsten Sicherung sagt das nur ungefähr, weil die Systeme einer Kette in unterschiedlichen Zyklen gesichert werden.
Messen lässt es sich mit Datenmarken. Vor dem Test legen die Beteiligten in jedem System der Kette Datensätze mit bekanntem Zeitstempel an, etwa vier Stunden, zwei Stunden, eine Stunde, dreißig, fünfzehn und fünf Minuten vor dem gesetzten Eintrittszeitpunkt. Nach der Wiederherstellung schaut jemand nach, welche Marken noch da sind. Die älteste fehlende Marke zeigt den Datenverlust, der Abstand zwischen den Marken zeigt, wie genau die Aussage ist. Beides gehört ins Protokoll, und bewertet wird der ungünstigere Wert.
Setzen Sie die Marken auch in die Systeme, für die niemand eine Forderung erhoben hat. Dort entsteht meistens der Wert, der am Ende für den ganzen Prozess gilt. Wer Fall 2 probt, staffelt die Marken über Tage statt über Stunden. Dann zeigt derselbe Test, wie weit der letzte saubere Stand zurückliegt.
Eine zweite Zahl fehlt fast immer: Was kostet es, den verlorenen Zeitraum nachzuerfassen, wer macht das, und woher kommen die Daten dafür? Erfassen die Fachbereiche während der Störung von Hand weiter, ist das der Notbetrieb selbst. Das Nachtragen der verlorenen Vorgänge nach der Wiederherstellung gehört zur Rückkehr in den Normalbetrieb. Beides kostet dieselben Leute Zeit, und beides steht selten im Plan.
Die fachliche Freigabe beendet den Wiederanlauf
Der Wiederanlauf ist zu Ende, wenn die Prozessverantwortung sagt: Wir können arbeiten. Damit das mehr ist als ein Nicken in die Runde, legen Sie vorher fest, woran sie das festmacht. Fünf bis acht Fachfälle reichen, wenn sie den Notbetrieb abdecken: einen Vorgang anlegen, einen abschließen, einen stornieren, eine Übergabe an ein Nachbarsystem, eine Auskunft an einen Kunden. In Fall 2 prüft der Fachbereich dabei auch, ob die Daten stimmen, etwa in Stichproben gegen Belege, und nicht nur, ob die Anwendung läuft.
Ins Protokoll kommt je Fachfall das Ergebnis, dazu die Uhrzeit, die Rolle der Person, die freigibt, und wofür die Freigabe nicht gilt. Ohne diesen Block ist der gemessene RTO eine Aussage des IT-Betriebs über den IT-Betrieb.
Was im Test ersetzt war, bleibt ungeprüft
Kein Test bildet den Ernstfall ganz ab, und das muss er auch nicht. Er muss nur sagen, was er ausgelassen hat: die Schnittstelle des Dienstleisters, die durch ein Testsystem ersetzt war. Den Verzeichnisdienst, der einfach lief. Den angekündigten Termin. Die vollständig besetzten Teams am Dienstagvormittag. Jede dieser Stellen ist ein Stück Wiederanlauf, über das der Test nichts aussagt. Dazu gehört auch, welcher der beiden Fälle geprobt wurde.
Ein ausgefülltes Beispiel
So sieht das ausgefüllt aus. Der Betrieb ist erfunden, ein Mittelständler aus der Fertigung; geprüft wurde die Auftragsannahme.
Kopf
| Feld | Eintrag |
| Prozess | Auftragsannahme und Versandvorbereitung |
| Prozessverantwortung | Leitung Auftragsabwicklung |
| MTPD (Stufe 1) | 24 Stunden |
| RTO des Prozesses (Stufe 1) | 8 Stunden |
| RPO des Prozesses (Stufe 1) | 1 Stunde |
| Notbetriebsniveau | Auftragsannahme und Lieferschein für Bestandskunden, 50 Prozent der Tagesmenge, keine Reklamations- und Retourenbearbeitung, längstens 5 Arbeitstage |
| Tragende Services (Stufe 2) | ERP-Auftragsmodul, Kundenportal beim Dienstleister, Übergabe an den Versanddienstleister |
| In Stufe 2 nicht erhoben, im Test aufgefallen | Schnittstellenserver zwischen Kundenportal und ERP, Druckdienst für Lieferscheine |
| Testart | funktionaler Wiederanlauftest, angekündigt |
| Szenario | Fall 1: Ausfall des Speichersystems unter ERP-Datenbank und Schnittstellenserver, Rückspielung aus intakter Sicherung |
| Beteiligte | IT-Betrieb, Anwendungsbetreuung ERP, drei Personen aus der Auftragsabwicklung, eine Beobachterin ohne Rolle im Ablauf |
Zeitachse
| Uhrzeit | Abschnitt | Dauer | Bemerkung |
| 08:00 | gesetzter Eintritt | im Drehbuch angenommen, nicht geübt | |
| 09:00 | Auftrag an das Wiederanlaufteam, Teststart | ||
| 09:00 bis 10:35 | Ausweichumgebung bereitgestellt | 1:35 | |
| 09:10 bis 10:05 | Sicherungskopie prüfen und freigeben | 0:55 | parallel |
| 10:35 bis 13:10 | Rückspielung ERP-Datenbank, Anwendung nutzbar | 2:35 | |
| 13:10 bis 13:55 | Wiederanlauf Schnittstellenserver | 0:45 | in der Planung nicht vorgesehen |
| 13:55 bis 15:05 | fachlicher Freigabetest | 1:10 | |
| 15:05 | fachliche Freigabe für das Notbetriebsniveau |
Erkennung und Entscheidung waren in diesem Test nicht dabei. Aus der Alarmierungsübung vom 14. April 2026 liegen dafür 41 Minuten bis zur belastbaren Meldung und 22 Minuten bis zur Notfall-Aktivierung vor. Mit ihr wurde zugleich das Wiederanlaufteam beauftragt. Die Stunde, die im Drehbuch zwischen Eintritt und Teststart steht, ist nur eine Annahme. Gerechnet wird mit den gemessenen 63 Minuten. Die Prüfung der Sicherungskopie läuft parallel zum Aufbau der Ausweichumgebung; deshalb ergeben die Abschnitte zusammen 6:05 und nicht mehr.
Forderung, Auskunft, Messung
| Wert | Forderung (Stufe 2) | Auskunft (Stufe 3) | gemessen im Test | Bewertung |
| RTO des Prozesses, ab Auftrag an das Team | 8:00 | keine | 6:05 | gehalten |
| RTO des Prozesses, ab Eintritt | 8:00 | keine | 7:08 rechnerisch | gehalten, mit Werten der Alarmierungsübung |
| RTO ERP-Auftragsmodul | 6:00 | 4:00, Umgebung und Freigabe vorausgesetzt | 4:10 bis zur nutzbaren Anwendung, davon 2:35 Rückspielung | Auskunft bestätigt, misst aber nur einen Teil der Strecke |
| RPO ERP-Datenbank | 1:00 | 0:15 | bis zu 0:15 | gehalten, bei lückenloser Sicherungskette |
| RPO Schnittstellenserver | nicht erhoben | nicht erhoben | bis zu 2:00 | setzt den Datenstand des Prozesses |
| RPO Prozess | 1:00 | keine | bis zu 2:00 | verfehlt |
| Fachfälle des Notbetriebs | 5 von 5 | keine | 4 bestanden, 1 nicht durchgeführt | teilweise |
Die erste Zeile hält nur den gemessenen Abschnitt gegen die Vorgabe für die ganze Strecke. Zählen tut die zweite Zeile, weil die Uhr hier ab dem Eintritt läuft. Alle Werte zum Datenstand gelten für Fall 1, also für eine unbeschädigte Sicherung. „Bis zu 2:00" ist deshalb der günstige Fall: Muss auf einen älteren Stand zurückgegriffen werden, ist der Verlust größer.
Datenstand
| Marke gesetzt | ERP-Datenbank | Schnittstellenserver |
| 04:00 | vorhanden | vorhanden |
| 06:00 | vorhanden | vorhanden |
| 07:00 | vorhanden | fehlt |
| 07:30 | vorhanden | fehlt |
| 07:45 | vorhanden | fehlt |
| 07:55 | fehlt | fehlt |
Den Datenstand des Prozesses bestimmt das schwächste Glied der Kette. Die ERP-Datenbank sichert ihre Transaktionen alle 15 Minuten, der Schnittstellenserver wird alle zwei Stunden gesichert. Beides sind gewöhnliche, zeitgesteuerte Sicherungen auf ein getrenntes Speichersystem, keine laufende Replikation und keine unveränderliche Kopie. Die Werte gelten deshalb nur, solange die Sicherungskette lückenlos und lesbar ist. Verloren waren die Aufträge, die zwischen 06:00 und 08:00 über das Kundenportal hereingekommen waren, im Beispiel 38 Stück. Sie lagen noch beim Portalbetreiber und ließen sich von dort erneut übernehmen. Das Nacherfassen kostete 2,5 Personenstunden und stand so im Notfallplan nicht drin.
Fachliche Freigabe
| Fachfall | Ergebnis |
| Auftrag für Bestandskunden anlegen | bestanden |
| Preis und Verfügbarkeit prüfen | bestanden |
| Lieferschein erzeugen und drucken | bestanden |
| Auftrag an den Versanddienstleister übergeben | nicht durchgeführt, Schnittstelle war durch ein Testsystem ersetzt |
| Auftrag stornieren | bestanden |
Freigegeben um 15:05 durch die Leitung Auftragsabwicklung, für den Notbetrieb, mit der Einschränkung, dass die Übergabe an den Versanddienstleister ungeprüft blieb.
Geltung des Ergebnisses
- Verzeichnisdienst und Netz standen zur Verfügung. Liegen sie auf demselben Speichersystem, fallen sie im Ernstfall mit aus.
- Die Schnittstelle zum Versanddienstleister war durch ein Testsystem ersetzt.
- Der Test war angekündigt, fand an einem Werktagvormittag statt und die Teams waren vollständig besetzt.
- Erkennung und Entscheidung wurden nicht geübt, die Werte stammen aus der Alarmierungsübung vom 14. April 2026.
- Geprobt wurde Fall 1, der Ausfall bei intakter Sicherung. Für Fall 2 sagt dieses Ergebnis nichts aus.
Diese fünf Punkte sind der Grund, warum das Ergebnis oben nur unter genau diesen Bedingungen gilt.
Abweichungen
| Nr. | Befund | Einstufung | Maßnahme | Wer | Bis |
| A1 | RPO des Prozesses verfehlt, bis zu 2 Stunden gegen 1 Stunde Forderung, weil der Schnittstellenserver alle zwei Stunden gesichert wird. Gemessen bei unbeschädigter Sicherung, sonst größer | Zielverfehlung | Sicherungszyklus auf 15 Minuten verkürzen, oder die Prozessverantwortung entscheidet mit der Geschäftsführung, dass zwei Stunden Datenverlust hinnehmbar sind, und die Forderung wird geändert | IT-Betrieb und Prozessverantwortung | 31.10.2026 |
| A2 | Schnittstellenserver und Druckdienst stehen in keiner der drei Erhebungsstufen | Erhebungslücke | beide Systeme in die Prozess-Technik-BIA aufnehmen, Forderung ableiten, Auskunft der Technik einholen; bei der nächsten Erhebung die Kette entlang der Datenflüsse aufnehmen statt entlang der bedienten Anwendungen | BCM und Prozessverantwortung | 30.11.2026 |
| A3 | Auskunft der Technik zum ERP-RTO gilt nur ab bereitgestellter Umgebung und erteilter Freigabe | Geltungseinschränkung der Erhebung | Auskunftsfeld in der Technik-BIA um die Vorbedingungen ergänzen, damit Forderung und Auskunft dieselbe Strecke meinen | BCM | 30.11.2026 |
| A4 | Übergabe an den Versanddienstleister ungeprüft, Schnittstelle war ersetzt | Geltungseinschränkung | Testbeteiligung im Dienstleistervertrag verankern und den nächsten Test gemeinsam fahren | Dienstleistersteuerung | 30.11.2026 |
| A5 | Nacherfassung von 38 Aufträgen mit 2,5 Personenstunden ist in keinem Plan vorgesehen | Lücke in der Rückkehr zum Normalbetrieb | Nacherfassung in die Rückkehr zum Normalbetrieb aufnehmen und die Personen benennen, die sie übernehmen | Prozessverantwortung | 15.10.2026 |
| A6 | Erkennung und Entscheidung nicht Teil des Tests | offener Punkt | den nächsten Test beim gesetzten Eintritt beginnen und den Meldeweg mitüben | BCM-Beauftragter | nächster Testtermin |
| A7 | Für Fall 2, verschlüsselte oder beschädigte Daten, liegt keine Aussage der Technik vor; geprobt wurde nur Fall 1 | offener Punkt | Auskunft für diesen Fall einholen, mit Aufbewahrungstiefe der Sicherungen. Lässt sich keine Zeit zusichern, das festhalten und der Geschäftsführung vorlegen | BCM-Beauftragter und IT-Betrieb | 31.12.2026 |
| A8 | Das Notbetriebsniveau setzt das wiederhergestellte ERP voraus und trägt längstens 5 Arbeitstage. Für Fall 2 gibt es kein Verfahren, mit dem die Auftragsannahme ohne ERP arbeitet | offener Punkt | Mit der Prozessverantwortung festlegen, wie Aufträge ohne ERP angenommen werden und wie lange das trägt. Das Ergebnis zusammen mit der MTPD von 24 Stunden der Geschäftsführung vorlegen | Prozessverantwortung und BCM-Beauftragter | 31.12.2026 |
Wohin die Abweichungen zurücklaufen
Fünf Einstufungen reichen, und jede hat einen anderen Adressaten.
Eine Zielverfehlung heißt: Der gemessene Wert liegt über der Forderung. Sie geht an die Technik und an die Prozessverantwortung zusammen, denn es gibt zwei Auswege. Entweder wird die Fähigkeit besser, oder die Forderung wird kleiner.
Eine Erhebungslücke heißt: Ein System bestimmt die Zeiten mit, steht aber in Stufe 2 und Stufe 3 nicht drin. Die geht zurück in die BIA und nicht an das Wiederanlaufteam. Das ist die wertvollste Zeile im ganzen Protokoll, weil sie erklärt, warum der letzte Gap-Bericht grün war.
Eine Geltungseinschränkung heißt: Der Wert hat gehalten, aber nur, weil etwas ersetzt war, einfach zur Verfügung stand oder nur Fall 1 geprobt wurde. Sie wird zur Bedingung im nächsten Testauftrag.
Eine Ablaufabweichung heißt: Es lief anders als im Plan beschrieben, ohne dass ein Wert gerissen wurde. Dann wird der Plan nachgezogen.
Alles Übrige ist ein offener Punkt mit Termin.
Jede Zeile bekommt eine Person und ein Datum und wandert in dasselbe Maßnahmenregister, in dem auch die Auditfeststellungen stehen. Dass ein Testprotokoll Soll und Ist gegenüberstellt und Handlungsempfehlungen trägt, gehört zu den Anforderungen an die Bewertung von Tests und Übungen, die auf BCM-News schon 2014 beschrieben wurden. Ein Protokoll, das im Berichtsordner endet, ist den Aufwand des Tests nicht wert.
Zwei Ergebnisse gehören nach oben. Liegt ein gemessener Wert über der MTPD, entscheidet die Geschäftsführung, ob sie die Fähigkeit bezahlt oder die Vorgabe ändert. Dasselbe gilt, wenn sich für Fall 2 keine Zeit zusichern lässt und der Betrieb ohne System nicht über die MTPD trägt. Soll eine Zielverfehlung dadurch aufgelöst werden, dass die Forderung sinkt, entscheidet das die Prozessverantwortung. Und wenn eine Forderung sinkt, zieht die Schutzbedarfsfeststellung für Verfügbarkeit im ISMS nach. Sonst laufen die beiden Managementsysteme auseinander. Wie man die Verfügbarkeitsstufen im ISMS führt, ohne sie doppelt zu pflegen, ist dann eine Frage an die Schutzbedarfsfeststellung und nicht mehr an das Testprotokoll.
Neun Schritte, damit die Werte im Ernstfall halten
Dass 76 und 64 Prozent ihre Vorgaben verfehlen, ist ein Symptom. Die Ursache liegt davor: Die Werte waren Zusagen für Fall 1, und gemessen hat sie niemand. Die Befragung, die auch der Daily Digest vom 2. September aufgegriffen hat, stellt unveränderliche Sicherungen als letzte Verteidigungslinie heraus; 16 Prozent setzen sie ein. Eine solche Kopie sorgt dafür, dass es nach einem Angriff überhaupt noch einen Stand gibt. Sie macht ihn nicht sauber, und sie verkürzt keine Minute der Wiederanlaufzeit. Wie groß der Datenverlust wird, zeigt dieselbe Befragung: Nur 39 Prozent der Angegriffenen konnten mindestens drei Viertel ihrer Daten rekonstruieren. Auch „unveränderlich" ist deshalb eine Auskunft, die mit Szenario und Vorbedingungen in die Erhebung gehört und im Test belegt wird. Die ersten vier Schritte gehören in die Erhebung, die nächsten drei in den Test, die letzten zwei in die Auswertung.
- Forderung und Fähigkeit getrennt führen. Tragen Sie je Service ein, was der Fachbereich fordert (RTO und RPO), und je System, was die Technik heute erreicht (RTA und RPA). Beides steht in zwei Spalten nebeneinander, damit die Lücke sichtbar bleibt.
- Jede Zeitangabe der Technik vollständig erfragen. Fragen Sie, ab welchem Moment die Zeit zählt, welcher Zustand am Ende erreicht ist, was vorher erledigt sein muss und für welchen Fall die Angabe gilt. Rechnen Sie alles, was vor dem Startpunkt liegt, als eigene Strecke dazu. Erst diese Summe lässt sich mit der Forderung vergleichen.
- Für Fall 2, verschlüsselte oder beschädigte Daten, eine eigene Aussage treffen. Klären Sie mit der Technik, wie weit die Sicherungen zurückreichen und wie sich der letzte saubere Stand für alle Systeme der Kette bestimmen lässt. Lässt sich für diesen Fall keine Zeit zusichern, steht genau das im Bericht, und nicht die Zahl aus Fall 1. Halten Sie dann daneben fest, wie lange der Fachbereich ohne das System arbeiten kann. Reicht das nicht, entscheidet die Geschäftsführung.
- Die Kette entlang der Datenflüsse erheben und als Ganzes rechnen. Nehmen Sie alle Systeme auf, durch die die Daten des Prozesses laufen, auch Schnittstellen und Dienste, an denen niemand arbeitet. Für den Prozess zählen die Zeiten der Systeme entlang der Anlaufreihenfolge zusammen, und beim Datenverlust gilt der schlechteste Wert.
- Den Startpunkt der Uhr und das Zeitfenster festlegen. Legen Sie einmal für alle Tests fest, ab wann die Wiederanlaufzeit zählt, am besten ab dem Eintritt der Störung. Schreiben Sie in jedes Protokoll, ab wann gemessen wurde und zu welcher Zeit der Test lief, denn ein Ausfall am Sonntagabend trifft den Betrieb anders als einer im Monatsabschluss.
- Den Datenverlust an Datenmarken messen. Setzen Sie vor dem Test Datensätze mit bekanntem Zeitstempel in jedes System der Kette und zählen Sie nach der Wiederherstellung, welche fehlen. Halten Sie dann fest, wie viele Vorgänge nachzutragen sind, wer das übernimmt und woher die Daten dafür kommen.
- Das Ende des Wiederanlaufs vom Fachbereich bestätigen lassen. Legen Sie vor dem Test fünf bis acht Fachfälle fest, an denen die Prozessverantwortung prüft, ob sich arbeiten lässt. In Fall 2 prüft sie auch, ob die Daten stimmen. Die Uhr stoppt mit dieser Freigabe und nicht mit dem Start des Systems.
- Ins Protokoll schreiben, wofür das Ergebnis gilt. Halten Sie fest, welcher der beiden Fälle geprobt wurde, in welchem Zustand die Sicherung war und was im Test ersetzt oder vorausgesetzt wurde. Für alles andere sagt das Ergebnis nichts aus.
- Jede Abweichung einstufen und einer Person mit Termin zuordnen. Eine verfehlte Vorgabe geht an Technik und Prozessverantwortung, ein System, das in der Erhebung fehlte, zurück in die BIA. Liegt ein gemessener Wert über der maximal tolerierbaren Ausfallzeit, entscheidet die Geschäftsführung, ob sie die Fähigkeit bezahlt oder die Vorgabe ändert.
Der erste Schritt kostet eine Stunde und keinen Test: Schreiben Sie für Ihre drei kritischsten Prozesse Forderung und Fähigkeit nebeneinander und markieren Sie die Zeilen, in denen Startpunkt, Vorbedingungen oder Szenario fehlen.
Quellen:
- Befragung von Omdia im Auftrag eines Anbieters für unveränderlichen Speicher, referiert bei it-daily.net: Unveränderliche Backups, abgerufen am 10. September 2026
- BCM-News: BCM-News Daily Digest vom 2. September 2026
- Matthias Hämmerle, BCM-News: BCM-Glossar des BCI in der zweiten Auflage erschienen, über das Wirrwarr der BCM-Begriffe, 20. Dezember 2011
- Torsten Zacher, BCM-News: Anforderungen an die Bewertung von Tests und Übungen, 23. Juni 2014
- BCM-News-Enzyklopädie: RTO und RPO
Zu den Begriffen: RPO ist die Wiederherstellungsanforderung für Daten, erhoben in der BIA. Beim RTO trägt dieser Text die Ebene mit, also Prozess, Service oder System. Wer nach BSI-Standard 200-4 arbeitet, findet den RTO des Prozesses dort als Wiederanlaufzeit (WAZ) und die MTPD als maximal tolerierbare Ausfallzeit (MTA). ISO 22301 verlangt in Kapitel 8.5 ein Übungsprogramm und in Kapitel 8.6 die Bewertung der Continuity-Fähigkeiten. Ein Protokoll mit Forderung, Auskunft, Messwert, Zeitachse, Datenstand, fachlicher Freigabe und Geltungseinschränkungen erfüllt beides und ist zugleich der Wirksamkeitsnachweis, nach dem ein Auditor fragt.
Über den Autor: Chris Müller ist Information Security Manager sowie CEO und Mitgründer von KaitoSec, einer Plattform für Informationssicherheit, Risikomanagement und Business Continuity Management. Kontakt und weitere Beiträge auf LinkedIn.