Source: https://www.fc-heidelberg.de/outsourcing-im-zuge-der-neuen-regulierung/
Timestamp: 2020-01-25 08:15:50
Document Index: 339160491

Matched Legal Cases: ['§ 44', '§ 25', '§ 25', '§ 613', '§ 25', '§ 25', '§ 25', '§ 25', '§ 1', '§ 25', '§ 25']

Was bedeuten die neuen Anforderungen der MaRisk / BAIT für das Outsourcing
I. Grundsätzliches zum Outsourcing
Der Begriff Outsourcing ist ein Kunstwort, der sich ausgehend vom Wortstamm, aus den drei englischen Wörtern „Outside“, „Ressource“ und „Using“ zusammensetzt. Wörtlich übersetzt bedeutet er in erster Linie „Nutzung externer Ressourcen“. Eine IT-Auslagerung (Outsourcing) liegt vor, wenn ein anderes Unternehmen mit der Wahrnehmung solcher IT-Aktivitäten und IT-Prozesse im Zusammenhang mit der Durchführung von Bankgeschäften, Finanzdienstleistungen oder sonstigen institutstypischen Dienstleistungen beauftragt wird, die ansonsten vom Institut selbst erbracht würden. Im Sprachgebrauch der Aufsicht des Kreditgewerbes handelt es sich dabei um den Begriff der „Auslagerung“ (AT 9 MaRisk). Der sonstige Fremdbezug von Leistungen wird sich aber mit der Novellierung der MaRisk und der Neueinführung der BAIT in 2017 ändern. Aus dem Konsultationsentwurf zur Überarbeitung der Mindestanforderungen an das Risikomanagement (MaRisk) ergibt sich eine Reihe von bislang noch nicht normierten Organisationspflichten, die die Institute je nach Komplexität und Umfang der Auslagerung in unterschiedlichem Ausmaß betreffen. Die Überarbeitung zielt zum einen auf die Umsetzung weiterentwickelter internationaler und europäischer Vorgaben ab. Zudem sind Erkenntnisse der vergangenen Jahre aus der Aufsichtspraxis eingeflossen. Derartige bisher nicht normierte Organisationspflichten sind dabei vielfach bereits in der Vergangenheit als Prüfungsfeststellungen in Prüfungen etwa nach § 44 KWG ausgesprochen worden. Es handelt sich also vielfach um Klarstellungen aufsichtsrechtlicher Sichtweisen, nicht um Neuregelungen im engeren Sinn. Der Begriff der Auslagerung wird in den MaRisk näher definiert. Die BaFin verschärft die Regeln für das Auslagerungswesen deutscher Banken. Kreditinstitute müssen künftig ausgelagerte Aktivitäten und Prozesse stärker überwachen. Dies geht einher mit einem einheitlichen Risikobewusstsein, das die Aufsicht von Finanzunternehmen auch für diese Tätigkeiten erwartet. Viele Banken müssen deshalb umdenken.
Eine Auslagerung liegt dann vor, wenn ein Institut einen Dienstleister mit der Wahrnehmung von Prozessen im Zusammenhang mit der Durchführung von Bankgeschäften, Finanzdienstleistungen oder sonstigen institutstypischen Dienstleistungen beauftragt, die ansonsten vom Institut selbst erbracht würden. Das Risiko besteht eindeutig in der Abhängigkeit zu einem Drittunternehmen. Im Rahmen ihrer Aufgaben ist auch zwingend die Interne Revision zu beteiligen. Soweit sich wesentliche Änderungen der Risikosituation ergeben, ist die Risikoanalyse anzupassen (MaRisk AT 9 Tz. 2). Neu ist, dass die Risikoanalyse auf der Grundlage von institutsweit oder gruppenweit einheitlichen Vorgaben sowohl regelmäßig als auch anlassbezogen durchgeführt werden muss. Dies betrifft Risikocontrolling, Compliance und Interne Revision. Bereits bei der Risikoanalyse sollen mögliche Risiken aus Weiterverlagerungen berücksichtigt werden. Es stellt sich die Frage, wie dies sichergestellt werden soll, ohne bereits vor Auslagerung eine vollständige Transparenz über alle Subauslagerungen des Dienstleisters zu haben. Insbesondere vor dem Hintergrund, dass bei wesentlichen Auslagerungen im Auslagerungsvertrag auch Regelungen über die Möglichkeit und über die Modalitäten einer Weiterverlagerung zu vereinbaren sind. Eine Vollauslagerungen der Risikocontrolling-Funktion ist gar nicht, Vollauslagerungen der Compliance-Funktion und der Internen Revision sind nur bei kleinen Instituten möglich, bei denen die Einrichtung letztgenannter Funktionen vor dem Hintergrund der Institutsgröße und der betriebenen Geschäfte unverhältnismäßig wäre. Eine Vergabe von bisher im eigenen Haus durchgeführten Prozessen kann die Geschäftstätigkeit eines Kreditinstituts grundlegend verändern. Die MaRisk schließen dies nicht aus – sofern nicht die Geschäftsleitung und die Ordnungsmäßigkeit der Geschäftsorganisation gem. § 25a Abs. 1 KWG davon betroffen sind bzw. beeinträchtigt werden. Festgehalten werden muss, dass die Leistungsverlagerungen nie zu einer Übertragung der Risikoverantwortung führen dürfen (AT 9 Tz. 4 MaRisk). Das vergebende Unternehmen trägt immer die Gesamtverantwortung. Eine verbesserte Risikokultur in Finanzunternehmen zu schaffen, ist eines der erklärten Ziele für die aktuelle Regulierungswelle im Bereich Risikomanagement. Tatsächlich übernimmt der Gesetzgeber dabei zahlreiche Vorgaben aus internationalen Vereinbarungen, die das deutsche Aufsichtsrecht seit der letzten MaRisk-Novelle 2012 noch nicht explizit abdeckt. Beispielsweise schreibt die Europäische Union den Instituten vor, Grundsätze und Standards einzuführen, die eine wirksame Kontrolle von Risiken durch Leitungsorgane gewährleisten (vgl. Bankenrichtlinie 2013/36/EU, CRD IV). Zudem bezieht sich die BaFin auf das Baseler Papier BCBS 239, das die Risikoberichterstattung und die Risikodatenaggregation behandelt. Damit rücken auch IT-technische Aspekte und mögliche Auslagerungen in den Fokus der Aufsicht.
II. Vertragsgestaltung und Service Level Agreements
Hat man sich für ein IT-Outsourcing mit geeignetem IT-Dienstleister entschieden, müssen die bei der Partnerwahl in einem Pflichtenheft beschriebenen Anforderungen in einem nächsten Schritt vertraglich festgehalten werden. Für den Outsourcing-Vertrag gibt es keine gesetzlichen Vorgaben. Es gibt aber aufsichtsrechtliche Anforderungen (§ 25a KWG, MaRisk usw.). Für die Vereinbarung der Leistungen gibt es Dienstleistungsverträge, Werkverträge, Werklieferverträge usw., die sich an den Grundtypen im BGB orientieren und auch bestimmte Regelungen z.B. § 613a BGB, die zu beachten sind. Dadurch gibt es auch keine verbindlichen Regeln, wie der Vertrag aufgebaut sein und welchen Inhalt er haben soll. Durch die Komplexität, die ein Outsourcing-Projekt annehmen kann, ist eine möglichst klare Abgrenzung von Rechten und Pflichten zwischen den Vertragsparteien wichtig. Ein eindeutiges und kontrollierbares Verhalten der Vertragspartner kann erst dadurch gewährleistet werden. Eine detaillierte Regelung im Vorhinein kann darüber hinaus auf beiden Seiten Klarheit schaffen, welche Voraussetzungen erfüllt werden müssen, um die Zusammenarbeit zum Erfolg zu führen. In diesem Zusammenhang ist die Gestaltung der Service-Level- Agreements (SLA) im Auslagerungsprozess essenziell. Die in AT 9 Tz. 6 MaRisk genannten Mindestanforderungen sollten hierbei wirklich nur den unteren Level darstellen. Je genauer die Auftragsinhalte und deren gewünschte Durchführung vereinbart wurden, umso genauer lassen sich quantitative sowie qualitative Abweichungen feststellen. Hierzu bedarf es, ähnlich wie in den Übernahmeverträgen zu Beginn des Outsourcing-Vorhabens, vertraglicher Vereinbarungen über die (Rück)Übertragung bestimmter Vermögensgegenstände (Hard- und Software) und Verträge vom Auftragnehmer auf den Auftraggeber, wobei in manchen Fällen sogar Personalübernahme stattfindet. Regelungen über das Change Management finden sich in der Regel im Rahmenvertrag. Sie betreffen die Behandlung von Änderungswünschen (Change Requests) des Auftraggebers oder des Auftragnehmers gegenüber den ursprünglich vereinbarten Leistungen. Hier muss ein Prozess definiert werden, der sicherstellt, dass solche Änderungswünsche kurzfristig bearbeitet und gegebenenfalls auch umgesetzt werden können. Dabei ist insbesondere auch eine Regelung über die Anpassung der für die betreffenden Leistungen vereinbarten Vergütung aufzunehmen.
Die Leistungsverpflichtungen und Rahmenbedingungen werden schließlich im Vertrag konkretisiert und ausgestaltet. Der Vertrag sollte deshalb sowohl flexible Variablen (z.B. Einführung neuer Technologien, verschlechterte wirtschaftliche Lage) zulassen, als auch stabile Vorgaben aufweisen. Ein Punkt, der bei der Gestaltung von einem Rahmenvertrag zum IT-Outsourcing ebenfalls berücksichtigt werden muss, ist die Informationssicherheit. Durch das Outsourcing können sich Verantwortlichkeiten im Unternehmen verschieben und ändern. Auch können zusätzliche Schnittstellen entstehen. Jedes Institut muss für die Steuerung und Überwachung wesentlicher Auslagerungen klare Verantwortlichkeiten festlegen. Bei Vollauslagerungen hat die Bank ohnehin jeweils einen Beauftragten zu benennen, der eine ordnungsgemäße Durchführung der jeweiligen Aufgaben gewährleistet. Zusätzlich fordert der Gesetzgeber bei Instituten mit umfangreichen Auslagerungslösungen ein zentrales Auslagerungsmanagement. Dieses stellt sicher, dass eine Stelle im Institut einen Gesamtüberblick über ausgelagerte Prozesse und Aktivitäten hat und so ein möglichst einheitlicher Umgang mit den besonderen Risiken aus Auslagerungen und deren Überwachung sichergestellt wird. Unter solchen Voraussetzungen sollte der Sicherheit von Daten und Informationen auch im Rahmenvertrag eine hohe Aufmerksamkeit gewidmet werden. Auf diese Weise kann ein Rahmenvertrag so gestaltet sein, dass Aufgaben, Kompetenzen und Verantwortlichkeiten für beispielsweise Zutritts- und Zugriffssicherheit, Berichterstattung und Releaseplanung mitberücksichtigt werden. Der Leitungsebene kommt eine hohe Verantwortung für die Informationssicherheit zu. Fehlende Steuerung, eine ungeeignete Sicherheitsstrategie oder falsche Entscheidungen können durch Sicherheitsvorfälle weitreichende negative Auswirkungen haben.
Die nachfolgend beschriebenen Aspekte werden im Service Level Management (SLM) gesteuert. Das SLM beschreibt den Prozess von der Erstellung und Verhandlung der Service Levels, über das Monitoring der Leistungserfüllung, das Reporting an zuständige Personen, bis hin zum kontinuierlichen Verbessern der Vertragsbestandteile und der Leistungsbeziehung. Oftmals kommuniziert ein Dienstleistungsgeber mit dem Auftraggeber nur über zwei Wege: die SLA-Reports und die Rechnungsstellung. Die Service Level sind vertraglich vereinbart. Der Dienstleistungsgeber kann in der Regelkommunikation, wie sie heute mehrheitlich praktiziert wird, überdurchschnittliche Leistungen nicht darstellen. Damit gerät er schnell in einen Jo-Jo-Effekt: Das Topmanagement des Kunden wird immer nur im Eskalationsfall - bei größerer SLA-Verletzung - einbezogen. Der Name des Dienstleisters fällt auf dieser Ebene stets zusammen mit "Negativschlagzeilen". Dabei gründen auf den Reports wichtige Entscheidungen zum Controlling, zur Anpassung der Qualitätsanforderungen (etwa an neue Geschäftsprozesse und
-modelle) sowie im schlimmsten Fall über die Nutzung von Exit-Klauseln bei Schlechtleistung. Was sollte ein Reporting leisten, das einerseits den Kunden zufrieden stimmt, andererseits dem Dienstleister die Chance eröffnet, seinen Beitrag in der Outsourcing-Beziehung angemessen darzustellen? Zunächst muss es eine grundlegende Anforderung erfüllen: Die Berichte müssen alle Governance-Ebenen des Kunden - operativ, taktisch und strategisch - mit den für sie jeweils relevanten Informationen versorgen, und zwar durchgängig. Das heißt: Die Daten, die diese verschiedenen Sichten unterstützen, müssen von unten nach oben generiert werden. Die operative Ebene erhält technische Informationen. Erfüllt das Reporting die Governance-Anforderungen, sollte es außerdem drei Inhalte abdecken. Erstens: Die Leistung transparent machen. Zum "Pflichtteil" des Reportings gehört es, den Zusammenhang zwischen den Servicebeschreibungen und Qualitätsvereinbarungen, den erbrachten Leistungen sowie der Rechnung herzustellen. Dazu ist es sinnvoll, nochmals die verschiedenen Etappen einer Beziehung beim Outsourcing anzuschauen. Ausgangspunkt ist die Sourcing-Strategie. Aus ihr werden die Serviceschritte abgeleitet, und auf dieser Grundlage wird die Qualität der einzelnen Services festgelegt. Beides hat Einfluss auf das Preismodell, das zusammen mit dem Verbrauch des Kunden im betrachteten Zeitraum die Rechnungsstellung bestimmt. Das Reporting muss diesen Prozess spiegeln. Zweitens muss man dem Kunden weitere Perspektiven aufzeigen. Neben dem "Pflichtteil" sollte ein Report darüber informieren, inwieweit die Ziele, die ursprünglich die Outsourcing-Entscheidung bestimmt haben, erreicht wurden. Für eine Auslagerung kann es viele Gründe geben. Neben Kostensenkung und Qualitätssteigerung sind dies oft strategische Ziele: beispielsweise zufriedenere Anwender, technische Weiterentwicklung oder ein höherer Wertbeitrag der IT, indem diese Business-Prozesse optimiert oder die Voraussetzungen für neue Geschäftsmodelle schafft. Sie sind meist in der Präambel der Outsourcing-Verträge beschrieben. Dort ruhen sie, geraten oft in Vergessenheit und fehlen in den Berichten der Dienstleister. Ein nachhaltiges Reporting sollte die Entwicklung dieser Größen dokumentieren. Dazu müssen geeignete KPI (Key Performance Indicators / Leistungskennzahlen) entwickelt werden. Als Drittes sollte die Zielerreichung dokumentiert werden. Diese Messgröße ist für den Kunden vor allem in der Anfangszeit der Vertragsbeziehung sehr wichtig. Das Reporting sollte dokumentieren, ob der vertragliche Übergang wie geplant voranschreitet, ob die Kosten den Erwartungen entsprechen und die Qualität beim Wechsel vom alten auf den neuen Provider (oder aus der unternehmensintern in die externe Verantwortung) gehalten wird. Ein nachhaltiges Reporting hängt nicht nur vom Dienstleister ab, sondern auch von der Vorgehensweise des Kunden. Der Auftraggeber sollte zunächst seine Anforderungen klar und verbindlich definieren und sie dem Dienstleister mitteilen. Gemeinsam sollten beide Parteien dann festlegen, wie diese Ziele gemessen werden. Auf dieser Grundlage können sie das Reporting aufbauen und in der Governance verankern. In den SLA wird die Leistung definiert. Beispielsweise wird Verfügbarkeit in einem SLA definiert (Messung, Ausfallzeiten, Bezugsgrößen z.B. übliche Geschäftszeiten, Toleranzgrenzen usw.). Die Messung selbst ist ein Report. Dazu werden die Serviceleistungen des Outsourcingnehmers in Bezug gesetzt zu den Anforderungen des Auftraggebers. Zielsetzung bei der Beschreibung von SLAs ist es, eine Kosten-, Leistungs- und Qualitätstransparenz zu schaffen. Im Allgemeinen wird zwischen Rahmen-SLAs und Leistungsscheinen unterschieden. Dies wird in der Praxis sehr unterschiedlich gehandhabt. SLA sind nicht normiert, können auch Teile von Leistungsscheinen sein oder in Verträge eingearbeitet sein. Rahmen-SLAs treffen dabei Aussagen zu den qualitativen und quantitativen Aspekten der ausgelagerten Leistungen, Leistungsscheine bestimmen detailliert die bereits oben dargestellten Merkmale der Leistungen. Bei Rahmen-SLAs, die durch eine Mehrzahl an Leistungsscheinen spezifiziert werden, vereinbaren die Parteien üblicherweise einheitliche Bewertungsmaßstäbe für alle Leistungen, anhand derer die Qualität der Dienstleistung gemessen werden kann. Leistungsstörungen können einerseits vom Dienstleistungsnehmer gemeldet werden, wenn sich Ungereimtheiten im Abgleich der erbrachten Leistungen gegen die entsprechenden Soll-Werte zeigen, andererseits durch den Dienstleister, indem er nach MaRisk AT 9 auf Verfehlungen hinweist, die in seinem Verschulden oder in mangelhafter Qualität der Vorleistung des Dienstleistungsnehmers liegen.
III. Dienstleistersteuerung
Es lässt sich die Notwendigkeit der Anwendung eines ganzheitlichen integrierten Risikomanagementansatzes ableiten, welcher die mit der Auslagerung in Verbindung stehenden Risiken in der Bank adressieren muss. Dies kann durch die adäquate Einbindung des Outsourcing-Managements in das bankweite Risikomanagement gelingen und stellt die vielfältigen Gestaltungsmöglichkeiten für einen ganzheitlichen wert- und risikoorientierten Managementansatz (Outsourcing Governance) vor. Viele der dargestellten Erkenntnisse ergaben sich im Rahmen der externen IT-Revision. Besonders wichtig ist im Rahmen der Beziehungspflege, dass alle Informationen, die zur Auftragserfüllung nötig oder hilfreich sind, dem Dienstleister zeitnah zur Verfügung gestellt werden. Notwendige interne Erklärungen müssen vorgenommen werden. Eine vertrauensvolle Zusammenarbeit ist die Basis des Outsourcings. Nicht zuletzt ist es Ziel aller Beteiligten, den Kunden (Mitarbeitern und Führungskräften) eine Dienstleistung anzubieten, die einen geräuschlosen Wechsel zwischen Bank und Dienstleister ermöglicht. Es ist insbesondere über die Problemfälle ausführlich quartalsweise zu berichten. Der Dienstleister erstellt hierfür eine detaillierte Fehlerstatistik. Gemeinsam werden Risiken vermieden. Die erfolgreiche Umsetzung der Outsourcing Governance umfasst dabei u. a. die Identifikation und Analyse von Wertschöpfungspotenzialen innerhalb der Bank, das effektive Management der zentralen Aufgaben in allen Phasen sowie die Verankerung der wichtigsten Outsourcing-Steuerungsinstrumente im Unternehmen. Der Einbezug des Outsourcings in das unternehmensweite Risikomanagement geht somit über die historische Form des operativen Risiko-managements, deren Fokus primär auf die Risikovermeidung und -minderung ausgelegt war, hinaus. Hauptziel ist das effiziente und effektive Management der ausgelagerten Bereiche, welches alle wesentlichen Einzelrisiken und deren Abhängigkeiten umfasst. Das risikoorientierte Management der ausgelagerten Bereiche hat das Ziel, eine ausgewogene Sichtweise von Risiken und Wertschöpfung über die gesamte Laufzeit des Outsourcing-Verhältnisses hinweg zu etablieren. Ein moderner chancen- und risikoorientierter Outsourcing-Management-Ansatz integriert die Organisation, die Aufgaben und die Instrumente in ein ganzheitliches Rahmenwerk. Die Analyse der Risiken ist wesentlich für die erfolgreiche Umsetzung des Outsourcings. Diese Risikobetrachtung besteht in der Analyse der veränderten Risikosituation der Bank nach einer möglichen Auslagerung von Prozessen und Funktionen. Voraussetzung für die Durchführung einer solchen Analyse ist die Existenz eines für die Bank angemessenen, bankweiten Risikomanagementsystems. Die Analyse kann als ein durch das Management sowie die jeweiligen Prozessverantwortlichen beeinflusster, fortlaufender Prozess beschrieben werden, der im Zuge der Strategiefindung definiert und unternehmensweit angewendet werden sollte. Potenzielle Gefahren für das Unternehmen sollen damit identifiziert und unter Berücksichtigung eines bankspezifischen Risikoappetits gesteuert werden, um die festgelegten Bankziele mit angemessener Sicherheit erreichen zu können. Das unternehmensweite Risikomanagement selbst lässt sich konzeptionell in die drei Komponenten Risikoumfeld, Risikomanagement und Risikocontrolling aufteilen. Dabei ist wesentlich, dass der Bereich Risikoumfeld auf Unternehmensebene und Risikomanagement sowie Risikocontrolling auf Prozessebene stattfinden. Die Kommunikation und Informationsverbreitung ist das notwendige Bindeglied zwischen Risikoumfeld, Risikomanagement und Risikocontrolling. Im Zusammenhang mit dem Outsourcing sind bei der Betrachtung von Risiken innerhalb einer Risikoanalyse (und damit innerhalb des unternehmensweiten Risikomanagements) zwei Risikodimensionen relevant: Risiken aufgrund externer Unsicherheiten und inhärente Risiken der Auslagerung. Der laufende Betrieb umfasst die Erbringung der vertraglich vereinbarten Leistung durch den Insourcer und ihre Steuerung und Kontrolle durch das Kreditinstitut. Ein mehrschichtiges Governance-Modell ermöglicht eine Differenzierung unterschiedlicher Ebenen der Zusammenarbeit. Kernaufgabe dieser Aktivität ist die risikominimale Zielerreichung unter Anwendung kosteneffizienter laufender Überwachungsmaßnahmen gemäß einem vollständigen Managementzyklus. Das Ziel der Dienstleistersteuerung sollte sein, durch Kontroll- und Koordinationsmaßnahmen eine regelmäßige Beurteilung der Leistungen des Dienstleisters vorzunehmen, um ggf. geeignete Maßnahmen ergreifen zu können. Die Steuerung erfolgt auf Basis der SLA’s sowie der Berichte des externen Dienstleisters oder aufgrund sonstiger Auffälligkeiten. Hierfür sollten klare Verantwortlichkeiten festgelegt und eine regelmäßige Berichterstattung sichergestellt werden. Zur risikoorientierten Dienstleistersteuerung ist eine einheitliche Methodik festzulegen. Hierbei macht es Sinn, den Steuerungsaufwand einerseits an der Wesentlichkeit des Geschäftsprozesses auszurichten und andererseits weitere Faktoren mit zu berücksichtigen. Abhängig vom Auslagerungsumfang können sich auch bei nicht als „wesentlich“ eingestuften Auslagerungen ggf. datenschutzrechtliche oder GuV-relevante Sachverhalte für die Dienstleistersteuerung ergeben. Meist erreicht der Gesamtaufwand für weitere Auslagerungen und Vergaben (nicht wesentliche, sonstiger Fremdbezug und nicht i. S. d. MaRisk zu klassifizierende Auslagerungen) ebenfalls sehr namhafte Beträge. Da solche vergebenen Leistungen oft nicht zentral gesteuert werden, benötigen die betreuenden Fachbereiche Hilfestellungen zur Steuerung ihrer Dienstleistungspartner. Bei dieser Dezentralisierung ist es wichtig, dass ein einheitliches Verständnis für die Aufgabenstellungen der vielen Prozesse oder Schnittstellenbeteiligten besteht. Eine besondere Herausforderung liegt hierbei vor allem beim rechtzeitigen Erkennen von Auffälligkeiten in der Leistungserbringung, der Ableitung und Umsetzung geeigneter Maßnahmen sowie dem gegenseitigen zeitgerechten Informationsaustausch. Die Funktionalität der Prozesse der Dienstleistersteuerung in Verbindung mit den übrigen Prozessen des Unternehmens, die auf Informationen aus der Dienstleistersteuerung angewiesen sind, z.B. Risikomanagement, Datenschutzbeauftragter oder Notfallmanagement, ist im Wesentlichen von der Qualität dieses Informationsaustausches abhängig. Perspektivisch werden die Anforderungen an die Ausgestaltung und Besetzung der Dienstleistersteuerung steigen. Die damit verbundenen hohen Etats und die Aufgabenvielfältigkeit bedingen auch Anforderungen an die stetige Weiterentwicklung der Dienstleistersteuerungsmethodik sowie Mitarbeiterquantität und -qualität. Der entscheidende Ansatz für eine nach AT 9 Tz. 7 der MaRisk angemessenen Überwachung der Aktivitäten des Dienstleisters beginnt mit der klaren systematischen Funktionstrennung auf Ebene der Internen Kontrollverfahren mit den beiden Teilen des Internen Kontrollsystems und der Internen Revision. Die Überwachung und Steuerung des Dienstleisters ist eine Aufgabe des Risikomanagements, die dem Internen Kontrollsystem zuzuordnen ist, da es sich um eine geschäfts- bzw. prozessbezogene Überwachungstätigkeit handelt. Die unternehmensinterne Methodik zur Dienstleistersteuerung spielt dabei eine wesentliche Rolle, da diese auch für die in den Fachbereichen nicht zentral gesteuerten Dienstleister den Handlungsrahmen vorgibt, um die mit der Auslagerung verbundenen Risiken angemessen zu steuern.
Neben dem Management der Überwachungsgrößen ist deren Kommunikation und Reporting Bestandteil dieser Aktivität. Die Reportinginformationen sollten sich an den Anforderungen orientieren und unterschiedliche Hierarchiestufen integrieren. Zur Verbesserung der Qualität der erbrachten Leistungen und der Zusammenarbeit wird ein periodischer oder dynamischer Optimierungsvorgang durchlaufen. Die Funktion „Dienstleistersteuerung" ist für die grundsätzliche Regelung der Leistungsbeziehung zwischen Institut als Abnehmer und einem dritten Dienstleister als Ersteller der Leistung verantwortlich. Im Fokus steht dabei zunächst – sofern relevant – die Erfüllung sämtlicher aufsichtsrechtlicher Anforderungen gemäß § 25a Abs. 2 KWG in Bezug auf die Auslagerung von Bank- und Finanzdienstleistungen. Eine sinnvolle Methode für eine solche Prüfung ist die regelmäßige Durchführung einer Zertifizierung nach IDW PS 951 Typ 2 durch einen Wirtschaftsprüfer. Die Berichterstattung nach IDW PS 951 ist explizit auf die Erfüllung der Anforderungen aus IDW PS 331 abgestellt. Insbesondere bei Mehrmandantendienstleistern bietet die Berichterstattung nach IDW PS 951 eine effiziente Prüfungsdurchführung, da die Abschlussprüfer der auslagernden Unternehmen i.d.R. keine eigenen Prüfungshandlungen beim Dienstleistungsunternehmen mehr durchführen müssen. Darüber hinaus kümmert sich die Dienstleistersteuerung im Sinne einer ganzheitlichen Steuerung der Leistungsbeziehung auch um die Wahrung der wirtschaftlichen Interessen bzgl. der Leistungsbeziehung.
Im Fall des § 25a Abs. 2 KWG ist sie für die Vorgabe von Bearbeitungsrichtlinien für den Dienstleister verantwortlich. Sie trägt somit die Prozessverantwortung für die Abläufe hinsichtlich des Leistungsbezugs vom Dienstleister. Fachspeziﬁsches Know-how lässt sich die Dienstleistersteuerung aus den jeweiligen Fachbereichen im Haus zuliefern. Die strategische Dienstleistersteuerung ist zum Beispiel für Vertragsverhandlungen und sehr kritische Eskalationen wie schwere Vertragsbrüche zuständig. Auf taktischer Ebene werden beispielsweise größere Changes genehmigt und Eskalationen geklärt. Die operative Dienstleistersteuerung sorgt für den störungsfreien Betrieb und prüft die Erfüllung aller Service Level. Die Auswertung der Ergebnisse zeigt, dass die Dienstleistersteuerung weitgehend definiert, jedoch nicht durchgehend vollzogen ist. Von der strategischen hin zur operativen Ebene nimmt der Anteil standardisierter Prozesse zu. Als unterdurchschnittlich reif werden die Prozesse Service-Kataloge und Service-Portfolio-Management beurteilt. Demnach verfügen etliche Banken noch über keinen standardisierten IT-Service-Katalog und keinen Prozess für das Management ihres Service-Portfolios. Sofern unter Effizienzgesichtspunkten sinnvoll kann die Dienstleistersteuerung den Dienstleister als weiteren Kompetenzträger in die Erarbeitung von Bearbeitungsrichtlinien einbeziehen oder Vorschläge von ihm einholen. Die Dienstleistersteuerung berichtet – hinsichtlich § 25a-KWG-relevanter Dienstleistungen – direkt der Geschäftsführung.
Die BaFin geht grundsätzlich davon aus, dass bankinterne Mechanismen beispielsweise im Risikocontrolling sowie bei Compliance-Aufgaben und Interner Revision auch bei Auslagerungen und Unterauslagerungen greifen. Die von der Bankenaufsicht erwünschte Risikokultur erstreckt sich damit unmittelbar auf die Dienstleistersteuerung. Institute müssen vor diesem Hintergrund die mit wesentlichen Auslagerungen verbundenen Risiken angemessen steuern und die Ausführung der ausgelagerten Aktivitäten ordnungsgemäß überwachen. Die Ergebnisse sind über einen expliziten Auslagerungsbericht in das eigene Berichtswesen aufzunehmen. Dieser muss zudem eine Aussage darüber treffen, ob die erbrachten Dienstleistungen der Auslagerungsunternehmen den vereinbarten Leistungen entsprechen. Die mit der Durchführung ausgelagerter Aktivitäten einhergehende Verantwortung lässt sich, vereinfacht gesagt, also nicht einfach mit auslagern. Das stellt die Aufsicht unmissverständlich klar: Sie bewertet die Frage des Auslagerungstatbestands unabhängig von möglichen zivilrechtlichen Verträgen. Das Reporting der Dienstleister ist die Grundlage für Entscheidungen im Rahmen der Anbietersteuerung. Exit-Klauseln für den Fall der Schlechtleistung, Controlling und Anpassung der Qualitätsanforderungen bauen auf ein aussagekräftiges Reporting auf. Einige IT-Führungskräfte be-klagten weiterhin ungenaue Berichte sowie SLA-Werte, die immer nur knapp über den Schwellenwerten liegen und dadurch Misstrauen hervorrufen. Zusammenfassend vermissen die Unternehmen bezüglich der Umsetzung des Berichtswesens bei ihrem IT-Dienstleister häufig Nachvollziehbarkeit, Zuverlässigkeit und Zweckmäßigkeit. Viele sind mit dem Berichtswesen ihrer IT-Dienstleister nicht zufrieden oder sehen lediglich die Minimalanforderungen als erfüllt an. Zu häufig werden Tätigkeiten, die eindeutig anderen Teilen des Internen Kontrollsystems zugeordnet sind, von der Internen Revision ausgeführt. Hierzu gehört auch die Auswertung von Risikoberichten von Mehrmandantendienstleistern. In diesen Fällen ist es nicht die Aufgabe der Internen Revision diese auszuwerten‚ sondern sie muss im Rahmen von Prüfungstätigkeiten feststellen, ob die Überwachung angemessen ist. Die Überwachungseinheiten der Auslagerung (z.B. die auslagernde Fachabteilung, der IT-Sicherheitsbeauftragte und/oder Risikomanager) müssen die erhaltenen Berichte/Informationen auswerten und vor dem Hintergrund der institutsinternen Risikokennziffer beurteilen. Es muss sich ein eigenes Urteil von der Leistung und den Risiken des Dienstleisters gebildet werden, welches anschließend in die institutsweite Betrachtung einfließt. Es sollte darauf geachtet werden, dass sich die Interne Revision nicht in diese Funktion drängen lässt und damit die nach MaRisk geforderte Funktionstrennung aufgehoben wird.
Die zentrale Norm für einen mindestens vierteljährlichen Risikobericht ﬁndet sich in AT 4.3.2 Tz. 3 der MaRisk. An dieser Stelle erwarten die MaRisk eine mindestens vierteljährliche Beschäftigung mit den wesentlichen Risiken und fordern ebenso in AT 4.3.2 Tz. 6 das vierteljährliche Reporting an den Aufsichtsrat über deren Entwicklung. Insbesondere die Risiken aus IT-Auslagerungen werden bei den meisten Banken, sofern sie nicht als eigene Risikoart eingestuft werden, in der Risikoinventur unter den operationellen Risiken aufgeführt. Alle mandantenrelevanten Mängel müssen der Bank offengelegt werden. Hierbei darf keine Filterung durch den Dienstleister erfolgen.
>>> Überleitung zum 2. Artikel: Im zweiten Teil des Artikels werden neue Alternativen betrachtet sowie konkrete Änderungen im IT-Risikomanagement berücksichtigt. Weiterhin werden verschiedene Aspekte von Softwarebezug, der künftig Outsourcing sein kann, beleuchtet.
IV. Software als Auslagerung
Die pauschale Auslagerungsqualifikation von Softwarebezug und diesbezüglichen Unterstützungsleistungen im Zusammenhang mit Risikoüberwachung ist neu, da diese – entgegen der Systematik des AT 9 – nicht an einen Auslagerungstatbestand anknüpft und bisher weder dem Risikogedanken der MaRisk noch den tatsächlichen Prozessen in der Bankpraxis gerecht wird. So würde sich auch eine vom Institut fremdbezogene, aber selbst betriebene Software als Auslagerung qualifizieren, ohne dass allgemeine Auslagerungselemente vorliegen. Dies träfe bei enger Auslegung sogar für den einmaligen Erwerb von in Eigenregie individuell an die Bedürfnisse der Banken angepasster Software ohne jeglichen Dienstleistungsbezug zu. Damit wurden die tatbestandlichen Voraussetzungen von § 25b KWG, AT 9 für (und nur für) das Thema Software de facto übergangen. Software ist für die Durchführung von Bankgeschäften per se von großer Bedeutung, da heutzutage jedes in § 1 KWG aufgeführte Bankgeschäft auf der Grundlage von IT-Systemen (teilweise vollständig automatisiert) durchgeführt wird. Die besondere Bedeutung von IT-Systemen führt dazu, dass klassische Unterstützungsleistungen wie Entwicklungsleistungen, IT-Consulting oder Wartung als Auslagerungstätigkeiten verstanden werden, da auch andere Risiken vertraglich geregelt und inhaltlich gesteuert werden müssen. Der Einkauf spezialisierten, qualitativ hochwertigen IT-Know-hows würde durch die neue Anforderung de facto verteuert und erschwert, was der gewünschten Konzentration auf Kernkompetenzen bei den Banken leider entgegenwirkt und außer Acht lässt, dass aufgrund einer Vielzahl an rechtlichen und marktgetriebenen Vorgaben eine spezialisierte, hoch entwickelte IT-Branche für die kostengünstige, effiziente und schnelle Massendatenverarbeitung zwingend erforderlich ist. Es kann aber nicht das Ziel sein, das Rad zurückzudrehen und die IT-Lösungen wieder inzusourcen. Nicht zuletzt ist zu berücksichtigen, dass die strengen Vorgaben der MaRisk für eine Vielzahl von kleineren Softwareanbietern, die auf bestimmte Randfunktionalitäten spezialisiert sind, aus Personal- und letztlich Kostengründen nicht umsetzbar sind. Dies engt die Banken bei der Auswahl fachlich geeigneter Dienstleister in diesem Bereich zusätzlich ein. Gleichzeitig wird indirekt in bestehende Marktstrukturen eingegriffen und letztlich ein Verdrängungswettbewerb gefördert. In den Banken wird Standardsoftware regelmäßig für einen bestimmten Zeitraum inkl. der Standard-Updates gekauft. Häufig erfolgt zusätzlich ein Customizing nach den Vorgaben der nutzungsberechtigten Bank, wobei die Vorgaben von der Bank selbst kommen, dessen Mitarbeiter regelmäßig projekthaft in die Umsetzungstätigkeiten des Softwareanbieters eingebunden sind, die Tests (mit-)durchgeführt werden und auch die Freigabe zur Produktion erteilt wird. Unter Risikogesichtspunkten sind diese individuellen Leistungen des Softwareanbieters über den gesamten Prozess in der Hand der jeweiligen Auftrag gebenden Banken. Aktivitäten und Prozesse werden also keinesfalls ausgelagert, vielmehr wird ein klar definierter, einmaliger Auftrag an den Softwareanbieter erteilt, der zudem institutsseitig noch eng begleitet wird. Zudem werden bei der Mehrzahl der Banken Programmeinsatzverfahren angewandt, die die mit der Software einhergehenden Risiken einer Beurteilung unterziehen. Eine solch erhebliche Ausweitung der Dienstleistersteuerung steht in keinem Verhältnis zu dem damit verbundenen Risiko. Mir sind bis dato keine besonderen Schadensfälle in dieser Hinsicht bekannt. Spezialisierte IT-Anbieter werden kaum den Source-Code, der Grundlage ihrer Geschäftstätigkeit ist, offenlegen.
V. Robotic Process Automation (RPA)
Bankenvorstände sind heutzutage nicht zu beneiden. Sie müssen immer mehr Prozesseffizienz schaffen, haben es aber mit wachsenden IT-Landschaften zu tun. Um in so einem Umfeld Prozesse zu vereinfachen, sind komplexe IT-Transformationsvorhaben wie die Modernisierung der Kernsysteme oder eine Implementierung von BPM-Systemen nötig. Will man ohne diese Projekte mehr Effizienz rausholen, bleibt oft nur noch das Outsourcing. Und doch sind Transformations- und BPM-Vorhaben oft schwierig: lange Umsetzungszyklen und ein hoher Integrationsaufwand. Oft sind diese Projekte komplex und risikoreich und amortisieren sich erst sehr spät. Outsourcing auf der anderen Seite büßt nach und nach an Effizienzeffekten ein. Dort wo es bereits seit langem im Einsatz ist, hat das Potenzial bereits ein Maximum erreicht. Auch das Lohnkostenargument wird zunehmend obsolet, wenn Löhne steigen. In diese Lücke springt nun die Robotic Process Automation (RPA), also die Automatisierung via Software-Roboter. Die Hersteller versprechen Einsparungen von bis zu 60 Prozent und eine schnelle und risikoarme Implementierung. Die wird vor allem dadurch möglich, dass kein Integrationsaufwand auf Seiten der bestehenden Systemlandschaft anfällt. Warum? Weil Robotics Automation außerhalb der bestehenden Systeme sitzt. Die Schnittstelle ist das User Interface. Die Konfiguration erfolgt durch „vormachen“ am System. Das kann durch den Fachexperten erfolgen und bindet dadurch kaum Ressourcen auf Seiten der IT – „Code free“ sozusagen. Einmal konfiguriert, werden Prozesse hochskalierbar. Hunderte Roboter können gleichzeitig das tun, was sonst einzelne Mitarbeiter seriell abarbeiten müssen. Glücklicherweise sind diese Roboter keine physisch existenten maschinellen Gestalten mit Armen, Beinen oder Rädern so wie wir sie aus der Fertigungsindustrie kennen – wo sollten wir so viele von ihnen auch unterbringen? RPA-Roboter sind reine Software und brauchen keine Schreibtische. Aber sie könnten einen ähnlichen Einfluss auf die Arbeitswelt im Backoffice haben wie ihre physischen Vorgänger auf die Fertigung. Automatisierung von Geschäftsprozessen ist nichts Neues. Unternehmen haben immer nach Möglichkeiten gesucht, um die Effizienz zu steigern und Wachstum zu fördern. Bisher haben Unternehmen dies oft über Investitionen in Enterprise-Systeme (ERP), Business Process Management-Lösungen oder in Shared Services/Outsourcing realisiert. Trotz starker Investitionen in diese Lösungen sind Prozesse immer noch nicht voll automatisiert und sehen häufig eher aus wie ein Flickenteppich. Das liegt oft daran, dass traditionelle Lösungen häufig sehr kostenintensiv sind, viele Ressourcen beanspruchen und zusätzlich nicht schnell auf veränderte Marktsituationen reagieren können.
In Systeme einloggen und diese bedienen bspw. ERP- und Kundenmanagementsysteme
E-Mails öffnen und Anhänge verarbeiten
Robotic Process Automation kann auch als virtueller Mitarbeiter betrachtet werden. RPA greift dazu auf Ihre bestehenden Applikationen zu und führt so strukturierte Prozesse automatisch aus. Es müssen keine Veränderungen an bestehenden Systemen durchgeführt werden, da RPA darauf genauso zugreift wie Ihre Mitarbeiter. Somit kann RPA eine Vielzahl von Prozessen automatisieren wie beispielsweise Rechnungsbearbeitung, Report-Erstellung oder Mitarbeiter-Onboarding. Durch Robotic Process Automation werden Geschäftsprozesse schnell, fehlerfrei und automatisch erledigt. Bei dieser Art von Prozessautomatisierung setzt ein Software-Roboter Aufgaben in einem System oder einer Anwendung in der gleichen Weise um, wie es ein Mensch tun würde. Der Roboter wird zum virtuellen Angestellten, der manuelle und sich ständig wiederholende Teilprozesse oder Aufgaben ausführt, die ein hohes Maß an Genauigkeit erfordern. Die Vorteile der Prozessautomatisierung via Roboter bestehen darin, dass Mitarbeiter von ermüdenden und immer wiederkehrenden Routinetätigkeiten entlastet werden, die Roboter wesentlich schneller erledigen können. Automatisierung durch Softwareroboter entdecken viele Banken aktuell für sich. Neun von zehn Instituten in Deutschland planen laut einer Studie, bis 2019 so viele Abläufe wie möglich zu standardisieren, sodass diese von Algorithmen übernommen werden können. Der Softwareroboter bildet dabei die Aktivitäten eines Menschen an Bildschirm und Tastatur nach. Möglichkeiten für den Einsatz sind etwa Tätigkeiten nach der Kontoeröffnung oder die Bearbeitung von Fehlerlisten.
VI. IT-Risikomanagement
Das KWG verlangt von der Bank eine ordnungsgemäße Geschäftsorganisation. Die ordnungsgemäße Geschäftsorganisation einer Bank muss insbesondere ein angemessenes und wirksames Risikomanagement umfassen, auf dessen Basis die Bank die Risikotragfähigkeit laufend sicherzustellen hat. Eine Auslagerung darf weder die Ordnungsmäßigkeit dieser Geschäfte und Dienstleistungen noch die Geschäftsorganisation im Sinne des § 25a Abs. 1 KWG beeinträchtigen. Insbesondere muss ein angemessenes und wirksames Risikomanagement durch das Institut gewährleistet bleiben, welches die ausgelagerten Aktivitäten und Prozesse einbezieht. Zuerst stellt sich die Frage, was eigentlich unter dem Begriff Risiko zu verstehen ist. An dieser Stelle soll deshalb der Risikobegriff erläutert werden und ein Überblick über die Risiken des IT-Outsourcings gegeben werden. Das Wort Risiko hat seinen Ursprung im frühitalienischen Wort „risicare“, das übersetzt „etwas wagen“ bedeutet. Obwohl sich zahlreiche Veröffentlichungen mit der Risikoproblematik wirtschaftlichen Handelns beschäftigen, gibt es trotz der Fülle keine einheitlich allgemeingültige Definition des Risikobegriffs. Bevor nun auf die Methoden des Risikomanagements eingegangen wird, soll zunächst geklärt werden, was unter dem Begriff des „Risikomanagements“ zu verstehen ist. Ähnlich wie beim Risikobegriff, gibt es in der Literatur auch zum Begriff des "Risikomanagements" eine Vielzahl an Definitionen. Prinzipiell ist Risikomanagement eine systematische Vorgehensweise im Umgang mit Risiken. Für ein besseres Verständnis helfen allgemeine Definitionen. In einer allgemeineren Definition werden unter Risiko- Management "alle erforderlichen Aufgaben und Maßnahmen zur Risikobekämpfung“ verstanden. Aufgabe des Risikomanagements ist es also, die wesentlichen Risiken, die den Unternehmenserfolg oder -bestand gefährden, frühzeitig zu erkennen und Gegenmaßnahmen zu treffen. Risiken können dabei in sehr zahlreichen Erscheinungsformen auftreten. Das IT-Risikomanagement ist ein Teil des Information Security Management Systems (ISMS) und befasst sich mit der Analyse und Bewertung von Risiken. Dieses Vorgehen generiert einen Mehrwert für das Unternehmen und seine Kunden, indem es die Umsetzung von Schutzmaßnahmen abhängig von der Höhe des Risikos macht. Dadurch wird es leichter, ein angemessenes Sicherheitsniveau zu finden, zu erreichen und zu halten. Dieses Vorgehen ist wirtschaftlich sinnvoller als starre Vorgaben in Form von komplett umzusetzenden Maßnahmenkatalogen. Im Rahmen des IT-Risikomanagements werden nur Risiken betrachtet, die die vier Schutzziele der IT (Verfügbarkeit, Integrität, Vertraulichkeit und Authentizität) bedrohen. Risikomanagement hat zum Ziel, fatale, sprich existenzgefährdende, Schäden für das Unternehmen möglichst zu verhindern. Die Steuerung von IT-Risiken muss in Übereinstimmung mit der Unternehmensstrategie erfolgen. Dazu müssen bestehende Risiken für die Unternehmensführung transparent sein. Mit den MaRisk werden die Anforderungen aus § 25a KWG weiter konkretisiert. Ziele der MaRisk (AT 2) sind u.a. der Schutz der anvertrauten Vermögenswerte, die häufig als Daten in IT-Systemen technisch repräsentiert werden, und die ordnungsgemäße Durchführung der Bankgeschäfte oder Finanzdienstleistungen. Die Risikoidentifikation als Teil des Gesamtrisikoprofils der Bank auf der einen und die Festlegung des bestehenden Risikodeckungspotenzials (AT 4.1) der Bank auf der anderen Seite ist der erste wesentliche Schritt bei allen Risikomanagement-Prozessen der IT-Risiken. Sie ist dabei einer der schwierigsten Teile des Risikomanagement-Prozesses, da alle weiteren Maßnahmen auf ihr beruhen. Schließlich können nur die Risiken bewertet und gesteuert werden, die im Vorfeld erkannt wurden. Es gilt die Regel, dass ein Risiko, das nicht im Vorfeld erkannt werden konnte, beim Eintreten auch nicht mit entsprechenden Maßnahmen in den Griff bekommen werden kann. Als Mindestanforderungskriterien an die Phase der Risikoidentifikation können dementsprechend Vollständigkeit, Aktualität und regelmäßige Überprüfungen genannt werden. Vollständigkeit bedeutet dabei eine vollständige Erfassung von Risiken eines Projekts. Unter Aktualität wird eine zeitnahe Erfassung von Risiken verstanden. Da sich Risiken durch z.B. veränderte Rahmenbedingungen auch ändern können, muss, um die Kriterien der Vollständigkeit und Aktualität erfüllen zu können, das Kriterium der regelmäßigen Überprüfung herangezogen werden. Auf dieser Grundlage wird die Geschäftsstrategie definieret und daraus ableitbare Teilstrategien (AT 4.2), zu denen auch die IT-Strategie gemäß IDW RS FAIT 1 als Funktionalstrategie gehört. Die Auswirkungen der Risiken lassen sich mindern, jedoch nie gänzlich ausschließen. Aus meiner Sicht gibt es konkret folgende wesentliche Risiken:
Die Bank hat keinen Einfluss auf die Wirtschaftlichkeit und eine eventuelle Insolvenz des Dienstleisters.
Die Bank hat keinen Einfluss und keinen direkten Zugriff mehr auf die handelnden Mitarbeiter.
Der Service für die Mitarbeiter wird von 'Externen' erbracht.
Business-Know-how geht auf Dauer verloren. Die Abhängigkeit von den allgemeinen Dienstleistern wird mit den Jahren größer.
Der Dienstleister erbringt seine Leistungen nicht nur für die Bank. Mit der Zeit könnte die Bank nicht mehr an erster Priorität stehen.
Die nachfolgenden Maßnahmen könnten die Auswirkung der Risiken mindern:
Außerordentliches Kündigungsrecht der Bank mit der Möglichkeit, im Insolvenzfall Mitarbeiter ohne Zustimmung des Dienstleisters zu übernehmen.
Monatliche Kopie der Personalsysteme und der Daten wird dem IT-Bereich der Bank übergeben. Im Havariefall kann eine eigene Plattform erstellt werden.
Partnerschaftlicher und professioneller Umgang mit dem Dienstleister, ohne sich gegenseitig zu übervorteilen.
Schaffung von Stellen in der Bank zur Überwachung und Steuerung der Dienstleistung.
Optimierung der Prozesse beim Dienstleister, gemeinsame Einrichtung der Schnittstellen und Festlegen der Prozesse.
Unter Risikosteuerung versteht man die aktive Beeinflussung der im Rahmen der Risikoidentifikation und Risikobewertung ermittelten Risiken entsprechend ihrer Risikoposition. Voraussetzung für eine effektive Risikosteuerung ist eine regelmäßige Erfassung der Analyseergebnisse und eine sachgerechte Information der Entscheidungsträger. Die Maßnahmen, die für die Steuerung getroffen werden, haben dabei eine Verringerung der Eintrittswahrscheinlichkeit und/oder eine Begrenzung der Auswirkungen zum Ziel. Die Steuerungs- und
-controllingprozesse müssen gewährleisten, dass die wesentlichen IT-Risiken – auch aus ausgelagerten Aktivitäten und Prozessen (z.B. an die Rechenzentrale) – frühzeitig erkannt, vollständig erfasst und in angemessener Weise dargestellt werden können. Die Steuerungs- und
-controllingprozesse für IT-Risiken sind zeitnah an sich ändernde Bedingungen anzupassen. Es muss gewährleistet sein, dass wesentliche IT-Risiken zumindest jährlich identifiziert und beurteilt werden (BTR 4 Tz. 2). Bedeutende Schadensfälle (z.B. längerer Ausfall von IT-Systemen) sind unverzüglich hinsichtlich ihrer Ursachen zu analysieren (BTR 4 Tz. 3). Die Umsetzung der zu treffenden Maßnahmen ist zu überwachen (BTR 4 Tz. 5). Der Vorstand hat sich in angemessenen Abständen über die IT-Risikosituation berichten zu lassen. Die IT-Risikoberichterstattung ist in nachvollziehbarer, aussagefähiger Art und Weise zu verfassen. Sie hat neben einer Darstellung auch eine Beurteilung der Risikosituation zu enthalten. In die Berichterstattung sind bei Bedarf auch Handlungsvorschläge, z.B. zur Risikoreduzierung, aufzunehmen. Die IT-Risikoberichterstattung an den Vorstand kann – soweit dies aus Sicht des Vorstandes als sinnvoll erachtet wird – durch prägnante Darstellungen ergänzt werden (z.B. ein Management Summary). Soweit sich keine relevanten Änderungen ergeben haben, kann im Rahmen der aktuellen Berichterstattung auf diese Informationen verwiesen werden. Auch eine Diskussion der Handlungsvorschläge mit den jeweils verantwortlichen Bereichen ist grundsätzlich unproblematisch, solange sichergestellt ist, dass der Informationsgehalt der Berichterstattung beziehungsweise der Handlungsvorschläge nicht auf eine unsachgerechte Weise verzerrt wird. In den Risikoberichten sind insbesondere auch die Ergebnisse der Stresstests von IT-Risiken sowie ggf. die Ergebnisse der Notfalltests (AT 7.3 Tz. 1) und deren potenzielle Auswirkungen auf die Risikosituation und das Risikodeckungspotenzial darzustellen. Ebenfalls darzustellen sind die den Stresstests zugrunde liegenden wesentlichen Annahmen. Darüber hinaus ist auch auf Risikokonzentrationen und deren potenzielle Auswirkungen gesondert einzugehen. Der Vorstand ist mindestens jährlich über bedeutende IT-Schadensfälle und wesentliche IT-Risiken als Teil der operationellen Risiken zu unterrichten. Die Berichterstattung hat die Art des Schadens beziehungsweise IT-Risikos, die Ursachen, das Ausmaß des Schadens beziehungsweise IT-Risikos und gegebenenfalls bereits getroffene Gegenmaßnahmen zu umfassen (BTR 4 Tz. 4). Auf Basis der Berichterstattung ist zu entscheiden, ob und welche Maßnahmen zur Beseitigung der Ursachen zu treffen oder welche Risikosteuerungsmaßnahmen (z.B. Versicherungen, Ersatzverfahren, Neuausrichtung von Geschäftsaktivitäten, Katastrophenschutzmaßnahmen) zu ergreifen sind (BTR 4 Tz. 5). Unter Risikogesichtspunkten wesentliche Informationen sind unverzüglich an den Vorstand, die jeweiligen Verantwortlichen und gegebenenfalls die Interne Revision weiterzuleiten, sodass geeignete Maßnahmen beziehungsweise Prüfungshandlungen frühzeitig eingeleitet werden können. Hierfür ist ein geeignetes Verfahren festzulegen. IT-Risiken sollten in angemessener Weise bei der Berichterstattung des Vorstandes an den Aufsichtsrat berücksichtigt werden. Der Ausdruck „Stresstests für IT-Risiken“ wird im Folgenden als Oberbegriff für die unterschiedlichen Methoden gebraucht, mit denen die Bank ihr individuelles Gefährdungspotenzial auch bezüglich außergewöhnlicher, aber plausibel möglicher Ereignisse im Umfeld der IT-Risiken auf den jeweils relevanten Ebenen der Bank überprüfen. Sollte die Bank IT-Risiken als wesentliche Risiken festgelegt haben, sind regelmäßig angemessene Stresstests für die IT-Risiken durchzuführen, die Art, Umfang, Komplexität und den Risikogehalt der Geschäftsaktivitäten widerspiegeln. Ein wichtiger Faktor zur erfolgreichen Umsetzung des Risikomanagements ist deshalb eine gelebte Risikokultur. Sie bildet das Fundament der einzelnen Risikomaßnahmen, die im Rahmen des Risikomanagements getroffen werden. Eine Risikokultur beinhaltet die Bereitschaft zur Wahrnehmung von Risiken, die Sensibilisierung der Mitarbeiter und die Kommunikation der Risiken. Die Geschäftsleitung erfüllt also eine wichtige Vorbildfunktion. Nicht vergessen darf man natürlich die Compliance-Aspekte. Die Bestimmungen zur Jahresabschlussprüfung wurden z.B. in Deutschland durch das Gesetz über Kontrolle und Transparenz im Unternehmensbereich und für an US-Börsen notierte Gesellschaften im SOX verschärft. Darüber hinaus existieren viele weitere Vorschriften mit teilweise nur lokaler oder bankspezifischer Bedeutung (MaRisk) sowie weitere Regulierungen wie Basel II, Solvency II oder die EU-Richtlinie MiFID („Markets in Financial Instruments Directive“). Banken können sich nicht durch Auslagerung ihren Nachweispflichten entziehen. Das auslagernde Unternehmen muss sicherstellen, dass die Vorgehensweisen des Dienstleisters den Ansprüchen des Gesetzgebers und der Regulatoren entsprechen.
Nach der MaRisk AT 9 hat eine regelmäßige Auswertung von Informationen und Berichten im Rahmen des internen Kontrollsystems für ausgelagerte Aktivitäten und Prozesse zu erfolgen. Hierbei sind grundsätzlich folgende Fragestellungen zu beachten:
Wer ist bankintern für die Überwachung und Steuerung der Auslagerungsdienstleitung verantwortlich?
Handelt es sich um einen Bericht über die Durchführung von Tätigkeiten der Internen Revision beim Auslagerungsunternehmen?
Erfolgt die Berichterstattung außerhalb eines regelmäßigen Turnus?
Ergeben sich Lücken bei den geprüften Zeiträumen?
Wurden wesentliche, schwerwiegende oder besonders schwerwiegende Mängel festgestellt?
Handelt es sich um Mängel, die bereits in vorangegangenen Berichten festgestellt wurden?
Sind Maßnahmen beim Insourcer erforderlich?
Müssen von der Bank Maßnahmen ergriffen werden?
In der Praxis ergibt sich in vielen Banken ein kompliziertes Geflecht aus Auslagerungen, die eine zentrale Instanz notwendig machen, um den Überblick über die Steuerung von Auslagerungen zu behalten. Denn häufig haben es die Institute nicht mit einfachen 1:1-Beziehungen zu nur einem Dienstleister zu tun, sondern mit 1:n-Beziehungen, falls beauftragte Dienstleister ihrerseits Auslagerungen vornehmen. Vor allem bei kleineren Instituten ist es beispielsweise verbreitet, den Zahlungsverkehr an einen gemeinsamen Dienstleister auszulagern. Angesichts des beschränkten Geschäftsauftrags lagert dieser dann häufig die Interne Revision zumindest teilweise aus. Das entlastet jedoch die erstauslagernden Institute nicht von der Verantwortung, für einen ordnungsgemäßen Informationsfluss zu sorgen. Dies ist in den Bedingungen für Weiterauslagerungen festzuhalten und durch das erstauslagernde Institut nachzuhalten.
VII. Konsistenz von Sicherheitsmanagement und Notfallplanung
Durch den IT-Outsourcing-Vertrag wird mittels der SLA festgelegt, welche Dienstleistungen vom Service Anbieter in welchem Umfang erbracht werden müssen. Dabei ist die Verantwortlichkeitsverteilung klar geregelt und die Konsequenzen bei Nicht-Erfüllung sind entsprechend definiert. Bei der IT-Sicherheit hingegen sind die Verantwortlichkeiten nicht mittels der SLA geregelt. Damit gewährleistet werden kann, dass mit Anwendungen oder Kundendaten auch beim Service Anbieter sicher umgegangen wird, wird zwischen den Outsourcing-Parteien ein sogenanntes IT-Sicherheitskonzept erstellt. In diesem Sicherheitskonzept sind die verschiedenen Verantwortlichkeiten und die relevanten Themen geregelt. Die zentrale Frage bei der Erstellung eines IT-Sicherheitskonzeptes lautet: Welchen Schutz benötigen welche IT-Systeme? Es ist zu beachten, was genau geschützt werden muss und wogegen die Systeme geschützt werden müssen. Wurde eine entsprechende Risikoanalyse vorgenommen, so muss man sich mit der Frage auseinandersetzen, wie ein wirksamer Schutz erreicht werden kann und ob der Nutzen des Schutzes einen potentiellen Schaden übersteigt. Damit sind die Kernbestandteile eines IT-Sicherheitskonzeptes umriussen. Der Service Anbieter schließt mit jedem einzelnen Kunden ein separates Konzept ab. Ein IT-Sicherheitskonzept ist wesentlicher Bestandteil zwischen Service Anbieter und Outsourcingnehmer, die Themen des Sicherheitskonzeptes sind nicht verhandelbar. Dies gilt auch für Kunden, die z.B. einem „geteilten Service“ angehören. Das sind Kunden, die sich beim Service Anbieter im gleichen Netzwerk oder Rechenzentrum wie andere Kunden befinden. Die Erstellung des IT-Sicherheitskonzeptes ist im Idealfall eine Zusammenarbeit zwischen dem Outsourcingnehmer und dem Service Anbieter. Diese Vorgehensweise wird in der Praxis auch so gehandhabt. Bei nicht wesentlichen Geschäftsprozessen ist eine gemeinsame Erarbeitung des Sicherheitskonzepts nicht zwingend. Die IT-Sicherheits-Verantwortlichen der Bank haben zu beachten, dass die eigenen internen Sicherheitsrichtlinien in das Sicherheitskonzept integriert werden. Die Praxis hat gezeigt, dass die Service Anbieter Vorlagen der Sicherheitskonzepte besitzen, die an die jeweiligen Kunden angepasst werden. Diese Vorlagen sind mit den Richtlinien und Weisungen des Service Anbieters bezüglich der IT-Sicherheit versehen. Die Einbringung der Richtlinien des Outsourcingnehmers gehört zu den Pflichten des IT-Sicherheit-Verantwortlichen des Outsourcingnehmers. Das Informationssicherheitskonzept ist in jedem IT-Projekt sowie in Projekten mit IT-Anteil zu erstellen. Das projektbezogene Informationssicherheitskonzept enthält alle an das zu entwickelnde System verbindlich gestellten Informationssicherheitsanforderungen und die Informationssicherheitsmaßnahmen zum Schutz der Informationen vor Verlust der Integrität, Verbindlichkeit, Vertraulichkeit und Verfügbarkeit sowie die Informationssicherheitsanforderungen und Informationssicherheitsmaßnahmen zum Schutz der technischen Anlagen zur Informationsverarbeitung und Informationsübermittlung. Im Rahmen der Erstellung und Fortschreibung des Informationssicherheitskonzepts sind seine Inhalte auf Korrektheit, Konsistenz und Vollständigkeit zu überprüfen und ggf. anzupassen.
Identifizieren Sie die Software in ihrer Bank, die zukünftig als Auslagerung gelten könnte
Gestaltet Sie die Prozesse durch eine zentrale Dienstleistersteuerung effizient
Auswertung der Berichterstattung ist zentraler Baustein der Dienstleistesteuerung
Führen Sie Stresstests zu IT-Risiken durch
Stimmen Sie Sicherheitsmanagement und Notfallplanung mit ihrem Dienstleister auch unterjährig ab
Beitragsnummer: 598