IT-Sicherheitsrisiko im Fokus der Aufsicht

• Die bisherige Praxis zur Behandlung von IT- und Sicherheitsrisiken besteht vor allem aus Schutzbedarfsanalysen.
• Neu formulierte regulatorische Anforderungen sind durch die zunehmende Bedeutung dieser Risiken veranlasst, was teilweise über etablierte Schutzbedarfsanalysen hinausgeht und u.a. Governance, Kontrollmechanismen, IT-Strategie, Budgetierung, Schulung und insbesondere einen Managementrahmen für IT- und Sicherheitsrisiken betrifft.
• Regulatorische Vorgaben sind unter Beachtung der Verhältnismäßigkeit anzuwenden, die insbesondere vom Risikogehalt der Geschäftsaktivität des Instituts abhängt. Wenn die Bedeutung von IT- und Sicherheitsrisiken zunimmt, dann werden eine angemessene Vorgehensweise und die Erfüllung der bestehenden regulatorischen Anforderungen tendenziell anspruchsvoller.

Vorbemerkungen

IT-Risiko wird gewöhnlich operationellem Risiko untergeordnet, wie dies auch gemäß aufsichtlicher Veröffentlichungen vorgesehen ist, und zwar wird u.a. in den EBA SREP Guidelines IT-Risiko als eine Unterkategorie von operationellem Risiko genannt.

In Abhängigkeit von der Wesentlichkeit sind IT-Risiken gemäß der EBA Guidelines on ICT Risk Assessment separat als Unterkategorie operationeller Risiken zu behandeln. Zur Feststellung der Wesentlichkeit von IT-Risiko sind die Voraussetzungen für ein Institut zu berücksichtigen, speziell für IT-Sicherheitsrisiko z.B. folgende Fragen:

• Inwieweit ist das Institut z.B. wegen Nutzung von Internetverbindungen oder den Vertriebskanälen IT-Sicherheitsrisiken auf besondere Weise ausgesetzt?
• Ist das IT-Sicherheitsrisiko besonders hoch wegen veralteter oder stark fragmentierter Systeme?
• Wird die IT-Sicherheit beeinträchtigt durch erhebliche Änderungen an Systemen?
• Wird die IT-Sicherheit durch Kostensenkungsmaßnahmen beeinträchtigt?
• Ist man auf Grund des Standorts IT-Sicherheitsrisiken auf besondere Weise ausgesetzt?

Die Aufsicht sieht eine zunehmende Bedeutung von IT-Sicherheitsrisiko in Instituten auf Grund u.a. der Digitalisierung und einer zunehmenden Nutzung von Internetverbindungen. Dies kann für die Institute erhebliche negative Auswirkungen haben, und vor diesem Hintergrund ist von der EBA Ende 2019 mit den Guidelines on ICT and security risk management eine Veröffentlichung erschienen, die nicht wie frühere Veröffentlichungen (SREP Guidelines, Guidelines on institutions´ stress testing) operationelle Risiken im Allgemeinen betrachtet, sondern sich explizit auf das Management von IT-Risiken bezieht. Diese neuen Vorgaben sind bis Ende Juni 2020 umzusetzen.

Die Inhalte der neuen EBA Guidelines on ICT and security risk management betreffen u.a. Risikobewertung, Risikoreduzierung, den Managementrahmen für die Behandlung von IT-Risiken, Berichterstellung und Audit.

Bisherige Praxis: Schutzbedarfsanalyse

Am Anfang der Behandlung von IT-Sicherheitsrisiko steht Risikobewertung in Form von Schutzbedarfsanalyse. Bei der Schutzbedarfsanalyse handelt es sich in der Regel um eine Erhebung mittels eines ausführlichen Fragebogens, der behandelt, ob und in welcher Weise Schutzbedarf für materielle oder immaterielle Vermögenswerte besteht.

Bei der Feststellung des Schutzbedarfs sind geeignete Ansatzpunkte auszuwählen, denn bei der Informationssicherheit könnte im Prinzip jede einzelne Information in Bezug auf ein Schutzziel wie die Vertraulichkeit betrachtet werden. Wenn jedoch ein nicht mehr zu bewältigender Aufwand mit einer solchen Herangehensweise verbunden wäre, dann ist ein praxistauglicher Ansatz zu suchen. Beispielsweise könnte Information pro IT-System betrachtet werden. Dann würden die Abhängigkeiten der Systeme untereinander noch nicht berücksichtigt. Jedoch sind alternative Lösungen denkbar; die Untersuchungen könnten auch an Geschäftsprozessen orientiert sein. Gemäß dem bevorzugten Ansatz werden Informationsbündel auf zweckmäßige Weise gebildet. Eine Klassifikation, wie hoch der Schutzbedarf ist, erfolgt dann für solche Informationsbündel. Die Bildung von Informationsbündeln ist dann grundlegend für die Schutzbedarfsanalyse wie auch für weitergehende Messung von Risiko, Datensammlung, Analyse und die Maßnahmen zum Schutz vor Risiken.

Die detaillierte Ausgestaltung der Schutzbedarfsanalyse kann unter Hinzunahme eines Prozesskatalogs abgeleitet werden. Vorgehensweisen für eine Schutzbedarfsanalyse sind:

• Der Schutzbedarf wird bestimmt, z.B. Verfügbarkeit, Integrität, Vertraulichkeit und Nachvollziehbarkeit von Informationen.
• Weitere Fragen betreffen diesbezügliche Gefährdungen einerseits und die Gefährdungen reduzierende Gegenmaßnahmen andererseits.
• Es wird abgefragt, wie schwerwiegend Auswirkungen voraussichtlich sein werden (Schadenhöhe), wie häufig Schäden voraussichtlich eintreten werden (Schadenhäufigkeit) oder unter welchen Umständen ein erheblicher Schaden eintreten wird.
• Die Schadenhöhe wird in der Regel in Bewertungsklassen wie beispielsweise ‚niedrig‘, ‚mittel‘, ‚hoch‘ und ‚sehr hoch‘ eingeordnet. Wie diese Klassen genau abgegrenzt werden sollen, hängt vom Einzelfall ab. Bei Verfügbarkeit kann im Hinblick auf die Betriebsstörung kategorisiert werden und konkret nach der Länge der Zeit des Ausfalls unterschieden werden (niedrig: nur 1 Prozess für weniger als 1 Tag, mittel: mindestens 1 Prozess für weniger als Woche, hoch: für mehr als 1 Woche). Bei Integrität, Vertraulichkeit oder Nachvollziehbarkeit kann der Anteil schlechter Fälle betrachtet werden. Abgrenzungen der Bewertungsklassen, die eine Quantifizierung der Schadenhöhe direkt erlauben (niedrig: < €10.000, mittel: < €100.000, hoch: > €100.000), sind zwar vorteilhaft, jedoch ist dies nur begrenzt machbar. Außerdem sollen qualitative Aspekte nicht vernachlässigt werden.
• Klassifizierungen bezüglich verschiedener Schutzziele können hierbei nebeneinander stehen, z.B. einerseits die Verfügbarkeit und andererseits die Vertraulichkeit von Informationen. Das heißt, der Schutzbedarf wird je Schutzziel ermittelt.
• Checklisten werden aufgestellt, um das Vorhandensein von Gegenmaßnahmen abzufragen.

Eine Schutzbedarfsanalyse wird häufig bereits seit Jahren praktiziert. Konkrete diesbezügliche Anforderungen werden durch die neuen EBA Guidelines on ICT and security risk management gestellt, z.B. bezüglich der Erstellung und der Pflege von Verzeichnissen (für Prozesse, Informationen u.a.) und bezüglich der Bestimmung des Schutzbedarfs. Es wird mindestens eine Klassifizierung hinsichtlich Verfügbarkeit, Integrität und Vertraulichkeit von Informationen gefordert (vgl. Abschnitt 3.3.3).

Neue regulatorische Vorgaben

In einem three lines of defence model ist die erste Linie u.a. mit Schutzbedarfsanalysen befasst. Die neuen EBA Guidelines on ICT and security risk management betreffen hingegen vor allem die zweite Linie in einem solchen Modell (vgl. insbesondere die Abschnitte 3.2 und 3.4.1):

Angemessene interne Governance und interne Kontrollmechanismen sind im Hinblick auf IT- und Sicherheitsrisiko einzurichten; sowie ein wirksamer Rahmen für das Management von IT- und Sicherheitsrisiken ist aufzustellen.
Um die IT-Strategie umzusetzen, sind die Qualifikation der für den laufenden IT-Betrieb und die IT-Sicherheit zuständigen Mitarbeiter dementsprechend sicherzustellen. Weiterhin sind angemessene Budgets und eine angemessene Schulung aller Mitarbeiter zu gewährleisten.

Auch bei Auslagerungen ist die Wirksamkeit der Maßnahmen des Risikomanagements sicherzustellen.

Die IT-Strategie soll sich in die Geschäftsstrategie einfügen und wiedergeben, wie die IT die Geschäftsstrategie unterstützt. Insbesondere soll in der IT-Strategie eine Zielstellung hinsichtlich Informationssicherheit formuliert sein. Eine Informationssicherheits-Richtlinie ist zu entwickeln und zu dokumentieren. Hierin sind u.a. prozessuale und technische Anforderungen enthalten.

Der Risikoappetit für IT- und Sicherheitsrisiken ist im Einklang mit dem Risikoappetit des Instituts insgesamt festzulegen, sodass der Risikoappetit insgesamt auch IT- und Sicherheitsrisiken einbezieht.

Rahmen für das Management von IT-Sicherheitsrisiken

Insbesondere wird in den neuen Leitlinien also über einen Managementrahmen für IT- und Sicherheitsrisiken gesprochen (siehe Abschnitt 3.3). Die Anforderungen Risiken zu identifizieren, zu überwachen, zu messen, zu analysieren, zu bewerten und zu berichten werden explizit für IT- und Sicherheitsrisiken formuliert.

Die etablierte Durchführung von Bedrohungs- und Schutzbedarfsanalysen beinhaltet Identifikation, Überwachung und Messung von Risiken. Weitere hieran anschließende Bestandteile eines Rahmenwerks zum Risikomanagement bezüglich IT-Risiken sind:

• Maßnahmenanalyse: Analyse von angewendeten oder potentiellen Gegenmaßnahmen einschließlich einer Priorisierung; Einordnung in eine Gesamtbetrachtung. In den neuen Leitlinien wird die Erstellung von Maßnahmenkatalogen genannt.
• Lückenanalyse: Ermittlung der Abweichungen zwischen dem erreichtem Risikoniveau und dem Risikoappetit. Die neuen Leitlinien verlangen die Festlegung eines Risikoappetits mit Bezug auf IT- und Sicherheitsrisiken.
• Risikomanagement im engeren Sinn: Risikosteuerung, das heißt, Bewertung und Auswahl beziehungsweise Priorisierung von Maßnahmen oder Akzeptanz von Risiko. Die neuen Leitlinien verlangen die Bestimmung notwendiger Sicherheitsmaßnahmen, um den Risikoappetit einzuhalten, und der Änderungsbedarf für Prozesse und IT-Systeme ist zu ermitteln.
• Wirksamkeitsanalyse: Bewertung, inwieweit das Risiko nach den durchgeführten Gegenmaßnahmen reduziert wurde oder welches ungewollte Restrisiko bleibt; Gegenüberstellung von Aufwand und Wirksamkeit; Auswirkungen auf die Gesamtrisikosituation und die Ableitung von Handlungsempfehlungen. Die neuen Leitlinien verlangen Prozesse, um die Umsetzung der IT-Strategie und die Wirksamkeit von risikoreduzierenden Maßnahmen zu überwachen und zu messen. Weiterhin verlangen die neuen Leitlinien den Änderungsbedarf für Kontrollmechanismen zu ermitteln und die Darstellung der Risikobewertungen in Berichten.

Weiterhin wird zum Managementrahmen in den neuen Leitlinien ausgeführt (vgl. die Abschnitte 3.3.1 und 3.3.6):

In der Organisation sind Rollen und Zuständigkeiten bezüglich IT-Risiko und Informationssicherheits-Management festzulegen.

Die Organisation betreffend wird die Einrichtung einer Kontrollfunktion verlangt. Diese Kontrollfunktion ist vom operativen IT-Betrieb zu trennen. Der interne Audit ist wiederum von dieser Kontrollfunktion zu trennen. Interner Audit ist dafür zuständig unabhängig zu überprüfen, dass einerseits interne Vorgaben, andererseits regulatorische Anforderungen eingehalten werden. Der interne Audit folgt hierbei einem Prüfungsplan, und ein Prozess für Nachbesserungen bei Prüfungsbefunden ist einzurichten.

Analyse und Bewertung von IT-Sicherheitsrisiken

Wirksame Prozesse und geeignete Systeme für die Verlustdatensammlung sowie die Risikobewertung sind erforderlich (vgl. EBA Guidelines on ICT and security risk management, Abschnitt 3.3.1; EBA SREP Guidelines, Abschnitt 6.4.4). Diesbezügliche regulatorische Vorgaben sind unter Beachtung der Verhältnismäßigkeit anzuwenden (vgl. z.B. EBA Guidelines on ICT and security risk management, Abschnitt 3.1). Die Verhältnismäßigkeit hängt hierbei insbesondere vom Risikogehalt der Geschäftsaktivität des Instituts ab, der jedoch mit Blick auf IT-Sicherheitsrisiko häufig zunimmt. Unter diesen Bedingungen werden eine angemessene Vorgehensweise und die Erfüllung der bestehenden regulatorischen Anforderungen tendenziell anspruchsvoller.

Was die Risikobewertung betrifft, wird bei operationellen Risiken und IT-Risiken häufig ein versicherungstechnisches Modell angewendet, in dem Schadenhöhen und Häufigkeit von Schadenereignissen betrachtet werden. Es gibt hierbei jedoch keine Erwartung seitens der Aufsicht, dass nur eine bestimmte Modellierung, z.B. ein versicherungstechnisches Modell, eingesetzt werden müsste (vgl. ECB Guide ICAAP, §81).

Wird ein versicherungstechnisches Modell eingesetzt, dann liegen entweder historische Beobachtungsdaten für das Modell in ausreichendem Umfang vor, oder eine Expertenschätzung für die Schadenhöhen und die Eintrittswahrscheinlichkeit von Schäden ist erforderlich. Wenn in einem solchen Modell Expertenschätzungen für Schadenhöhe und Eintrittswahrscheinlichkeit eingestellt werden, dann ist erstrebenswert, dass die Höhe beziehungsweise die Wahrscheinlichkeit mit Hilfe kausaler Zusammenhänge hergeleitet werden. Damit ist explizit dargestellt, welche Zusammenhänge unterstellt wurden, und spätere Korrekturen dieser Größen werden vereinfacht. Diese explizite Darstellung unterstützt auch, unterschiedliche Sichtweisen und damit Abweichungen zwischen den Schätzungen verschiedener Experten einzuschränken. Daher sind die Entwicklung von Methodik und Vorgaben für die Herleitung dieser Größen beziehungsweise eine Dokumentation bereits gebräuchlicher Vorgehensweisen erstrebenswert.

Wenn möglich, ist jedoch die Abhängigkeit von Expertenschätzungen zu vermeiden, und stattdessen eine Datenhistorie für in der Vergangenheit realisierte Schadenereignisse mittels interner Datensammlung oder Beschaffung externer Daten aufzubauen. Diese historischen Beobachtungsdaten sind dann durch Ablage in einer Datenbank (Verlustdatenbank) für die Bestimmung von Schadenhöhen, Eintrittswahrscheinlichkeiten und andere Auswertungen verfügbar zu halten. Eine mögliche Schwierigkeit für die Datensammlung und den Aufbau der Datenbank stellt bereits dar, dass Schäden zuverlässig erkannt werden und geeignete Meldeprozesse für Schäden bestehen.

Bei der Datensammlung und -haltung ist genau abzugrenzen, welche Schäden einer bestimmten Schadenart beziehungsweise Risikoart zugeordnet werden. Im Fall der Nutzung externer Daten für den Aufbau einer Verlustdatenbank wäre die Repräsentativität der externen Daten für das eigene Portfolio zu untersuchen. Dies betrifft einerseits eine möglicherweise unterschiedliche Abgrenzung der Schadenarten, andererseits die Vergleichbarkeit der Umfeldbedingungen während der Erhebungen der Datenbestände. Die Frage der Repräsentativität kann sich auch bei alten internen Daten stellen.

Sofern eine Verlustdatenbank für operationelles Risiko vorhanden und zuverlässig ist, stellt dies eine Hauptinformationsquelle dar (vgl. EBA SREP Guidelines, Abschnitt 6.4.2, jedoch wird das Vorhandensein einer solchen Plattform in den EBA SREP Guidelines nicht vorausgesetzt). Größere Institute haben eine solche Plattform einzurichten (vgl. die Erläuterungen zu Teil BTR 4 in den MaRisk).

Eine Verlustdatensammlung erlaubt insbesondere ein aussagekräftiges Backtesting eines Modells zur Bewertung von IT-Sicherheitsrisiko unter der Voraussetzung, dass Schadenfälle mit einer gewissen Häufigkeit beobachtet werden können. Alternativ könnten noch Beinahe-Schadenereignisse zusätzlich in die Betrachtung einbezogen werden. Diesbezüglich wäre eine Vorgehensweise zu entwickeln und zu dokumentieren.

Für das Backtesting eines Risikomodells ist eine hinreichend genau definierte Methodik erforderlich, und zwar dass die Zielgröße des Modells eindeutig definiert und die Bestimmung der realisierten Werte für die Zielgröße darauf abgestimmt ist. Auf technischer Ebene ist dann klarzustellen, wie Abzüge aus der Verlustdatenbank unter Beachtung dessen vorgenommen werden können. Dies setzt voraus, dass nicht nur die Abgrenzung der Schadenarten, sondern auch die Bestimmung der Schadenhöhe präzise definiert und implementiert sind.

Wenn für Schadenereignisse im Bereich der IT-Risiken die Schadenhöhe bestimmt wird, dann sind Auswirkungen der Ereignisse in verschiedener Hinsicht zu berücksichtigen (vgl. EBA SREP Guidelines, Abschnitt 6.4.1; EBA Guidelines on ICT Risk Assessment, Abschnitt 3.2.3):

• Operationelle Schäden im engeren Sinn:
  • Reparaturkosten (Kosten, um die korrekte Funktionsfähigkeit eines IT-Systems wiederherzustellen);
  • Folgeschäden wie Mehrkosten der Fortsetzung des Geschäftsbetriebs, Schadenersatzforderungen, Kosten für Rechtsstreitigkeiten, Eigenschäden beziehungsweise entgangener Umsatz oder Gewinn (z.B. durch Verzögerungen verursacht);
• gegebenenfalls Beinahe-Schadenereignisse;
• Reputationsschäden und Reaktionen der Aufsicht;
• Schäden, die Strategie- und Geschäftsziele beeinträchtigen.

Die Funktionsweise eines versicherungstechnischen Modells ist grundsätzlich davon abhängig, ob es sich nur um operationelle Risiken im engeren Sinn handelt. Bei einem operationellen Risiko im engeren Sinn können nach Eintritt von Schäden finanzielle Auswirkungen zeitnah festgestellt werden, das sind Auswirkungen in der Bilanz, auf den Ertrag oder auf die Liquiditätslage.

Allerdings bestehen besondere Herausforderungen für die Behandlung von IT-Sicherheitsrisiko im Vergleich zu anderen Risiken:

• Cyberattacken sind nicht immer einfach festzustellen. Darüber hinaus sind Schäden nicht immer einfach vollständig zu beheben oder das Ausmaß des Schadens kann unklar bleiben.
• Es ist zu berücksichtigen, dass Cyberattacken Sicherheitsmaßnahmen, die wegen anderer Risiken eingeführt wurden, unwirksam machen können.
• Die Aufsicht sieht Cybersicherheit auch als wesentlich für kleine Institute an, sofern durch Vernetzung kleiner Institute mit anderen die Ausbreitung von Cyberattacken droht.

Währenddessen sind für die Effekte von Schadenereignissen auf die Reputation oder die Strategie- und Geschäftsziele, die zusätzlich zu den operationellen Schäden im engeren Sinn auftreten können, weitergehende Betrachtungen erforderlich: Die Berücksichtigung eines Reputationsrisikos wäre angebracht, wenn erhebliche Auswirkungen zu erwarten sind, wobei unsicher sein kann, zu welchem Zeitpunkt und in welcher Höhe nach einem Schadenereignis eine finanzielle Auswirkung tatsächlich vorliegen wird. Es könnten bezüglich der Höhe finanzieller Auswirkungen Schätzungen vorgenommen werden, mit der Absicht, eine Vernachlässigung von Reputationsrisiko gegenüber leichter quantifizierbaren Risiken zu vermeiden. Demgemäß bestehen regulatorische Anforderungen insbesondere in Zusammenhang mit Risikotragfähigkeit und Kapitalplanung, schlecht quantifizierbare Risiken nicht zu vernachlässigen, sondern hinreichend konservative Risikobewertungen in diesem Fall vorzunehmen (vgl. ECB Guide ICAAP, §74).

Reputationsrisiko besteht gegenüber verschiedenen Stakeholdern. Unter Beachtung einer dementsprechenden Unterteilung können nach Schadenereignissen verschiedene Effekte auftreten, wobei zumindest teilweise finanzielle Auswirkungen anzunehmen sind:

• Reputation gegenüber Kunden: künftig entgangenes Geschäft, höhere Prozesskosten (in Verbindung mit der Bearbeitung von Beschwerden);
• Reputation gegenüber Geschäftspartnern: künftig nicht mehr bestehende Geschäftsbeziehungen oder schlechtere Konditionen;
• Reputation gegenüber der Aufsicht: höhere Prozesskosten (wegen erhöhter Aufmerksamkeit der Aufsicht und mehr Kommunikation mit der Aufsicht);
• Reputation in der Öffentlichkeit: künftig entgangenes Neugeschäft (im Fall, dass bei einem Schadenereignis eine gewisse Wahrnehmungsschwelle überschritten wird).

Szenarioanalyse, Stresstest und ICAAP

Wenn Risiken wesentlich sind, dann ist Eigenkapital zu hinterlegen, um das Risiko zu decken, oder die Rechtfertigung zu dokumentieren, warum kein Kapital hinterlegt wird. Die Angemessenheit der Eigenkapitalausstattung ist insbesondere für Stressszenarios und adverse Szenarios im Rahmen der Risikotragfähigkeit beziehungsweise der Kapitalplanung zu untersuchen. Bei wesentlichen IT-Sicherheitsrisiken und Reputationsrisiken ist dann angemessen festzulegen, wie diese Risikoarten in die Szenarios einbezogen werden.

Der Zeithorizont für die Kapitalplanung ist 3 bis 4 Jahre, sodass Risiken mit wesentlichen finanziellen Auswirkungen, die innerhalb eines solchen Zeitraums eintreten können, zu berücksichtigen sind. In Anbetracht dieses Zeithorizonts können hierzu auch verzögerte finanzielle Auswirkungen von reputationsschädigenden Ereignissen gehören.

Die Einführung eines Szenarios besteht aus Definitionen einer Reihe von Parametern, für die Herleitung und Begründung zu dokumentieren sind:

• Wieso ist die Auswahl, welche Parameter in Szenarios Stress unterzogen werden, insbesondere im Hinblick auf IT-Sicherheitsrisiko und Reputationsrisiko angemessen und ausreichend?
• Wenn Werte in einem Szenario für bezüglich IT-Sicherheitsrisiko oder Reputationsrisiko untersuchte Parameter definiert werden, wie können diese Werte begründet beziehungsweise abgeleitet werden?

Ein adverses Szenario wird danach beurteilt, einerseits realistisch und plausibel zu sein, andererseits hinreichend adverse Umfeldbedingungen wiederzugeben und zumindest ein schlechteres Gesamtergebnis als das Normalszenario herbeizuführen. Ein Stressszenario soll erst recht ein schlechteres Gesamtergebnis als das Normalszenario herbeiführen. Dementsprechend verlangen Stressszenarios sowie adverse Szenarios keine Vorhersage eines mittleren Werts für die Auswirkungen in Verbindung mit IT-Sicherheitsrisiko oder Reputationsrisiko, sondern eine konservative Abschätzung.

Eine Begründung der Risikoposition für IT-Sicherheitsrisiko, die z.B. auf Ebene der gesamten Bank in einem Szenario definiert wird, kann sich dennoch auf geschätzte Höhe und geschätzte Häufigkeit von Schäden, die unter diese Risikoart fallen, als Ausgangspunkt stützen. Die Risikoposition ist im Szenario dann in angemessener Weise höher als der erwartete Wert (die erwartete mittlere Schadenhöhe multipliziert mit der erwarteten Schadenhäufigkeit) zu setzen. In dieser Hinsicht ist von Bedeutung, dass bei Schätzungen für Schadenwahrscheinlichkeiten und -höhen nicht nur die geschätzten Werte angegeben werden, sondern auch eine Ableitung hierfür explizit ausformuliert wird, um eine angemessene Anpassung der Schätzung nach oben zu unterstützen.

In den mehrjährigen Szenarios für die Kapitalplanung wird neben der Setzung von Risikoparametern eine Annahme bezüglich der Entwicklung des Geschäftsvolumens und des Gewinns benötigt. Hierbei ist zu beachten, dass Reputation ein Bestandteil der externen Aufstellung einer Bank ist. Die Realisierung von geplantem Geschäftsvolumen sowie geplantem Gewinn wird von der Aufstellung der Bank abhängig sein und kann dementsprechend insbesondere durch Reputationsschäden behindert werden.

Andererseits ist für die Szenariodefinition beziehungsweise für die Methodik zur Verarbeitung von Szenarios im Rahmen der Kapitalplanung die Frage zu behandeln, wie sich Wachstum beziehungsweise Schrumpfung des Geschäftsvolumens auf das Risiko auswirkt. Im Gegensatz zu anderen Risikoarten wie beispielsweise Kreditrisiko ist nicht immer ein kleineres IT-Risiko bei schrumpfendem Geschäftsvolumen anzunehmen.

Für den ICAAP sind nicht nur Szenarios bezüglich einer Risikoart, sondern auch Szenarios bezüglich mehrerer Risikoarten zu betrachten, sodass nicht nur die Sensitivität bezüglich einer Risikoart, sondern Stress bezüglich mehrerer Risikoarten gleichzeitig getestet wird. Dementsprechend sind in einem Szenario Parameter für mehrere Risikoarten gegebenenfalls einschließlich IT-Sicherheitsrisiken und Reputationsrisiken zu definieren. Die Entwicklung der verschiedenen Szenarioparameter einschließlich der Wachstumsraten im Rahmen eines mehrjährigen Szenarios sind hierbei konsistent zu halten (vgl. EBA Guidelines on institutions´ stress testing, Abschnitt 4.6.3). In dieser Hinsicht ist von Bedeutung, dass bei der Setzung von Parametern für IT-Sicherheitsrisiken, anderen Risikoparametern und Wachstumsraten nicht nur die Werte an sich verfügbar sind, sondern auch die für die Herleitung herangezogenen Zusammenhänge. Wenn Wirkungsketten transparent gemacht werden, unterstützt dies eine konsistente Ausübung von Stress für verschiedene Parameter.

Letztlich ist durch Szenariobetrachtungen einschließlich einer gestressten Position für IT-Sicherheitsrisiko die Frage zu beantworten, welche Auswirkungen schlagend werdende IT-Sicherheitsrisiken auf regulatorisch vorgegebene Kennzahlen wie etwa Kapitalquoten haben würden. Im Rahmen des ICAAP sind die Ergebniseffekte für einzelne Szenarios von Interesse; die Frage ist, ob ein Szenario ausgehalten wird.

Optimierungspotential?

Was sind besonders kritische Punkte, wenn das Management von IT-Risiken optimiert werden soll?

Ergebnisse von Erhebungen zu IT-Risiken, insbesondere der Schutzbedarfsanalysen, sollten in geeigneter Weise in einer Datenbank abgelegt werden, um Zugriff auf mehrere Jahre historische Daten zu ermöglichen. Nur damit wird eine solide Basis für eine Validierung der Vorgehensweise geschaffen.

Wenn möglich, ist eine Verlustdatenbank aufzubauen. Hierbei sind einheitliche und genaue Abgrenzungen der Schadenarten beziehungsweise Risikoarten in dieser Datensammlung wesentlich, weil nur damit eine konsistente Vorgehensweise bei der Schätzung von Schadenwahrscheinlichkeiten und -höhen sowie der Bestimmung von Risikopositionen unterstützt wird. Dies führt wiederum auf die Frage zurück, wie genau die Taxonomie der Risikoarten in der Bank ausgestaltet wird, insbesondere in Bezug auf nichtfinanzielle Risiken.

Wenn Schadenwahrscheinlichkeiten und Schadenhöhen geschätzt werden, dann ist erstrebenswert, dass die Wahrscheinlichkeit beziehungsweise die Höhe mit Hilfe kausaler Zusammenhänge hergeleitet werden. Bezüglich dieser Herleitung ist die Entwicklung einer Methodik beziehungsweise eine Dokumentation bereits gebräuchlicher Vorgehensweisen erstrebenswert. Dies stellt einen Ausgleich dafür dar, dass während der Ausführung einer Schutzbedarfsanalyse nur ein begrenztes Verständnis für Datensammlung und die Verwendbarkeit dieser Daten gegeben ist.

Zuständigkeiten sind im Bereich von IT-Risiko und Informationssicherheit möglicherweise dann unklar, wenn bei Eintritt eines Schadens verschiedene Abteilungen, verschiedene Prozesse und verschiedenartige Transaktionen betroffen sind. Die Festlegung von Rollen und Zuständigkeiten bezüglich IT-Risiko und Informationssicherheits-Management in der Organisation ist insofern von wesentlicher Bedeutung.

Über den Autor

Dr. Helge Thiele ist als Unternehmensberater mit Schwerpunkt auf dem Risikomanagement in Banken tätig. Seit mehr als 10 Jahren beschäftigt er sich mit Entwicklung und Validierung von Risikomethodik, Verlustdatensammlung, regulatorischen Anforderungen und der technischen Umsetzung von Risikomodellen.

Wie ADVISORI Ihnen hilft

Neue regulatorische Anforderungen sowie technische Entwicklungen erfordern teilweise eine Weiterentwicklung der Systeme und der Verfahren. Advisori deckt durch Zusammenarbeit der Bereiche Information Security, Data Integration, BI und Risk Management das erforderliche Spektrum ab – von Cyber Risk und IT-Security über Datensammlung, Risikomanagement und -methodik bis zu IT-Audit und IT-Compliance. Advisori ist eine unabhängige Beratung und arbeitet mit allen am Markt gängigen Software-Lösungen. Wir begleiten Sie gerne bei der Umsetzung neuer Anforderungen.