Tausende Fachanwendungen, null Berechtigungskonzepte – IDV als DER blinde Fleck der DORA-Compliance

Individuelle Datenverarbeitung (IDV) ist in der Finanzwirtschaft allgegenwärtig – von Power-Automate-Flows über Access-Datenbanken bis hin zu Python-Skripten im Risikomanagement. Die BaFin hat wiederholt Verstöße festgestellt und macht IDV auch unter DORA zum Prüfungsgegenstand. Was viele Institute dabei übersehen: Diese Fachanwendungen erzeugen nicht nur Dokumentationsrisiken, sondern auch ein strukturelles Identity-Governance-Problem. Wer Zugriffe, Berechtigungen und SoD-Vorgaben für IDV-Anwendungen nicht systematisch steuert, riskiert regulatorische Feststellungen – und operative Schwachstellen.

von Dr. Heiko Klarl, Nexis

IDV ist mehr als Excel –
und größer als gedacht.“

IDV beschreibt Anwendungen, die außerhalb der zentralen IT-Organisation durch Fachabteilungen entwickelt und betrieben werden. Dazu zählen nicht nur makrogestützte Tabellenkalkulationen, sondern auch Low-Code-Applikationen auf Basis von Microsoft Power Platform, selbst entwickelte RPA-Prozesse, Access-Datenbanken oder Skripte in Python und R. In der Praxis entsteht so eine parallele Anwendungslandschaft, die operative Prozesse der Bank unmittelbar beeinflusst – von der Risikosteuerung über das Meldewesen bis zum Controlling.

Die Größenordnung ist erheblich: Einzelne Institute betreiben mehrere tausend solcher Anwendungen, oft mit Millionen von Formeln und Abhängigkeiten.“

Studien zeigen, dass 94 Prozent der für Geschäftsentscheidungen genutzten Tabellenkalkulationen Fehler enthalten. Die BaFin stellte bei Versicherern fest, dass 90 Prozent die VAIT-Anforderungen an IDV nur teilweise oder gar nicht erfüllen.

Zwei blinde Flecken, ein Risiko

IDV-Anwendungen erzeugen zwei Governance-Herausforderungen, die bisher häufig getrennt oder gar nicht adressiert werden.

Fehlende Sichtbarkeit: Die meisten IDV-Anwendungen existieren außerhalb der zentralen IAM-Landschaft. Sie haben eigene Benutzer, Konten und Zugriffsrechte, die von keinem IGA-System erfasst werden. Wer in einem Power-Automate-Flow administrative Rechte besitzt, wer Zugriff auf eine Access-Datenbank mit Kundendaten hat, wer ein Python-Skript zur Risikoberechnung verändern darf – all das bleibt für die zentrale IT unsichtbar und erfüllt häufig keine zentralen Sicherheitsvorgaben. Aus Identity-Governance-Sicht ist das Schatten-IT mit unkontrollierten Zugriffspfaden.

Fehlende Berechtigungskonzepte: Unter DORA und den noch übergangsweise geltenden BAIT müssen für jede Anwendung mit regulatorischer Relevanz Berechtigungskonzepte dokumentiert sein – inklusive Rollenmodell, Kritikalitätseinstufung, SoD-Vorgaben und Rezertifizierungszyklen. Für zentral betriebene Applikationen ist dies in vielen Häusern zumindest in Grundzügen etabliert. Für IDV-Anwendungen existieren diese Konzepte in der Regel nicht. Der Grund: Sie wurden nie in einen strukturierten Onboarding- und Governance-Prozess einbezogen.

Wer nichts sieht, kann nichts steuern

Der erste Schritt zur Beherrschung des IDV-Risikos liegt in der systematischen Anbindung dieser Anwendungen an eine zentrale Governance-Plattform. Technisch bedeutet das: Identitäten, Konten und Berechtigungen aus IDV-Anwendungen werden über standardisierte Konnektoren oder API-basierte Sideload-Mechanismen in ein übergreifendes Datenmodell überführt.

Das Ziel ist nicht bloß Inventarisierung, sondern Observability: Nicht nur wissen, dass Anwendungen existieren, sondern verstehen, wer mit welchen Rechten darauf zugreift, ob diese Rechte tatsächlich genutzt werden und ob sie mit den organisatorischen Vorgaben übereinstimmen.“

Durch die Korrelation von HR-Stammdaten, technischen Konten und tatsächlichem Nutzungsverhalten lassen sich Anomalien erkennen – etwa verwaiste Konten nach Personalwechseln, überhöhte Berechtigungen oder SoD-Konflikte, die erst durch die systemübergreifende Betrachtung sichtbar werden.
Dieser Ansatz geht über klassisches IAM hinaus. Eine Governance-Schicht, die über fragmentierte IAM-Landschaften gelegt wird, stellt Steuerungsfähigkeit her – unabhängig davon, ob die angebundene Anwendung ein SAP-System, ein Cloud-Service oder eine fachbereichseigene Low-Code-Applikation ist.

Vom Blindflug zum Berechtigungskonzept

Der Gewinn entsteht, wenn die gewonnene Sichtbarkeit direkt in strukturierte Berechtigungskonzepte überführt wird. Die Daten, die bei der Integration erhoben werden – Rollen, Berechtigungen, Kritikalitätsstufen, Nutzungsmuster und Verantwortlichkeiten – bilden die Grundlage für ein vollständiges Berechtigungskonzept gemäß den regulatorischen Anforderungen.
Der technische Ablauf folgt einem strukturierten Onboarding-Prozess: Über template-basierte Erfassung definieren Application Owner die regulatorisch geforderten Inhalte – Risikoklassifikation, Rollenstruktur, SoD-Constraints, Rezertifizierungs­intervalle.

KI-gestützte Verfahren können diesen Prozess beschleunigen, indem sie vorhandene Dokumentation (Fachkonzepte, User Stories, Confluence-Seiten) auswerten und das Berechtigungskonzept automatisch vorbefüllen.“

Nach Freigabe fließen die definierten Berechtigungsstrukturen direkt in die entsprechende Applikation oder das verwendete Werkzeug zurück. Das Ergebnis: Aus der IDV-Anwendung, die bislang außerhalb jeder Governance existierte, wird eine regulatorisch dokumentierte und kontinuierlich überwachte Applikation.

Berechtigungskonzepte veralten am Tag ihrer Freigabe

Dokumentation allein genügt nicht. Die  Schwachstelle klassischer Berechtigungskonzepte ist der Drift zwischen dem definierten Soll-Zustand und der technischen Realität. Rollen werden informell erweitert, Berechtigungen nicht entzogen, Ausnahmen werden zur Regel.
Continuous Drift Detection adressiert genau dieses Problem. Die Plattform vergleicht den dokumentierten Soll-Zustand des Berechtigungskonzepts kontinuierlich mit den tatsächlichen Systemkonfigurationen. Abweichungen lösen Validierungswarnungen aus und stoßen definierte Follow-up-Aktionen an – von der Benachrichtigung des Application Owners bis zur automatisierten Bereinigung.

Das Prinzip: Das System lernt, wie der korrekte Zustand aussieht, und erkennt Abweichungen in Echtzeit.“

Für die Revision bedeutet das: Berechtigungskonzepte sind keine statischen Dokumente mehr, die einmal jährlich aktualisiert werden, sondern lebende Governance-Artefakte mit vollständiger Versionshistorie und zeitstempelbasierter Nachvollziehbarkeit.

IDV gehört nicht verboten – sondern eingebunden

Die DORA-Verordnung hat die nationalen Regelwerke KAIT, VAIT und ZAIT bereits abgelöst. Die BAIT werden bis Ende 2026 schrittweise aufgehoben. Auch wenn DORA IDV nicht explizit adressiert, hält die BaFin in ihren Umsetzungshinweisen fest: Die Anforderungen bestehen implizit fort – und die Prüfungstiefe könnte zunehmen.
Für Finanzinstitute bedeutet das: IDV-Anwendungen müssen aus dem Schatten der Fachabteilungen in die zentrale Governance überführt werden. Der Weg dorthin führt über Integration, Sichtbarkeit und strukturierte Berechtigungskonzepte – nicht über das Verbot von Fachanwendungen, sondern über deren kontrollierte Einbindung in die Identity-Governance-Architektur des Unternehmens. Dr. Heiko Klarl, Nexis