Die Unternehmens-IT in Abhängigkeit von den BAIT | IT-Strategie

Durch die Digitalisierung von Geschäftsprozessen, eine immer komplexer werdende Fachlichkeit, regulatorische Vorgaben und steigende Anforderungen zur Interaktion mit den Kunden, wird ein verstärkter Einsatz von IT notwendig. Oft hat die IT dabei ihre Unterstützungsfunktion verlassen und ist zu einem Geschäftstreiber oder sogar Enabler geworden.

Ein Teil der regulatorischen Vorgaben sind die „Bankaufsichtliche Anforderungen an die IT“ (BAIT), die für die IT von Kredit- und Finanzdienstleistungsinstituten in Deutschland gilt und sich an die Geschäftsleitungen der Unternehmen richtet.

Die Anforderungen der BAIT dürfen dabei nicht als vollständiger und abschließender Katalog von Anforderungen verstanden werden. Die MaRisk mit dem Allgemeinen Teil 7.2 „Technisch-organisatorische“ Ausstattung gilt weiterhin.

Lesen Sie dazu mehr im Beitrag "Die Unternehmens-IT in Abhängigkeit von MaRisk und BAIT" >>>

Was aber bedeuten diese Vorgaben für die Unternehmens-IT? Im Folgenden werden wir diese Themenbereiche einzeln beleuchten. In diesem Beitrag steht die IT-Strategie im Fokus. Erfahren Sie, wie Sie bei der Festlegung der IT-Strategie vorgehen und welche Mindestinhalte diese umfassen sollte.

Ihre IT-Strategie muss zwingend die Anforderungen nach AT 4.2 der MaRisk erfüllen. Entsprechend der Formulierung in den BAITs ist die Geschäftsleitung dafür verantwortlich, eine IT-Strategie festzulegen, die mit der Geschäftsstrategie vereinbar ist. Zum besseren Verständnis zeige ich Ihnen im nächsten Abschnitt, was unter der IT-Strategie verstanden wird und welche Fragen Sie sich in diesem Kontext stellen sollten. 

Eine IT-Strategie beschreibt die Vision, Mission, Ziele und Wege dorthin und dient als Orientierungshilfe. Die Hauptthemen einer IT-Strategie sind die Sicherung und Steigerung des Unternehmenserfolgs, die Verbesserung der IT-Leistungen und die Senkung der IT-Kosten. Der Umfang der IT-Strategie hängt dabei von der Größe des Unternehmens, insbesondere von der Bedeutung und der Größe der IT-Abteilung ab.

Die wesentlichen Voraussetzungen für die Entwicklung einer IT-Strategie sind das Unternehmensleitbild und die Unternehmensstrategie.

• Im Unternehmensleitbild werden die Grundsätze und Überzeugungen, nach denen gearbeitet werden soll, beschrieben. Das könnte z.B. die Festlegung sein, dass das Unternehmen Marktführer werden soll oder, dass in der IT bewusst die neuesten Technologien und Möglichkeiten ausprobiert werden sollen und man Risiken auch als Chancen begreift.
• Die Unternehmensstrategie gibt den Weg vor, wie ausgehend von einem Ist-Zustand der Soll-Zustand erreicht werden soll. Eine strategische Zielsetzung für ein Unternehmen kann beispielsweise sein, ein höheres Absatzvolumen durch den verstärkten Einsatz von E-Commerce zu generieren.

Zur IT-Strategie ergeben sich mehrere Fragen:

Wer ist der Owner der IT-Strategie und wie entsteht diese?

Owner ist die IT-Leitung. Die IT-Strategie wird typischerweise von der IT-Abteilung erstellt, wobei ausgewählte Beteiligte aus dem Unternehmen oder externe Berater mitwirken.

Welche Möglichkeiten und welche Trigger gibt es bei der Erstellung der IT-Strategie?

1. Top-down-Verfahren:

• Die IT-Strategie wird aus der Unternehmensstrategie abgeleitet. Hier ist ein Mapping hilfreich, das beschreibt, welche Abhängigkeiten zwischen den Zielen dieser beiden Strategien bestehen.
• Weiterhin kann im Rahmen einer SWOT-Analyse (Stärken, Schwächen, Chancen, Risiken) erkannt werden, dass ein Anpassungsbedarf bei der IT besteht, der z.B. in der Maßnahme „Verlagerung von Anwendungen in die Cloud“ resultiert.
• Ein komplett neues Produkt, eine Dienstleistung oder ein neues Geschäftsmodell soll bereitgestellt werden oder ein neuer Geschäftspartner ist vorhanden.

2. Bottom-up-Verfahren:

• Es ergeben sich neue Möglichkeiten aufgrund von technischen Neuerungen wie leistungsfähigeren Geräten oder Anwendungen, mobilen Geräten, KI, Cloud- oder Quanten-Computing.
• … wegen der Unzufriedenheit von IT-Anwendern entsteht Handlungsbedarf.

3. Top-down und Bottom-up-Verfahren können auch kombiniert werden.

Aus den BAITs sind insgesamt 5 Mindestinhalte definiert, die eine IT-Strategie enthalten sollte. Im Folgenden werde ich diese näher erläutern

a) Strategische Entwicklung der IT-Aufbau- und IT-Ablauforganisation des Instituts sowie der Auslagerungen von IT-Dienstleistungen

Die IT-Aufbauorganisation definiert die statische Struktur der IT eines Unternehmens und benennt die Stellen/Positionen in ihr. Im Gegensatz dazu beschreibt die IT-Ablauforganisation dynamische Arbeitsprozesse und konzentriert sich auf die Aktivitäten und deren Reihenfolge. Beide Arten der Organisation müssen strategisch geplant und regelmäßig auf die Einhaltung der Planung geprüft werden.

Eine wichtige Frage bei der Erstellung der IT-Aufbauorganisation ist, welche Teile der IT ausgelagert werden sollen (Outsourcing). Dabei sollte man mindestens prüfen,

• welche Aufgaben vorhanden sind.
• welcher Aufwand hierfür betrieben wird.
• welche internen Ressourcen mit welchem Know-how vorhanden sind, die diese Aufgaben durchführen können.
• wie erfolgreich die Aufgaben durchgeführt werden.

Oftmals ist es wirtschaftlich günstiger, Aufgaben auszulagern, als mühevoll Know-how bei internen Mitarbeitern aufzubauen. Allerdings begibt man sich durch eine Auslagerung in die Abhängigkeit zum externen Dienstleister. Die Entscheidungen und Festlegungen zum Outsourcing sowie die Weiterentwicklung dazu sollten im Rahmen eines Auslagerungsmanagements durchgeführt werden. Weiterhin ist ein Auslagerungsvertrag mit dem jeweiligen Dienstleister erforderlich.

b) Zuordnung der gängigen Standards, an denen sich das Institut orientiert, auf die Bereiche der IT

Kredit- und Finanzdienstleistungsinstitute in Deutschland unterliegen den vielfältigsten Gesetzen, Regelungen und Standards. Ein Teil dieser Standards betrifft die IT. Diese Untermenge muss in einem ersten Schritt definiert werden und könnte Standards oder Regelungen wie Risikomanagement, Informationssicherheit, Notfallmanagement, Auslagerungsmanagement und Kontrollsysteme oder auch Prozesse nach ITIL umfassen. Aber auch Vorgaben wie das „Merkblatt Orientierungshilfe zu Auslagerungen an Cloud-Anbieter“ der BaFin, die „Leitlinien zu Auslagerungen“ der EBA oder die „EBA Guidelines on ICT and security risk management“ sind hier sinnvoll.

In einem weiteren Schritt erfolgt dann die Festlegung, welche Standards für welche Bereiche bzw. Prozesse der IT, wie z.B. Beratung, Anwendungsentwicklung, Betrieb, Technologiemanagement gelten sollen.

Im letzten Schritt wird dargestellt, welcher Anteil der festgelegten Standards in den jeweiligen Prozessen oder Services umgesetzt werden soll.

c) Zuständigkeiten und Einbindung der Informationssicherheit in die Organisation

Daten bzw. Informationen müssen auf vielfältige Weise geschützt werden. Dies geschieht durch Maßnahmen der Informationssicherheit, welche die sogenannten Schutzziele Vertraulichkeit, Verfügbarkeit und Integrität adressieren. Damit sollen Schäden vermieden, Gefahren abgewendet und Risiken des IT-Einsatzes minimiert werden.

Das Thema Informationssicherheit muss organisatorisch im Unternehmen verankert sein. Dabei müssen die Verantwortlichkeiten und die Zuständigkeiten definiert sein.

Das Management der Informationssicherheit kann dabei im Unternehmen unterschiedlich positioniert werden.

Für die Positionierung der Informationssicherheit im Unternehmen gibt es verschiedene Möglichkeiten:

• Die Informationssicherheit wird durch die IT-Abteilung abgedeckt, da dort IT-Know-how vorhanden ist. Allerdings reicht das alleine nicht aus, denn es werden auch andere Fähigkeiten wie Organisationsvermögen, der Blick für das Ganze und die Fähigkeit, Maßnahmen aus der IT-Strategie abzuleiten, benötigt. Weiterhin sind in der IT-Abteilung oft nicht genug Ressourcen für die Tätigkeiten zur Informationssicherheit verfügbar. Aus diesen Gründen kann ich diese Positionierung nicht empfehlen.
• Ein Informationssicherheits-Beauftragter (ISB) wird dem IT-Leiter zur Seite gestellt bzw. ihm untergeordnet. Dies bedingt, dass der ISB vom IT-Leiter abhängig ist. Damit könnte der IT-Leiter ihm nicht genehme Themen zurückhalten oder abschwächen. Weiterhin könnten für Mitarbeiter der IT Interessenskonflikte entstehen, wenn sich die Anforderungen oder Vorgaben des IT-Leiters und des ISB unterscheiden.
  Auch diese Positionierung der Informationssicherheit wird nicht empfohlen.
• Wenn die Unabhängigkeit der Informationssicherheit gewährleistet werden soll, dann kann für diese eine Stabsstelle eingerichtet werden. Diese existiert dann losgelöst von der Linienorganisation, so dass eine gewisse Unabhängigkeit gegeben ist.
• Die Informationssicherheit kann Teil der unternehmensweiten Sicherheit sein. Damit arbeiten alle Sicherheitsbereiche nach einem einheitlichen Vorgehen und es ist eine Unabhängigkeit von den IT-Funktionen vorhanden.
• Die Aktivitäten zur Informationssicherheit werden durch ein Gremium wahrgenommen. Dieses Gremium besteht aus Vertretern aller Bereiche, die eine Relevanz für die IT-Sicherheit haben. Hierbei sollte darauf geachtet werden, die Anzahl der Mitglieder des Gremiums möglichst klein ist.

Neben der organisatorischen Einbettung ist es wichtig, dass sich die Aktivitäten zur Informationssicherheit auch in den dafür relevanten Prozessen wiederfinden, z.B. beim Beantragen von Rechten oder beim Onboarding eines neuen Mitarbeiters. Falls Aufgaben an externe Dienstleister gegeben werden, ist eine Beschreibung notwendig, inwieweit das Thema Informationssicherheit dabei berücksichtigt wurde.

d) Strategische Entwicklung der IT-Architektur

Die IT-Architektur beschreibt, wie die Hardware und die Software eines Unternehmens beschaffen ist, welche Abhängigkeiten bestehen und wie das Architektur Management aussieht. Ein wichtiger Teil der IT-Strategie ist es, die vorhandene IT-Architektur strategisch zu planen und weiter zu entwickeln.

Die Ziele dabei sind:

• Bereitstellung und laufende Modernisierung einer anpassungsfähigen Infrastruktur
• Bereitstellung von Applikationen zur optimalen Unterstützung der Geschäftsprozesse
• Gewährleistung eines zuverlässigen und unterbrechungsfreien Betriebs
• Optimierung der Kosten
• Erzielung einer hohen Nutzer-Zufriedenheit
• Testen und ggf. Einsetzen von neuen Technologien

Oft sind die Infrastruktur-Komponenten und die Applikationen in einem Unternehmen organisch gewachsen, so dass folgende Problempunkte bestehen:

• Es ist kein Überblick und keine Dokumentation zu den IT-Systemen vorhanden. Sowohl das Zusammenspiel und die Daten- als auch Kontrollflüsse der IT-Systeme sind nicht voll umfänglich bekannt. Weiterhin ist oft nicht bekannt, welche Daten redundant vorliegen.
• Mitunter haben die Know-how Träger zu den IT-Systemen das Unternehmen verlassen, so dass das Wissen nicht mehr verfügbar ist.
• Die Entwicklung von neuen IT-Anwendungen und die Beschaffung von Hard- und Software gestaltet sich riskanter, da kein Überblick vorhanden ist. Es ist nicht klar ersichtlich, wie sich das neue System in das vorhandene „Geflecht“ integriert.
  Kurzfristige und unabgestimmte Entscheidungen von Fachabteilungen zur Beschaffung von IT-Systemen verschärfen die Problematik zusätzlich und erhöhen die Komplexität der IT-Landschaft.

Eine Lösung dieser Probleme kann ein IT-Architekturmanagement sein. Wenn sich dieses als integraler Bestandteil des Geschäfts sieht, dann liegt ein Enterprise Architecture Management (EAM) vor. Hier wird ein gesamtheitlicher und strategischer Blick eingenommen, der nach TOGAF (The Open Group Architecture Framework) folgende Themen umfasst:

• Geschäftsarchitektur:
  Diese entsteht bei der Geschäftsprozess-Modellierung und beschreibt die Geschäftsziele und -prozesse, die Strategie, die Organisationsstrukturen und die Ressourcen des Unternehmens. Die Ergebnisse werden als Text, als Prozesslandkarten, fachliche Bebauungspläne und optional als Ereignisgesteuerte Prozessketten dokumentiert. Es bietet sich an, die Prozesse in Kern-, Management- und Unterstützungsprozesse zu unterteilen.
• Technologiearchitektur:
  Diese beschreibt die Architekturelemente, wie Hard- und Software, Netzwerke, Plattformen, Schnittstellen, Konzepte und Standards. Sinnvolle Diagrammtypen zur Beschreibung der Architekturelemente sind hier die Implementation und die Deployment Diagrams der Unified Modeling Language (UML), Schichtenmodelle oder Diagramme, die die Verteilung der Komponenten auf den Server und den Client darstellen.

• Anwendungsarchitektur
  Die Anwendungsarchitektur beschreibt die Anwendungen und die Schnittstellen zwischen den Anwendungen, die zur Bearbeitung der Geschäftsprozesse erforderlich sind. Es empfiehlt sich, sich bei der Beschreibung an den Hauptprozessen des Unternehmens (Kern-, Management- und Unterstützungsprozesse) zu orientieren. Die Dokumentation geschieht in Anwendungs-Bebauungsplänen.
• Datenarchitektur
  Diese beschreibt die für die Prozesse benötigten Daten und ihre Abhängigkeiten untereinander. Dabei sollte die logische und die physische Struktur der Daten festgehalten werden. Die Ziele der Datenarchitektur sind, für die Daten(-Pakete) im Unternehmen einen Owner zu identifizieren und ihm die Verantwortung für die Daten zu übertragen. Weiterhin sollen Redundanzen in den Daten erkannt und möglichst eliminiert werden. Die Daten und ihre Struktur können in ERM-Diagrammen (Datenmodell) oder in Class Diagrams (gemäß UML) beschrieben werden.

Die Architekturen werden dabei in der Form von textuellen Beschreibungen oder als grafische Darstellungen beschrieben. Eine wichtige grafische Darstellungsart ist der Bebauungsplan, welcher aufzeigt, welche Geschäftsprozesse mit welchen IT-Systemen unterstützt werden und welche Abhängigkeiten bestehen.

Der Bebauungsplan, der dann auch die Anwendungslandschaft enthält, sollte als Ist-Stand und als Soll-Stand (Zielbild) vorliegen und es sollte beschrieben sein, wie man vom Ist- zum Soll-Stand gelangen kann.

Als Ergebnis der strategischen Entwicklung der IT-Architektur ist die Anwendungslandschaft formal vollständig abgebildet. Auf diesen Ergebnissen setzen dann die Schutzbedarfsanalyse sowie die IT-Risikoanalyse auf.

e) Aussagen zum Notfallmanagement unter Berücksichtigung der IT-Belange

Wichtige oder zeitkritische Geschäftsprozesse, wie z.B. der Zahlungsverkehr in einem Kreditinstitut, dürfen bei Notfällen, wie dem Ausfall von IT-Systemen, der Zerstörung von Gebäuden (z.B. durch Brand oder durch Überschwemmung), dem Ausfall von Personal (z.B. durch eine Virus-Pandemie) oder von Dienstleistern nicht unterbrochen werden, sondern müssen weiterlaufen.

Wichtig ist es, auf einen Notfall vorbereitet zu sein. Dies geschieht im Rahmen einer Notfallvorsorge, bei der kritische Situationen definiert und entsprechende Gegenmaßnahmen festgelegt werden. Dies wird in einem Notfallkonzept dokumentiert. Dieses dazugehörende Notfallmanagement wird oft auch als Business Continuity Management bezeichnet. Weiterhin sollten auch die Ergebnisse von Bedrohungsanalysen in das Notfallkonzept einfließen.

Die in einem Notfall oder einer Krise erforderlichen Abläufe für einen Notbetrieb oder für die Wiederherstellung des Normalbetriebs werden in einem Notfallhandbuch festgehalten und sollten regelmäßig trainiert werden.

f) Aussagen zu den in den Fachbereichen selbst betriebenen bzw. entwickelten IT-Systemen (Hardware- und Software-Komponenten)

Fachbereiche sind mitunter mit den angebotenen IT-Services nicht zufrieden oder benötigen spezielle Lösungen, die die IT-Abteilung nicht oder nicht zeitnah bereitstellen kann. Deshalb erstellen Fachbereiche selbst IT-Lösungen, die dann allerdings oft nicht in die vorhandenen IT-Lösungen integriert sind. So kann beispielsweise ein Dienst fehlen, der die Daten regelmäßig sichert und archiviert, was später zu einem Datenverlust führen kann.

Falls der Fachbereich IT-Systeme erstellt, die nur gelegentlich benutzt werden, daher nicht ständig verfügbar sein müssen und nur eine geringe Kritikalität besitzen, dann ist dies akzeptabel. Es sollte eine Auflistung der selbst entwickelten und betriebenen Anwendungen vorhanden sein. Erforderlich ist eine Dokumentation des Zwecks der einzelnen IT-Anwendung, des Verantwortlichen, der Nutzer, der Schnittstellen und der Aktivitäten zum Betrieb.

Nicht akzeptabel ist es, wenn der Fachbereich geschäftskritische IT-Systeme betreibt.

In den folgenden Teilen des Blogbeitrags "Die Unternehmens-IT in Abhängigkeit von den BAIT " werden wir uns mit den weiteren Kapiteln der BAIT beschäftigen und was diese Vorgaben für die Unternehmens-IT bedeuten.