BAIT verstehen: Was Banken jetzt wirklich umsetzen müssen

W

er heute über die IT-Steuerung eines Kreditinstituts spricht, kommt an einem Begriff nicht vorbei: BAIT – die bankaufsichtlichen Anforderungen an die IT. Hinter dem Kürzel verbirgt sich kein weiteres Technik-Dokument für Spezialisten, sondern eine klare Erwartungshaltung der Aufsicht an das gesamte Haus: IT ist nicht länger „Unterstützung“, sie ist Produktionskern. Damit verschiebt sich die Verantwortung aus dem Serverraum in die Chefetage. BAIT beschreibt das Betriebssystem, auf dem eine Bank ihre IT sicher, beherrscht und prüfbar organisiert – von der Strategie über den Betrieb bis zur Auslagerung. Wer BAIT richtig liest, erkennt, dass es nicht um hübsche Policies geht, sondern um gelebte Routinen, um nachweisbare Wirksamkeit und um die Fähigkeit, in der Krise reproduzierbar zu handeln. Dieser Beitrag ordnet BAIT in den aufsichtsrechtlichen Kontext ein, erläutert die gemeinsame Logik hinter Governance, Risiko, Sicherheit, Berechtigungen, Entwicklung, Betrieb und Auslagerungen und zeigt, welche Schritte Institute jetzt konkret gehen sollten, damit „BAIT-konform“ nicht auf Papier, sondern im Alltag funktioniert.

Warum BAIT? Von der Technikinsel zum Steuerungsmodell

Die Ausgangslage ist einfach: Banken sind digital getriebene Organisationen. Wertschöpfung, Kundenschnittstellen, Zahlungsverkehr, Handel, Meldewesen – alles hängt an Anwendungen, Datenflüssen und Dienstleistern. Fehler in der IT sind keine isolierten Störungen mehr, sondern Geschäftsrisiken. BAIT ist die Antwort darauf. Die Anforderungen verankern IT-Strategie und -Risiko im Herzen der Gesamtsteuerung, verzahnen Informationssicherheit mit Projekt- und Betriebsdisziplin und machen die Auslagerungssteuerung zur Pflichtaufgabe des Managements. Das Regelwerk ist dabei ausdrücklich prinzipienorientiert: Die Aufsicht schreibt kein starres Rezept vor, sondern Ziele und Mindeststandards. Wie ein Institut diese Ziele proportional zu Größe, Komplexität und Risikoprofil erreicht, muss es selbst tragfähig gestalten – und im Zweifel der Prüfung standhalten.

Die Klammer zu MaRisk: BAIT ist Konkretisierung, nicht Konkurrenz

BAIT steht nicht im luftleeren Raum. Die MaRisk beschreiben bereits die Grundarchitektur von Risikosteuerung und Governance. BAIT führt diesen Rahmen auf IT-Ebene aus: Was heißt „angemessene Organisation“ in der Praxis eines Rechenzentrums? Wie sieht „wirksame Kontrolle“ im Berechtigungsprozess aus? Woran erkennt man, dass Notfallkonzepte mehr sind als ein Ordner im Regal? Diese Konkretisierung ist der Kernnutzen von BAIT. Sie ersetzt kein bestehendes Risikomanagement, sie verbindet es mit der IT-Wirklichkeit – und genau dort ergeben sich in Prüfungen regelmäßig die Sollbruchstellen, wenn Begriffe, Rollen und Nachweise nicht zusammenpassen.

Die sieben Handlungsfelder: Von der Strategie bis zur Auslagerung

BAIT zeichnet eine Landkarte, die sich in jedem Institut wiederfinden muss: IT-Strategie und Governance, IKT-Risikomanagement, Informationssicherheit, Identitäts- und Berechtigungsmanagement, Entwicklung und Veränderungswesen, IT-Betrieb inklusive Notfallmanagement sowie Auslagerungen und sonstiger Fremdbezug von IT-Dienstleistungen. Diese Kapitel sind keine Silos, sondern eine Prozesskette. Aus der Strategie leitet sich der Risikoappetit ab, aus Risiko und Schutzbedarf folgen Kontrollen, aus Kontrollen folgen Messgrößen, aus Messgrößen folgen Entscheidungen in Projekten, Betrieb und Lieferkette – und am Ende müssen all diese Schritte durch belastbare Evidenzen belegt werden. Genau diese Kohärenz ist die Achillessehne vieler Häuser: Das Risikoregister behauptet eine Sache, die Testberichte eine andere, und der Auslagerungsvertrag kennt weder Melde- noch Prüfungsrechte. BAIT fordert, diese Lücken zu schließen.

IT-Strategie und Governance: Verantwortung, Mandat, Messbarkeit

BAIT beginnt oben: Die Geschäftsleitung hat eine IT-Strategie zu verabschieden, die mit dem Geschäftsmodell und den Risikozielen kompatibel ist. Das klingt banal, ist aber in der Praxis der Lackmustest dafür, ob IT wirklich Teil der Gesamtsteuerung ist. Eine belastbare Strategie benennt Zielarchitektur und Leitplanken (z. B. Grad der Standardisierung, Sourcing-Grundsätze, Cloud-Leitlinien), setzt Prioritäten (welche Fähigkeiten sind strategisch, welche werden extern bezogen), definiert Risikotoleranzen (Verfügbarkeit, Datenintegrität, Informationssicherheit) und macht klar, wie Fortschritt gemessen wird. Die Governance-Frage lautet: Wer entscheidet was, auf welchen Informationsgrundlagen und in welchen Zyklen? Ohne klare Gremien, Mandate und regelmäßige Management-Reviews bleibt die schönste Strategie wirkungslos.

IKT-Risikomanagement: Von der Inventur zum Steuerungsentscheid

BAIT verlangt ein gelebtes, nachvollziehbares IKT-Risikomanagement. Die Logik ist simpel: Man kann nur steuern, was man kennt und bewertet. Der erste Schritt ist deshalb eine vollständige Inventur kritischer Prozesse und Assets – Anwendungen, Schnittstellen, Plattformen, Datenbestände, technische und organisatorische Abhängigkeiten. Darauf folgt die Schutzbedarfsfeststellung nach Vertraulichkeit, Integrität und Verfügbarkeit sowie eine Bewertung wesentlicher IT-Risiken: Was ist die Wahrscheinlichkeit, was der potenzielle Schaden, welche Kontrollen existieren, wie wirksam sind sie? Ergebnis müssen priorisierte Maßnahmen sein – technisch, organisatorisch, vertraglich –, die in Umsetzungspläne münden. BAIT betont, dass es nicht um Momentaufnahmen geht: Risiken verändern sich mit Releases, Auslagerungen, neuen Angriffsmethoden. Entsprechend braucht es Schwellenwerte, Kennzahlen und Alarmwege, die eine Bank in die Lage versetzen, nicht nur zu dokumentieren, sondern zu steuern.

Informationssicherheit: System statt Produkt

Informationssicherheit ist in BAIT kein Einkaufsthema, sondern ein Managementsystem. Gefordert ist eine Sicherheitsorganisation mit ausreichender Unabhängigkeit, klaren Mandaten, Ressourcen und direkter Berichtsbeziehung zur Leitung. Ihre Aufgabe ist nicht, Firewalls zu konfigurieren, sondern Sicherheitsziele operational zu übersetzen: Richtlinien, Prozesse, Messgrößen und regelmäßige Berichterstattung. Kernprozesse sind: Asset- und Schutzbedarfsmanagement, Schwachstellen- und Patch-Management, Logging und Monitoring, Security-Incident-Management inklusive Meldeketten, Kryptokonzept, Schulung und Sensibilisierung, regelmäßige Prüf- und Testaktivitäten sowie Notfall- und Wiederanlaufplanung. Entscheidend ist der Nachweis der Wirksamkeit: Erkennungszeiten, Schließzeiten für Schwachstellen, Abdeckungsgrade von Überwachungsregeln, Anteile erfolgreicher Restore-Tests. BAIT will keine „Policy-Landschaften“, sondern Zahlen, die zeigen, ob das System funktioniert.

Identitäts- und Berechtigungsmanagement: End-to-End statt Excel

Berechtigungen sind ein Dauerbrenner der Aufsicht – verständlich, denn viele Vorfälle beginnen bei zu weiten oder verwaisten Rechten. BAIT verlangt einen durchgängigen Prozess von Eintritt bis Austritt: Rollen und Rechte auf Basis dokumentierter Funktionstrennungen, Vier-Augen-Prinzip bei Vergabe, befristete Notfall- und privilegierte Zugriffe, regelmäßige Rezertifizierungen, technische Durchsetzung (z. B. zentrale Verzeichnisdienste, kontrollierte Admin-Jump-Hosts, Sitzungsaufzeichnung, Protokollierung). Entscheidend ist der Beleg, dass dieser Prozess nicht nur existiert, sondern greift: Stichproben aus echten Populationen, Protokolle genehmigter Rechte, Nachweise entzogener Zugriffe nach Organisationswechseln, Journal der Notfallzugriffe. Eine Berechtigungsverwaltung in Tabellenkalkulationen ohne Systemkopplung ist ein Warnsignal – BAIT erwartet ein auditierbares, integriert betriebenes Modell.

Entwicklung und Veränderungswesen: Qualität vor Geschwindigkeit – aber mit beidem

Anwendungen ändern sich – und mit ihnen Risiken. BAIT fordert deshalb ein Entwicklungs- und Änderungswesen, das Qualität sichert, ohne die Bank zu lähmen. Elemente sind: klare Trennung von Entwicklung, Test und Produktion; reproduzierbare Build-Prozesse; Peer-Reviews und Testabdeckung; Freigabegremien mit dokumentierten Kriterien; definierte Wartungsfenster und Rückfallpläne; Steuerung von Parametrisierungen genauso wie von Code; geordnete Dokumentation von Anforderungen, Tests und Abnahmen. Gerade in heterogenen Landschaften, in denen Eigenentwicklungen, Standardsoftware und Individualparametrisierung nebeneinander existieren, entscheidet dieses Veränderungswesen über Stabilität. BAIT schaut hier auf die Verbindung zu Risiko und Sicherheit: Werden Schutzbedarfsentscheidungen in der Umsetzung berücksichtigt? Sind Sicherheitsanforderungen Teil der Abnahmekriterien? Werden Schwachstellenberichte in Tickets überführt und nachgehalten? Wer diese Kette schließt, reduziert Störungen – und besteht Prüfungen.

IT-Betrieb und Notfallmanagement: Wiederherstellbarkeit ist messbar

„Wir haben Backups“ ist kein Notfallkonzept. BAIT erwartet geprobte Wiederherstellbarkeit, und zwar auf Anwendungsebene. Das heißt: periodische Restore-Tests mit Integritätsnachweis (Checksummen, Transaktionskohärenz, stichprobenweise End-to-End-Verifikation), dokumentierte Ergebnisse mit Abweichungsanalyse und Re-Tests. Daneben gehören Kapazitätsmanagement, Monitoring und Alarmierung, Log-Management, Patch- und Konfigurationssteuerung, Datensicherung mit Trennung der Sicherungsumgebung, Härtung von Systemen und Standardisierung der Basisplattformen zum Pflichtprogramm. Für den Ernstfall fordert BAIT auch die organisatorische Seite: Eskalationswege, Kommunikationsleitfäden, Vertretungsregelungen, Entscheidungsrechte. Notfallhandbücher, die nicht geübt werden, sind eine Illusion – BAIT misst am Ergebnis: Wie lange dauert der Wiederanlauf? Mit welchem Datenstand? Welche Ersatzprozesse greifen? Welche Lücken wurden geschlossen?

Auslagerungen und Fremdbezug: Steuerung statt Hoffnung

Die wichtigste Verschiebung der letzten Jahre ist die Verlagerung von IT-Leistung zu Dienstleistern. BAIT macht klar: Verantwortung bleibt im Haus. Institute müssen risikoadäquat auswählen, vertraglich absichern und laufend überwachen – unabhängig davon, ob es sich um eine Auslagerung im engeren Sinne oder um sonstigen Fremdbezug handelt. Mindestinhalte sind: Transparenz über Subdienstleister, Informations- und Prüfungsrechte, Meldepflichten bei Vorfällen, Regelungen zur Datenlokation und zum Schutzbedarf, Exit-Klauseln und Portabilitätsmechanismen, Sicherheitsanforderungen an Betrieb und Entwicklung, Service-Levels mit Sanktionen. Ein aktuelles Register aller wesentlichen Fremdbezüge mit Kritikalitäten, Ergebnissen der Due-Diligence und laufenden Bewertungen ist Pflicht. Die Praxisfrage lautet: Wie wird überwacht? Reichen Berichte, oder gibt es technische Telemetrie? Werden Auditrechte genutzt? Gibt es geübte Exit-Szenarien? BAIT sucht nicht nach Vertragsdeutsch, sondern nach Steuerungswirkung.

Drei Verteidigungslinien: Rollen trennen, Zusammenarbeit sichern

BAIT setzt das bekannte Modell der drei Verteidigungslinien voraus: Operative Verantwortung (erste Linie), Risikokontrolle und Compliance (zweite Linie), Interne Revision (dritte Linie). Entscheidend ist die gelebte Trennung der Rollen – ebenso entscheidend ist die Zusammenarbeit. Die Sicherheitsorganisation darf nicht in der IT „aufgehen“, sie braucht Unabhängigkeit und Eskalationsrecht. Die zweite Linie muss Bewertungsmaßstäbe und Metriken liefern, die die Führung versteht. Die Revision prüft nicht nur Existenz, sondern Wirksamkeit – auf Basis nachvollziehbarer Populationen und Stichproben. Wo Linien verschwimmen, werden Prüfungen ungemütlich; wo sie sauber zusammenarbeiten, entstehen robuste Routinen.

Nachweise und Kennzahlen: Was die Aufsicht sehen will

BAIT-Prüfungen sind kein Literaturwettbewerb. Gewinnt nicht, wer die meisten Richtlinien hat, sondern wer die beste Evidenz liefert: systemseitige Exporte und Protokolle mit Zeitstempeln, Populationsbeschreibungen und Stichproben, Messwerte und Schwellwertverletzungen mit Reaktionen, Testprotokolle mit klaren Akzeptanzkriterien, Rezertifizierungslisten mit Freigaben, Vorfallprotokolle mit Fakten/Hypothesen-Trennung, Auslagerungsregister mit verknüpften Verträgen, Auditergebnissen und Scorecards. Dazu gehören Kennzahlen, die Steuerung ermöglichen: Erkennungs- und Behebungszeiten, Patch-Alter, Abdeckung von Use-Cases im Monitoring, Quote erfolgreicher Restores, Anteile zeitgerechter Rezertifizierungen, SLA-Erfüllung kritischer Dienstleister. Wer diese Nachweise als Nebenprodukt gelebter Prozesse erzeugt, ist „always audit ready“ – alle anderen sammeln in Hektik und verlieren Konsistenz.

Proportionalität richtig verstanden: Tiefe dort, wo es brennt

„Proportional“ heißt nicht „weniger“, sondern „gezielt“. Ein kleines Institut mit wenigen Eigenentwicklungen wird den Fokus auf Berechtigungen, Notfallmechanik und Auslagerungssteuerung legen; ein Haus mit eigenem Rechenzentrum und Individualsoftware muss Entwicklung, Konfiguration und Betrieb mit mehr Tiefe steuern; Institute mit exponiertem Zahlungsverkehr brauchen höhere Taktung bei Tests und Überwachung. BAIT lässt diese Zuschnitte zu – verlangt aber die Begründung aus Risiko und Geschäftsrelevanz. Wer seine Schutzbedarfe und Geschäftsprozesse nicht sauber klassifiziert, entscheidet ins Blaue.

Typische Sollbruchstellen – und wie man sie vermeidet

In der Praxis zeigen sich wiederkehrende Schwächen. Erstens: Inkonsistenzen zwischen Risiko, Tests, Vorfällen und Verträgen. Abhilfe schafft ein „Kohärenz-Review“ pro Quartal, in dem die führenden Datenquellen auf Widersprüche geprüft und behoben werden. Zweitens: Berechtigungen ohne Ende-zu-Ende-Prozess. Heilmittel sind zentrale Identitätsquellen, Rollenmodelle, dokumentierte Funktionstrennungen, Rezertifizierungszyklen und technische Durchsetzung. Drittens: Backup ohne Restore-Beweise. Hier helfen standardisierte Restore-Schemata mit Integritätsnachweis, regelmäßige Proben und Re-Tests. Viertens: Auslagerungen ohne gelebte Steuerung. Gegenmittel sind Scorecards, jährliche Audits/Assessments, Nachträge mit klaren Melde- und Prüfungsrechten, geübte Portabilität. Fünftens: Informationssicherheit als Policy-Abteilung. Dagegen helfen Metriken, die das Management interessieren, und eine Organisation, die Projekte und Beschaffung frühzeitig einbindet.

Umsetzung in der Praxis: Vom Projekt zur Routine

Der erste Impuls vieler Häuser ist ein Projekt: Lücken analysieren, Maßnahmenlisten, Dokumente erstellen. Das ist als Start legitim, aber BAIT verlangt Dauerbetrieb. Der Übergang gelingt, wenn Verantwortungen verbindlich verankert, Zyklen definiert und Datenquellen automatisiert werden. Hilfreich sind „Evidence-Tage“ im Monatsrhythmus, an denen Teams systemseitige Nachweise ziehen und ablegen; Testkalender mit klaren Akzeptanzkriterien; Rezertifizierungsfenster mit Erinnerung und Eskalation; vierteljährliche Management-Reviews mit Kennzahlen statt Foliensätzen; jährliche Probe-Audits mit echten Stichproben. Wer diese Routinen etabliert, reduziert nicht nur Prüfungsdruck, sondern erhöht Stabilität – der eigentliche Zweck von BAIT.

Entwicklung, Sicherheit, Betrieb – gemeinsam denken

Ein häufiger Kulturfehler ist die Trennung von Projekten, Sicherheit und Betrieb. BAIT zwingt zum Querschnitt: Sicherheitsanforderungen gehören in die Definition von fertig („Definition of Done“), nicht in die Nachsorge; Risiko-Entscheidungen müssen Releases beeinflussen; Betriebserfahrung muss in Entwicklung zurückfließen. Dazu braucht es gemeinsame Metriken (z. B. Anteil sicherheitsrelevanter Findings pro Release, Zeit bis zur Schließung, Auswirkung auf Verfügbarkeit) und Gremien, die sowohl Geschwindigkeit als auch Qualität priorisieren. „Schnell“ und „sicher“ sind keine Gegensätze, wenn die Disziplin stimmt – BAIT liefert dafür die Leitplanken.

Ausblick im Haus: Was jetzt konkret zu tun ist

Institute, die BAIT ernst nehmen, beginnen mit Transparenz. Eine vollständige, risiko­basierte Inventarisierung kritischer Prozesse und IT-Assets ist der Start. Daraus folgen Schutzbedarfe und Prioritäten. Parallel werden Governance und Rollen geschärft: Sicherheitsorganisation mit Mandat, Berechtigungs-Owner, Auslagerungs-Manager, Notfall-Verantwortliche, Gremien mit verbindlichen Entscheidungen. Auf dieser Basis entstehen messbare Routinen: Testkalender, Restore-Proben, Rezertifizierungen, Scorecards für Dienstleister, Management-Berichte. Verträge erhalten Nachträge, wo Prüf- und Melde-rechte fehlen; Register werden mit Änderungstriggern gepflegt. Und weil Papier geduldig ist, werden die Nachweise in systemischen Ablagen versioniert – unveränderlich, mit Zeitstempel, prüfbar. So wächst aus BAIT keine Dokumentenlandschaft, sondern ein Betriebsmodell.

Warum sich der Aufwand lohnt

BAIT zu leben ist Arbeit – aber es ist die Arbeit, die ein reifer Betrieb ohnehin leisten muss. Die Effekte sind konkret: weniger Ausfälle, kürzere Wiederherstellungszeiten, weniger Überraschungen bei Prüfungen, bessere Verhandlungsposition gegenüber Dienstleistern, schnellere Entscheidungen, weil Zahlen vorliegen, und am Ende ein stabileres Geschäft. Die vielleicht wichtigste Erkenntnis: BAIT ist keine Hürde, sondern eine Betriebsanleitung. Wer sie befolgt, professionalisiert nicht die Aufsicht, sondern sich selbst. Und das ist im Wettbewerb um Vertrauen, Verfügbarkeit und Sicherheit ein Vorteil, den man sehen und messen kann.

Schluss: BAIT als gemeinsame Sprache

BAIT gibt Banken, Aufsicht, Prüfern und Dienstleistern eine gemeinsame Sprache. Diese Sprache ist nüchtern: Ziele, Risiken, Kontrollen, Nachweise. Sie ist aber auch hilfreich, weil sie Silos auflöst und Zusammenhänge sichtbar macht. Wer BAIT als Checkliste liest, wird müde; wer BAIT als Architektur begreift, richtet sein Haus so aus, dass Strategie, Risiko, Sicherheit, Betrieb und Lieferkette ineinandergreifen. Genau das ist der Punkt. Nicht, weil es vorgeschrieben ist, sondern weil es funktioniert. Wer heute damit beginnt, hat morgen weniger zu erklären – und übermorgen mehr Zeit für das, worum es eigentlich geht: ein stabiles, verlässliches, prüfbares Bankgeschäft in einer Welt, in der IT das Fundament ist.