Der Datenkern: Wie bedient ein Inventar DORA, NISG, SREP und KI-Verordnung?

Redaktionell geprüft: 22. Oktober 2026 · Rechtslage geprüft bis: 22. Oktober 2026. Zeitgebundene Aussagen sind datiert; angekündigte, aber noch nicht veröffentlichte Rechtsakte sind als solche gekennzeichnet.

Für wen: Banken (SI) Banken (LSI) Versicherungen Meldewesen-Dienstleister Die Datenkern-Architektur gilt für Banken und Versicherer gleichermaßen; die rechtlichen Bezüge auf SREP und RDARR betreffen Banken.

Die Kernthese in einem Satz: Ein vollständiges, aktuelles und verantwortlich zugeordnetes Verzeichnis der Bestände – IKT-Assets, Datenattribute, kritische Funktionen, Dienstleisterverträge und KI-Anwendungsfälle, verknüpft über eindeutige Kennungen – speist das IKT-Bestandsverzeichnis nach Art. 8 DORA, das Informationsregister nach Art. 28 Abs. 3 DORA, die Perimeterfrage des NISG 2026, die ab 2027 im SREP bewertete Datenfähigkeit und die Datenanforderungen des Art. 10 KI-VO. Es erfüllt diese Pflichten nicht – die jeweiligen Sichten, Datenfelder, Qualitätskontrollen und vor allem die gesetzlichen Einstufungen bleiben eigenständig –, aber es verhindert, dass dieselbe Erhebung viermal stattfindet. Kurz: gemeinsames Inventar, getrennte regulatorische Entscheidungen.

Welchen gemeinsamen Befund sieht die Aufsicht?

Die EZB hat aus ihrer Vor-Ort-Kampagne 2022 bis 2024, dem Targeted Review 2024 und dem jährlichen Management Report drei Mängelcluster destilliert: lückenhafte Data Governance, nicht zweckmäßige Dateninfrastruktur und IT-Architektur, mangelhafte Datengenauigkeit und -integrität. Zwei Detailbefunde sind für diese Seite entscheidend: Der Data-Governance-Rahmen deckt bestimmte wesentliche Risiken nicht ab, und die Kriterien zur Bestimmung wesentlicher Rechtseinheiten sind vage; in der IT-Risikoerhebung erwies sich das IT-Datenqualitätsmanagement als die am wenigsten ausgereifte Domäne. Beide Befunde sind nicht auf die Risikoberichterstattung beschränkt – ein Institut, das seinen Anwendungsbereich nicht sauber abgrenzen kann, hat dieses Problem auch bei kritischen Funktionen nach DORA, beim NIS2-Perimeter und bei der Klassifizierung seiner KI-Anwendungsfälle.

Die Aufsicht hat die Verbindung inzwischen selbst hergestellt. EBA/GL/2026/06 führt DORA-Materie und Risikodatenaggregation ab 1. Jänner 2027 in einem SREP-Abschnitt zusammen, und die EZB-Aufsichtsprioritäten 2026–2028 führen Risikodatenaggregation, IKT-Resilienz und KI-Governance gemeinsam unter Priorität 2.

DORA: Warum ist das Informationsregister eine Datenqualitätsprüfung?

Das Informationsregister wird in der Praxis als Auslagerungsthema behandelt. Fachlich ist es eine strukturierte, maschinell validierte Meldung über Vertragsbeziehungen, Dienstleisterketten, Kritikalität und Substituierbarkeit – mit Pflichtfeldern, Fremdschlüsselbeziehungen und Identifikatorprüfungen. Die einzige quantifizierte Auswertung stammt aus dem Trockenlauf der ESAs 2024 mit 1.039 Finanzunternehmen aus 27 Mitgliedstaaten und 947 ausgewerteten Registern:

Der letzte Punkt ist der aussagekräftigste: Finanzunternehmen melden häufiger die eigene Kennung falsch als die ihrer Dienstleister. Das hat mit IKT-Risiko nichts zu tun – es ist ein Stammdatenproblem, derselbe Defekt, den die EZB im RDARR-Kontext unter fehlender eindeutiger Datenidentifikation beanstandet. Aus dem österreichischen Aufsichtsdialog vom Oktober 2025 berichtete die FMA über Zurückweisungen wegen eines Leerzeichens hinter der LEI und wegen Kopierfehlern aus dem Excel-Format: keine konzeptionellen Mängel, sondern Symptome fehlender automatisierter Kontrollen an der Datenquelle. Und das Register ist der unmittelbare Dateninput für die Benennung kritischer IKT-Drittdienstleister – am 18. November 2025 haben die ESAs 19 Anbieter designiert.

Wo decken sich DORA und RDARR/BCBS 239?

In vier Anforderungen: Bestandsverzeichnis, Abhängigkeiten, Kritikalität und Scope sowie Datenintegrität, nur mit unterschiedlichem Vokabular.

NISG 2026: Warum liegt der Prüfauftrag im Konzern?

Für das regulierte Institut selbst gehen die DORA-Bestimmungen nach § 24 Abs. 7 NISG 2026 vor: Nach der Darstellung der FMA entfallen für Finanzunternehmen Governance (§ 31), Risikomanagementmaßnahmen (§ 32), Nachweis (§ 33), Berichtspflichten (§ 34) sowie Aufsichts- und Durchsetzungsmaßnahmen; die Registrierung nach § 29 Abs. 2 bleibt – über das Unternehmensserviceportal, nach Angabe des Bundesamts für Cybersicherheit bis 31. Dezember 2026, je Einrichtung einzeln. Voraussetzung ist in jedem Fall, dass das Unternehmen nach Tätigkeit und Größe überhaupt wesentliche oder wichtige Einrichtung ist; DORA allein macht niemanden registrierungspflichtig. Der eigentliche Aufwand entsteht bei konzerneigenen Rechenzentren, IT-Gesellschaften und Managed-Service-Einheiten, die über Anhang I Nr. 8 und 9 der Richtlinie eigenständig in den vollen Anwendungsbereich fallen können – IKT-Drittdienstleister sind nach Art. 2 Abs. 2 DORA keine Finanzunternehmen, DORA wirkt für sie nicht als lex specialis. Ob eine Konzerngesellschaft erfasst ist, entscheiden Tätigkeit, Schwellenwerte mit Konzernzurechnung und Ausnahmen – nicht die Konzernzugehörigkeit als solche; Österreich kennt, anders als Deutschland, keine Ausnahme für rein konzerninterne Leistungserbringung. Diese Perimeterbestimmung ist dieselbe Übung wie die Abgrenzung wesentlicher Rechtseinheiten im RDARR-Leitfaden. Ein Institut mit einer gepflegten Rechtseinheiten- und Leistungsbeziehungslandkarte beantwortet die Frage in Tagen; eines ohne beginnt eine Erhebung, die es in zwei Jahren wiederholt.

KI-Verordnung: Warum ist Art. 10 derselbe Bau auf neuer Baustelle?

Der Digital Omnibus (VO (EU) 2026/1744) hat die Hochrisiko-Frist für Anhang-III-Systeme auf den 2. Dezember 2027 verschoben – mit festen Kalenderdaten, ohne Auslösemechanismus. Art. 10 hat er dabei nicht unberührt gelassen: Die Rechtsgrundlage für die Verarbeitung besonderer Datenkategorien zur Erkennung und Korrektur von Verzerrungen wurde aus Art. 10 Abs. 5 in einen neuen Art. 4a überführt und auf Betreiber erweitert, und auch Art. 4 zur KI-Kompetenz wurde neu gefasst (Volltext der Änderungsverordnung vor verbindlicher Verwendung prüfen). Der Kern der Datenanforderungen bleibt: Trainings-, Validierungs- und Testdatensätze müssen relevant, hinreichend repräsentativ, so weit wie möglich fehlerfrei und vollständig sein, mit dokumentierter Prüfung auf Verzerrungen (Art. 10 Abs. 2 und 3). Verglichen mit dem RDARR-Datenqualitätsmanagement beschreiben beide Normen dieselbe Disziplin für unterschiedliche Datenbestände: definierte Qualitätsdimensionen, messbare Kriterien, dokumentierte Prüfung, benannte Verantwortung, nachweisbare Behebung. Die EZB stellte im Supervision Newsletter vom 20. November 2025 fest, dass nur ein Teil der Banken die eigenen Datenmanagementstandards konsequent auf KI-Modelle anwendet – insbesondere bei unstrukturierten Daten. Genau dort endet der typische Datenqualitätsrahmen: an der Grenze des Meldewesens.

Welche sechs Bausteine werden einmal gebaut?

Inventar, Bewertungsbestand, Datenqualitätsrahmen, Herkunftssicht, Stammdatenregime und Feststellungsregister.

1. Ein gemeinsames Inventar mit gemeinsamen Schlüsseln. IKT-Assets, kritische Datenelemente, Rechtseinheiten, Dienstleisterverträge, Geschäftsprozesse und KI-Anwendungsfälle in einem Objektmodell, verknüpft über eindeutige Kennungen. Der teuerste Baustein – und der einzige, ohne den keiner der anderen trägt.
2. Ein gemeinsamer Bewertungsbestand für getrennte Einstufungen. Die Kritikalität nach DORA, die Wesentlichkeit nach RDARR, die Betroffenheit nach dem NISG und die Hochrisiko-Einstufung nach Anhang III beantworten verschiedene Fragen und folgen jeweils eigenen gesetzlichen Kriterien – ein Ausfall kann betriebskritisch sein, ohne dass ein beteiligtes KI-System hochriskant ist. Gemeinsam sollte die Faktenbasis sein: dieselben Funktionen, Rechtseinheiten, Systeme und Anwendungsfälle mit denselben Kennungen. Was in Prüfungen auffällt, sind widersprüchliche Bestandsangaben, nicht unterschiedliche rechtliche Einstufungen.
3. Ein Datenqualitätsrahmen mit erweitertem Anwendungsbereich. Dimensionen, Kennzahlen mit Toleranzschwellen, dokumentierte Eskalation – angewandt auf Meldewesen, Registerdaten nach DORA und Modelldatensätze einschließlich unstrukturierter Quellen.
4. Eine werkzeuggestützte Herkunfts- und Abhängigkeitssicht. Aus den Verarbeitungsstrecken abgeleitet, nicht manuell dokumentiert; sie bedient die Lineage-Anforderung, die Abhängigkeitskarten nach Art. 8 DORA und die Herkunftsnachweise nach Art. 10 und 11 KI-VO.
5. Ein Stammdatenregime. Verbindliche Pflege von Rechtsträger-, Vertrags- und Systemkennungen mit automatisierter Validierung an der Quelle. Der Trockenlauf 2024 hat gezeigt, dass hier der größte Teil der Meldefehler entsteht – und die Behebung ist vergleichsweise billig.
6. Ein gemeinsames Feststellungs- und Maßnahmenregister. Ein Eintrag je Defekt mit Zuordnung zu allen betroffenen Regelwerken, Ursache, Verantwortlichem, Frist und Behebungsnachweis – das Instrument, mit dem sich belegen lässt, dass eine Feststellung an der Ursache behoben wurde.

Was muss getrennt bleiben?

FRIA, Penetrationstests, NISG-Registrierung der Konzerngesellschaften, Konformitätsbewertung mit CE-Kennzeichnung und die Meldekaskaden.

• Die Grundrechte-Folgenabschätzung nach Art. 27 KI-VO. Grundrechtlich, nicht prudenziell begründet; der Verweis auf eine Datenschutz-Folgenabschätzung ist zulässig, die Gleichsetzung mit einer Risikoinventur nicht.
• Das bedrohungsgeleitete Penetrationstesten. Eigene Methodik, eigenes Vertraulichkeitsregime, eigene Aufsichtsbeteiligung.
• Die NISG-Registrierung der Konzerngesellschaften. Andere Adressaten, andere Behörde, andere Fristen – organisatorisch bei den betroffenen Gesellschaften, mit zentraler Steuerung der Perimeterfrage.
• Konformitätsbewertung und CE-Kennzeichnung bei Eigenentwicklung. Ein produktsicherheitsrechtliches Verfahren ohne Entsprechung im Bankaufsichtsrecht.
• Die Meldekaskaden. Unterschiedliche Auslöser, Fristen, Klassifizierungslogiken und Adressaten: Bei DORA läuft die Erstmeldung ab der Einstufung als schwerwiegend (vier Stunden) und zugleich ab Kenntnis (24 Stunden), Zwischen- und Abschlussmeldung folgen in Stufen; beim CRA zählt die Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Vorfalls, und der Abschlussbericht hängt bei Schwachstellen an der Verfügbarkeit der Abhilfe; das NISG kennt für erfasste Konzerngesellschaften eine eigene Kaskade. Die Melde-Uhr auf der CRA-Seite rechnet CRA und DORA mit ihren Auslösern. Gemeinsam sein sollte die Datenbasis, nicht der Meldeweg.

Wer verantwortet was?

Häufige Fragen

Erfüllt ein Bestandsverzeichnis die vier Pflichten gleichzeitig?

Nein – es speist sie. Die regulatorischen Sichten, Datenfelder und Qualitätskontrollen von Informationsregister, SREP-Nachweis, NISG-Registrierung und KI-Dokumentation bleiben daneben erforderlich. Der Datenkern verhindert nur, dass dieselbe Erhebung viermal stattfindet.

Müssen Banken sich nach dem NISG 2026 registrieren, obwohl DORA gilt?

Wenn sie nach Tätigkeit und Größe wesentliche oder wichtige Einrichtung sind: ja. Nach Darstellung der FMA bleibt die Registrierung nach § 29 Abs. 2 NISG 2026 bestehen, während die materiellen Pflichten – Governance, Risikomanagement, Nachweis, Berichte – nach § 24 Abs. 7 von DORA verdrängt werden. Die Registrierung läuft über das Unternehmensserviceportal, laut Bundesamt für Cybersicherheit bis 31. Dezember 2026.

Was hat das Informationsregister mit Datenqualität zu tun?

Es ist eine maschinell validierte Meldung mit 116 Datenqualitätsprüfungen. Im Trockenlauf 2024 hatten 93,5 % der Register mindestens einen Fehler, 86 % der Fehler waren fehlende Pflichtangaben, und die meldenden Unternehmen gaben häufiger ihre eigene LEI falsch an als die ihrer Dienstleister. Das ist Stammdatenpflege, nicht IKT-Risiko.

Welche Frist ist für Banken beim AI Act maßgeblich?

Der 2. Dezember 2027 für Hochrisiko-Systeme nach Anhang III – im Bankgeschäft das Kredit-Scoring natürlicher Personen, bei Versicherern die Risikobewertung und Preisbildung in der Lebens- und Krankenversicherung. Die Datenqualitätsanforderungen des Art. 10 Abs. 2 und 3 gelten ab dann; wer den Datenqualitätsrahmen vorher auf Modelldatensätze ausdehnt, baut nicht zweimal.