---

---

Die 9. MaRisk-Novelle bringt für das Business Continuity Management eine wichtige fachliche Verschiebung. AT 7.3 wird dadurch nicht neu erfunden, aber anders akzentuiert – weg von der vorrangigen Betrachtung zeitkritischer Aktivitäten und Prozesse, hin zu kritischen oder wichtigen Funktionen.

Diese Begrifflichkeit kommt nicht zufällig. Sie knüpft an DORA an. Dort ist die kritische oder wichtige Funktion ein zentraler Bezugspunkt, insbesondere für IKT-Risikomanagement, Drittparteienmanagement und Resilienztests. Die BaFin verweist in ihren DORA-FAQ darauf, dass Finanzunternehmen die Analyse kritischer oder wichtiger Funktionen anhand der Kriterien aus Art. 3 Nr. 22 DORA vornehmen sollen.

Damit greift AT 7.3 erkennbar eine DORA-Begrifflichkeit auf und nähert sich in diesem Punkt der DORA-Logik an. Genau dadurch stellt sich jedoch eine fachliche Frage: Warum bleibt der Abschnitt weiterhin unter der Überschrift „Notfallmanagement“, obwohl die Inhalte zunehmend BCM- und Resilienzlogik abbilden?

Begriffliche Einordnung: AT 7.3 zwischen Notfallmanagement und BCM

Der Begriff „Notfallmanagement“ bleibt in AT 7.3 erhalten, obwohl die Anforderungen fachlich deutlich über eine reine Ereignisbewältigung hinausgehen. Es geht um Vorsorge, Geschäftsfortführung, Wiederanlauf, Wiederherstellung, Kommunikation, Überprüfung und kontinuierliche Verbesserung bei schwerwiegenden Störungen. Das sind Kernelemente eines Business-Continuity-Managements.

Der fehlende sprachliche Anschluss fällt auch deshalb auf, weil das BSI diese Entwicklung bereits vollzogen hat. Der frühere BSI-Standard 100-4 trug noch den Titel „Notfallmanagement“. Der Nachfolgestandard BSI 200-4 heißt dagegen ausdrücklich „Business Continuity Management“ und löst den BSI-Standard 100-4 ab. Damit hat das BSI den Begriff „Notfallmanagement“ auf Standardebene durch BCM ersetzt.

Gerade vor diesem Hintergrund wäre eine stärkere Harmonisierung des Sprachgebrauchs hilfreich gewesen. Wenn der BSI-Standard 200-4 in der Prüfungspraxis als methodischer Referenzrahmen für BIA, Planarten, Tests und Übungen herangezogen wird, stellt sich die Frage, warum AT 7.3 weiterhin am Begriff „Notfallmanagement“ festhält, statt die etablierte BCM-Terminologie aufzugreifen.

Das gilt auch für die Planlogik. Der BSI-Standard 200-4 unterscheidet zwischen verschiedenen Planarten, unter anderem Geschäftsfortführungsplan, Wiederanlaufplan und Wiederherstellungsplan. In der Unternehmenspraxis werden diese Begriffe nicht immer deckungsgleich verwendet. Häufig ist von BCPs die Rede und bei IT-bezogenen Maßnahmen von IT-Recovery-Plänen. Eine harmonisierte Begrifflichkeit würde daher nicht nur redaktionell helfen, sondern auch die fachliche Abgrenzung zwischen BCM, ITSCM, Krisenmanagement und technischer Wiederherstellung erleichtern.

Von zeitkritischen Prozessen zu kritischen Funktionen

Inhaltlich ist BCM für Institute selbstverständlich keine neue Anforderung. Frühere MaRisk-Fassungen verlangten bereits Vorsorge für zeitkritische Aktivitäten und Prozesse, Geschäftsfortführungs- und Wiederherstellungspläne sowie regelmäßige Überprüfungen. Die 8. Novelle stellte bereits auf „zeitkritische Aktivitäten und Prozesse“ ab und verlangte für diese einen Wirksamkeitsnachweis „für alle relevanten Szenarien mindestens jährlich und anlassbezogen“.

Die 9. MaRisk-Novelle setzt nun einen anderen Schwerpunkt. In der finalen Fassung heißt es, dass für Aktivitäten und Prozesse, die „kritische oder wichtige Funktionen darstellen“, Vorsorge zu treffen ist. Außerdem sind Risiken schwerwiegender Störungen dieser Funktionen, ihrer notwendigen Unterstützungsprozesse, IKT-Systeme und sonstigen Ressourcen zu identifizieren. Als Grundlage dient eine Übersicht über alle Funktionen.

Dadurch verschiebt sich der BCM-Blick stärker auf die Funktionsebene. Der einzelne Geschäftsprozess bleibt relevant. Er ist aber nicht mehr der alleinige Bezugspunkt. Künftig wird die Frage, wie eine kritische oder wichtige Funktion tatsächlich erbracht wird, eine entscheidende Rolle spielen. Dazu sind die erforderlichen Prozesse, Systeme, Dienstleister, Standorte, Daten und Rollen zu identifizieren.

Ein Beispiel ist der Zahlungsverkehr. Er ist in vielen Instituten nicht nur ein einzelner Prozess, sondern eine wesentliche Geschäftsleistung. Diese Leistung entsteht durch eine Prozesskette: Zahlungsannahme, Validierung, Sanktionsprüfung, Freigabe, Clearing, Settlement, Verbuchung, Abstimmung, Fehlerbearbeitung und Kommunikation. Hinzu kommen Payment-Anwendungen, Core-Banking-Systeme, Schnittstellen, Netzwerke, externe Dienstleister und Kontrollmechanismen. Daraus folgt zunächst nicht die Frage nach der passenden Testart. Vor dem Test steht die fachliche Einordnung.

Strategische BIA als Ausgangspunkt der Funktionslogik

Wenn kritische oder wichtige Funktionen der neue Bezugspunkt sind, muss zunächst klar sein, welche Funktionen bestehen und wie sie erbracht werden. Kritische oder wichtige Funktionen sind dabei nicht zwingend einzelne Geschäftsprozesse, sondern können übergeordnete Leistungen, Fähigkeiten oder Verpflichtungen des Instituts beschreiben, deren Ausfall wesentliche Auswirkungen auf Geschäftsbetrieb, Kunden, Marktrollen oder regulatorische Pflichten hätte. Genau hier gewinnt die strategische BIA an Bedeutung. Sie beantwortet die vorgelagerte Frage, welche Produkte, Services, Dienstleistungen, Marktrollen, regulatorischen Verpflichtungen oder geschäftlichen Fähigkeiten für das Institut so wesentlich sind, dass ihr Ausfall nicht akzeptabel wäre.

Viele Institute arbeiten seit Jahren mit taktischer und operativer BIA. Die taktische BIA bewertet zeitkritische Geschäftsprozesse und definiert Kontinuitätsparameter wie MTPD, MBCO, RTO oder RPO. Die operative BIA erhebt Ressourcen, Mengengerüste, IT-Anforderungen, Personalbedarfe und Dienstleisterabhängigkeiten.

Diese Ebenen bleiben zentral. Die stärkere Orientierung an kritischen oder wichtigen Funktionen verlangt jedoch eine konsequentere strategische Einordnung. Erst sie verbindet Geschäftsmodell, kritische Funktion, unterstützende Prozesse, Ressourcenanforderungen und Abhängigkeiten.

Erst aus dieser strategischen Einordnung lassen sich belastbare Prozessketten ableiten. Und erst aus diesen Prozessketten ergibt sich, welche Testart angemessen ist.

Prozessketten als Brücke zwischen Funktion und Test

Dort, wo eine kritische oder wichtige Funktion über mehrere Prozesse, Systeme, Schnittstellen, Dienstleister und Rollen erbracht wird, liegt ein Prozesskettentest fachlich nahe. Er prüft nicht nur einen einzelnen Ablaufabschnitt. Er prüft, ob eine kritische oder wichtige Funktion über mehrere Prozess-, System- und Organisationsgrenzen hinweg fortgeführt, wieder angelaufen oder wiederhergestellt werden kann.

Beim Zahlungsverkehr würde ein solcher Test also nicht bei der Frage stehen bleiben, ob ein einzelner Zahlungsprozess im Notbetrieb funktioniert. Er würde prüfen, ob die Funktion Zahlungsverkehr entlang der relevanten Prozess- und Systemkette weiterhin in einem akzeptablen Mindestmaß erbracht oder innerhalb definierter Zielzeiten wieder bereitgestellt werden kann.

Auch die Testanforderung in AT 7.3 unterstützt diese Lesart. Die finale Fassung verlangt, dass die Wirksamkeit und Angemessenheit des Konzepts regelmäßig überprüft wird. Für kritische oder wichtige Funktionen muss dies jährlich erfolgen. Häufigkeit und Umfang sollen sich an der Gefährdungslage orientieren, Dienstleister sind angemessen einzubinden.

Die 9. MaRisk-Novelle schreibt Prozesskettentests nicht ausdrücklich vor. Entscheidend wird sein, wie sich die Prüfungspraxis entwickelt und welche Nachweise Aufsicht, Prüfer und interne Revision künftig tatsächlich erwarten. Gerade deshalb spricht viel dafür, Prozesskettentests nicht erst dann einzuführen, wenn sie ausdrücklich eingefordert werden.

Weiterentwicklung der Testpraxis

Die Reife im Finanzsektor ist in vielen Häusern vorhanden. Business-Impact-Analysen, Business-Continuity-Pläne, IT-Recovery-Pläne, Krisenstabsübungen, Funktionstests sowie weitere technische und organisatorische Test- und Übungsformate sind vielfach etabliert. Der nächste Schritt besteht darin, diese bestehenden Nachweise stärker entlang kritischer oder wichtiger Funktionen zu verbinden.

Für Institute bedeutet das keine Abkehr von bestehender BCM-Praxis. Es bedeutet eine fachliche Weiterentwicklung: von einer überwiegend prozessbezogenen Testlogik hin zu einer stärker funktionsbezogenen Testabdeckung.

Nicht der einzelne Plan steht im Mittelpunkt – sofern er nicht bereits die relevante Prozesskette abbildet –, sondern die Fähigkeit des Instituts, kritische oder wichtige Funktionen unter realistischen kritischen Vorfällen fortzuführen, wieder anlaufen zu lassen oder wiederherzustellen.

Der nächste Reifeschritt liegt nicht in einer neuen BCM-Methodik, sondern in der konsequenteren Verbindung bestehender Bausteine: Kritische oder wichtige Funktionen werden über die strategische BIA eingeordnet, über die taktische und operative BIA in Prozesse, Ressourcen, Systeme und Dienstleister übersetzt und in geeignete Testformate überführt. Wo eine Funktion über mehrere Prozesse, Systeme und Dienstleister erbracht wird, wird der Prozesskettentest zum naheliegenden Instrument des funktionsbezogenen Wirksamkeitsnachweises.

Foto-/Grafiknachweis: S. 1: iStock.com/Tippapatt, S. 2: iStock.com/Olivier Le Moal, S. 3: iStock.com/M.photostock