Aufrufe
vor 1 Jahr

RISIKO MANAGER 04.2018

  • Text
  • Anforderungen
  • Bonds
  • Institute
  • Unternehmen
  • Aufsicht
  • Institut
  • Risiken
  • Marisk
  • Insbesondere
  • Februar
  • Risiko
RISIKO MANAGER ist das führende Medium für alle Experten des Financial Risk Managements in Banken, Sparkassen und Versicherungen. Mit Themen aus den Bereichen Kreditrisiko, Marktrisiko, OpRisk, ERM und Regulierung vermittelt RISIKO MANAGER seinen Lesern hochkarätige Einschätzungen und umfassendes Wissen für fortschrittliches Risikomanagement.

24

24 RISIKO MANAGER 04|2018 bezug) berücksichtigt werden, da vor einer änderungen in den IT-Systemen im Rahmen von IT-Projekten, deren Auswirkung auf die IT-Aufbau- und IT-Ablauforganisation sowie die dazugehörigen IT-Prozesse im Rahmen einer Auswirkungsanalyse – nach AT 8.2 Tz. 1 MaRisk – bewerten müssen. Weiterhin wird von den Instituten verlangt, dass sie beim erstmaligen Einsatz sowie bei wesentlichen Veränderungen von IT-Systemen die Anforderungen der AT 7.2 (insbesondere Tzn. 3 und 5) Ma- Risk, AT 8.2 Tz. 1 MaRisk sowie AT 8.3 Tz. 1 MaRisk beachten. Institute müssen die organisatorischen Grundlagen von IT-Projekten (einschließlich Qualitätssicherungsmaßnahmen) und die Kriterien für deren Anwendung festlegen (Tz. 32). Jedes Institut muss seine IT-Projekte angemessen steuern sowie dabei die Risiken hinsichtlich Dauer, Ressourcenverbrauch und Qualität der IT-Projekte berücksichtigen. Zu diesem Zweck hat es Vorgehensmodelle zu bestimmen und deren Einhaltung zu überwachen (Tz. 33). Die Geschäftsleitung muss darauf achten, dass eine Gesamtübersicht der IT-Projekte und der Risiken erstellt wird. Dabei muss das Institut sein Portfolio der IT-Projekte unter Berücksichtigung der Abhängigkeiten der verschiedenen Projekte und die daraus resultierenden Risiken angemessen überwachen und steuern (Tz. 34). Das gegenüber dem Entwurf in die Tzn. 33 und 34 aufgenommene Wort „angemessen“ erleichtert und relativiert diese Anforderungen an die Institute im Sinn des Proportionalitätsprinzips. Über wesentliche IT-Projekte und IT-Projektrisiken muss die Geschäftsleitung regelmäßig und anlassbezogen informiert werden. Dabei sind wesentliche Projektrisiken im Risikomanagement zu erfassen (Tz. 35). Die Institute müssen für ihre Anwendungsentwicklung risikoorientiert angemessene Prozesse bestimmen, die Vorgaben zur Anforderungsermittlung, zum Entwicklungsziel, zur (technischen) Umsetzung (einschließlich Programmierrichtlinien), zur Qualitätssicherung sowie zu Test, Abnahme und Freigabe beinhalten (Tz. 36). Die Anforderung einer risikoorientierten Ausgestaltung der Prozesse sollte auch beim Themenkomplex „Entwicklung durch Dritte“ (Auslagerung/Fremd- endgültigen Annahme oder Ablehnung des IT-Projekts die damit verbundenen Risiken näher untersucht werden sollten. Anwendungsentwicklung umfasst gemäß den Erläuterungen zu Tz. 36 u. a. die Entwicklung von Software zur Unterstützung bankfachlicher Prozesse oder die von Endbenutzern in den Fachbereichen selbst entwickelten Anwendungen (wie Individuelle Datenverarbeitung, IDV). In den Tzn. 37 bis 42 werden verschiedene, aber den Instituten nicht unbekannte Anforderungen zur Anwendungsentwicklung präzisiert. So muss das Institut Vorkehrungen treffen, sodass man erkennen kann, ob eine Anwendung versehentlich geändert oder absichtlich manipuliert wurde. Weiterhin müssen Anwendungen sowie deren Entwicklung übersichtlich und für sachkundige Dritte nachvollziehbar dokumentiert sein. Die Aufsicht fordert in Tz. 43 ein angemessenes Verfahren zur Klassifizierung und Kategorisierung (Schutzbedarfsklasse) sowie für den Umgang mit den von Endbenutzern des Fachbereichs entwickelten oder betriebenen Anwendungen. Dabei wird auch die Einhaltung von Programmierstandards für die von Endbenutzern in den Fachbereichen entwickelten Anwendungen erwartet (wie IDV-Anwendung). Hierbei ist insbesondere auf die in den Fachabteilungen entwickelten Anwendungen in Excel, Lotus Notes oder Programmiersprachen hinzuweisen. Jede dieser Anwendungen muss einer Schutzbedarfsklasse – die Aufsicht benutzt den Begriff „Risikoklasse“ – zugeordnet werden. Es ist zu erwarten, dass sich die Prüfer in einem ersten Schritt die Inventarisierung der Anwendungen beispielsweise in Form eines zentralen Registers vorlegen lassen [Essler & Gampe, 2018, S. 20]. Die Fachabteilungen müssen nachweisen können, welche Anwendungen wo und wofür angewendet werden. Ansonsten sind Feststellungen der Prüfer in diesem Bereich nicht ausgeschlossen. Nicht unproblematisch ist die Anforderung der Tz. 44, die von den Instituten Regelungen zur Identifizierung aller von Endbenutzern des Fachbereichs entwickelten oder betriebenen Anwendungen, zur Dokumentation, zu den Programmierrichtlinien und zur Methodik des Testens, zur Schutzbedarfsfeststellung und zum Rezertifizierungsprozess der Berechtigungen erwartet. Ein Beispiel wäre eine IDV-Richtlinie des Instituts. Diese Anforderung könnte in der Praxis dazu führen, dass die Institute vor allem bei Kernprozessen verstärkt eine Standardisierung in der Digitalisierung vorantreiben und immer weniger – insbesondere bei Risikodatenverarbeitung – Excel-Programme oder dergleichen einsetzen. IT-Betrieb Basierend auf AT 7.2 Tzn. 1 und 2 MaRisk hat der IT-Betrieb (einschließlich Datensicherung) gemäß Tz. 45 die Erfüllung der Anforderungen umzusetzen, die sich aus der Anwendung der Geschäftsstrategie und aus den IT-unterstützten Geschäftsprozessen ergeben. Gegenüber dem Entwurf vom 14. Juni 2017 sind die Formulierungen in der finalen Fassung präzisiert worden. Der Fokus ist auf die Geschäftsprozesse im Allgemeinen und nicht nur auf IT-Prozesse gerichtet. Weiterhin ist in den Anforderungen das Wort „unterstützen“ ersetzt worden durch „umzusetzen“. Der Juni-Entwurf lautete an dieser Stelle „... sowie die daraus resultierenden IT-Prozesse, wirksam zu unterstützen“ [Essler & Gampe, 2018, S. 20]. Die Institute müssen die Komponenten ihrer IT-Systeme sowie deren Beziehungen zueinander in geeigneter Weise verwalten und die hierzu erfassten Bestandsangaben regelmäßig sowie anlassbezogen aktualisieren (Tz. 46). Die Aufsicht empfiehlt, eine Configuration Management Database (CMOB) zu nutzen. Gemäß Tz. 47 müssen die Institute ihr Portfolio aus IT-Systemen angemessen steuern und dabei auch die Risiken aus veralteten IT-Systemen berücksichtigen (Lebens-Zyklus-Management). Die Aufsicht erwartet in diesem Kontext, dass eine gezielte Erfassung der Risiken aus veralteten IT-Systemen das IT-Risikobewusstsein der Institute schärft. Die Institute haben darauf zu achten, dass sie die Prozesse zur Änderung von IT-Systemen abhängig von Art, Umfang, Komplexität und Risikogehalt ausgestalten

Regulierung 25 und umsetzen. Dies ist sowohl für Neuund Ersatzbeschaffungen von IT-Systemen als auch für sicherheitsrelevante Nachbesserungen (Sicherheitspatches) erforderlich (Tz. 48). Tz. 49 präzisiert die Anträge zur Änderung von IT-Systemen unter Berücksichtigung möglicher Umsetzungsrisiken. Die Institute haben nach Tz. 50 geeignete Kriterien für die Information der Geschäftsleitung über ungeplante Abweichungen vom Regelbetrieb (Störungen) zu bestimmen. Hierbei müssen auch die Ursachen, die eingesetzten Notfallmaßnahmen zur Aufrechterhaltung und zur Wiederherstellung des Geschäftsbetriebs sowie die Beseitigung der Mängel erfasst werden. Eine Analyse möglicher Korrelationen von Störungen und deren Ursachen muss im Rahmen eines Prozesses vorgenommen werden. Die Institute müssen Vorgaben für die Verfahren zur Datensicherung (ohne Datenarchivierung) schriftlich in einem Datensicherungskonzept implementieren. Dabei sind die im Datensicherungskonzept dargestellten Anforderungen an die Verfügbarkeit, Lesbarkeit und Aktualität der Kunden- und Geschäftsdaten sowie an die für deren Verarbeitung notwendigen IT-Systeme aus den Anforderungen der Geschäftsprozesse und den Geschäftsfortführungsplänen abzuleiten. Die Institute müssen ihre Verfahren zur Wiederherstellbarkeit im erforderlichen Zeitraum und zur Lesbarkeit von Datensicherungen regelmäßig, mindestens jährlich, im Rahmen einer Stichprobe sowie anlassbezogen testen. Gegenüber dem BAIT-Entwurf ist der Testumfang für die Institute beschränkt worden; es ist nur mindestens jährlich eine Stichprobe erforderlich. Auslagerungen und sonstiger Fremdbezug von IT-Dienstleistungen Die Institute müssen die BAIT-Regelungen zu den Auslagerungen und zu sonstigem Fremdbezug von IT-Dienstleistungen stets im Kontext mit den Vorgaben der MaRisk, insbesondere AT 9 Tz. 1, beachten. Im Rahmen der 5. MaRisk-Novelle [Schulte-Mattler & Dürselen, 2018] ist bereits eine grundsätzliche Abgrenzung zwischen Auslagerung und dem sonstigen Fremdbezug von IT-Dienstleistungen erfolgt. Dies bedeutet, dass in den BAIT „nur“ ergänzende Anforderungen an Auslagerungen und sonstigen Fremdbezug von IT-Dienstleistungen geregelt sind. Tz. 52 präzisiert zunächst den Begriff „IT-Dienstleistungen“ und fasst darunter

RISIKO MANAGER

RISIKO MANAGER 01.2019
RISIKO MANAGER 02.2019
RISIKO MANAGER 03.2019
RISIKOMANAGER_04.2019
RISIKO MANAGER 05.2019
RISIKO MANAGER 06.2019
RISIKO MANAGER_07.2019
RISIKO MANAGER 01.2018
RISIKO MANAGER 02.2018
RISIKO MANAGER 03.2018
RISIKO MANAGER 04.2018
RISIKO MANAGER 05.2018
RISIKO MANAGER 06.2018
RISIKO MANAGER 07.2018
RISIKO MANAGER 08.2018
RISIKO MANAGER 09.2018
RISIKO MANAGER 10.2018
RISIKO MANAGER 01.2017
RISIKO MANAGER 02.2017
RISIKO MANAGER 03.2017
RISIKO MANAGER 04.2017
RISIKO MANAGER 05.2017
RISIKO MANAGER 06.2017
RISIKO MANAGER 07.2017
RISIKO MANAGER 08.2017
RISIKO MANAGER 09.2017
RISIKO MANAGER 10.2017
RISIKO MANAGER 01.2016
RISIKO MANAGER 02.2016
RISIKO MANAGER 03.2016
RISIKO MANAGER 04.2016
RISIKO MANAGER 05.2016
RISIKO MANAGER 06.2016
RISIKO MANAGER 07.2016
RISIKO MANAGER 08.2016
RISIKO MANAGER 09.2016
RISIKO MANAGER 10.2016
RISIKO MANAGER 01.2015
RISIKO MANAGER 02.2015
RISIKO MANAGER 03.2015
RISIKO MANAGER 04.2015
RISIKO MANAGER 05.2015
RISIKO MANAGER 06.2015
RISIKO MANAGER 07.2015
RISIKO MANAGER 08.2015
RISIKO MANAGER 09.2015
RISIKO MANAGER 10.2015
RISIKO MANAGER 11.2015
RISIKO MANAGER 12.2015
RISIKO MANAGER 13.2015
RISIKO MANAGER 15-16.2015
RISIKO MANAGER 17.2015
RISIKO MANAGER 18.2015
RISIKO MANAGER 19.2015
RISIKO MANAGER 20.2015
RISIKO MANAGER 21.2015
RISIKO MANAGER 22.2015
RISIKO MANAGER 23.2015
RISIKO MANAGER 24.2015
RISIKO MANAGER 25-26.2015
 

Copyright Risiko Manager © 2004-2017. All Rights Reserved.