Power-Automate, Access, Python-Skripte: Die Schatten-IT, die jede BaFin-Prüfung sprengt

Die Anwendung, die niemand in der Liste hatte

Individuelle Datenverarbeitung ist in der Finanzwirtschaft allgegenwärtig, von Power-Automate-Abläufen über Access-Datenbanken bis zu Skripten im Risikomanagement. Diese Werkzeuge entstehen, weil sie ein echtes Problem lösen, das die zentrale IT nicht schnell genug bedient. Sie sind produktiv, hilfreich und meistens unsichtbar, bis eine Prüfung nach ihnen fragt.

Selbstgebaute Fachbereichsanwendungen verschwinden nicht durch ein Verbot, sondern nur aus dem Blickfeld; beherrschbar werden sie erst, wenn sie erfasst, nach Risiko eingestuft und kontrolliert zugelassen werden. Dieser dritte Weg zwischen Verbot und Wegsehen bringt Prüfungssicherheit und zeigt nebenbei, wo Prozesse und IT nachziehen sollten.

Was die Aufsicht unter individueller Datenverarbeitung versteht

Individuelle Datenverarbeitung, kurz IDV, meint Anwendungen, die Mitarbeitende in den Fachbereichen selbst entwickeln oder betreiben. Die MaRisk der BaFin (Rundschreiben 05/2023, AT 7.2 Textziffer 5) stellen klar, dass die Anforderungen an IT-Systeme auch für solche Anwendungen gelten, und zwar entsprechend der Kritikalität der unterstützten Geschäftsprozesse; der Schutzbedarf der verarbeiteten Daten bestimmt die nötigen Sicherheitsmaßnahmen.

Mit DORA, der europäischen Verordnung über die digitale operationale Resilienz, kommt seit dem 17. Januar 2025 die Pflicht hinzu, IKT-Assets vollständig zu identifizieren und zu inventarisieren. Die bisherigen Rundschreiben zu IT-Anforderungen werden dabei abgelöst, die BAIT schrittweise bis Ende 2026. Für die Frage, ob eine Anwendung als IDV gilt, beschreibt KPMG einen einfachen Entscheidungsbaum mit vier Merkmalen: Entwicklung und Betrieb durch Endnutzer, Verarbeitung von Daten, Einbindung in einen Geschäftsprozess und regelmäßige Nutzung. Treffen alle vier Merkmale zu, gehört die Anwendung ins Register.

Warum individuelle Datenverarbeitung überhaupt entsteht

Die Ursache verdient mehr Aufmerksamkeit als das Symptom. IDV entsteht nicht aus Nachlässigkeit, sondern aus Bedarf: Ein Fachbereich braucht eine Auswertung, eine Verknüpfung oder eine Automatisierung, die zentrale IT kann sie nicht rechtzeitig liefern, also baut sich der Bereich die Lösung selbst.

Diese Werkzeuge sind oft erstaunlich leistungsfähig und tief in die täglichen Abläufe eingewachsen. Eine Access-Datenbank liefert seit Jahren eine kritische Auswertung, ein Skript übernimmt eine Berechnung im Risikomanagement. Sie sind so nützlich, dass niemand sie hinterfragt, und so selbstverständlich, dass niemand sie meldet. Hängt eine kritische Auswertung an einer Logik, die nur eine Person versteht, ist das Institut verwundbar: Fällt die Person aus, fällt die Anwendung aus, und ein Fehler in der Logik pflanzt sich unbemerkt fort.

Warum helfen weder Verbot noch Wegsehen?

Ein Verbot treibt die Werkzeuge in den Untergrund, und Wegsehen lässt die Risiken bestehen. Wird IDV untersagt, bauen die Fachbereiche ihre Lösungen trotzdem weiter, melden sie aber erst recht nicht mehr. Aus einer sichtbaren Schatten-IT wird eine unsichtbare, und das Risiko steigt, statt zu sinken.

Gewährenlassen ist das andere Extrem, weil die Werkzeuge ja funktionieren und das Aufräumen mühsam wäre. Eine unvollständige IDV-Liste fällt aber spätestens in der nächsten Prüfung auf, und unabhängig davon gefährden undokumentierte Anwendungen mit kritischen Daten Datenqualität, Betriebsstabilität und Sicherheit.

Wie sieht kontrolliertes Ermöglichen konkret aus?

Kontrolliertes Ermöglichen heißt: Der Fachbereich darf seine Lösung bauen, aber sie wird erfasst, eingestuft, dokumentiert und ihrem Risiko entsprechend kontrolliert. Drei Schritte tragen diesen Weg.

Der erste Schritt ist eine ehrliche Bestandsaufnahme ohne Drohung. Solange die Fachbereiche fürchten, dass eine Meldung zum Verbot führt, wird nichts gemeldet. Erst wenn klar ist, dass Kontrolle und nicht Abschaffung das Ziel ist, kommen die Anwendungen ans Licht.

Der zweite Schritt ist die Risikoklassifizierung. Eine kleine Auswertung ohne Einfluss auf wichtige Entscheidungen braucht weniger Kontrolle als ein Skript, das in eine regulatorisch relevante Berechnung eingeht. Die Klassifizierung lenkt die begrenzten Kontrollressourcen dorthin, wo das Risiko am größten ist.

Der dritte Schritt stellt für die kritischen Anwendungen die nötige Kontrolle her: dokumentierte Logik, geregelte Zugriffe, Absicherung gegen Ausfall und, wo sinnvoll, die Überführung in die zentrale IT. So wird aus einer riskanten Schatten-IT eine kontrollierte Anwendungslandschaft, ohne den Bedarf der Fachbereiche zu unterdrücken. Wie ein vollständiges Inventar mit dem Modellrisikomanagement zusammenhängt, zeigt der Beitrag zu den KI-Anforderungen der MaRisk-Novelle.

Was ändert sich durch KI-Werkzeuge in den Fachbereichen?

KI-Werkzeuge machen individuelle Datenverarbeitung leichter zu bauen und schwerer zu überblicken. Wo früher eine Access-Datenbank entstand, entstehen heute KI-gestützte Abläufe, die Daten aggregieren, Texte erzeugen oder Entscheidungen vorbereiten. Ein KI-Assistent, der täglich Daten zusammenführt, rechnet und Ergebnisse in operative Prozesse überträgt, erfüllt nach einer Einordnung von KPMG potenziell alle vier IDV-Merkmale; ein reines Recherchewerkzeug in der Regel nicht.

Damit verschmelzen IDV und Schatten-KI. Gibt jemand vertrauliche Daten in ein nicht freigegebenes KI-Werkzeug ein, entsteht ein Risiko, das über die klassische Schatten-IT hinausgeht. Beide gehören in denselben kontrollierten Rahmen. Was die BaFin-Orientierungshilfe zu KI unter DORA dazu erwartet, beschreibt der Beitrag „KI unter DORA“.

Warum Prüfung und Fachbereich aneinander vorbeireden

Eine Prüfung fragt nicht, ob eine Anwendung nützlich ist, sondern ob sie erfasst, eingestuft, dokumentiert und kontrolliert ist. Eine hilfreiche Access-Datenbank, die in keiner Liste steht, ist aus Sicht der Prüfung ein Mangel, ganz gleich, wie wertvoll sie für den Fachbereich ist. Aus Sicht des Fachbereichs wurde dagegen ein Problem gelöst. Diese Diskrepanz lässt sich nur auflösen, wenn das Institut beides verbindet: den Nutzen anerkennen und zugleich die Kontrolle herstellen.

Ein lebendiger Prozess, kein einmaliges Aufräumprojekt

IDV wächst ständig nach, weil ständig neue Bedarfe entstehen. Eine Liste, die heute vollständig ist, ist in einem Jahr wieder lückenhaft, wenn der Prozess nicht lebt. Gebraucht wird deshalb eine Routine, die neue Anwendungen erfasst, sobald sie entstehen, und den Bestand regelmäßig überprüft, mit den Fachbereichen als Beteiligten statt als Beschuldigten. Wer die Lücken im DORA-Informationsregister kennt, erkennt das Muster wieder, wie der Beitrag zum DORA-Register zeigt.

Langfristig ist die beste Antwort, den Anlass zu verringern. Bedient die zentrale IT die Bedarfe der Fachbereiche schneller, entsteht weniger Druck, sich selbst zu behelfen. Ganz verschwinden muss IDV nicht; ein gewisses Maß an fachnaher Selbsthilfe ist gesund, solange sie kontrolliert geschieht und kritische Anwendungen den Weg in die zentrale IT finden. Richtig gehandhabt liefert IDV sogar die besten Hinweise darauf, wo Prozesse haken. Warum fehlende Governance das größere Risiko ist, ordnet der Beitrag zum BaFin-Risikobericht 2026 ein.

Was das Management jetzt veranlassen sollte

1. Eine Bestandsaufnahme ohne Sanktionsdrohung ausrufen und ausdrücklich zusagen, dass Meldung nicht Verbot bedeutet.

2. Die vier IDV-Merkmale als einfachen Test vorgeben, ausdrücklich auch für KI-Assistenten und automatisierte Abläufe.

3. Anwendungen nach Kritikalität einstufen und Kontrollaufwand entsprechend verteilen.

4. Für kritische Anwendungen Dokumentation, Zugriffe und Vertretung regeln oder die Überführung in die zentrale IT planen.

5. Einen laufenden Meldeweg einrichten, der neue Anwendungen erfasst, sobald sie entstehen.

Häufige Fragen

Was gilt als individuelle Datenverarbeitung?
Anwendungen, die Fachbereiche selbst entwickeln oder betreiben, die Daten verarbeiten, in einen Geschäftsprozess eingebunden sind und regelmäßig genutzt werden, etwa Access-Datenbanken, Makros, Skripte oder automatisierte Abläufe.

Gelten KI-Assistenten als IDV?
Es kommt auf den Einsatz an. Ein KI-Assistent, der regelmäßig Daten verarbeitet und Ergebnisse in Prozesse überträgt, kann alle Merkmale erfüllen; ein reines Recherchewerkzeug in der Regel nicht.

Sollte IDV grundsätzlich verboten werden?
Ein Verbot treibt Anwendungen erfahrungsgemäß aus dem Blickfeld. Wirksamer ist, sie zu erfassen, nach Risiko einzustufen und kontrolliert zuzulassen.

Weitere Beiträge zu DORA, KI-Verordnung und Aufsicht bündelt das Dossier Regulierung & Resilienz.

Wie viel individuelle Datenverarbeitung tatsächlich im Einsatz ist, zeigt sich meist erst, wenn die erste Meldung ohne Folgen bleibt. Wir freuen uns auf ein erstes Gespräch dazu.