Die Unternehmens-IT in Abhängigkeit von MaRisk und BAIT

1. „[…] Diese Verantwortung bezieht sich unter Berücksichtigung ausgelagerter Aktivitäten und Prozesse auf alle wesentlichen Elemente des Risikomanagements. Die Geschäftsleiter werden dieser Verantwortung nur gerecht, wenn sie die Risiken beurteilen können und die erforderlichen Maßnahmen zu ihrer Begrenzung treffen. Hierzu zählt auch die Entwicklung, Förderung und Integration einer angemessenen Risikokultur innerhalb des Instituts und der Gruppe. […]“

- Operationelle Risiken, die durch den Einsatz von IT entstehen, müssen im Risikomanagement betrachtet werden.
- Sofern ausgelagerte Aktivitäten oder Prozesse vorliegen, so müssen davon ausgehende Risiken ebenfalls betrachtet werden.

AT 4.2 Strategien

1. Besondere strategische Aspekte
„Aufgrund der Bedeutung für das Funktionieren der Prozesse im Institut hat das Institut in Abhängigkeit von Art, Umfang, Komplexität und Risikogehalt der Geschäftsaktivitäten auch Aussagen zur zukünftig geplanten Ausgestaltung der IT-Systeme zu treffen.“ (MaRisk, Anlage 1 Erläuterungen)

- Es muss eine schriftlich fixierte IT-Strategie vorliegen. Der Umfang und Detaillierungsgrad hängt dabei von der Größe der IT-Organisation ab.
- Die IT-Strategie beschreibt neben dem Ist-Zustand die Vision, Mission, Ziele und die Wege dorthin.

AT 4.3 Internes Kontrollsystem

AT 4.3.1 Aufbau- und Ablauforganisation
1. „Bei der Ausgestaltung der Aufbau- und Ablauforganisation ist sicherzustellen, dass miteinander unvereinbare Tätigkeiten durch unterschiedliche Mitarbeiter durchgeführt und auch bei Arbeitsplatzwechseln Interessenkonflikte vermieden werden. […]“

- Die Aufbau- und Ablauforganisation muss gemäß MaRisk gestaltet werden.
- User IDs und die dazu gehörigen Rechte in den betroffenen IT-Systemen müssen gemäß der Aufbau- und Ablauforganisation vergeben werden.
- Plausibilitätsprüfungen bei der Rechtevergabe können fehlerhafte Rechtevergaben erkennen bzw. erschweren.

2. „[…] Berechtigungen und Kompetenzen sind nach dem Sparsamkeitsgrundsatz (Need-to-know-Prinzip) zu vergeben und bei Bedarf zeitnah anzupassen. Dies beinhaltet auch die regelmäßige und anlassbezogene Überprüfung von IT-Berechtigungen, Zeichnungsberechtigungen und sonstigen eingeräumten Kompetenzen innerhalb angemessener Fristen. Die Fristen orientieren sich dabei an der Bedeutung der Prozesse und, bei IT-Berechtigungen, dem Schutzbedarf verarbeiteter Informationen. Das gilt auch bezüglich der Schnittstellen zu wesentlichen Auslagerungen.“

- Das Rechte-Konzept muss eine ausreichend feine Untergliederung der Rechte aufweisen.
- Nur wenn ein Recht für die Arbeit eines Users zwingend erforderlich ist, wird es an diesen User vergeben (principle of least privilege - POLP).
- Rechte dürfen grundsätzlich immer nur für einen begrenzten und möglichst kurzen Zeitraum vergeben werden.
-Bei Änderungen an der Rolle / den Rollen eines Users müssen die Rollen und Rechte zeitnah angepasst werden.
- Die vergebenen Rollen und Rechte werden regelmäßig überprüft. Nicht mehr benötigte Rollen oder Rechte werden entfernt. Die Fristen für die Überprüfung orientiert sich am Schutzbedarf der Informationen.

„Zeichnungsberechtigungen in Verbindung mit Zahlungsverkehrskonten und wesentliche IT-Berechtigungen sind mindestens jährlich zu überprüfen, alle anderen mindestens alle drei Jahre. Besonders kritische IT-Berechtigungen, wie sie beispielsweise Administratoren aufweisen, sind mindestens halbjährlich zu überprüfen.“ (MaRisk, Anlage 1 Erläuterungen)

AT 4.3.4 Datenmanagement, Datenqualität und Aggregation von Risikodaten
2. „Datenstruktur und Datenhierarchie müssen gewährleisten, dass Daten zweifelsfrei identifiziert, zusammengeführt und ausgewertet werden können sowie zeitnah zur Verfügung stehen. Hierfür sind, soweit möglich, einheitliche Namenskonventionen und Kennzeichnungen von Daten festzulegen und innerhalb des Instituts zu kommunizieren. Bei unterschiedlichen Namenskonventionen und Kennzeichnungen hat das Institut sicherzustellen, dass Daten automatisiert ineinander überleitbar sind.“

- Es ist sinnvoll, ein Verzeichnis aller Daten oder ein Data Warehouse bereitzustellen und für die Mitarbeiter des Instituts zugänglich zu machen.
- Für die Daten bietet sich eine Strukturierung in die Kategorien Anwendungslandschaft, Geschäftsvorfall, fachlicher Kernprozess, fachlicher Prozess und Anwendung an, z.B. Dezentrale Systeme / Vertrieb / Vertrieb Wertpapiere / Beratung / Portfolio-Optimierung.
- Die Daten selbst müssen aussagefähige Bezeichnungen tragen.
- Reports oder automatisierte Datenextraktoren und -aggregatoren ermöglichen eine automatisierte Bearbeitung und eine kurzfristige Bereitstellung der Daten.

3. „Das Institut hat zu gewährleisten, dass Risikodaten genau und vollständig sind. Daten müssen nach unterschiedlichen Kategorien auswertbar sein und sollten, soweit möglich und sinnvoll, automatisiert aggregiert werden können. Der Einsatz und der Umfang manueller Prozesse und Eingriffe sind zu begründen und zu dokumentieren und auf das notwendige Maß zu beschränken. Die Datenqualität und die Datenvollständigkeit sind anhand geeigneter Kriterien zu überwachen. Hierfür hat das Institut interne Anforderungen an die Genauigkeit und Vollständigkeit der Daten zu formulieren“

6. „Die Datenaggregationskapazitäten müssen hinreichend flexibel sein, um Informationen ad hoc nach unterschiedlichen Kategorien ausweisen und analysieren zu können. Dazu gehört auch die Möglichkeit, Risikopositionen auf den unterschiedlichsten Ebenen (Geschäftsfelder, Portfolios, ggf. Einzelgeschäfte) auszuweisen und zu analysieren.“

3. „Das Institut hat zu gewährleisten, dass Risikodaten genau und vollständig sind. Daten müssen nach unterschiedlichen Kategorien auswertbar sein und sollten, soweit möglich und sinnvoll, automatisiert aggregiert werden können. Der Einsatz und der Umfang manueller Prozesse und Eingriffe sind zu begründen und zu dokumentieren und auf das notwendige Maß zu beschränken. Die Datenqualität und die Datenvollständigkeit sind anhand geeigneter Kriterien zu überwachen. Hierfür hat das Institut interne Anforderungen an die Genauigkeit und Vollständigkeit der Daten zu formulieren“

6. „Die Datenaggregationskapazitäten müssen hinreichend flexibel sein, um Informationen ad hoc nach unterschiedlichen Kategorien ausweisen und analysieren zu können. Dazu gehört auch die Möglichkeit, Risikopositionen auf den unterschiedlichsten Ebenen (Geschäftsfelder, Portfolios, ggf. Einzelgeschäfte) auszuweisen und zu analysieren.“

7. „Für alle Prozessschritte sind Verantwortlichkeiten festzulegen und entsprechende prozessabhängige Kontrollen einzurichten. […]“

- In der Organisationsstruktur müssen die Verantwortlichen definiert und die dazu gehörenden User IDs mit entsprechenden Rechten versehen werden.
„Die mit der Überprüfung betrauten Mitarbeiter sollten möglichst über hinreichende Kenntnisse bezüglich der IT-Systeme und des Berichtswesens verfügen.“ (MaRisk, Anlage 1 Erläuterungen)

1. „Das Institut hat sicherzustellen, dass die Geschäftsaktivitäten auf der Grundlage von Organisationsrichtlinien betrieben werden (z. B. Handbücher, Arbeitsanweisungen oder Arbeitsablaufbeschreibungen). Der Detaillierungsgrad der Organisationsrichtlinien hängt von Art, Umfang, Komplexität und Risikogehalt der Geschäftsaktivitäten ab.“

- Organisationsrichtlinien werden sinnvollerweise in die Aufbau- und die Ablauforganisation unterschieden und elektronisch bereitgestellt.
- Hier bietet sich zur Ablage das Intranet an. Das Intranet sollte rechtemäßig zwischen internen und externen Mitarbeiter unterscheiden.

1. „Geschäfts-, Kontroll- und Überwachungsunterlagen sind systematisch und für sachkundige Dritte nachvollziehbar abzufassen und grundsätzlich fünf Jahre aufzubewahren. Die Aktualität und Vollständigkeit der Aktenführung ist sicherzustellen.“

- Für die sichere Aufbewahrung von Unterlagen sollte ein Versionsführungssystem / Configuration Management System verbunden mit einem Archivsystem verwendet werden.
- Die Aufbewahrungsdauer der verschiedenen Dokumenttypen kann in den Systemen gemäß den Erfordernissen eingestellt werden.

AT 7.2 Technisch-organisatorische Ausstattung

2. „Die IT-Systeme (Hardware- und Software-Komponenten) und die zugehörigen IT-Prozesse müssen die Integrität, die Verfügbarkeit, die Authentizität sowie die Vertraulichkeit der Daten sicherstellen. Für diese Zwecke ist bei der Ausgestaltung der IT-Systeme und der zugehörigen IT-Prozesse grundsätzlich auf gängige Standards abzustellen, insbesondere sind Prozesse für eine angemessene IT-Berechtigungsvergabe einzurichten, die sicherstellen, dass jeder Mitarbeiter nur über die Rechte verfügt, die er für seine Tätigkeit benötigt; die Zusammenfassung von Berechtigungen in einem Rollenmodell ist möglich. Die Eignung der IT-Systeme und der zugehörigen Prozesse ist regelmäßig von den fachlich und technisch zuständigen Mitarbeitern zu überprüfen.“

Standards zur Ausgestaltung der IT-Systeme
„Zu solchen Standards zählen z.B. der IT-Grundschutzkatalog des Bundesamtes für Sicherheit in der Informationstechnik (BSI) und der internationale Sicherheitsstandard ISO/IEC 2700X der International Organization for Standardization. Das Abstellen auf gängige Standards zielt nicht auf die Verwendung von Standardhardware beziehungsweise -software“ ab. Eigenentwicklungen sind grundsätzlich ebenso möglich.“ (MaRisk, Anlage 1 Erläuterungen)

IT-Berechtigungsvergabe
- Das Rechte-Konzept muss eine ausreichend feine Untergliederung der Rechte vorsehen.
- Nur wenn ein Recht für die Arbeit eines Users zwingend erforderlich ist, wird es an den User vergeben (principle of least privilege - POLP).
- Rechte sollten immer nur für einen begrenzten und möglichst kurzen Zeitraum vergeben werden.
- Bei Änderungen an der Rolle/den Rollen eines Users müssen die Rollen und Rechte zeitnah angepasst werden.
- Alle Änderungen an Rollen und an Rechten müssen protokolliert werden.
- Die vergebenen Rollen und Rechte werden regelmäßig überprüft. Nicht mehr benötigte Rollen oder Rechte werden entfernt.
- Sinnvoll ist die Bereitstellung einer IT-Sicherheitslösung, um einen Missbrauch entdecken zu können. Hier bietet sich die Verwendung eines SIEM- (Security Information and Event Management) Systems an.

„Die eingerichteten Berechtigungen dürfen nicht im Widerspruch zur organisatorischen Zuordnung von Mitarbeitern stehen. Insbesondere bei Berechtigungsvergaben im Rahmen von Rollenmodellen ist darauf zu achten, dass Funktionstrennungen beibehalten beziehungsweise Interessenkonflikte vermieden werden.“ (MaRisk, Anlage 1 Erläuterungen)

3. „Die IT-Systeme sind vor ihrem erstmaligen Einsatz und nach wesentlichen Veränderungen zu testen und von den fachlich sowie auch von den technisch zuständigen Mitarbeitern abzunehmen. Hierfür ist ein Regelprozess der Entwicklung, des Testens, der Freigabe und der Implementierung in die Produktionsprozesse zu etablieren. Produktions- und Testumgebung sind dabei grundsätzlich voneinander zu trennen.“

- Im Vorgehensmodell muss der Test- und der Freigabeprozess sowie ein Release- und Change Management definiert und dokumentiert sein.
- Bei Neuentwicklungen und bei Änderungen (z.B. Erweiterungen, Fehlerbehebungen, Umstellungen etc.) müssen ausreichend viele und qualitativ ausreichende Tests (bezogen auf die möglichen Auswirkungen) gemäß einem dedizierten Testkonzept durchgeführt werden.
- Die Testdurchführung und die Testergebnisse müssen dokumentiert werden. Dies wird durch die Nutzung eines Testtools erleichtert.
- Formale Abnahmen müssen durchgeführt und dokumentiert werden.
- Die Produktions- und die Testumgebung müssen getrennt sein. Sinnvoll ist es, eine gesonderte Entwicklungsumgebung vorzusehen.
- Es muss ein Konzept sowie ein technischer Prozess zur Überführung von Test in die Produktion vorhanden sein.

4. „Für IT-Risiken sind angemessene Überwachungs- und Steuerungsprozesse einzurichten, die insbesondere die Festlegung von IT-Risikokriterien, die Identifikation von IT-Risiken, die Festlegung des Schutzbedarfs, daraus abgeleitete Schutzmaßnahmen für den IT-Betrieb sowie die Festlegung entsprechender Maßnahmen zur Risikobehandlung und -minderung umfassen. Beim Bezug von Software sind die damit verbundenen Risiken angemessen zu bewerten.“

- Für IT-Risiken muss ein Risikomanagement auf Unternehmens-, auf Bereichs-, Abteilungs- und auf Projektebene bereitgestellt und durchgeführt werden.
- Für Teile des IT-Bebauungsplans und für relevante Anwendungen müssen Schutzbedarfsanalysen und System-Risikoanalysen durchgeführt werden.
- Bei der Beschaffung von Software müssen die dadurch entstehenden Risiken im Rahmen des Auswahlprozesses betrachtet werden.

5. „Die Anforderungen aus AT 7.2 sind auch beim Einsatz von durch die Fachbereiche selbst entwickelten Anwendungen (Individuelle Datenverarbeitung - IDV) entsprechend der Kritikalität der unterstützten Geschäftsprozesse und der Bedeutung der Anwendungen für diese Prozesse zu beachten. Die Festlegung von Maßnahmen zur Sicherstellung der Datensicherheit hat sich am Schutzbedarf der verarbeiteten Daten zu orientieren.“

- Die Unternehmens-IT hat die „selbstgestrickten“ Anwendungen der Fachbereiche oft nicht auf dem Radar. Hier gilt es, eine Bestandsaufnahme durchzuführen, eine Inventarliste anzulegen, Verantwortlichkeiten festzulegen und geeignete Maßnahmen durchzuführen.

AT 7.3 Notfallkonzept

1. „Für Notfälle in zeitkritischen Aktivitäten und Prozessen ist Vorsorge zu treffen (Notfallkonzept). Die im Notfallkonzept festgelegten Maßnahmen müssen dazu geeignet sein, das Ausmaß möglicher Schäden zu reduzieren. Die Wirksamkeit und Angemessenheit des Notfallkonzeptes ist regelmäßig durch Notfalltests zu überprüfen. Die Ergebnisse der Notfalltests sind den jeweiligen Verantwortlichen mitzuteilen. Im Fall der Auslagerung von zeitkritischen Aktivitäten und Prozessen haben das auslagernde Institut und das Auslagerungsunternehmen über aufeinander abgestimmte Notfallkonzepte zu verfügen.“

- Für Teile des IT-Bebauungsplans und für relevante Anwendungen müssen Notfallkonzepte erarbeitet und bereitgestellt werden.
- Oft ist es mit erheblichem Aufwand verbunden, einen Notfall herbeizuführen bzw. zu simulieren oder die Voraussetzungen für den Eintritt des Notfalls zu schaffen, ohne dass dabei Daten verändert oder verloren gehen. Oft entsteht ein (unverhältnismäßig) hoher Aufwand für die „Aufräumarbeiten“ nach einem Notfall.
- Es müssen regelmäßig Notfalltests durchgeführt und die Ergebnisse mitgeteilt werden.

2. „Das Notfallkonzept muss Geschäftsfortführungs- sowie Wiederanlaufpläne umfassen. Die Geschäftsfortführungspläne müssen gewährleisten, dass im Notfall zeitnah Ersatzlösungen zur Verfügung stehen. Die Wiederanlaufpläne müssen innerhalb eines angemessenen Zeitraums die Rückkehr zum Normalbetrieb ermöglichen. Die im Notfall zu verwendenden Kommunikationswege sind festzulegen. Das Notfallkonzept muss den beteiligten Mitarbeitern zur Verfügung stehen.“

- Für die beteiligten Mitarbeiter müssen Geschäftsfortführungs- sowie Wiederanlaufpläne bereitgestellt werden.
- Es muss ein Krisenstab definiert werden, der im Notfall einberufen wird und die Steuerung übernimmt. Dabei werden die vorher definierten Kommunikationswege benutzt. Die Kommunikation nach außen darf im Notfall nur durch Mitglieder des Krisenstabs erfolgen.

AT 8.1 Neu-Produkt-Prozess

1. „Jedes Institut muss die von ihm betriebenen Geschäftsaktivitäten verstehen. Für die Aufnahme von Geschäftsaktivitäten in neuen Produkten oder auf neuen Märkten (einschließlich neuer Vertriebswege) ist vorab ein Konzept auszuarbeiten. Grundlage des Konzeptes müssen das Ergebnis der Analyse des Risikogehalts dieser neuen Geschäftsaktivitäten sowie deren Auswirkungen auf das Gesamtrisikoprofil sein. In dem Konzept sind die sich daraus ergebenden wesentlichen Konsequenzen für das Management der Risiken darzustellen.“

Inhalt des Konzepts
Zu den darzustellenden Konsequenzen gehören solche bezüglich der Organisation, des Personals, der notwendigen Anpassungen der IT-Systeme, der Methoden zur Beurteilung damit verbundener Risiken sowie rechtliche Konsequenzen (Bilanz- und Steuerrecht etc.), soweit sie von wesentlicher Bedeutung sind.“ (MaRisk, Anlage 1 Erläuterungen)

- Die Anpassungen der IT-Systeme müssen detailliert beschrieben werden. Die geforderten Arten der Beschreibungen (z.B. als objektorientierte Klassen-Modellierung) in der Form von UML-Aktivitätendiagrammen oder als Mockups müssen im Vorgehensmodell definiert sein.

AT 8.3 Übernahmen und Fusionen

1. „Vor der Übernahme anderer Unternehmen oder Fusionen mit anderen Unternehmen hat das Institut ein Konzept zu erarbeiten, in dem die wesentlichen strategischen Ziele, die voraussichtlichen wesentlichen Konsequenzen für das Management der Risiken und die wesentlichen Auswirkungen auf das Gesamtrisikoprofil des Instituts beziehungsweise der Gruppe dargestellt werden. Dies umfasst auch die mittelfristig geplante Entwicklung der Vermögens-, Finanz- und Ertragslage, die voraussichtliche Höhe der Risikopositionen, die notwendigen Anpassungen der Risikosteuerungs- und -controllingprozesse und der IT-Systeme (inklusive der Datenaggregationskapazitäten) sowie die Darstellung wesentlicher rechtlicher Konsequenzen (Bilanzrecht, Steuerrecht etc.).“

- Im Übernahme- bzw. Fusionskonzept müssen auch die Änderungen an den IT-Systemen beschrieben werden. Dies können z.B. Änderungen an den Geschäftsprozessen, Datenflüssen, Verarbeitungsstufen, Rechten und IT-Kapazitäten sein.
- Ggf. ist es hilfreich, wenn Anwendungen mandantenfähig sind.

1. „Eine Auslagerung liegt vor, wenn ein anderes Unternehmen mit der Wahrnehmung solcher Aktivitäten und 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. […]“

„[…] für Software, die zur Identifizierung, Beurteilung, Steuerung, Überwachung und Kommunikation der Risiken eingesetzt wird oder die für die Durchführung von bankgeschäftlichen Aufgaben von wesentlicher Bedeutung ist; bei dieser Software sind Unterstützungsleistungen als Auslagerung einzustufen. Ferner gilt der Betrieb der Software durch einen externen Dritten als Auslagerung.“ (MaRisk, Anlage 1 Erläuterungen)

- Oft ist es nicht leicht zu entscheiden, ob eine Auslagerung vorliegt oder nicht. matrix technology hat eine Checkliste entwickelt, mit der anhand der Antworten auf spezifische Fragen leicht ermittelt werden kann, ob eine Auslagerung bzw. eine wesentliche Auslagerung vorliegt oder nicht.

- Bei der Vergabe von Aufgaben an einen Service Provider ist zu prüfen, ob eine (wesentliche) Auslagerung vorliegt.
- Ob eine Auslagerung wesentlich ist, entscheidet sich anhand der Gesichtspunkte Art, Risiko, Umfang und Komplexität der auszulagernden Teile.

6. „Das Institut hat bei wesentlichen Auslagerungen im Fall der beabsichtigten oder erwarteten Beendigung der Auslagerungsvereinbarung Vorkehrungen zu treffen, um die Kontinuität und Qualität der ausgelagerten Aktivitäten und Prozesse auch nach Beendigung zu gewährleisten. Für Fälle unbeabsichtigter oder unerwarteter Beendigung dieser Auslagerungen, die mit einer erheblichen Beeinträchtigung der Geschäftstätigkeit verbunden sein können, hat das Institut etwaige Handlungsoptionen auf ihre Durchführbarkeit zu prüfen und zu verabschieden. Dies beinhaltet auch, soweit sinnvoll und möglich, die Festlegung entsprechender Ausstiegsprozesse. Die Handlungsoptionen sind regelmäßig und anlassbezogen zu überprüfen.“

“Handlungsoptionen und Ausstiegsprozesse
Ausstiegsprozesse sind mit dem Ziel festzulegen, die notwendige Kontinuität und Qualität der ausgelagerten Aktivitäten und Prozesse aufrechtzuerhalten bzw. in angemessener Zeit wieder herstellen zu können. Bei gruppen- und verbundinternen Auslagerungen kann auf die Erstellung solcher Prozesse verzichtet werden.

Existieren keine Handlungsoptionen, ist zumindest eine angemessene Berücksichtigung in der Notfallplanung erforderlich.“ (MaRisk, Anlage 1 Erläuterungen)

- Für den Fall der unerwarteten Beendigung einer Auslagerungsvereinbarung muss ein „Plan B“ vorliegen, aus dem hervorgeht, wie der Betrieb inkl. der IT aufrechterhalten werden kann.
- Der „Plan B“ muss technische, fachliche und organisatorische Regelungen umfassen.
- Je umfangreicher und je komplexer die ausgelagerten Teile sind, desto schwieriger und größer fällt der „Plan B“ aus.
- Zur Umsetzung des „Plan B“ bieten sich Cloud-Techniken (z.B. „Lift & Shift“) an, die - bei entsprechender Vorbereitung - typischerweise einigermaßen kurzfristig umgesetzt werden können.

7. „Bei wesentlichen Auslagerungen ist im Auslagerungsvertrag insbesondere Folgendes zu vereinbaren:

a. Spezifizierung und ggf. Abgrenzung der vom Auslagerungsunternehmen zu erbringenden Leistung,

b. Festlegung angemessener Informations- und Prüfungsrechte der Internen Revision sowie externer Prüfer,

c. Sicherstellung der uneingeschränkten Informations- und Prüfungsrechte sowie der Kontrollmöglichkeiten der gemäß § 25b Absatz 3 KWG zuständigen Behörden bezüglich der ausgelagerten Aktivitäten und Prozesse,

d. soweit erforderlich Weisungsrechte,

e. Regelungen, die sicherstellen, dass datenschutzrechtliche Bestimmungen und sonstige Sicherheitsanforderungen beachtet werden,

f. Kündigungsrechte und angemessene Kündigungsfristen,

g. Regelungen über die Möglichkeit und über die Modalitäten einer Weiterverlagerung, die sicherstellen, dass das Institut die bankaufsichtsrechtlichen Anforderungen weiterhin einhält,

h. Verpflichtung des Auslagerungsunternehmens, das Institut über Entwicklungen zu informieren, die die ordnungsgemäße Erledigung der ausgelagerten Aktivitäten und Prozesse beeinträchtigen können.“

- Der Auslagerungsvertrag muss ausreichend detailliert geregelt werden. Insbesondere die Festlegung des Leistungsschnitts ist essenziell.
- Der Aufwand für die Erstellung und Abstimmung eines Auslagerungsvertrags ist hoch und darf nicht unterschätzt werden.
- Es sollte festgehalten werden, dass Auditierungen sowohl vom Kunden als auch von externen Prüfern durchgeführt werden können. Von Vorteil ist hier das Prüfergebnis zum International Standard on Assurance Engagements (ISAE 3402).
- Die Sicherheitsanforderungen müssen detailliert beschrieben werden.
- Auch beim Dienstleister muss ein Risikomanagement vorhanden sein und es muss eine enge Kopplung des Risikomanagements beider Unternehmen vorliegen.
- Beim Dienstleister muss ein Notfallmanagement vorhanden sein.

9. „Bei IT-gestützter Bearbeitung ist die Funktionstrennung durch entsprechende Verfahren und Schutzmaßnahmen sicherzustellen.“

- Die Funktionstrennung kann durch die Vergabe entsprechender User IDs - verbunden mit Rollen und Rechten - erreicht werden.
- Die Vergabe von Rechten sollte durch Plausibilitätsprüfungen begleitet werden.
- Die Vergabe von Rechten muss protokolliert werden.

BTO 2.2 Anforderungen an die Prozesse im Handelsgeschäft

BTO 2.2.1 Handel
6. „Bei Direkterfassung in den IT-Systemen muss sichergestellt sein, dass ein Händler nur unter seiner eigenen Händleridentifikation Handelsgeschäfte eingeben kann. Erfassungstag und -uhrzeit sowie fortlaufende Geschäftsnummern müssen automatisch vorgegeben werden und dürfen vom Händler nicht veränderbar sein.“

Die Handelsplattform muss dies gewährleisten.

4. „Auf Basis der Risikoberichterstattung gemäß BT 3.2 Tz. 6 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. Die Umsetzung der zu treffenden Maßnahmen ist zu überwachen.“

- Katastrophenschutzmaßnahmen sollten regelmäßig in „K-Fall“-Tests zur IT geprobt werden.
- Die Vorbereitung, Durchführung und Nachbereitung von K-Fall-Tests ist nicht trivial und kann einigen Aufwand bedeuten.
- K-Fall-Tests sollten erst dann anberaumt werden, wenn alle Beteiligten informiert wurden.