Eine gelungene DORA-Umsetzung erlaubt es Instituten, aus den IKT-Anforderungen strukturelle Verbesserungen herbeizuführen. Aus der bisher angestrebten „Informationssicherheit“ kann der Blick so auf die digitale operationale Resilienz erweitert werden.
DORA bestärkt Institute, ihren Fokus von der Informationssicherheit auf eine umfassende Betrachtung operationeller Resilienz zu erweitern.
Kein IKT-System ist sicher. Die Frage ist nicht mehr, ob ein Finanzinstitut angegriffen wird, sondern wann und in welchem Rhythmus. Deshalb setzt DORA den Fokus auf die operationelle Resilienz; also die Fähigkeit eines Instituts, einen Sicherheitsvorfall auszuhalten und zu überwinden.
Dabei arbeiten Finanzinstitute bislang mit drei meist isolierten Funktionen: Das Business Continuity Management (BCM) betrachtet anhand von Prozessen, wie lange das Institut bei einem Ausfall von Geschäftstätigkeiten, Anwendungen oder anderen Assets durchhalten würde, bevor wirtschaftlicher Schaden entsteht, es Reputation einbüßt, es gegen gesetzliche Fristen verstößt oder seine Aufgaben nicht mehr erfüllen kann. Die in der Business Impact Analyse (BIA) abgeleitete Anforderung an die Verfügbarkeit beeinflusst den Schutzbedarf der Assets. In der Informationssicherheit selbst bewerten Institute vor allem, welche Informationen schützenswert sind, leiten daraus Maßnahmen ab und erstellen Anforderungen für die Verwendung der Informationen im eigenen Haus und bei Dienstleistern. Diese Anforderungen gibt das Institut über das Dienstleistermanagement an Dienstleister weiter und bleibt zugleich für deren Einhaltung verantwortlich. Das Institut bewertet die Abhängigkeit von den Dienstleistern und die Auswirkungen auf die Informationssicherheit.
Aus diesen fragmentierten Blickwinkeln entwickeln Finanzunternehmen schon heute detaillierte Auswertungen ihrer IKT-Sicherheit. Eine ganzheitliche Diagnose zur IKT-Resilienz lässt sich daraus jedoch nur selten ableiten. Zudem ermitteln und behandeln Institute Risiken, die sich an diesen neuralgischen Punkten zwischen Fachdisziplinen ergeben, oft unabhängig voneinander. Die Wechselwirkungen dieser Risiken bleiben auf der Strecke.
DORA will das ändern: Statt Daten, Prozesse und Dienstleister einzeln zu betrachten und die Ergebnisse miteinander abzugleichen, müssen Finanzunternehmen nun aus den vorhandenen Bewertungen und ermittelten Risiken der Informationssicherheit, des BCM und des Auslagerungsmanagements eine gesamtheitliche, eine prozessbasierte Diagnose der IT-Resilienz des Instituts ableiten. Audits und Test sind dabei ein integraler Bestandteil.
Finanzinstitute erheben Prozesse zum übergeordneten Referenzrahmen der operationalen Resilienz und konzentrieren so ihre Risikobetrachtung.
Institute müssen Schutzbedarfe von Daten, Prozessen und Dienstleistern in Abhängigkeit voneinander bewerten und behandeln. Der naheliegende Rahmen kommt dabei aus den Prozessen des Instituts. Dazu müssen sich alle Bewertungen der IKT-Sicherheit am gleichen Referenzrahmen ausrichten. Alle Einzelbetrachtungen sind auf die Prozessebene zurückzuführen und dort einer übergeordneten Schutzbedarfsbewertung zu unterstellen, anhand einer gemeinsamen Kritikalitätsdefinition vergleichbar zu bewerten und angemessen zu schützen.
Erst dieses Zusammenführen aller Risikoanalysen auf Prozessebene erlaubt es dem Institut, ein Gesamtbild des IKT-Rahmens und der digitalen operationalen Resilienz gebündelt abzubilden. So gelingt es dann auch, kritische und wichtige Funktionen im Sinne der DORA zu definieren und gezielt zu schützen.
Kritische und wichtige Funktionen werden unter DORA zum Ausgangspunkt der Risikobetrachtung. Institute müssen sie deshalb zu Beginn ihrer DORA-Implementierung definieren. Wenn das in den Dienstleisterbezug übertragen wird, mussten Institute bislang zwischen Auslagerungen und sonstigen IT-Fremdbezug unterscheiden. Hier fanden vor allem Informationskategorien Anwendung, die über das anzustrebende Schutzniveau entschieden. Das drückte sich im Schutzbedarf aus.
Der Schutzbedarf von Informationskategorien sagte tatsächlich nur wenig über die Bedeutung und die Sicherheitsanforderungen von Geschäftsprozessen aus. Ein Beispiel: Ein Prozess zum Versand von Weihnachtskarten hat aufgrund der verwendeten personenbezogenen Kundendaten einen hohen Schutzbedarf im Schutzziel Vertraulichkeit, ist jedoch für die Geschäftstätigkeiten eines Finanzinstituts weder kritisch noch wichtig. Ein Prozess im Handels– und Zahlungsverkehr hingegen ist Teil der kritischen Infrastruktur und somit auch eine kritische oder wichtige Funktion. Sie hat aber keinen hohen Schutzbedarf in der Vertraulichkeit, weil größtenteils öffentlich verfügbare Informationen prozessiert werden. In der Schutzbedarfsklasse wird aber oft nach Maximalprinzip der einzelnen Schutzziele entschieden. Beide Prozesse könnten daher in der höchsten Schutzbedarfsklasse enden.
DORA ermutigt zum Umdenken: Statt die Kritikalität von Geschäftsprozessen davon abzuleiten, wie schützenswert die Informationskategorien sind, die in diesen Prozessen verwendet werden, bestimmt das Institut, welche Dienstleistungen, Prozesse und Tätigkeiten des Unternehmens – gemäß Art. 3 Abs. 22 DORA – besonders wichtig sind,
— weil sie unmittelbar auf die Liquidität des Unternehmens einzahlen,
— weil sie dem Institut ermöglichen, seine Geschäftstätigkeiten fortzuführen,
— weil das Institut durch diese Prozesse seine Zulassungsbedingungen im Sinne der Geschäftslizenz erfüllt,
— oder weil das Institut mit diesen Prozessen Anforderungen aus dem Finanzdienstleistungsrecht nachkommt.
Die Kritikalität des Prozesses steht also am Anfang und erst dann zahlen die Schutzbedarfe von Daten, Dienstleistern und anderen Assets auf den Prozess als ihren gemeinsamen Referenzrahmen ein. Dadurch können die Wechselwirkungen von Risiken gesamtheitlich betrachtet werden. Das wiederum erlaubt Instituten, ihre Risikobehandlung auf die Wichtigkeit der Prozesse abzustimmen und die Kosten ihrer Risikosteuerung adäquater zu steuern.
Das IKT-Rahmenwerk verlangt, die Wechselwirkungen zwischen verschiedenen Arten von Assets in Abhängigkeit voneinander zu durchdenken. Ziel ist, IKT-Risiken zueinander in Beziehung zu setzen und im Kontext des übergreifenden Risikoökosystems zu behandeln.
Bislang hatten Institute oftmals einen Asset-fokussierten Blickwinkel: Sie haben betrachtet, welche Systeme sie betreiben, welche Abweichungen vom Sollschutzkatalog darin vorliegen, und welche Risiken sich daraus für ein bestimmtes Asset ergeben. Mit dem umfassenden Risikobegriff erfordert DORA eine gesamtheitliche Analyse aller Abhängigkeiten, durch die sich Einzelrisiken eines Assets durch den IKT-Rahmen fortsetzen. Ist beispielsweise ein kritischer Prozess zwingend von der SaaS-Lösung eines Dienstleisters abhängig, besteht ein IKT-Risiko, das Prozess, Anwendung und Vertragsbeziehung gleichermaßen berührt. Aus der isolierten Betrachtung einzelner Assets entsteht so ein Überblick über das gesamte Risikoökosystem des Instituts.
Allerdings kommen im Informationsverbund recht unterschiedliche Kategorien von Assets zusammen: Anwendungen, Infrastrukturen und Dienstleistungen. Sie liegen als IT-Systeme vor, als Hardware, als cloudbasierte PaaS oder SaaS-Dienste, und auch immer häufiger nur noch als Dienstleistungsverträge und Service Level Agreements. Es stellt sich also die Frage, wie so unterschiedliche Risikoquellen miteinander vereinbar sein können und wie Risiken nicht nur bezogen auf ein konkretes Asset, sondern im Verbund mit anderen Asset-Klassen zu verstehen sind.
Das eigene Ökosystem der Informationswerte holistisch zu begreifen und IKT-Risiken in ihrer Natur als solche zu erfassen – nicht nur getrennt als Informations-, BCM- und Auslagerungsrisiken. Hat man den Blickwinkel auf diese Art erweitert, lassen sich Risiken verschiedener Asset-Typen bzw. aus verschiedenen Arbeitseinheiten übergreifend bündeln und im Zusammenspiel miteinander analysieren. Erst dadurch ergibt sich ein Gesamtbild der Schwachstellen – und auch eine tragfähige Einschätzung der Resilienz des Instituts.
In der Umsetzung dieser Herangehensweise gibt es drei kritische Erfolgsfaktoren:
Erstens ist eine saubere Prozessdarstellung aller Tätigkeiten und Verfahren im Institut sowie der dafür erforderlichen Assets und Ressourcen zwingend notwendig, um Prozesse als Referenzrahmen für die Risikobehandlung zu etablieren. Hat das Institut unter den bisherigen Anforderungen an die IT (BAIT, VAIT oder KAIT) seinen Informationsverbund schon detailliert dokumentiert, ist diese Hürde leicht genommen.
Zweitens wird ein GRC-Tool benötigt, um einen einheitlichen Datenbestand mit hoher Datenqualität zu sichern, sodass sich im Risikomanagement dann auch ein einheitliches Informationsbild ableiten lässt. Die besondere Herausforderung hier ist, ein Tool auszuwählen, das ein qualitativ hochwertiges Risikomanagement erlaubt.
Drittens braucht es eine logische und konsequente Risikoaggregationsstruktur, in der Risiken aus den verschiedenen Asset-Klassen anhand sinnvoller Kontrollkategorien zusammengeführt und ausgewertet werden können.
Der Überblick über das Risikoökosystem ebnet den Weg für die übergreifende Risikoaggregation, -bewertung und -behandlung.
Wie eingangs erläutert sind in Finanzinstituten die Risikobewertung, -aggregation und -behandlung weitgehend dezentral auf verschiedene Arbeitseinheiten verteilt: Das Auslagerungsmanagement identifiziert und reduziert Risiken, die von Dienstleistern ausgehen. Die Informationssicherheit gibt Vorgaben zur Datensicherheit unter anderem an die Netzwerksicherheit und die physische Sicherheit weiter. Das BCM erstellt Notfallpläne für Ausfallszenarien, die alle möglichen Funktionen betreffen können.
Wenn mehrere Fachbereiche Risiken für die verschiedenen Asset-Typen einzeln erfassen, in separaten Tools bearbeiten und unterschiedlichen Risikomanagern und Schadensträgern zur Behandlung vorlegen, kann das Risikomanagement nicht berücksichtigen, welche Wechselwirkungen zwischen Risiken aus unterschiedlichen Quellen bestehen. Risiken können somit nicht gegeneinander aufgewogen und Risikoappetit und Risikotragfähigkeit nicht kosteneffizient austariert werden. Die übergreifenden IKT-Risiken, die aus ganz verschiedenen Asset-klassen hervorgehen, müssen daher anhand sinnvoller Kontrollkategorien aggregiert werden.
Dazu kann beispielsweise die ISO 27001 mit ihren vier Kapiteln zu organisatorischen, technologischen, physischen und People Controls dienen. Alternativ kann das Institut Risiken entlang des eigenen Sollmaßnahmenkatalogs kategorisieren. In jedem Fall wird den verschiedenen Arbeitseinheiten durch das einheitliche System zur Aggregation vorgegeben, in welcher standardisierten Form sie Risiken zu erfassen und Richtung Prozess als gemeinsamem Referenzrahmen zu steuern haben. Das Institut kann dann auf Prozessebene Abweichungen vom Sollzustand in allen Arten von IKT-Assets auf ihren Risikogehalt vergleichend prüfen und entstehende, quantifizierte Risiken zu entsprechenden Szenarien im OpRisk zusammenführen.
Gepaart mit der Bewertung von Prozessen als kritische oder wichtige Funktionen unter DORA, werden IKT-Risiken somit treffender gesteuert als assetbezogene Einzelrisiken, indem an einen kritischen Prozess höhere Sicherheitsanforderungen zu stellen sind als an einen unkritischen.
Die Natur der Risiken als IKT-Risiken muss sich dann auch bei der Allokation der Mittel im Eigenkapitaladäquanzprozess widerspiegeln. Und sie hilft festzulegen, wer diese Risiken im Institut trägt, besonders in einer komplexen Konzernstruktur.
Der prozessorientierte Ansatz führt das gesamte Risikomanagement strukturiert bis hin zur Identifikation geeigneter Schadensträger im Konzern.
Der Kerngedanke der DORA, den bisherigen Fokus auf informationstypenbasierte Schutzbedarfsfest stellungen um eine bereichsübergreifende, prozesskritische Betrachtung der Informationssicherheit zu erweitern, lässt sich auch auf die Bestimmung von Risikomanagern und Schadensträgern fortsetzen.
Werden Risikomanager und Schadensträger wie bisher pro Risiko oder Risikoart einzeln von dem Fachbereich bestimmt, der das Risiko identifiziert hat, wird das Risiko sehr isoliert betrachtet. Dadurch kann es sein, dass mehrere Risikomanager für Risiken, die den gleichen Geschäftsprozess betreffen, widersprüchliche Entscheidungen treffen, weil sie nur den Blick auf die Schadenshöhe ihrer Einzelrisiken richten, nicht auf die insgesamte Schadensbemessung eines Geschäftsprozesses. Im Ergebnis können Risikomanager unterschiedliche Risiken nicht ausreichend miteinander abgleichen, Kumulationseffekte nicht richtig berücksichtigen und Steuerungsentscheidungen selten auf Grundlage eines aussagekräftigen Gesamtüberblicks treffen.
Besonders in komplexen Konzern– und Gruppenstrukturen wird es schwierig, wenn zum Beispiel eine große Mutter mit hoher Risikotragfähigkeit das Risiko durch einen Dienstleister für sich als gering einschätzt, eine kleine Tochter jedoch nach internen Weiterverlagerungen von dessen Services in kritischer Weise abhängig ist. Hat die Tochter mit der Mutter keine Bail-Out-Vereinbarung für den Schadensfall, herrscht oft Uneinigkeit über die Angemessenheit einer Risikomitigation und die Höhe akzeptabler Rücklagen.
Die Lösung dieser Konflikte ist von mehreren Faktoren abhängig:
— Zunächst muss die finanzielle Schadensbemessung zentral festgehalten werden. Im Sinne der DORA sollte dies immer in Bezug auf den jeweiligen Geschäftsprozess erfolgen. Das hat den Synergieeffekt, dass die Einstufung der möglichen Schäden auf die Prozesskritikalität und -rentabilität abgestimmt und mit der Schadenshistorie abgeglichen werden kann.
— Durch die Zuschreibung von Risiken zu Prozessen kann das Institut dann leichter und konsistenter Risikomanager und Schadensträger zuordnen, indem zum Beispiel jedem Prozess ein verantwortliches Ressort zugeordnet wird, das die Geschäftstätigkeit erfüllt.
— Um in einer Konzernstruktur das Ungleichgewicht zwischen großen Müttern und kleinen Töchtern zu adressieren, gibt es nun nicht mehr nur die Option einer Bail-Out-Vereinbarung. Werden Risiken pro Prozess gebündelt, können Risikomanager und Schadensträger Prozesse einzeln pro Gesellschaft betrachten und unterschiedlich hohe Risikotoleranzen pro Prozess führen, ohne dass diese im Einzelfall immer neu zwischen den Gesellschaften verhandelt werden müssen.
DORA zeigt: Neben der arbeitsaufwendigen Umsetzung der neuen regulatorischen Anforderungen, gibt dieser Paradigmenwechsel zahlreiche Denkanstöße, diverse bekannte Schmerzpunkte im tradierten IKT- Risikomanagement von Finanzinstituten in neue Chancen zu verwandeln.
