Vorstellung von MTCR: Die bisher fehlende Kennzahl für den Erfolg bei der Cyber-Recovery

MTCR misst, wie lange es dauert, Systeme und Daten nach einem Cyberangriff vollständig wiederherzustellen – frei von Malware, Beschädigungen oder Persistenz. 

RTO und RPO messen Zeit und Datenverlust. MTCR misst Vertrauen. Eine schnelle Recovery ist bedeutungslos, wenn Bedrohungen bestehen bleiben. 

Sie erfordert die Überprüfung von Backups, das Scannen nach versteckten Bedrohungen und die Validierung wiederhergestellter Workloads – was weitaus komplexer ist als ein einfaches Failover. 

Angreifer manipulieren zunehmend Backups und verbergen ihre Persistenz, wodurch die Identifizierung sauberer Daten zur längsten Phase der Recovery wird. 

Es bietet Führungskräften eine realistische Kennzahl für die Qualität der Recovery-Prozesse und ermöglicht so intelligentere Investitionen und Vorbereitungen. 

Sehen Sie sich hier das Video mit dem zeitgestempelten Transkript an

Willkommen zu unserer Diskussion über einen neuen Ansatz für Cyber-Resilienz: „Mean Time to Clean
Recovery“ (MTCR).

Zu mir gesellen sich zwei Experten, die dieses MTCR-Konzept entwickelt haben: Darren Thomson, Field CTO bei
Commvault, der eng mit Unternehmen aus verschiedenen Branchen an Resilienz- und

Strategien zusammenarbeitet, sowie Duncan Bradley, Leiter des Bereichs Sicherheit und Resilienz für Großbritannien und Irland bei Kyndryl
. Sie sind die Autoren des ursprünglichen Thought-Leadership-Papiers zu MTCR. Und

seit Jahren wird der Erfolg der Recovery in Unternehmen daran gemessen, wie schnell Systeme wiederhergestellt werden
können.

Wir verwenden Abkürzungen wie RTO und RPO – RTO steht für „Recovery Time Objective“ und RPO für „Recovery Point
Objective“.

Doch in der heutigen Bedrohungslandschaft wissen wir, dass Geschwindigkeit allein nicht gleichbedeutend mit Sicherheit ist und auch
keinen erfolgreichen Recovery-Vorgang garantiert.

Wenn die wiederhergestellten Daten nicht fehlerfrei und vertrauenswürdig sind, riskieren Sie, dass Ihre Recovery zur
Fortsetzung eines weiteren Angriffs wird.

Hallo.

Ich bin Danielle Sheer, Chief Trust Officer bei Commvault.

Und ich verbringe einen Großteil meiner Zeit damit, Vorständen und Führungskräften zu verdeutlichen, dass Cyberrisiken mit Geschäftsrisiken einhergehen
.

Ich freue mich sehr darauf, die heutige Diskussion zu leiten und zu erläutern, warum dieses neue Konzept, MTCR,
nicht nur eine weitere technische Kennzahl ist, sondern der Unternehmensstandard, der mittlerweile in den

Vorstand gehört.

Versuchen wir es doch einmal.

Ja, danke, Danielle.

Und danke für die tolle Einleitung.

Gerade in diesem Jahr, 2025, haben wir insbesondere in Großbritannien, aber eigentlich weltweit,
vor allem in Europa, einige gezielte Angriffe auf den Einzelhandel erlebt.

Und wir haben aus erster Hand miterlebt, wie schwer es für diese Einzelhändler war, den Kontakt
zu ihren Kunden aufrechtzuerhalten und – was noch wichtiger ist – ihre Systeme wiederherzustellen.

In diesem Jahr war ich persönlich an einem bestimmten Angriff beteiligt, der etwa Mitte April
2025 begann.

Und um Ihnen einen kleinen Eindruck davon zu vermitteln, wie lange es gedauert hat, bis sich das Unternehmen
wieder erholt hatte:

Im April kam es im Wesentlichen zu einem Ransomware-Vorfall.

Und während dieser Zeit hat das Unternehmen hervorragende Arbeit geleistet, um den
Vorfall zwar nicht vollständig zu stoppen, aber zumindest einzudämmen und die Ausbreitung zu verhindern.

Im Mai ging man dazu über, die Art und den Umfang – ich
nenne das den „Blast Radius“ des Angriffs – zu ermitteln.

Und man begann, nach außen zu kommunizieren.

Von Mai bis Anfang August erfolgte dann die eigentliche Recovery-Prozedur für die Systeme.

Mit anderen Worten: Es dauerte fast drei Monate bis einschließlich August, und erst
dann erfolgte eine schrittweise Wiederinbetriebnahme der Systeme.

Warum also all diese Zeit – drei Monate –, um den Betrieb des Unternehmens wieder
aufzunehmen?

Nun, ein Großteil dieser Zeit wurde damit verbracht, die richtigen Daten zu finden – die „sauberen“ Daten.

Die einwandfreien Systeme, auf die sich das Unternehmen verlassen konnte, um wieder mit seinen
Kunden in Kontakt zu treten und als Einzelhändler Umsatz zu generieren.

Und genau dieser Zeitraum von drei Monaten ist bezeichnend für das, worüber wir hier sprechen
wollen.

Das Unternehmen muss anfangen, der IT-Abteilung
andere Fragen zu stellen, um an einen Punkt zu gelangen, an dem nicht nur Versprechungen darüber gemacht werden können, wie schnell

wir Systeme wiederherstellen können,

sondern auch darüber, wie einwandfrei diese Systeme sein werden, wie einwandfrei
ihre Daten sein werden.

Andernfalls befürchte ich, dass wir weiterhin erleben werden, dass es in der Regel zwei, drei,
manchmal sogar vier oder fünf Monate dauert, bis Systeme wieder online sind.

Wissen Sie, okay, das ist faszinierend.

Sie haben uns viel Stoff zum Nachdenken gegeben.

Duncan, lassen Sie mich nun noch einmal zum Anfang zurückkommen.

Können Sie uns die Definition von MTCR erläutern?

Erläutern Sie uns die fünf Säulen und warum dies in diesem
Umfeld – dieser Bedrohungslandschaft – der richtige Weg für uns ist, um den Erfolg der Recovery zu messen.

Ja, klar, Danielle.

Ich halte das für wirklich wichtig.

Wir haben das Konzept der „Mean Time to Clean Recovery“ entwickelt, damit es wirklich eine geschäftliche Kennzahl
ist, die das Unternehmen nachvollziehen kann.

Es geht darum, wie lange es dauert, bis das System wieder online ist, wie Darren bereits sagte.

Mit sauberen Daten und mit Systemen, die wieder funktionieren und in den Produktionsbetrieb zurückkehren können.

Die meisten Unternehmen haben sich wirklich darauf konzentriert, dass ihre Systeme online verfügbar
sind, ohne zu verstehen, dass diese Cyberangriffe die Daten und Plattformen lahmlegen,

die diese Abläufe unterstützen, lahmlegen.

Wenn es also zu einem Cyber-Recovery-Vorfall kommt, geht es vielmehr darum, vom ersten Tag an
bis zum Wiederherstellungspunkt

in einer sauberen Umgebung wiederherzustellen.

Das dauert oft Tage, wie Darren am Beispiel des Einzelhandels bereits erwähnt hat.

Anschließend müssen Sie alle Ihre grundlegenden Dienste neu aufbauen.

Anschließend müssen Sie Ihre Plattformen wieder in Betrieb nehmen und saubere Daten
darauf wiederherstellen.

Und bei den Arten von Angriffen, die wir beobachten, kommt es häufig vor, dass die Daten bereits
Tage, wenn nicht sogar Wochen vor dem Angriff kontaminiert waren.

Daher müssen Sie Ihre Backups überprüfen und diese sauberen Daten wieder in die Produktion zurückführen.

Diese MTCR (Mean Time to Clean Recovery) soll als geschäftlicher Indikator dienen, um zu sagen:

Wie lange können Sie sich einen Ausfall leisten?

Wie lange wären Sie heute außer Betrieb, wenn das Ereignis eintreten würde?

Dies dient dann dazu, die IT- und CC-Abteilungen dazu anzuspornen, diese Zeit
bis zu Recovery zu verkürzen.

Und wie unterscheidet sich MTCR von herkömmlichen Kennzahlen?

Es klingt so, als wären viele der herkömmlichen Kennzahlen in einer einzigen, umfassenderen Kennzahl zusammengefasst.

Nun, ich denke, hier kommen die Ziele für die Recovery-Zeiten ins Spiel.

Wie lange dauert es, bis das System wieder online ist?

Dabei wird nicht berücksichtigt, welche Art von Daten sich auf dieser Plattform befinden.

Wissen Sie, normalerweise wird die Verfügbarkeit herangezogen.

Wie lange dauert es, bis ich von Rechenzentrum A auf Rechenzentrum B umschalte – und das
bei einem herkömmlichen, ähm, Angriff auf die Infrastruktur?

Die Wiederherstellung der Daten ist ein viel komplizierteres Unterfangen.

Es geht nicht nur darum, einen Datensatz wiederherzustellen.

Es geht darum, die Plattform wieder online zu bringen.

Wenn man also an Identitätsdienste denkt, muss die Identitätsverwaltung funktionieren, bevor jemand auf die Daten zugreifen kann
.

Nur zu messen, wie schnell es dauert, eine Datenbank wiederherzustellen,

bedeutet noch nicht, dass dieser Geschäftsprozess wieder online ist.

Und es ist wirklich darauf ausgelegt, diese verschiedenen Säulen der Systeme zu bündeln, die Sie
wieder in Betrieb nehmen müssen, damit der Geschäftsprozess wieder funktioniert.

Und Danielle, wenn ich das sagen darf: Ich glaube, das deutet auf ein größeres Problem hin.

Es ist also sehr leicht, in diesem Gespräch den technischen Weg einzuschlagen.

Und tatsächlich bietet dies in vielerlei Hinsicht eine Möglichkeit, die technische Organisation zu bewerten.

Aber ich glaube, hier geht es um ein organisatorisches Problem.

Was wir immer wieder beobachten, ist, dass eines der kulturellen Probleme bei der Wiederherstellung
von Systemen – und einer der Gründe, warum es in vielen Fällen so lange dauert, wie es in meinem

Beispiel der Fall war –, dass wir es tatsächlich mit zwei Teams zu tun haben, die hier
Verantwortung übernehmen müssen.

Da ist natürlich das traditionelle Infrastrukturteam, dessen Mitarbeiter für Backup and Recovery zuständig
sind – sie haben zweifellos eine Aufgabe zu erfüllen, aber es sind nicht mehr nur sie.

Es ist auch das Sicherheitsteam.

Ein Team, das Ihnen beispielsweise mithilfe forensischer Untersuchungen sagen kann, wo sich das intakte Backup befindet, wo die
intakten Daten sind und wie stark die Systeme infiziert sind – das ist ein Sicherheitsteam.

Wenn diese Teams also bei der Recovery nicht zusammenarbeiten, unterschiedliche
Sprachen sprechen oder sich an unterschiedlichen Maßstäben messen, entsteht ein Problem

und das beginnt bei der Unternehmenskultur.

Eine Möglichkeit, darüber nachzudenken, besteht darin, RPO und RPO – das Ziel der Recovery-Zeit – zu betrachten:

Wie lange werde ich für die Wiederherstellung benötigen?

Recovery Point Objective: Wie viele Daten werde ich voraussichtlich benötigen?

Und das kombiniert man mit der Forensik, einem Bereich der Sicherheit.

Nun haben wir MTCR.

Dabei ist das „C“ wichtig.

Die Sauberkeit dieser Daten ist wirklich, wirklich entscheidend.

Und der Ausgangspunkt, über den wir zweifellos sprechen werden, ist: Lassen wir einfach das Unternehmen diese Frage stellen
.

Wie lange brauchen wir, um unsere Systeme wieder in einen sauberen Zustand zu versetzen?

Und was wir jeden Tag beobachten, ist, dass diese Frage zwar nicht schwer zu stellen, aber sehr schwer
zu beantworten ist – insbesondere dort, wo diese kulturelle Kluft zwischen

dem Sicherheits- und dem Infrastrukturteam besteht.

Ich bin fest davon überzeugt, dass genau darin die Genialität von MTCR liegt: Man nimmt eine Reihe sehr
technischer Konzepte, an denen sich IT- und Sicherheitsteams messen, und verwandelt sie in

etwas, worüber man mit CEOs und Vorständen sprechen kann.

Um dein Beispiel, Darren, eines Einzelhändlers zu Weihnachten aufzugreifen, der Opfer eines Cyberangriffs
geworden ist: Wie würdest du MTCR einsetzen, wenn du vor einem Vorstand stünden, um

zu erklären, was passiert ist und wie der Recovery-Prozess abläuft?

Nun, ich werde mit der Antwort beginnen und dann an Duncan übergeben, damit er sie
vervollständigt, denn es gibt einen Teil dieses Papiers, für den Duncan maßgeblich verantwortlich war und der sich wirklich

Gruppierung

von Ressourcen, die zu einem Dienst zusammengefasst werden.

Aber ich möchte zunächst sagen, dass es einige Diskussionen gibt, die geführt werden müssen, die aber sehr
oft nicht stattfinden.

Eine davon betrifft die Risikobereitschaft.

Wer sind wir also als Unternehmen?

Was für ein Unternehmen sind wir?

Ein Einzelhändler – typischerweise hat man da eine eher geringe bis mittlere Risikobereitschaft, irgendwo
in diesem Bereich.

Aber das muss definiert werden, damit wir im weiteren Verlauf, wenn wir beginnen, die
Risiken um uns herum zu verstehen, entscheiden können, was akzeptabel ist und was

beispielsweise durch unsere Versicherung abgedeckt werden sollte und was unbedingt integriert werden
muss.

Das ist also das erste Gespräch.

Im zweiten Gespräch dreht sich dann alles um die Frage: Was ist hier das „Minimal Viable Company“?

Es ist völlig unrealistisch anzunehmen, dass irgendein Unternehmen – egal mit welchem Budget – in der Lage sein wird
, alle Geschäftsbereiche schnell wiederherzustellen.

Was ist also in diesem Geschäft wirklich entscheidend?

Das ist ein sehr, sehr tiefgreifendes und interessantes Gespräch, das man mit den meisten Unternehmen führen sollte.

Die meisten Unternehmen können sich eine Welt ohne IT gar nicht vorstellen.

Daher fällt es ihnen sehr schwer, die Geschäftsprozesse zu entflechten und darüber zu sprechen:
Wie würde das aussehen, wenn wir wieder mit Papier arbeiten würden?

Aber genau dieses Gespräch muss irgendwie stattfinden.

Und das führt uns zu dem, was wir als MVC bezeichnen, einem „Minimal Viable Company“.

Das heißt: Was muss in der Anfangsphase – oder in welchem Zeitrahmen auch immer wir
uns entscheiden – vorhanden sein?

Was sind die Dinge, ohne die dieses Unternehmen überhaupt nicht läuft, ohne die wir nicht arbeiten können?

Und das ist eine sehr, sehr wichtige Diskussion.

Was man dann tun kann, ist, das MTCR-Konzept auf das „Minimal Viable Company“ anzuwenden.

Und ich übergebe nun das Wort an Duncan, der uns erklären kann, was einen Service ausmacht.

Wie betrachten wir das im Zusammenhang mit Dienstleistungen?

Und danke, Darren.

Und noch einmal: Dabei geht es nicht darum, die Sache zu kompliziert oder zu tiefgründig zu machen.

MTCR lässt sich mit der Messung der mittleren Zeit bis zur Recovery eines Geschäftsprozesses vergleichen,

eines kritischen Unternehmensdienstes, der dann in die übergeordnete Ebene einfließt, um das minimal funktionsfähige Unternehmen als Ganzes zu bilden.

Es gibt also mehrere verschiedene MTCRs für unterschiedliche Geschäftsprozesse.

Ich habe gerade erst heute mit einem Unternehmen aus dem Konsumgüterbereich, einer Brauerei, gesprochen, und
dort hieß es: Wenn wir Daten im Umfang von vier Tagen verlieren, müssen wir buchstäblich

Bier im Wert von vier Tagen in den Abfluss schütten, da wir nicht nachweisen können, dass es trinkbar ist,
und es daher nicht verkaufen dürfen.

Bei diesem Konzept geht es also darum, diese Geschäftsprozesse zu zerlegen und dann dieses
MTCR als gemeinsame Geschäftssprache zu nutzen, um sagen zu können: „Okay, in meinem Prozess brauche

dann: ‚Oh, dieser Prozess stützt sich auf verschiedene Arten von Anwendungen.‘

Sie alle stützen sich auf grundlegende Dienste, wie zum Beispiel die Identitätsverwaltung und die Möglichkeit für Kunden
, sich auf der Plattform anzumelden.

Dann gibt es Ihre Backend-Systeme, sei es in der Cloud oder vor Ort, Ihre Hypervisoren,
Ihre kritischen Cloud-Lösungen.

Ihre Frontend-Systeme, auf denen die eigentlichen Anwendungen laufen, und schließlich Ihre
Benutzerzugangssysteme – also die Art und Weise, wie Nutzer auf diese Lösung zugreifen: über PDAs, Kassensysteme

usw.?

All diese Komponenten müssen verfügbar sein, damit dieser Unternehmensdienst ausgeführt werden kann.

Das MTCR ist so konzipiert, dass der Geschäftsinhaber die Verantwortung dafür übernimmt.

Der erste Schritt auf diesem Weg ist dann ein Benchmark.

Wie sieht Ihr aktuelles MTCR aus?

Wie lange würde es derzeit dauern, selbst wenn Sie wieder auf intakte Daten zugreifen könnten?

Denn das ist derzeit der schockierende Punkt: Die meisten Unternehmen verfügen
nicht über die Technologie, die es ihnen ermöglicht, ihre Backups zu schützen und

ihre Backups zu durchsuchen, um fehlerfreie Daten zu extrahieren – und genau das ist das eigentliche geschäftliche Problem, das wir hier
lösen wollen.

Das ist sehr interessant.

Sie sagten: „Wie hoch ist der aktuelle MTCR?“

Der MTCR ist also kein Messwert, der am Ende ermittelt wird, um zu messen, wie gut wir die Daten wiederhergestellt haben.

Der MTCR wird in regelmäßigen Abständen während des gesamten Angriffs ermittelt.

Und das liegt wahrscheinlich daran,

dass man, wenn man die Recovery überstürzt, tatsächlich noch mehr Schaden anrichten kann.

Können Sie ein wenig näher darauf eingehen?

Ja, darauf kann ich gerne eingehen.

Bevor ich das tue, hast du hier allerdings einen wirklich interessanten Punkt angesprochen,
der meiner Meinung nach noch weiter ausgeführt werden muss.

MTCR ist also nicht nur etwas, das man während der gesamten Recovery-Phase nach einem Angriff misst.

Man sollte es bereits vor dem Angriff messen.

Ich nenne das sozusagen „left of bang“.

Wenn wir dieses Konzept in den Vorstand einbringen, sehen wir, wie es sich in der gesamten Organisation durchsetzt
.

Und es stellt sich die Frage: Was ist zum Beispiel der MTCR für unser „Minimal Viable Company“?

Wir erhalten Antworten, die wir nicht hören wollen, wie zum Beispiel, dass wir gar nicht wissen, was ein „Minimal Viable
Company“ ist.

Oder selbst wenn wir es wissen: Realistisch gesehen beträgt unser MTCR derzeit wahrscheinlich vier Monate.

Wir wollen diese Antworten nicht hören, aber wir müssen sie hören, damit wir uns auf Verbesserungen konzentrieren
können.

Und das ist meiner Meinung nach ein wirklich, wirklich wichtiger Punkt.

Und Darren, um darauf aufzubauen: Ich denke, es ist entscheidend für das Unternehmen, zu verstehen, wie
hoch sein MTCR heute ist, denn dies fließt dann angemessen in den Risk-Prozess ein.

Und es wird nicht immer eine technologische Lösung sein, die diese MTCR verkürzt.

Oftmals kann das Unternehmen, wenn es weiß, dass das Risiko
besteht,

, einen alternativen Business-Continuity-Plan einbauen –
etwa auf Papier zurückgreifen. Das mag der schlimmste Fall sein, Darren, aber derzeit

verstehen die Unternehmen nicht, welche Risiken sie eigentlich abdecken.

Und dieser MTCR soll dem Vorstand die Möglichkeit geben, sich an den CISO und dessen Teams
zu wenden und zu fragen: „Wie lange wird der Ausfall heute realistisch gesehen dauern?“

Und wenn das dann ein akzeptabler Zeitraum ist – ich habe bereits eine Reihe solcher Untersuchungen durchgeführt, und oft
sind es …

28, 35 oder 42 Tage sind häufig.

Das Unternehmen ist dann völlig entsetzt darüber, dass es für diesen
Zeitraum ohne IT-Dienste auskommen müsste.

Aber sie haben diese Anforderungen nie an den CIO oder die CISO-Organisationen gestellt und gesagt: Wir brauchen
das „Minimum Viable Company“ – diese Ressourcen müssen innerhalb von 24 Stunden wieder online sein.

Wie kann man diese Geschäftsprozesse so gestalten, dass sie innerhalb von 24 Stunden wiederhergestellt werden können?

Es muss eine funktionale oder nicht-funktionale Anforderung des Unternehmens sein, zu sagen: Das
sind unsere Anforderungen.

IT, CISO, könnt ihr mir helfen, diese zu erfüllen?“

Und um noch einmal auf den Punkt zurückzukommen, den ich zuvor angesprochen habe: Es ist übrigens wirklich wichtig zu
verstehen, dass diese Frage in gewisser Weise gar nicht an eines oder beide dieser

Teams gerichtet werden kann.

Nur dann erhält man eine Antwort, die irgendeinen Sinn ergibt – auch wenn
es nicht die Antwort ist, die man sich wünscht –, wenn sowohl das Infrastrukturteam als auch das Sicherheitsteam

anwesend sind, um sie zu beantworten.

Denn die Frage lässt sich einfach nicht von einem der beiden Teams allein beantworten.

Und das ist – noch einmal – aus kultureller Sicht so unglaublich wichtig, bevor wir uns überhaupt mit
der Technologie befassen.

Aus kultureller Sicht geht es darum, mit diesem Konzept ein
Verhalten zu fördern, das es heute noch nicht gibt.

Das stimmt.

Man versucht, Silos aufzubrechen.

Jede Organisation – sei es die IT, das Infrastrukturteam oder SecOps – denkt zwar: „Mein
Teil läuft gut“, aber all diese Teile müssen zusammenarbeiten.

Und so bringt MTCR sie zusammen und regt sie dazu an, über dieses

Konzept des Risikos in der Umgebung nachzudenken, da jede einzelne Person dabei eine Rolle spielt.

Und ich denke, das ist wirklich transformativ, da es jedem einzelnen dieser
Führungskräfte die Möglichkeit gibt, dies einem CEO oder einem Vorstand zu vermitteln und darüber zu sprechen, was

sie tatsächlich in Bezug auf die Recovery und Geschäftsrisiken erleben, richtig?

Absolut, das ist großartig.

Wie hängt das nun mit einfachen Anforderungen zusammen?

Nicht ganz so einfach, aber Compliance-Anforderungen wie DORA und NIST 2.

Inwiefern, wenn überhaupt, geht MTCR darauf ein?

Nun, ich fange mal an, wenn das okay ist, Duncan.

Hier sind also meine ersten Gedanken dazu: Weißt du, Danielle, wir beide haben diese DORA-Artikel schon oft gemeinsam durchgegangen
und über Compliance gesprochen.

Eines der Dinge, die wir in der Compliance-Landschaft zunehmend beobachten – sei es bei
DORA, NIST 2 oder anderen globalen Vorschriften –, ist zum einen die Erwähnung dessen, was

Resilienz ist und was Resilienz im Gegensatz zu Sicherheit bedeutet, und zweitens: das Testen.

Hast du einen Plan?

Hast du den Plan für die Recovery getestet?

Nun, ich denke, das spricht direkt dafür, woran der Plan gemessen werden sollte.

Ich bin etwas besorgt darüber, dass viele der Vorschriften, die ich sehe – selbst die sich weiterentwickelnden und
neueren –, sich immer noch auf Dinge wie Disaster Recovery beziehen.

Sie sind immer noch nicht sehr konkret darin, was eigentlich getestet werden sollte.

Ich habe sogar einige Erwähnungen von RPO und RTO gesehen.

Und in gewissem Maße ist ein solches Konzept natürlich wichtig, wenn Unternehmen
damit beginnen, die Vorschriften einzuhalten und zu einer Compliance überzugehen, die stark auf Resilienz

ausgerichtet ist.

Was sollen wir hier also messen?

Denn wenn wir nur die alten Kennzahlen zur Notfall-Recovery messen, werden wir hier wirklich nicht sehr weit kommen
.

Was wir dann feststellen werden: Wir werden angegriffen, greifen auf unseren DR-Plan zurück, setzen ihn um –
und, Überraschung, Überraschung – wir können unser einwandfreies Backup nicht finden, und wir brauchen 30, 40, 50, 60

Tage, bis wir wieder einsatzfähig sind.

Wir müssen also unsere Denkweise ändern.

Und was die Compliance betrifft, war es sehr erfrischend, einige der neuen Compliance-Richtlinien
und -Zeitpläne zu sehen,

Resilienz, Recovery und Tests erwähnten – aber wir müssen sicherstellen, dass wir diese Themen
auf die richtige Art und Weise und unter den richtigen Rahmenbedingungen und im richtigen Kontext betrachten.

Ja, da stimme ich dir voll und ganz zu, Darren.

Wenn man sich viele der Anforderungen aus DORA und die Aussagen der Europäischen
Zentralbank zu Stresstests ansieht, hat sich die Mehrheit der Organisationen so aufgestellt, dass sie

zum Scheitern verurteilt sind, denn es heißt, man müsse nachweisen, dass man sich innerhalb der eigenen Toleranzgrenze
für geschäftliche Auswirkungen erholen kann.

Und die meisten Organisationen orientieren sich bei dieser Toleranz für geschäftliche Auswirkungen

an Verfügbarkeitskennzahlen oder am alten DR-Plan orientiert, der besagt: „Ich kann innerhalb von vier Stunden von Rechenzentrum A auf
Rechenzentrum B umschalten.“

Man kann eine ganze Bank oder ein ganzes Finanzinstitut nicht in vier Stunden wiederherstellen, das ist
unmöglich.

Deshalb denke ich – und das unterstreicht gewissermaßen die Notwendigkeit dieses neuen Vokabulars des MTCR –
, dass sie diese Geschäftstoleranz, diese Toleranz gegenüber geschäftlichen Auswirkungen, neu betrachten und

sie neu definieren und sagen sollten: Wenn ich zum Beispiel mein Kernsystem, also mein Hauptbuch, verliere,

wie kann ich dann weiterarbeiten?

Nun, ich kann nicht weiterarbeiten.

Deshalb muss ich Notfallpläne aufstellen, wie ich Teilprozesse durchführen kann, um dann – im Finanzbeispiel – ein Rollback durchführen zu können
, sobald das Hauptbuch wieder online ist.

Was das Testen angeht – die meisten Unternehmen verweisen, wenn ich sie frage, wann sie
ihre CR zuletzt getestet haben, auf ihren herkömmlichen DR-Plan.

Sie verweisen nicht auf ihren Cyber-Recovery-Plan, da die meisten Unternehmen noch keinen

einen Cyber-Recovery-Plan vollständig konzipiert und umgesetzt haben.

Und dieser MTCR muss unbedingt eine der Schlüsselkennzahlen innerhalb dieses Cyber-Recovery-Plans
sein.

Sie haben Ihre Szenarien entworfen, vor denen Sie sich schützen und von denen Sie sich wiederherstellen wollen.

Und dann haben Sie einen MTCR-Wert für diese verschiedenen Angriffsarten.

Er dient wirklich dazu, wie ich bereits sagte, die Lücke zwischen dem Unternehmen, der IT und dem CISO zu schließen.

Weißt du, Darren, du hast gesagt, es gehe darum, die Kultur zu verändern, und Duncan, du hast
gerade gesagt, dass so viele…

Verträge zwischen, äh, Organisationen eine Recovery-Zeit vorschreiben, und das ist bedeutungslos.

Es geht also nicht nur um die, äh, technischen Teams, sondern auch um die Teams für das Risikomanagement
des Unternehmens und die Juristen, die Verträge ausarbeiten – sie müssen verstehen, dass RTO und RPO nicht ausreichen, sondern

der neue Standard eine lückenlose Recovery ist.

Und jeder muss verstehen, was das Endergebnis sein sollte, und nicht nur die einzelnen Schritte
auf dem Weg dorthin, die

vielleicht bedeutungslos sind, oder?

Ja, ich finde, das ist ein wirklich guter Punkt.

Und ich gehe fest davon aus, dass wir – während wir das Konzept weiterentwickeln und Workshops zur
bevorzugten Risikoposition, zu allen tragfähigen Geschäftsmodellen und zum MTCR durchführen – feststellen werden,

feststellen werden, dass vielleicht viel mehr Menschen als bisher – die traditionell mit dem Recovery-Verfahren in Verbindung gebracht wurden –
ein Interesse an diesen

Workshops zeigen.

Genau aus den Gründen, die du genannt hast, Danielle.

An alle Führungskräfte, die zuhören:

möchte ich Sie alle ermutigen, sich den vollständigen Bericht anzusehen.

Er trägt den Titel „Redefining Cyber Recovery, Introducing Mean Time to Clean Recovery“.

Und ich habe noch eine Frage an Duncan und Darren: Ihr habt heute viele
Themen behandelt.

Ihr habt das Ganze anhand eines konkreten Anwendungsbeispiels aus der Praxis veranschaulicht, was sehr einleuchtend ist.

An alle Führungskräfte, die zuhören: Wo fangen wir an?

Wo fangen wir sofort an?

Wir haben den Bericht gelesen und möchten dieses Konzept in unseren Unternehmen, in unserem
Geschäftsbetrieb einführen.

Wie fangen wir an?

Nun, für mich als nicht technisch versierte Führungskraft würde ich empfehlen, ein Treffen
zwischen der Person, die im Unternehmen für die Bereitstellung der Infrastruktur verantwortlich ist – normalerweise ein CIO –

und dem Verantwortlichen für Cybersicherheit im Unternehmen – normalerweise ein CISO, aber vielleicht auch jemand anderes –
ein Treffen einzuberufen und diese beiden Führungskräfte zu fragen: Wie

schnell – nehmen wir als Beispiel Ransomware

als Beispiel – denn sie ist weit verbreitet und wir alle sind von Ransomware betroffen.

Also: Im Falle einer Katastrophe durch Ransomware – wie schnell könnten Sie gemeinsam den
Geschäftsbetrieb wiederherstellen und mir garantieren, dass die Daten, die ich bald zur Führung des

, einwandfrei sind?

Ich garantiere Ihnen, dass aus diesem einen Treffen fünf weitere Treffen hervorgehen werden, denn die
Antwort ist nicht einfach.

Es erfordert die teamübergreifende Zusammenarbeit.

Außerdem ist ein Umdenken erforderlich.

Und ich denke, ich würde etwas sehr Ähnliches sagen, abgesehen davon, dass ich den Kreis
der Teilnehmer wahrscheinlich erweitern würde, um Personen wie den Chief Risk Officer und die Beschaffungsabteilung in dieses Gespräch einzubeziehen.

Denn die meisten Unternehmen schweigen sich in der Regel über diese Cyber-Recovery aus, egal
ob es sich um einen SaaS-Vertrag oder einen Outsourcing-Vertrag handelt.

Wann kann ich wieder auf bereinigte Daten aus Recovery zugreifen?

Denn bei den meisten dieser Vertragsarten ist der Kunde für
seine Daten verantwortlich.

Die Infrastrukturanbieter und die SaaS-Anbieter sind für die
Infrastruktur verantwortlich, die diesen Dienst unterstützt.

Sie sind also diejenigen, die die Verantwortung dafür übernehmen müssen, ihre sauberen
Daten wiederherzustellen.

Aber sie müssen diese Daten dann auch recht schnell an ihre Führungskräfte weiterleiten, um zu versuchen
, wirklich zu verstehen, was unser MVC ist, denn Unternehmen – wie Sie bereits erwähnt haben –

Darren, können es sich einfach nicht leisten und werden niemals in der Lage sein, ihre gesamten Unternehmenssysteme
innerhalb sehr kurzer Zeit wiederherzustellen.

Der Schlüssel liegt hier in der Priorisierung, und nur das Unternehmen selbst kann beurteilen, was für es in einer Situation eines Cyber-Ausfalls am wichtigsten
ist.

Darren, CTO bei Commvault, und Duncan, Leiter des Bereichs Sicherheit und Ausfallsicherheit bei Kyndryl.

Vielen Dank.

Als nächste Schritte hoffe ich, dass ihr dieses MTCR-Konzept in die Praxis umsetzt und Führungskräften
dabei helft, es in Workshops zu erarbeiten.

Und ich gehe fest davon aus, dass wir dies bald weltweit sehen werden, wenn wir unseren Unternehmen dabei helfen
, das für sie passende MVC zu ermitteln.

Vielen Dank für Ihre Zeit heute.

Danke, Danielle.