• Dänemark: Melderegister in Dänemark mit Millionen Nutzerdaten gehackt | DIE ZEIT
  Bei einem Hackerangriff auf das dänische Melderegister haben sich Unbekannte Zugriff auf Daten von 8,8 Millionen Menschen verschafft. Dies teilte das Digitalministerium mit
• »Killsec«: 16-Jähriger soll zentrale Rolle in Ransomware-Gruppe haben - DER SPIEGEL
  Ein 16 Jahre alter Jugendlicher soll der Kopf einer Hackerbande sein, die mit zuvor entwendeten Daten hohe Lösegelder kassiert haben soll. Die Cybercrimegruppe soll weltweit rund tausend Angriffe zum Diebstahl sensibler Daten verübt haben, 70 davon in Deutschland, wie die Polizei in Hamburg am Donnerstag mitteilte

Der Beitrag BCM-News Daily Digest erschien zuerst auf Business Continuity Management News.

• Vodafone Bußgeld: 400.000 Euro nach Ransomware-Angriff - datenschutzticker.de
  Ein Vodafone Bußgeld in Höhe von insgesamt 400.000 Euro zeigt, wie eng Auftragsverarbeitung und IT-Sicherheit nach der Datenschutz-Grundverordnung (DSGVO) zusammenhängen. Die spanische Datenschutzaufsicht Agencia Española de Protección de Datos (AEPD) sanktionierte Vodafone España nach einem Ransomware-Angriff auf einen Call-Center-Dienstleister. Neben Sicherheitsmängeln spielte dabei eine entscheidende Rolle, dass die Vereinbarung zur Auftragsverarbeitung erst nach dem Vorfall unterzeichnet worden war.
• Grenzenlose Notfall-Kommunikation: EU plant Breitbandnetz für Einsatzkräfte | heise online
  Ob verheerende Waldbrände, grenzüberschreitende Verfolgungsjagden, Flutkatastrophen oder gezielte Angriffe auf kritische Infrastrukturen: Wenn Polizei, Feuerwehr, Rettungsdienste und Katastrophenschutz schnell reagieren müssen, entscheidet jede Sekunde. Bislang stoßen Einsatzkräfte bei länderübergreifenden Einsätzen aber regelmäßig an technische Grenzen. Um diese Sicherheitslücke zu schließen, hat die EU-Kommission am Mittwoch das "EU Critical Communication System" (EUCCS) vorgeschlagen

Der Beitrag BCM-News Daily Digest erschien zuerst auf Business Continuity Management News.

• Hamburgische Bürgerschaft betont Bedeutung resilienter Stadt
  Vier Tage nach Abschluss der Militärübung «Red Strom Charlie» in Hamburg haben Vertreter aller Fraktionen in der Hamburgischen Bürgerschaft die Bedeutung einer resilienten Stadt in Zeiten von Krisen und Bedrohungen betont
• LMU-Hackerangriff trifft 600.000 Personen
  Nach dem Hacker-Angriff auf die Ludwig-Maximilians-Universität (LMU) in München sind rund 600.000 Datensätze von aktuellen und ehemaligen Studierenden betroffen. Nach neuesten forensischen Erkenntnissen war der gesamte Datenbestand im Zulassungssystem betroffen, in dem sämtliche Daten der Studierenden verarbeitet werden, wie die LMU mitteilte. Die Immatrikulationsdaten reichen demnach etwa 50 Jahre zurück

Der Beitrag BCM-News Daily Digest erschien zuerst auf Business Continuity Management News.

• Flink: Hacker erpressen Kunden nach Datenleck
  Zusätzlich schreiben die Angreifer betroffene Kunden direkt an. "Wenn Sie sich weigern, bis zum 2. Oktober 0,005 ETH (etwa 10 Euro) zu zahlen, werden Ihre persönlichen Daten im Darknet verkauft. Sie können diese E-Mail an Flink weiterleiten, um deren Aufmerksamkeit zu bekommen", heißt es in der Nachricht. Werden neben dem Unternehmen auch die Betroffenen selbst erpresst, spricht man von dreifacher Erpressung

Der Beitrag BCM-News Daily Digest erschien zuerst auf Business Continuity Management News.

• Risiko- und Krisenmanagement in der Ernährungsindustrie 2026
  Wie gut ist die deutsche Ernährungsindustrie auf Krisen und wachsende Risiken vorbereitet? Die neue Studie der AFC Risk & Crisis Consult GmbH und der Bundesvereinigung der Deutschen Ernährungsindustrie (BVE) zum Risiko- und Krisenmanagement in der Ernährungsindustrie untersucht, wie Unternehmen mit den zunehmenden Herausforderungen in einer komplexen und global vernetzten Wirtschaft umgehen
• Bruttoinlandsprodukt: Hitze kostet Europa 113 Milliarden Euro
  Die Hitzewelle dieses Sommers hat die europäische Wirtschaftsleistung für das laufende Jahr nach Schätzung der Allianz um 113 Milliarden Euro reduziert. Deutschland liegt dabei mit geschätzten Einbußen von 25 Milliarden auf Platz zwei hinter Italien mit 28 Milliarden Euro, wie der Münchner Dax-Konzern mitteilt

Der Beitrag BCM-News Daily Digest erschien zuerst auf Business Continuity Management News.

• Wer kümmert sich eigentlich um das Backup von Daten in der Cloud?
  Werden diese Daten versehentlich gelöscht, von Cyberkriminellen manipuliert oder von einer Ransomware verschlüsselt, kann der Cloud-Anbieter nicht weiterhelfen. Er besitzt schlicht kein klassisches Backup, das er wieder einspielen könnte, weil dies nicht in seiner Verantwortung liegt

Der Beitrag BCM-News Daily Digest erschien zuerst auf Business Continuity Management News.

• Hacker hacken Hacker: Zwei berüchtigte Cybergangs streiten sich im Darknet - Golem.de
  Opfer der Hackergruppe Clop könnten erneut unter Druck geraten. Shinyhunters hat die Datenleckseite gekapert und droht mit Leaks über Lösegeldzahlungen
• Cyber Resilience Act: Überfordert die 24-Stunden-Meldepflicht Unternehmen?
  Die 24-Stunden-Frist ist machbar, wenn man bedenkt, wann der Zeitmesser tatsächlich zu laufen beginnt: nämlich erst, nachdem man Kenntnis von einem Vorfall erlangt hat. Kompliziert wird es bei der Frage, "wann man davon wusste", da das Bewusstsein für einen Vorfall davon abhängt, wie der Kommunikationsfluss im Rahmen des Erkennungsprozesses protokolliert und nachverfolgt wird
• NIS2: Die Tür als erste Verteidigungslinie
  Einen weiteren wichtigen Aspekt stellt die Aufrechterhaltung des Betriebs dar. Für physische Sicherheitssysteme stellt sich dahingehend die Frage, was bei einem Server- oder Netzwerkausfall geschieht. Mit dem Einsatz von Videomanagementsystemen kann über Failover-Konzepte im Worst-Case die Videoüberwachung fortgeführt werden. Bei einer Unterbrechung der Netzwerkverbindung ermöglicht zudem Edge Recording eine lokale Kameraaufzeichnung mit anschließender Synchronisation. Aber auch die Zutrittskontrolle lässt sich ausfallsicher auslegen. So können bestimmte Komponenten der Produktlösung weiterhin definierte Zutrittsfunktionen bereitstellen - auch wenn keine Verbindung zum zentralen Server besteht
• Digitale Sicherheit: Rechnungshof: EU nicht genug gegen Cyberangriffe gewappnet | STERN.de
  Die EU ist nach Einschätzung des Europäischen Rechnungshofs nicht genug auf die Aufdeckung und Abwehr großer Cyberangriffe vorbereitet. Staaten und Institutionen der EU müssten stärker zusammenarbeiten, um Informationen besser auszutauschen und Überschneidungen zu vermeiden, stellen die unabhängigen Prüfer des Rechnungshofs in ihrem Bericht fest

Der Beitrag BCM-News Daily Digest erschien zuerst auf Business Continuity Management News.

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.

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

Zeitachse

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

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

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

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

1. Verzeichnisdienst und Netz standen zur Verfügung. Liegen sie auf demselben Speichersystem, fallen sie im Ernstfall mit aus.
2. Die Schnittstelle zum Versanddienstleister war durch ein Testsystem ersetzt.
3. Der Test war angekündigt, fand an einem Werktagvormittag statt und die Teams waren vollständig besetzt.
4. Erkennung und Entscheidung wurden nicht geübt, die Werte stammen aus der Alarmierungsübung vom 14. April 2026.
5. 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

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.

Der Beitrag Wiederanlauftest: Was im Protokoll stehen muss, damit RTO und RPO belegt sind erschien zuerst auf Business Continuity Management News.

• Smart-Home-Hersteller lassen Nutzer nach dem Hack allein
  Smart-Home-Geräte werden millionenfach verkauft, doch ihre Sicherheit endet oft genau dort, wo der Ernstfall beginnt: beim Hack. Hersteller in­ves­tie­ren in automatische Updates und Passwortpflichten, doch was nach einem erfolgreichen Angriff passiert, bleibt meist ungeklärt. Wer nur vor­sorgt, aber im Ernstfall schweigt, lässt Nutzer genau dann allein, wenn sie am meisten Hilfe brauchen
• Deutsche KMU: Cyber-Angriffe treffen sie härter als gedacht
  Die wirtschaftlichen Folgen fallen der Umfrage zufolge deutlich gravierender aus als oft angenommen: Jedes dritte betroffene deutsche Unternehmen (33 Prozent) sah seine Zahlungsfähigkeit oder Existenz erheblich gefährdet, im weltweiten Durchschnitt waren es 25 Prozent. Im Schnitt stand der Betrieb betroffener deutscher Unternehmen 41,7 Stunden still, gegenüber 31,6 Stunden im globalen Durchschnitt

Der Beitrag BCM-News Daily Digest erschien zuerst auf Business Continuity Management News.

• Ransomware Attacks on Manufacturers Surge as Supply Chain Risk Grows - SecurityWeek
  Research shows attacks on manufacturers rose 40% in early 2026, as ransomware groups increasingly exploit the supply-chain disruption caused by operational shutdowns
• Experte zu Cyberangriffen: "Ich habe so eine Dynamik bisher noch nicht erlebt" | heise online
  Cyberangriffe können Krankenhäuser lahmlegen. Fraunhofer SIT simuliert den Ernstfall, um Resilienz zu testen und Schwachstellen in Notfallplänen aufzudecken

Der Beitrag BCM-News Daily Digest erschien zuerst auf Business Continuity Management News.