RegTech News! 12. RegTech-Beitrag "Informationssicherheit im Homeoffice" ist jetzt online

Liebe Leserinnen und Leser, 

RegTech ist im Dialog mit Finanzinstituten nicht mehr wegzudenken. Aber wofür steht der Begriff, was bedeutet er in der Praxis, welche Anwendungsfälle bestehen im Compliance-Umfeld, wie fügt sich RPA in den Themenkomplex ein?

All diese Fragen behandeln wir seit längerem in einer Reg-Tech Beitragsserie. Natürlich wollen wir Ihnen unseren Blog-Lesern diese Beiträge nicht vorenthalten!

Deshalb erhalten Sie ab sofort zu jedem neuen RegTech Beitrag News auf diesem Blog und heute geht es weiter mit dem 12. RegTech Beitrag:

Informationssicherheit im Homeoffice

War Homeoffice bis vor Jahresfrist eher ein Schlagwort aus dem Dunstkreis Work-Life-Balance, so hat die Corona-Pandemie das Arbeiten von zu Hause in den Fokus der öffentlichen Wahrnehmung gerückt. In kürzester Zeit entstanden in Unternehmen die notwendigen Infrastrukturen, um den Geschäftsbetrieb aus den Wohn-, Arbeits-, Esszimmern oder Küchen der Mitarbeiter fortzuführen. Cyberkriminelle nutzen die entstehenden Angriffsflächen aus, die Zahl der Attacken auf Unternehmensnetzwerke stieg stark an. Wie Banken bei Homeoffice-Lösungen auf der sicheren Seite bleiben zeigt unsere zweiteilige Beitragsserie!  Jetzt weiterlesen

Alle weiteren Informationen und Leistungen rund um das Thema RegTech erhalten Sie hier.

Viel Spaß beim Lesen
Ihre Sandra Reinhard


PS: Lesen Sie auch unsere anderen Beiträge zum Thema RegTech!

ESG – haben Sie den Schuss schon gehört?

Kürzlich fiel mir eine meiner ersten Bewerbungen aus dem Jahr 1986 in die Hand. Darin war zu lesen, dass „es in unserer Volkswirtschaft noch viele Probleme zu bewältigen gibt, bis wir im Stande sind, nicht nur ökonomisch vorteilhaft, sondern auch ökologisch sinnvoll zu produzieren …“. Weiter hieß es, dass es Ziel sein sollte, den Wohlstand zu heben und das Leben sicherer und lebenswerter zu machen. „Sieh mal einer an“, dachte ich mir. Der Kerl war damals noch keine 18 Lenze alt und stand schon dort, wo die EU jetzt hin will. Seinerzeit haben saurer Regen und Tschernobyl einen ersten tiefen Graben im Bewusstsein vieler Menschen hinterlassen und eine erste Ahnung, dass es wohl so nicht endlos weitergehen kann.

Nun, über drei Jahrzehnte später, haben wir einen „Green Deal“ der EU und diverse internationale und nationale Vorhaben und Regulierungsansätze, die offen darauf ausgerichtet sind, die Finanzströme in Richtung eines nachhaltigen Wirtschaftens zu leiten. ESG ist hier das Schlagwort, das immer mehr Raum in der öffentlichen Diskussion der Finanzbranche einnimmt und viele neue und alte Akteure auf den Plan ruft. Dahinter stecken die auch als Nachhaltigkeitsaspekte bezeichneten Themen von E für Environment, S für Social und G für Governance.

Diese Materie ist uns in der Finanzindustrie nicht unbekannt. Sie steht bereits seit einigen Jahren hauptsächlich im Fonds- und Anlageberatungsgeschäft auf der Agenda. Hier geht es im Wesentlichen darum, die sich zunehmend ändernden Präferenzen von Investoren in Bezug auf ökologische Nachhaltigkeit, soziale Mindestnormen und Aspekte der Unternehmensführung zu berücksichtigen. Ganz banale Beispiele sind Investitionen, die auf Waffengeschäfte, Kinderarbeit, Gen- oder Kerntechnik verzichten. Hierfür gibt es schon eine Menge Gütesiegel mit unterschiedlichen Schwerpunkten und unterschiedlicher Akzeptanz.

Ich selbst beschäftige mich mit den recht jungen Anforderungen an das eigene Risikomanagement der Institute. Hierbei geht es nicht allein um die Interessen von Kunden und anderen Stakeholdern, sondern vielmehr um das Eruieren der möglichen und konkreten Auswirkungen von Veränderungen in Umwelt, Gesellschaft und Politik auf die eigenen Risikopositionen. Während die meisten Menschen häufig den „moralischen“ ESG-Score kennen, der hauptsächlich auf Kaufentscheidungen von Investoren abzielt und seine größte Wirkung in der Reputation von Unternehmen entfaltet, geht es zukünftig im Risikomanagement eher darum, diejenigen Treiber zu identifizieren, die die wesentlichen Risiken in den Banken beeinflussen. Aus diesen Kerntreibern wird dann der ESG-Impact-Score gebildet. Er beeinflusst Kreditentscheidungen und fließt in neue Szenarioberechnungen ein.

Das alles ist bei weitem nicht so trivial wie es den Anschein hat. Zudem drängt die Zeit: Die Umsetzung der neuen Datenanforderungen und auch die Implementierung neuer Methoden dauern einfach. Daneben schmerzt mich sehr, dass bei vielen Beteiligten das grundlegende Verständnis für den Umfang des Wandels zu fehlen scheint. Es sind nämlich die gesamte Organisation und sämtliche operativen Prozesse betroffen, angefangen vom Aufsichtsorgan über sämtliche operative Einheiten bis hin zum Hausmeister. Viele Marktteilnehmer scheinen aber den Startschuss immer noch nicht gehört zu haben – schlimmer noch: Sie bewegen sich nicht einmal in Richtung Startblock!

Auch wenn die Branche gerade dabei ist, den zweiten Schritt hin zu mehr Nachhaltigkeitsbewusstsein zu wagen, so ist der Weg zum Ziel noch weit. 

Etwas Orientierung auf dem Pfad liefern hier unsere aktuellen Whitepaper: www.ppi.de/banken/regulatorische-anforderungen/qualitative-bankenaufsicht/whitepaper-esg-risiken/

Thomas Maul
 

Teil 4: Agile Transformation in Banken - Warum regulatorisch agil nicht agile Regulatorik bedeutet

Die Bankenwelt unterliegt einer strengen Regulatorik, was an sich genommen ja erst einmal nicht schlecht ist: Diese verbessert die Marktintegrität, stärkt Anlegervertrauen und formuliert klare Anforderungen an das Risikomanagement der Institute. Die bankaufsichtlichen Anforderungen an die IT (BAIT) sind dabei Verwaltungsanweisungen für die sichere Ausgestaltung der IT-Systeme sowie der zugehörigen Prozesse und diesbezüglicher Anforderungen an die IT-Governance. Zugegeben: Das war jetzt direkt zu Beginn eine Menge Juristerei. Wer aber schon mal versucht hat, einen großen Einkauf zu tätigen und weder EC-Karte noch Geldautomat funktionierten, weiß, dass diese Regelungen durchaus Sinn machen.

Das Papier wurde elektrifiziert, die Regulatorik blieb

Die Zeiten, in denen Kundenaufträge auf einem Papierformular notiert und per Kurier an die bearbeitende Einheit gesendet wurden, sind, bis auf ganz wenige Ausnahmen, vorbei. Kreditinstitute bilden vernünftigerweise ihre bankfachlichen Prozesse mit IT-Systemen ab. Zugegebenermaßen ist aber nicht alles dadurch einfacher geworden: So reichte es früher aus, einen Antrag auf Formularänderung zu stellen und ein neues Formular mit neuer Versionsnummer drucken zu lassen. Heute müssen solche Änderungen an der IT-Landschaft akribisch dokumentiert werden. Ohne Fach- und IT-Konzept, Release Notes oder Testabnahmeprotokolle geht nichts mehr – und das ist auch gut so. Denn damit wird sichergestellt, dass die in Produktion befindliche Software auch nachvollziehbar dokumentiert ist und sie genau das tut, was sie tun soll.

Augen auf bei der Einführung agiler Frameworks, denn ohne Regulatorik keine Produktivstellung!
Die sogenannten „Betrieblichen Anweisungen“ regeln die Erstellung dieser Dokumentationen und sind somit auch Gegenstand von Prüfungen durch einen Revisor. Dumm nur, dass sie in der agilen Softwareentwicklung gar nicht mehr explizit vorkommen. Was passiert? Spätestens bei der Produktivstellung rennt man ohne die erforderliche Dokumentation schlicht gegen die Wand. Ist Agilität bei Finanzdienstleistern also unmöglich? Natürlich nicht, allerdings muss diese sehr eng mit der Revision abgestimmt werden. Die Lösung ist ein agiles Governance-Modell, das auch die Anforderungen aus Sicht des Regulators erfüllt. So weit, so gut. Aber was bedeutet das jetzt konkret für mich, wenn ich agil arbeiten möchte? Fallen die bestehenden Dokumentationen etwa einfach weg?

Entwickler und Dokumentation – zwei Welten treffen aufeinander

Das gängige Vorurteil lautet: Entwickler dokumentieren nicht gerne. Als der Punkt „Funktionierende Software mehr als umfassende Dokumentation“ im Agilen Manifest veröffentlicht wurde, löste dies einen Jubelsturm unter Entwicklern aus. Endlich mal voll auf die Programmierung fokussieren und nicht auch noch auf die lästige Erstellung von Konzepten oder so grausamen Dingen wie Sourcecode-Dokumentationen. Schließlich beweisen ja Compiler und die sehr umfangreichen funktionalen Tests, dass die Entwicklung allerhöchste Qualität hat. Dummerweise verzweifelten genau jene Entwickler dann aber am Betrieb, auch Run-The-Bank genannt, aus, die eben solche Dinge vehement einforderten, bevor sie bereit waren, sie produktiv einzusetzen. Da diese nicht im Rahmen der agilen Softwareentwicklung erstellt wurden, weigerte sich der Betrieb in seiner Rolle als Quality Gate, die Software auch wirklich produktiv zu stellen. Dahinter stecken regulatorische Anforderungen, die sicherstellen sollen, dass Entwickler Software nicht in betrügerischer Absicht manipulieren, sodass sie selbst oder Außenstehende davon profitieren. Leider führt das oftmals dazu, dass in einem förmlichen Kontrollwahn viele nicht sinnvolle Dokumentationen eingefordert werden, die sich sehr stark am historischen Wasserfallmodell orientieren. 

Schon Immanuel Kant sagte: „Habe den Mut, dich deines eigenen Verstandes zu bedienen.“
Klar ist: Die bisherigen Ergebnisdokumente scheinen wenig tauglich für die agile Vorgehensweise. Natürlich kommen jetzt ein paar Schlaumeier und fangen an, alte Ergebnistypen einfach auf neue abzubilden, um so die regulatorischen Anforderungen zu erfüllen. Wer aber schon mal versucht hat, alle User Stories als ein Fachkonzept zusammen zu bekommen, weiß, dass das nicht funktionieren kann. Spätestens beim DV-Konzept steht man dann mit leeren Händen da.
Da ist es doch durchaus sinnvoller, zu verstehen, warum diese Dokumente regulatorisch verpflichtend sind und wie sich diese regulatorische Anforderung auf die agile Welt projizieren lässt. Anders gesagt, es hilft mehr, die Ursache zu verstehen, als die Symptome zu reduzieren. Ich mache es mal an einem Beispiel klar: Bislang erstellte der Fachbereich ein Fachkonzept. Die IT prüfte dieses ausgiebig und nahm es schlussendlich ab. So wurde im Wasserfallmodell sichergestellt, dass die fachliche Anforderung von der IT verstanden wurde. Dieses ganze Procedere stammt aus einer Zeit, zu der ich noch gar nicht im Berufsleben stand, also schon fast prähistorisch. Klar, seinerzeit gab es noch die Bankmitarbeiter, für die IT ein Fremdwort war, und ITler, deren bankfachliches Verständnis sich auf das eigene Girokonto beschränkte. Dummerweise halten alle Beteiligten nach wie vor an dieser Umsetzung der regulatorischen Anforderung starr fest, anstatt zu überlegen, wie man diese sinnvoll auf die agile Welt anpasst.

Das regulatorische Gebot lautet nicht: „Du sollst ein Fachkonzept schreiben“

Wer in der agilen Welt noch Fachkonzepte und deren Freigabe durch die IT fordert, hat die eigentliche regulatorische Anforderung nicht verstanden oder kurz: hat den Schuss noch nicht gehört. In agilen Teams werden User Stories zur Umsetzung geschrieben. Diese werden nicht mehr explizit durch die IT freigegeben, sondern in Form des Backlog Groomings vom Product Owner dem Entwicklungsteam erläutert. Haben diese alles verstanden, werden User Stories auf „ready“ für die Umsetzung gesetzt. Hier gibt es also ein Quality Gate, welches das gemeinsame Verständnis von Fachseite (Product Owner) und IT-Seite (Entwicklungsteam) dokumentiert, analog einer Freigabe des Fachkonzeptes. Solange eine User Story nicht verständlich für das Entwicklungsteam ist, kann sie nicht in ein Sprint Backlog überführt und umgesetzt werden. 

Wer regulatorische Anforderungen effizient erfüllen möchte und nicht einfach nur historische Umsetzungen dieser Anforderungen blind übernehmen will, muss zwangsläufig das agile Governance-Modell anpassen. Die entsprechenden Kontrollmechanismen, etwa in Form von Quality Gates oder Seggregation of Duties, sind folglich so einzusetzen, dass sie die Regulatorik an diesem Prozessschritt bestmöglich unterstützen. Das bedeutet beispielsweise, dass im Agilen über die Definition of Done festgelegt ist, welche Dokumente zu erstellen sind, um eine Software produktiv zu setzen. Die eigentliche Produktivsetzung erfolgt dann aber durch gesondertes Personal. Das erfordert zunächst einmal, dass man sich ernsthafte Gedanken über die wahrhaftigen Anforderungen machen muss, anstelle Bestehendes blind zu übernehmen. Dies würde ich mir im Übrigen nicht nur von der Change-the-Bank-Organisation, sondern insbesondere auch von den Revisoren und Prüfern der Bank wünschen.

 Gib dem Prüfer Futter – Das betriebliche Anweisungswesen

Wie in meinem vorherigen Blog-Artikel schon erwähnt, erfordert agiles Arbeiten die „Agilifizierung“ der IT-Prozesse. Damit ändern sich aber die Prozesse und diese Änderungen müssen auch über betriebliche Anweisungen abgesichert sein. Ansonsten führt jede §44-Prüfung zu fatalen Ergebnissen. Denn: Prüfer beurteilen nicht die Sinnhaftigkeit eines Prozesses, sondern die Einhaltung dessen Vorgaben aus den Arbeits- und Verfahrensanweisungen. Selbstverständlich müssen neben den bankfachlichen auch die IT-Prozesse im Rahmen der Betrieblichen Anweisungen beschrieben werden. Somit erhalten die Prüfer eine saubere Grundlage für ihre Arbeit, die Mitarbeiter einen Rahmen zur agilen Vorgehensweise und zudem lassen sich Schnittstellen zu anderen Organisationseinheiten beschreiben. Besonders die Einhaltung regulatorischer Quality Gates und die Seggregation of Duty sind als Anforderung hier zu formulieren und deren Umsetzung zu beschreiben.



Mein Fazit zur Regulatorik: Agiles Vorgehen bedarf keiner Aufweichung der regulatorischen Anforderungen, es kann auch regulatorisch konform eingesetzt werden. Insbesondere die Definition of Ready und die Definition of Done stellen hier gute Quality Gates dar, deren Einhaltung über den Prozess einfach sicherzustellen und nachzuweisen ist. Ein agiles Governance-Modell liefert hierbei den Rahmen.

#agil #scrum #it-prozesse #it-dokumentation #agileprozesse #agilesgovernancemodell #it-governance #governancemodell #regulatorik #qualitygates #seggregationofduties

Andreas Milanese