BAIT, VAIT, KAIT: Was die xAITs eint – und wo sie unterscheiden

BAIT, VAIT, KAIT: Was die xAITs eint – und wo sie unterscheiden

Wer die IT-Aufsicht im deutschen Finanzsektor verstehen will, kommt an drei Kürzeln nicht vorbei: BAIT, VAIT und KAIT. Hinter diesen Abkürzungen stehen die bank-, versicherungs- und kapitalverwaltungsaufsichtlichen Anforderungen an die IT – drei Regelwerke, die in kurzer Folge eingeführt wurden und seitdem die Messlatte für Governance, Informationssicherheit, Outsourcing und den Betrieb geschäftskritischer IT setzen. Sie sind Geschwister aus einem Haus: in Aufbau und Anspruch eng verwandt, im Detail aber spürbar geprägt von den Besonderheiten ihrer jeweiligen Domäne. Wer sie nur als „weitere Checkliste“ liest, übersieht ihren eigentlichen Charakter: Die xAITs beschreiben nicht bloß technische Mindeststandards, sondern ein integriertes Betriebs- und Steuerungsmodell für digitale Stabilität. Dieser Beitrag ordnet das Trio ein, zeigt die gemeinsame DNA – und markiert jene Stellen, an denen die Pfade sichtbar auseinandergehen.

Wozu überhaupt xAIT? Entstehung, Anspruch, Kontext

Der Auslöser ist schnell erzählt: IT hat sich von der Unterstützungsfunktion zum Produktionskern der Finanzwirtschaft entwickelt. Wertschöpfung, Kundenschnittstellen, Risiko- und Meldeprozesse – alles hängt an verteilten Anwendungen, Datenströmen und einer Lieferkette, die weit über die Unternehmensgrenzen reicht. Gleichzeitig hat der Sektor in den vergangenen Jahren mehrere schmerzhafte Lektionen gelernt: Sicherheitsvorfälle, Verfügbarkeitsprobleme, Fehlentwicklungen in Projekten, Abhängigkeiten von einzelnen Dienstleistern. Aufsicht und Institute, Versicherer und Kapitalverwaltungsgesellschaften teilen deshalb dasselbe Zielbild: ein beherrschbares, prüfbares, resilient aufgestelltes IT-Ökosystem. Die xAITs liefern dafür die Systematik – prinzipienorientiert („Ziel, nicht Mittel“), risikobasiert („Tiefe nach Kritikalität“) und proportional („Größe und Komplexität zählen“).

BAIT adressiert Banken und Finanzdienstleister und schmiegt sich eng an das Risikomanagement-Rahmenwerk der MaRisk an. VAIT überträgt dieses Prinzip in die Welt der Versicherer, mit hörbarer Resonanz zu Governance- und Risikoprozessen unter Solvency-II-Prämissen. KAIT schließlich richtet sich an Kapitalverwaltungsgesellschaften und Investmentvermögen; es ergänzt die bereits etablierten aufsichtsrechtlichen Erwartungen an Organisation, Auslagerung und Risikosteuerung im KVG-Kosmos. Drei Sektoren, ein gemeinsamer Anspruch: IT nicht als Technikinsel, sondern als integralen Bestandteil der Gesamtsteuerung zu verstehen.

Gemeinsame DNA: Was alle xAITs verlangen – unabhängig vom Sektor

Beginnt man mit der Struktur, wirken die Parallelen sofort vertraut. Alle drei Regelwerke zeichnen – in leicht unterschiedlicher Terminologie – dieselbe Landkarte ab: IT-Strategie und Governance, IKT-Risikomanagement, Informationssicherheitsmanagement, Benutzer- und Berechtigungsmanagement, Entwicklung und Veränderungsprozesse, IT-Betrieb inklusive Notfallvorsorge, sowie Auslagerungen und sonstiger Fremdbezug von IT-Dienstleistungen. Diese Kapitel stehen nicht zufällig nebeneinander. Sie beschreiben eine Prozesskette, die sich von der Zielsetzung des Managements über die konkrete Steuerung operativer Risiken bis zur Nachweisführung in Prüfung und Aufsicht spannt.

Im Kern fordern die xAITs zunächst Verantwortlichkeit. Das Leitungsorgan soll die IT-Strategie billigen, die Zielarchitektur kennen, Risikoappetit und Kontrollambitionen festlegen und regelmäßig überprüfen, ob Anspruch und Wirklichkeit zusammenpassen. Daraus folgt zweitens ein formales, gelebtes IKT-Risikomanagement: identifizieren, bewerten, steuern, beobachten – und zwar nachvollziehbar. Drittens verlangen die xAITs eine strukturierte Informationssicherheit, nicht als Produktkauf, sondern als Managementsystem mit Rollen, Prozessen und Metriken. Viertens müssen Berechtigungen beherrscht werden – von der Vergabe bis zum Entzug, inklusive Notfall- und privilegierter Zugriffe. Fünftens stehen Änderungen im Fokus: Projekte, Releases, Parametrisierung – alles braucht definierte Gateways, Tests, Freigaben, Rückfalloptionen. Sechstens gilt: Betrieb ist mehr als „läuft schon“. Es geht um Monitoring, Kapazität, Datenintegrität, Backup, Wiederanlauf, um geprobte Notfallmechanismen und dokumentierte Wiederherstellbarkeit. Und siebtens: Wer Leistungen fremd bezieht, steuert nicht weniger, sondern anders – über Auswahl, Vertragsgestaltung, laufendes Monitoring und realistische Exit-Strategien.

Diese gemeinsame DNA ist kein Zufall. Sie bildet die minimalen Bausteine, aus denen sich jedes tragfähige IT-Steuerungsmodell zusammensetzen muss. Wer in einem Sektor reif ist, erkennt das Muster im anderen wieder. Genau das ist die Stärke der xAITs: Sie geben über Branchen hinweg ein gleiches Vokabular, vergleichbare Erwartungshorizonte und kompatible Prüfpfade vor.

Proportionalität und Risikobasierung: Das Maß der Dinge

Trotz einheitlicher Landkarte sind die xAITs keine Schablonen. Alle drei betonen, dass Umfang und Tiefe der Umsetzung am Risikoprofil auszurichten sind. Ein kleiner, regionaler Player mit hohem Standardisierungsgrad braucht eine andere Ausgestaltung als ein institutsübergreifender Anbieter mit kritischer Marktinfrastruktur oder eine KVG mit komplexen Auslagerungsketten. „Proportionalität“ ist hier kein Freibrief zum Weglassen, sondern die Aufforderung, die richtigen Schwerpunkte zu setzen: Wo entstehen die größten Schäden bei Ausfall oder Manipulation? Welche Prozesse tragen die höchste Verantwortung gegenüber Kunden, Märkten und Aufsicht? Welche Lieferketten bergen Konzentrationsrisiken? Wer darauf belastbare Antworten hat, darf Tiefe und Taktung differenzieren – wer sie nicht hat, wird in der Prüfung Schwierigkeiten bekommen.

Informationssicherheit: Vom Richtlinienskelett zum gelebten System

Alle xAITs verlangen ein Informationssicherheitsmanagementsystem mit klarer Verankerung im Haus. Im Zentrum steht ein Sicherheitsbeauftragter beziehungsweise eine Sicherheitsorganisation mit ausreichend Unabhängigkeit, klaren Mandaten und adäquater personeller Ausstattung. Das System muss Schutzbedarfe ermitteln, Risiken bewerten, Maßnahmen planen, Wirksamkeit messen und regelmäßig berichten. Es muss die bekannten Kernprozesse abdecken: Richtlinienwerk, Schulung und Sensibilisierung, Asset- und Schwachstellenmanagement, Patch- und Vulnerability-Prozesse, Logging und Monitoring, Security Incident Handling, Notfallmanagement mit Wiederanlaufszenarien und geprobter Datenwiederherstellung. Die xAITs verlangen übergreifend, dass Sicherheit in Projekte und Beschaffung hineinreicht, nicht nur im Betrieb nachsorgt; sie verlangen, dass die zweite Verteidigungslinie prüfen und fordern kann und dass die interne Revision die Wirksamkeit des Systems in vertretbaren Abständen bewertet. Gemeinsam ist ihnen auch die Erwartung, dass Kennzahlen zur Steuerung genutzt werden: Erkennungs- und Wiederherstellungszeiten, Patch-Alter, Integritätsnachweise, Abdeckungsgrade von Kontrollen – Zahlen, die ein Managementgespräch über den Status der Sicherheitslage überhaupt erst ermöglichen.

Identitäten und Zugriffe: Der stete Klassiker – mit mehr Tiefe als früher

Berechtigungen gehören zu den ältesten Aufsichtsthemen, aber die xAITs schärfen sie nach. Gefordert werden belastbare Rollen- und Berechtigungskonzepte, die Funktionstrennungen ebenso abbilden wie der Grundsatz „so wenig wie möglich, so viel wie nötig“. Wiederkehrende Rezertifizierungen, ein End-to-End-Prozess vom Eintritt bis zum Austritt, Notfall- und Privilegienkontrollen sowie technische Durchsetzung stehen im Vordergrund. Es reicht nicht, dass ein Prozess existiert; er muss Audit-Spuren hinterlassen. Gerade in heterogenen Landschaften mit Legacy, Standardsoftware, Eigenentwicklung und Cloud-Services entscheidet sich hier, ob Governance wirklich wirkt: Prozesse ohne Systemkopplung, „Sonderrechte“ ohne Journal, Admin-Konten ohne Jump-Server – das sind die Muster, an denen Prüfungen regelmäßig ansetzen.

Entwicklung, Änderungen, Betrieb: Von der Idee bis zur Wiederherstellung

Die xAITs verbinden Projektmanagement, Software Lifecycle und Betrieb. Wer entwickelt oder parametrisiert, muss Qualitätssicherung und Freigabeprozesse betreiben; wer in Produktion bringt, muss im Störungsfall handlungsfähig sein. Release-Management, Änderungsfenster, Trennung von Entwicklung, Test und Produktion, definierte Rückfallpläne, reproduzierbare Builds, nachvollziehbare Konfigurationen – das gehört in allen drei Regelwerken zum Standardrepertoire. Ebenso klar: Backups sind nur so gut, wie ihre Wiederherstellung geprobt wurde. Daher verlangen die xAITs nicht bloß „Backups vorhanden“, sondern nachweisliche Restore-Tests mit Integritätsbelegen, die über bloße Dateiwiederherstellung hinausgehen. Und sie verlangen Notfallkonzepte, die auch die organisatorische Seite adressieren: Kommunikation, Eskalation, Entscheidungswege, Ersatzprozesse. Ein Notfallordner ist kein Backup-Tape; beides wird gebraucht – geübt, nicht nur beschrieben.

Auslagerung und Fremdbezug: Steuerung statt Blindflug

Der vielleicht sensibelste gemeinsame Block ist der Umgang mit Dienstleistern und Lieferketten. Hier verlangen die xAITs eine konsequente Vorfeldprüfung, klare Verträge und ein laufendes, risikoorientiertes Monitoring. Dazu zählen Transparenz über Subdienstleister, Informations- und Prüfungsrechte, Sicherheitsanforderungen einschließlich Meldepflichten bei Vorfällen, Regelungen zu Datenstandorten, Exit-Klauseln und – wo angemessen – Escrow-Mechanismen oder Portabilitätskonzepte. Wichtig ist die Unterscheidung zwischen Auslagerung im engeren Sinne und „sonstigem Fremdbezug“; beide müssen gesteuert werden, aber die Tiefe der Anforderungen ist eine Frage der Wesentlichkeit. Gemeinsam ist den xAITs außerdem die Forderung, ein aktuelles und vollständiges Register aller wesentlichen Fremdbezüge zu führen – mit Bewertungs- und Überwachungsergebnissen, die in die Risikosteuerung zurückspielen.

Wo die Wege sich trennen: Drei Sektoren, drei Logiken

Bis hierher war viel Gemeinsamkeit. Doch die xAITs sind keine Kopien, sondern konsequent in ihren Sektor gedacht. Das beginnt mit der Einbettung in die jeweilige Governance- und Risikowelt.

Bei Banken orientiert sich BAIT eng an den MaRisk. Das Leitungsorgan soll die IT-Strategie im Rahmen des Gesamtbanksteuerungsmodells verankern; Risiken aus IT sind in den Risikoinventuren sichtbar zu machen; die Verzahnung mit Notfall- und Auslagerungsmanagement ist Pflicht. Wo Banken spezifische Markt-Infrastrukturen oder Zahlungsverkehrsschnittstellen betreiben, zieht die Aufsicht die Zügel enger: Fristen, Meldewege, Testtaktungen, Dokumentationsgüte – hier steigen Anspruch und Nachweisdichte. Die europäische Bankenaufsicht wirkt ergänzend durch Leitlinien zu Outsourcing und zu IKT- und Sicherheitsrisiken; BAIT und diese Leitlinien sind in der Sache kompatibel, weichen aber im Zuschnitt gelegentlich voneinander ab. Erwartet wird, dass Institute diese Ebenen sauber aufeinander abbilden.

VAIT folgt derselben Systematik, aber die Sprache der Versicherer macht sich bemerkbar. Governance, Risikoprozesse, Berichterstattung – alles muss mit dem versicherungsspezifischen Steuerungsverständnis harmonieren. Die Einbindung der IT in das unternehmensindividuelle Risikoprofil, die Schnittstellen zu Solvency-II-Prozessen, die Rolle der Schlüssel- und Querschnittsfunktionen: Hier liegen die Akzente ein wenig anders als im Bankenumfeld. Themen wie aktuarielles Berichtswesen, Bestands- und Leistungsprozesse oder die Langfristigkeit von Datenhaltungen bringen eigene Anforderungen an Integrität, Nachvollziehbarkeit und Archivierung mit sich. Wer kurze Innovationszyklen aus dem Digitalvertrieb mit jahrzehntelangen Aufbewahrungspflichten zusammenbringen muss, spürt die Besonderheit der VAIT unmittelbar im Betrieb.

KAIT schließt die Lücke für Kapitalverwaltungsgesellschaften und Investmentvermögen. Auch hier ist der Grundaufbau vertraut, aber die Domänenlogik ist eine andere. Portfolio-Management-Systeme, Bewertungs- und Risikomessverfahren, Anbindung an Verwahrstellen, Order- und Abwicklungswege, Melde- und Berichtspflichten – diese Kette bestimmt, was als „kritisch“ einzustufen ist und welche Kontrollen zwingend in hoher Qualität nachzuweisen sind. Auslagerungsketten sind in dieser Welt häufig tief und international; die Notwendigkeit, Subdienstleister transparent zu machen und Exit-Fähigkeit zu sichern, ist entsprechend hoch. Ein KAIT-Prüfpfad wird immer wieder bei denselben Fragen landen: Wo entstehen Bewertungs- und Abwicklungsrisiken? Wie stellen Sie sicher, dass Parametrisierungen – im Systemportfolio wie in der Risikomessung – nachvollziehbar, freigegeben, getestet und dokumentiert sind? Und wie zeigen Sie das?

Unterschiedliche Wertungen bei „Wesentlichkeit“ und „Kritikalität“

Ein zweiter Trennstrich verläuft in der Einschätzung, was als „wesentlich“ oder „kritisch“ zu werten ist. Banken messen das naturgemäß an Zahlungsverkehr, Handel, Kernbankprozessen, Meldewesen; Versicherer an Bestands- und Leistungsprozessen, Schaden/Leistung, Produktverwaltung, aktuariellen Bewertungen; KVGs an Handel, Bewertung, Verwahrung, Abwicklung. Diese Sektorlogik hat unmittelbare Folgen: Für wen sind welche Wiederanlaufzeiten realistisch? Wo ist ein Test halbjährlich, wo jährlich, wo nur szenariobasiert? Welche Lieferanten bekommen die höchste Aufmerksamkeit? Wer hier die falschen Maßstäbe setzt, verteilt Prüf- und Steuerungsressourcen an der falschen Stelle.

Governance-Nuancen: Funktionen, Mandate, Unabhängigkeit

Die xAITs wollen keine Schaubilder, sondern gelebte Governance. Gleichwohl unterscheiden sie sich in Nuancen. In Banken wird die Rolle des Informationssicherheitsbeauftragten mit deutlichem Unabhängigkeitsanspruch gezeichnet; daneben wird eine robuste zweite Linie erwartet, die IT- und Sicherheitsrisiken eigenständig bewertet. In Versicherungen spielt die Einordnung in das Gefüge der Schlüsselfunktionen eine größere Rolle; hier ist erklärungsbedürftig, wie die Sicherheitsorganisation mit Risiko, Compliance, Interner Revision und Aktuariat arbeitet, ohne in Interessenkonflikte zu geraten. Im KVG-Umfeld schließlich steht die Frage im Raum, wie die IT- und Sicherheitsfunktion in die Prozesse mit Verwahrstellen und Auslagerungsunternehmen eingebunden ist, ohne Verantwortung zu verwischen. Allen gemeinsam: Mandat, Ressourcen, Eskalationsrecht – und die Pflicht, regelmäßig und adressatengerecht zu berichten.

Cloud und Lieferketten: Nicht „ob“, sondern „wie“

Alle drei Regelwerke sind technologieagnostisch, aber die Realität heißt längst Cloud. Die xAITs verlangen nicht den Verzicht, sondern die Steuerungsfähigkeit: Datenlokationen kennen und bewerten, klare Informations- und Prüfungsrechte vereinbaren, Notfall- und Exit-Szenarien testen, Nutzungskonzepte risikoadäquat gestalten. Dazu gehört ein nüchterner Blick auf Konzentrationsrisiken. Eine Multi-Region-Architektur ist mehr als ein Marketingversprechen; sie muss im Ernstfall schalten, nicht nur in PowerPoint glänzen. Ebenso gilt: Ein Backup, das in derselben Cloud, Verfügbarkeitszone oder bei demselben Provider liegt, ist kein Backup, sondern ein Spiegel. Die xAITs verordnen das nicht im Techniksatz, aber jede Prüfung fragt nach dem Ergebnis: Wie schnell und wie integer können Sie wiederanlaufen – und womit belegen Sie das?

Schnittstellen zu ISO- und BSI-Welt: Synergie mit Stolperfallen

Viele Häuser bringen ISO-27001- oder BSI-Grundschutz-Erfahrung mit. Das hilft – wenn man die Brücke korrekt baut. ISO liefert ein gutes Managementraster, die xAITs liefern die fach- und aufsichtsnahe Ausgestaltung. Wer ISO-Prozesse unverändert in die xAIT-Welt kippt, übersieht leicht ein paar Stolperstellen: die Verzahnung mit Auslagerungs- und Notfallregimen, die geforderte Kohärenz zwischen Risikoregister, Vorfallhistorie und Testergebnissen, die Erwartung, systemsourced Evidenzen statt manuell kuratierter Listen zu zeigen. Umgekehrt gilt: Wer xAIT ohne ISO-Disziplin lebt, verliert die Systematik. Die Kunst liegt im Mapping – mit klarer Verantwortlichkeit dafür, dass die Modelle zusammenpassen.

Was in Prüfungen zählt: Wirksamkeit statt Papier

Prüfungen nach xAIT sind keine Literaturwettbewerbe. Erwartet werden nachvollziehbare, belastbare, aktuelle Nachweise, dass Kontrollen nicht nur gedacht, sondern getan werden – nicht einmal, sondern als Routine. Wer Risiken benennt, zeigt Kontrollen und Kennzahlen. Wer Notfall kann, zeigt gemessene Wiederanläufe, nicht nur Kaskadendiagramme. Wer Auslagerungen steuert, zeigt Scorecards, Auditergebnisse, Vertragsnachträge, Exit-Proben. Wer Informationssicherheit führt, zeigt Schutzbedarfsentscheidungen, Use-Case-Abdeckung in Monitoring und Detektion, Schwachstellen- und Patch-Prozesse mit Alterskennzahlen und Remediation-Nachweisen. Das ist der gemeinsame Nenner aller xAIT-Prüfpfade – und er trennt gelebte Governance von Schaufenster-Compliance.

Typische Schwachstellen – und wie man ihnen begegnet

In der Praxis tauchen ähnliche Muster auf. Häufig fehlen konsistente Verknüpfungen: Das Risikoregister erzählt eine andere Geschichte als die Testberichte; die Incident-Chronik widerspricht den Meldeprozessen; das Auslagerungsregister ist veraltet; Berechtigungen werden zwar vergeben, aber selten entzogen; Backups existieren, aber die Integrität des Restores wurde nie auf Anwendungsebene geprobt. Das Heilmittel ist nie die große Geste, sondern konsequente Routine: definierte Änderungstrigger für Register, monatliche Evidenz-Tage, quartalsweise Kohärenz-Reviews, jährliche Probe-Audits mit echter Stichprobenmethodik. Wer diese Handgriffe institutionalisiert, muss vor einer xAIT-Prüfung nichts inszenieren – er öffnet seine Systeme und zeigt, was jeden Tag passiert.

Proportionalität leben: Drei skizzierte Szenarien

Ein kleines Institut mit hohem SaaS-Anteil braucht keine Armada an Eigenentwicklungskontrollen, wohl aber scharfe Auslagerungs- und Berechtigungsprozesse, klare Meldewege, getestete Datenportabilität und eine knackige Notfallorganisation mit verlässlichen Wiederanlaufzielen. Ein Versicherer mit hybrider Landschaft wird den Fokus auf Schnittstellen-Integrität, Daten-Langzeithaltbarkeit, Identität und Funktionstrennung legen – hier werden Restore-Integritätsnachweise und szenariobasierte Übungen den Ausschlag geben. Eine KVG schließlich wird eine Auslagerungstiefe beherrschen müssen, die andere Sektoren selten sehen: Transparenz bis in Sub-Prozessoren, Portfolio- und Bewertungslogik nachvollziehbar dokumentiert und freigegeben, Exit-Fähigkeit nicht nur beschrieben, sondern geübt. In allen drei Fällen gilt: Proportionalität heißt nicht weniger Arbeit, sondern die richtige.

Warum die xAITs mehr sind als „noch ein Regelwerk“

Die xAITs haben den Nebeneffekt, interne Silos aufzubrechen. IT- und Nicht-IT-Welt müssen sich auf ein gemeinsames Modell verständigen, Datenhaushalte werden bereinigt, Verantwortlichkeiten geschärft, Metriken professionalisiert. Wer das ernsthaft betreibt, gewinnt nicht nur Prüf- und Aufsichtsruhe, sondern echte Steuerungsfähigkeit: Planbarkeit im Change, Stabilität im Betrieb, schnellere Wiederherstellung im Notfall, bessere Verhandlungslage gegenüber Dienstleistern. Das ist kein Beiwerk, sondern gerade im Wettbewerb relevant: Verfügbarkeit, Integrität, Sicherheit und Portabilität sind längst Kaufargumente – nicht nur für Endkunden, sondern auch in B2B-Ketten.

Ein pragmatischer Blick nach vorn

Wie also umgehen mit BAIT, VAIT und KAIT? Der nüchterne Rat lautet: die Gemeinsamkeiten als Grundgerüst nutzen, die sektorspezifischen Nuancen ernst nehmen, und alles auf die eigene Landschaft mappen. Ohne vollständiges Inventar kritischer Prozesse und IT-Assets, ohne belastbare Schutzbedarfsfeststellung und ohne klare Bewertungen von Auslagerungen lässt sich kein xAIT sinnvoll leben. Ohne geprobte Notfallmechanik, ohne belastbare Evidenzen und ohne regelmäßige Kohärenz-Checks bleibt es bei Papier. Und ohne eine Mindestautomatisierung – bei Berechtigungen, Konfigurationsdrift, Vulnerabilities, Backups, Telemetrie aus Lieferantenbeziehungen – wird die Organisation unter der Last der Nachweise ächzen.

Die gute Nachricht: Das Zielbild ist erreichbar. Die xAITs schreiben kein Ideal jenseits der Praxis vor. Sie beschreiben, was ein reifer Betrieb ohnehin tun sollte – nur eben sichtbar, konsistent und auskunftsfähig. Wer das innere System findet, statt äußeren Listen hinterherzulaufen, wird merken, dass BAIT, VAIT und KAIT nicht drei Pfade sind, die man separat rennen muss, sondern eine breite Straße, die man mit unterschiedlichen Spuren befährt. Gemeinsame Leitplanken, klare Verkehrsregeln, sektorabhängige Vorfahrten – und am Ende zählt, dass alle heil ankommen: mit beherrschten Risiken, resilienter IT und der Fähigkeit, das zu zeigen. Genau darum geht es den xAITs. Und deshalb lohnt es sich, sie nicht als Hürde zu lesen, sondern als Betriebsanleitung für den eigenen, stabilen Kurs.