In diesem Beitrag werden die Änderungen der MaRisk durch die BaFin und Ihre Auswirkungen auf die IT dargestellt, sowie einmal die Ableitung von IT-Vorgaben aus den MaRisk grundsätzlich dargestellt.
Bei der Betrachtung gibt es drei Bereiche:
1.) Stärkere Zentralisierung beim Risikomanagement in Unternehmensgruppen bzw. Konzernen
2.) Konkrete Technische bzw. IT-Anforderungen in den MaRisk
3.) Vorgaben für die IT-seitige Notfallplanung
zu 1.) Stärkere Zentralisierung beim Risikomanagement in Unternehmensgruppen bzw. Konzernen
| AT 4.5 Risikomanagement auf Gruppenebene
1. Nach § 25a Abs. 1a KWG sind die Geschäftsleiter des übergeordneten Unternehmens einer Institutsgruppe oder Finanzholding-Gruppe sowie die Geschäftsleiter des übergeordneten Finanzkonglomeratsunternehmens eines Finanzkonglomerats für die Einrichtung eines angemessenen und wirksamen Risikomanagements auf Gruppenebene verantwortlich. Die Reichweite des Risikomanagements auf Gruppenebene erstreckt sich auf alle wesentlichen Risiken der Gruppe unabhängig davon, ob diese von konsolidierungspflichtigen Unternehmen begründet werden oder nicht (z. B. Risiken aus nicht konsolidierungspflichtigen Zweckgesellschaften)... |
Anmerkungen:
Dies bedeutet in der Interpretation für die Informatik von Unternehmensgruppen und insbesondere bei verteilten/dezentralisierten IT-Einheiten innerhalb der Gruppe
a.) Zentrale und vollständige IT-Risiko - Transparenz
Eine zentrale und vollständige Risikotransparenz muss auch über die IT der Konzerntochter bzw. -töchter vorliegen (Einbezug in den zentralen IT-Risikomanagement-Prozess (zentrale Risikoinventur/Maßnahmencontrolling etc.)
b.) Zentrale konzern-/unternehmensweite IT-Strategie und verbindliche Vorgaben
Die dezentrale IT-Einheit darf bzw. sollte nicht von zentralen IT-Standards und -Vorgaben ausgeklammert sein. Es sollte eine zentrale bzw. übergeordnete IT-Strategie geben, die auch die dezentralisierten Einheiten entsprechend mit einbezieht.
zu 2.) Konkrete Technische bzw. IT-Anforderungen in den MaRisk
| AT 7.2 Technisch-organisatorische Ausstattung
1. Umfang und Qualität der technisch-organisatorischen Ausstattung haben sich insbesondere an betriebsinternen Erfordernissen, den Geschäftsaktivitäten sowie der Risikosituation zu orientieren. |
Keine Änderung, Ableitung der zwingenden IT-Anforderungen:
- Es muss bekannt sein, wie kritisch bzw. risikoreich die durch die IT gestützten Geschäftsprozesse sind:- Identifizieren der kritischen Geschäftsprozesse
- Welche Services bzw. IT-Anwendungen/-Systeme und -Prozesse stützen die einzelnen kritischen Prozesse
- Hinterfragen, ob die Anwendungen und Systeme der Kritikalität der gestützten Geschäftsprozesse entsprechen
Auf die Details zu diesem Punkt wird in einem späteren Artikel "Prozess-/Business-Impact- und Schutzbedarfsanalyse genau eingegangen.
| 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. |
Keine Änderung, Ableitung der zwingenden IT-Anforderungen:
Aufbauend auf den zuvor erwähnten Schritt der Analyse, welche Services, Anwendungen und Infrastrukturkomponenten welche kritischen Geschäftsprozesse stützten, wird jetzt folgendes ermittelt:
- Prüfen, ob z.B. die (Ausfall-)Sicherheit der Anwendungen und stütztenden Systeme angemessen bzw. ausreichend ist
- Durchführung einer Schutzbedarfsanalyse zwischen IT und Fachbereich
- Es ist zu hinterfragen, welche Daten mit der Anwendung innerhalb des Prozesses ver- bzw. bearbeitet werden.
Daraus wird die dann die "Schutzbedürftigkeit" hinsichtlich Integrität und Vertraulichkeit für die Anwendung abgeleitet. Gleiches gilt für die Fragestellung, was konkret im Geschäftsprozess passiert, wenn z.B. die Anwendung xy ausfällt (z.B. < 1 Stunde, > 1 Stunde und < 3 Stunden etc.). Hieraus leitet sich die Ausgestaltung hinsichtlich Verfügbarkeit und der Notfallplanung ab.
| Für diese Zwecke ist bei der Ausgestaltung der IT-Systeme und der zugehörigen IT-Prozesse grundsätzlich auf gängige Standards abzustellen, |
Keine Änderung, Ableitung der zwingenden IT-Anforderungen:
- Orientierung an Standards, bzw. deren konkrete Umsetzung, z.B.:
IT-Prozesse = ITIL
IT-Sicherheit = ISO27001, BSI-Grundschutz
IT-Risikomanagement = ISO27005, BSI-1003, Cobit
| 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. |
Achtung, Änderung ! Ableitung der zwingenden IT-Anforderungen:
Dies bedeutet ganz konkret, dass dem Punkt IT-Prozesse rund um das Berechtigungsmanagement (Berechtigungsvergabe, Eintritts-/Austrittsmanagement) in Zukunft ein noch stärkerer Fokus in der IT gelten muss.
Im Endeffekt wird hier ein klares und nachvollziehbares "Identity-Management" verlangt.
Dieser Vorgabe nicht entsprechende Anwendungen (z.B. excelbasierte Anwendungen wie Excel-Sheet mit Makros) müssten somit zwingend abgelöst werden, da hier keine Berechtigungsmechanismen vorhanden sind und keinerlei Nachvollziehbarkeit darüber gegeben ist, wer was mit welcher Berechtigung und auf Basis welcher Parametereinstellungen getan hat.
| Die Eignung der IT-Systeme und der zugehörigen Prozesse ist regelmäßig von den fachlich und technisch zuständigen Mitarbeitern zu überprüfen. |
Keine Änderung, Ableitung der zwingenden IT-Anforderungen:
- IT-Anwendungen und -Systeme entsprechend der IT-Strategie auswählen
- Systematischer Auswahlprozess von Anwendungen/Systemen (sowohl IT- als auch fachliche Beteiligung nötig)
- Prozess-Reviews durchführen (im Falle von ITIL ist dies standardmäßig gegeben)
| 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. Produktions- und Testumgebung sind dabei grundsätzlich voneinander zu trennen. |
Keine Änderung, Ableitung der zwingenden IT-Anforderungen:
- Fachliche und technische Tests sind zwingend und müssen dokumentiert werden (Nachweispflicht)
- Zwingend getrennte IT-Produktions- und IT-Testumgebungen
| 4. Die Entwicklung und Änderung programmtechnischer Vorgaben (z. B. Parameteranpassungen) sind unter Beteiligung der fachlich und technisch zuständigen Mitarbeiter durchzuführen. Die programmtechnische Freigabe hat grundsätzlich unabhängig vom Anwender zu erfolgen. |
Keine Änderung, Ableitung der zwingenden IT-Anforderungen:
- Keine Änderungen an Anwendungen ohne fachliche Einbindung bzw. fachliche Anforderung/Fachkonzept (gemeint ist in Anspielung an die Parameter, dass es nicht sein darf, daß in einer Anwendung z.B. Prüfparameter wie Berechtigungen oder Limit-Prüfparameter eigenständig durch die IT geändert werden. Dieses könnte theoretisch dafür sorgen, dass Limit-Prüfungen oder auch unberechtigte Handlungen erfolgen können)
- Indirekt Impliziert dies aber auch daß die technische Administration/Pflege von Anwendungen und Systemen nicht ausschließlich in der Hand der Fachlichkeit liegen darf
Hintergrundbetrachtung:
Es gibt den Fall, daß vermeintliche Nischenanwendungen von der Fachlichkeit ohne Einbezug der IT gekauft und durchaus auch selbst betreut werden. Die MaRisk schließen eine solche Vorgehensweise eigentlich aus. Denn hier wird die Möglichkeit der Kontrolle und der Risikotransparenz außer Kraft gesetzt. Berechtigungen werden in diesen Fällen oft durch die Fachlichkeit vergeben, Parameter für Limits etc. selbst administriert. Dies muss ausgeschlossen sein, hier muss die Funktionstrennung Fachlichkeit/IT greifen - Indirekt gefordert wird hier letztlich auch ein stringenter Change- und Release-Prozess
| 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. |
Keine Änderung, Ableitung der zwingenden IT-Anforderungen:
- Die Umschreibung implementiert, daß bekannt sein muss, welches die (Zeit-)kritischen fachlichen Geschäftsprozesse sind und auch die Kenntnis, welche Services, Anwendungen und Systeme die einzelnen kritischen Geschäftsprozesse stützen
- Es muss ein entsprechendes zentrales Notfallmanagement (Business-Continuity), sowie informatikseitiges IT-(Service)-Continuity vorhanden sein und systematisch betrieben werden (inkl. zwingender dokumentierter Notfalltests)
- Es muss sowohl fachliche als auch informatikseitige Notfallpläne geben, die aufeinander abgestimmt sind, bzw. mit einander verzahnt sind
- Im Falle des Outsourcings von Unternehmensaktivitäten bzw. -Prozessen muss eine Risikoanalyse (Fachlichkeit und IT) durchgeführt werden. Es ist die Kritikalität des auszulagernden Prozesses zu definieren und eine Prozess-/Business-Impact und Schutzbedarfsanalyse durchzuführen.
Es müssen sowohl auf Seiten des auslagernden Unternehmen, als auch beim Outsourcingunternehmen aufeinander abgestimmt Notfallkonzepte vorliegen (die auch getestet werden müssen)
Hinweis "Outsourcing":
Es muss ganz klar bewusst sein und auch gemacht werden, dass mit einer Auslagerung bzw. Outsourcing von Geschäftsprozessen oder Unternehmensteilen kein Abwälzen der Risiken möglich ist. Die Risikoverantwortung obliegt auch bei Auslagerungen dem auslagernden Unternehmen. Es muss sicherstellen bzw. sich davon überzeugen, dass die Maßgaben der MaRisk durch den Sourcingnehmer erfüllt werden. Dies ist sinnvoller Weise auch entsprechend zu dokumentieren. Neben der Existenz von Notfallplänen sind auch viele weitere Aspekte zu beachten (ist angemessene ggf. zertifizierte IT-Sicherheit gegeben etc.).
| 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. |
Keine Änderung, Ableitung der zwingenden IT-Anforderungen:
- Wie bei Punkt 1.) bereits beschrieben, ist ein ganzheitliches, dokumentiertes, gelebtes und aufeinander abgestimmtes Business- und IT-(Service)-Continuity von Nöten
| < Zurück | Weiter > |
|---|
