Das DORA-Informationsregister klingt auf den ersten Blick nach einer regulatorischen Pflichtübung: Daten sammeln, Template befüllen, Meldung vorbereiten. Formal stimmt das. Finanzunternehmen müssen ihre vertraglichen Vereinbarungen mit IKT-Drittdienstleistern strukturiert, aktuell und meldefähig dokumentieren.
In der Praxis zeigt sich jedoch schnell: Das eigentliche Thema ist nicht das Register selbst, sondern die Datenrealität dahinter. Richtig verstanden ist das Informationsregister ein Datenprodukt: Es zeigt, ob ein Institut Dienstleister, Verträge, IKT-Dienstleistungen, Prozesse, Assets, Risiken und Subdienstleister konsistent miteinander verbinden kann. Damit wird es zum Stresstest für Datenarchitektur, Verantwortlichkeiten und operative Steuerungsfähigkeit im IKT-Drittparteienmanagement.
Wer das Register nur als Excel- oder Tool-Export baut, erfüllt kurzfristig zwar die Meldeanforderung. Wer es jedoch als steuerungsrelevante Datenbasis aufsetzt, schafft darüber hinaus Transparenz über Auslagerungsketten, verbessert die Risikobewertung und legt die Grundlage für belastbare Entscheidungen zu Dienstleistern, Konzentrationen und Exitstrategien.
Dieser Beitrag argumentiert, dass Finanzdienstleister das Informationsregister nicht nur als regulatorisches Endprodukt verstehen sollten, sondern dass es richtig implementiert der Ausgangspunkt für ein datenbasiertes Drittparteienmanagement ist, das auch strategischen Mehrwert bietet.
Regulatorischer Kontext des Informationsregisters
Schauen wir uns zunächst an, warum Finanzdienstleister überhaupt ein Informationsregister erstellen müssen, welche Inhalte darin enthalten sein müssen und welche Auswirkungen dies auf die Institute hat.
DORA und IKT-Dienstleistungen
DORA, der europäische Rechtsrahmen für digitale operationelle Resilienz im Finanzsektor, verpflichtet Finanzunternehmen unter anderem dazu, ihre Abhängigkeiten von Informations- und Kommunikationstechnologie (IKT) systematisch zu steuern. Dazu gehört auch ein aktuelles Informationsregister über vertragliche Vereinbarungen zur Nutzung von IKT-Dienstleistungen – also digitalen oder technologischen Services wie Betrieb, Wartung, Cloud, Software, Datenverarbeitung oder IT-Support – durch IKT-Drittdienstleister. Formal klingt das nach Registerpflege. Das Informationsregister ist eine strukturierte Datei für die Meldung an die Aufsicht. Die dafür zu nutzenden standardisierten Templates wurden im Rahmen der EU-Durchführungsverordnung 2024/2956 festgelegt; die zugrunde liegenden technischen Standards wurden von den drei europäischen Aufsichtsbehörden EBA, EIOPA und ESMA für ihren jeweiligen Bereich erarbeitet.
Die Aufsichtsbehörden versprechen sich hierdurch Transparenz über mögliche Risiken, die auch in tieferen Stufen der Auslagerungskette von Finanzdienstleistern liegen. Risikokonzentrationen sollen so besser und frühzeitiger erkannt werden. Für den einzelnen Finanzdienstleister scheint hier wieder einmal viel Aufwand generiert zu werden, ohne dass man selbst dadurch unmittelbare Vorteile genießt.
Drittparteienmanagement wird datenbasiert
Praktisch zwingen die regulatorischen Anforderungen zum Informationsregister Finanzinstitute dazu, ihre Drittparteienbeziehungen datenbasiert zu verstehen: Wer liefert welche IKT-Dienstleistung über welchen Vertrag, für welchen Prozess oder welche Funktion, mit welchen Assets, Risiken und Subdienstleistern?
Genau dort liegt der Aufwand. Nicht das Template für die Meldung an die Aufsicht ist das Problem, sondern die Datenrealität dahinter. In vielen Häusern liegen relevante Informationen über Einkauf, Vertragsmanagement, Auslagerungsmanagement, IT, Informationssicherheit, Datenschutz und Fachbereiche verteilt. Das Informationsregister bringt diese Teilwahrheiten in eine gemeinsame Struktur – und macht sichtbar, ob sie zusammenpassen.
DORA verändert mit dem Informationsregister daher das IKT-Drittparteienmanagement von einer dokumentations- und vertragsorientierten Funktion zu einer datenbasierten Steuerungsdisziplin. Institute müssen künftig nicht nur wissen, mit welchem Dienstleister ein Vertrag besteht. Sie müssen auch nachvollziehen können, welche IKT-Dienstleistung erbracht wird, welche kritische oder wichtige Funktionen dadurch unterstützt werden, welche Risiken daraus entstehen und welche vertraglichen Anforderungen daraus folgen. Das Informationsregister steht nicht isoliert, sondern ist Teil einer fachlichen Kette wie Abbildung 1 zeigt.
Der erste operative Schritt ist die Klassifizierung und Abgrenzung der Leistung: Nicht jede eingekaufte Leistung ist automatisch eine IKT-Dienstleistung im Sinne von DORA. Diese Klassifizierung entscheidet darüber, welche Leistungen in den DORA-Bearbeitungspfad überführt werden und welche Informationen später im Informationsregister erforderlich sind.
Auf die Klassifizierung folgt die Risikobewertung der Dienstleistung. IKT-Dienstleistungen müssen nach erweiterten Kriterien bewertet werden, insbesondere mit Blick darauf, ob sie eine kritische oder wichtige Funktion unterstützen. Diese Bewertung bestimmt die Steuerungsintensität und die Tiefe der benötigten Informationen.
Auf dieser Grundlage werden die Vertragsinhalte geprüft. DORA fordert für IKT-Dienstleistungen verpflichtende vertragliche Mindestinhalte; der konkrete Anpassungsbedarf hängt wiederum von Kritikalität und Risiko der Dienstleistung ab. In der Praxis entsteht daraus ein iterativer Prozess: Vertragsdaten prüfen, Informationslücken identifizieren, Dienstleister kontaktieren und Vertragsbestandteile ergänzen.
Erst danach wird das Informationsregister fachlich belastbar. Es ist nicht der Ausgangspunkt der DORA-Umsetzung, sondern ein Ergebnis vorgelagerter Entscheidungen: Welche Leistung ist IKT-relevant? Welche Funktion wird unterstützt? Welche Vertragsinformationen liegen vor und welche Daten müssen ergänzt werden? Welche Risikoeinwertung liegt vor?
Informationsregister und Auslagerungskette als Datenmodell
Für jede IKT-Dienstleistung im Informationsregister muss nachvollziehbar sein, über welche vertragliche Vereinbarung sie bezogen wird, welcher IKT-Drittdienstleister beteiligt ist, welche Funktion oder welcher Prozess unterstützt wird und ob eine kritische oder wichtige Funktion betroffen ist. Damit entsteht zunächst der regulatorische Register- und Meldekern.
Für eine wirksame Steuerung reicht dieser Kern jedoch nicht aus. Steuerungsfähig wird diese Sicht erst durch die fachliche Verbindung mehrerer Datenobjekte. Der Meldekern muss mit weiteren Informationen aus dem IKT-Drittparteienmanagement verbunden werden, etwa mit Assets, Systemen, Daten, Risiken, Schutzbedarfen, relevanten Subdienstleistern und Exitstrategien.
Hinzu kommt: Die tatsächliche Leistungserbringung endet häufig nicht beim direkten Vertragspartner. IKT-Drittdienstleister nutzen wiederum Subdienstleister, etwa für Cloud-Infrastruktur, Betrieb, Datenverarbeitung, Support oder einzelne technische Leistungsteile. Für DORA ist dabei insbesondere die relevante Subdienstleisterkette entscheidend, also jene Weiterverlagerungen, die Sicherheit, Verfügbarkeit, Integrität oder Kontinuität einer IKT-Dienstleistung wesentlich beeinflussen können. Genau dort entstehen zusätzliche Abhängigkeiten, Konzentrationsrisiken und Anforderungen an Exit-Fähigkeit.
Für das Informationsregister bedeutet das eine klare Differenzierung: Der Register-/Meldekern umfasst insbesondere Vertragsstammdaten, IKT-Dienstleistungen, Funktionsbezüge und relevante Subdienstleisterinformationen. Die Steuerungsanschlüsse liegen darüber hinaus in Asset- und Systembezügen, Risiko- und Schutzbedarfsinformationen sowie Exitstrategien. Diese Informationen sind nicht alle im engen Sinne identisch mit dem offiziellen Registerdatenmodell, sie sind aber notwendig, um das Register für das IKT-Drittparteienmanagement nutzbar zu machen.
Ein Beispiel verdeutlicht diese Logik: Ein Institut kann einen Vertrag mit einem IKT-Dienstleister im Register erfassen. Steuerungsrelevant wird dieser Eintrag aber erst, wenn klar ist, dass der Dienstleister eine bestimmte Anwendung betreibt, diese Anwendung einen kritischen Prozess unterstützt, ein Cloud-Subdienstleister eingebunden ist, personenbezogene oder geschäftskritische Daten verarbeitet werden und für den Ausfallfall eine belastbare Exitstrategie existiert. Ohne diese Verbindung bleibt das Register formal gefüllt, aber fachlich nur eingeschränkt nutzbar.
Abbildung 2 zeigt diese Logik als Prinzipdarstellung der internen Datenbeziehungen rund um das Informationsregister. Der obere Teil bildet die Leistungs- und Vertragskette ab: vom Finanzinstitut über den direkten IKT-Drittdienstleister, Vertrag und IKT-Dienstleistung bis zu Funktion, Asset-/System-/Datenbezug und Risiko. Der untere Teil unterscheidet zwischen Register-/Meldekern und Steuerungsanschlüssen. Die rechte Seite zeigt, welche Steuerungsfragen das IKT-Drittparteienmanagement auf Basis dieser verknüpften Daten beantworten können sollte.
Wichtig ist die Einordnung: Abbildung 2 zeigt nicht das offizielle Informationsregister-Datenmodell der Aufsicht. Die DORA-Templates und das Reporting-Datenmodell sind vorgegeben; die interne Datenarchitektur eines Instituts ist jedoch nicht 1:1 vorgeschrieben. Institute müssen allerdings sicherstellen, dass ihre interne Datenarchitektur die regulatorischen Vorgaben vollständig, konsistent und validierbar abbilden kann.
Damit wird die Auslagerungskette unter DORA nicht selbst zu einem starren Pflichtdatenmodell. Sie muss aber als Datenmodell abbildbar werden. Wer nur Dienstleister und Verträge erfasst, bleibt auf der Ebene klassischer Registerpflege. Wer dagegen Dienstleister, Verträge, IKT-Dienstleistungen, Funktionen, relevante Subdienstleister, Assets, Systeme, Daten, Risiken und Exitstrategien miteinander verbindet, schafft die Grundlage für tatsächliche Steuerung. Genau hier entscheidet sich, ob das Informationsregister nur meldefähig ist oder auch operativ und strategisch Wert stiftet.
Die eigentliche Herausforderung: Datenrealität vor Meldelogik
Ist das Datenmodell rund um das Informationsregister definiert, muss es im nächsten Schritt mit konkreten Daten zum Drittparteienmanagement gefüllt werden.
In der Theorie kann das Informationsregister auf bestehenden Vertragsdaten aufbauen. In der Praxis zeigt sich jedoch schnell, dass vorhandene Vertragsdatenbanken meist nicht in der Granularität gepflegt sind, die DORA für das Informationsregister verlangt.
Aufbau und Erstellung eines Informationsregisters in der Praxis
Viele Institute verfügen zwar über einen umfangreichen Vertragsbestand, aber nur ein Teil davon ist tatsächlich IKT-relevant. Gleichzeitig sind die relevanten Informationen häufig unvollständig, uneinheitlich gepflegt oder nur im Vertrag selbst enthalten wie Abbildung 3 zeigt. Häufig existieren Vertragsdatenbanken oder frühere Registerlogiken aus BAIT-, MaRisk- oder Auslagerungsmanagement-Kontexten. Diese Bestandsdaten enthalten typischerweise Vertragsstammdaten, Dienstleister, Laufzeiten, Verantwortlichkeiten oder bestehende Auslagerungseinordnungen. Nutzbar sind sie jedoch nur, wenn Vollständigkeit, Aktualität und fachliche Eignung geprüft sind.
DORA möchte diesen Bestand um zusätzliche Informationsanforderungen ergänzen. Die relevanten Templates ergeben sich aus den technischen Durchführungsstandards, den sogenannten ITS (Implementing Technical Standards) der Aufsichtsbehörden. Sie beschreiben im DORA-Kontext die Tabellen, Pflichtfelder und Datenstrukturen, mit denen die Registerpflicht formal abgebildet wird. Aus einer bestehenden Vertragsdatenbank wird damit erst durch Ergänzung und Qualitätsprüfung ein DORA-konformes Informationsregister.
Ein Teil der zusätzlichen Informationen lässt sich aus bestehenden Verträgen ableiten, etwa aus Leistungsbeschreibungen, Vertragsparteien, Kündigungsrechten, Laufzeiten oder Servicebestandteilen. Häufig verbleibt jedoch eine Lücke: Entweder sind die Informationen zwar im Vertrag vorhanden, aber nicht strukturiert in der Vertragsdatenbank gepflegt, oder sie fehlen bereits im Vertragswerk selbst. Dann reicht reine Registerpflege nicht aus. Es müssen Verträge geprüft, Daten ergänzt, Dienstleister kontaktiert und fehlende Informationen fachlich validiert werden.
Entscheidend ist daher: Das Informationsregister ist kein bloßer Export aus einer Vertragsdatenbank. Es ist eine strukturierte Erweiterung und Qualitätsprüfung bestehender Datenbestände. Wer vorhandene Vertragsdaten ungeprüft übernimmt, riskiert formale Vollständigkeit ohne fachliche Belastbarkeit. Wer dagegen systematisch zwischen Datenbankbestand, Vertragsinhalt und zusätzlichem DORA-Bedarf unterscheidet, schafft die Grundlage für ein Register, das nicht nur meldefähig ist, sondern auch für Steuerung, Risikoanalyse und Dienstleistermanagement genutzt werden kann.
Ein typisches Phänomen ist, dass Verträge in der Datenbank vorliegen. Davon ist jedoch nur ein Teil tatsächlich für DORA relevant. Ein erheblicher Anteil betrifft Leistungen ohne IKT-Bezug und muss für das Informationsregister nicht weiter vertieft werden. Nach der fachlichen Abgrenzung verbleibt ein kleinerer, aber weiterhin relevanter Bearbeitungsbestand.
Für Verträge ist anschließend zu prüfen, ob die benötigten Informationen sowohl in der Vertragsdatenbank als auch im Vertrag selbst vollständig vorliegen.
Abbildung 4 übersetzt diese Prüfung in eine einfache Matrix entlang zweier Fragen: Ist die Datenbank vollständig? Und ist der Vertrag vollständig? Daraus entstehen vier Bearbeitungsfälle:
- Datenbank vollständig, Vertrag vollständig: Die erforderlichen Informationen sind bereits strukturiert vorhanden und im Vertrag nachvollziehbar belegt. Es entsteht kein zusätzlicher Bearbeitungsaufwand.
- Datenbank unvollständig, Vertrag vollständig: Die Informationen stehen im Vertrag, sind aber nicht oder nicht vollständig in der Datenbank gepflegt. Dann müssen Vertragsinhalte geprüft und in der Datenbank beziehungsweise im Informationsregister erfasst werden.
- Datenbank vollständig, Vertrag unvollständig: Die Datenbank enthält bereits Informationen, der Vertrag bildet diese jedoch nicht vollständig oder nicht belastbar ab. In diesem Fall sind eine Kontaktaufnahme mit dem Dienstleister, eine Ergänzung des Vertragswerks und gegebenenfalls eine Nachpflege der Daten erforderlich.
- Datenbank unvollständig, Vertrag unvollständig: Weder Datenbank noch Vertrag enthalten die notwendigen Informationen vollständig. Dann müssen Informationen zunächst strukturiert in der Datenbank erfasst, fehlende Angaben beim Dienstleister erhoben, Vertragsinhalte ergänzt und die Daten anschließend gepflegt werden.
Damit wird das Informationsregister zu einem praktischen Datenqualitätsprojekt. Die reine Existenz einer Vertragsdatenbank sagt wenig darüber aus, ob ein Institut meldefähig ist. Entscheidend ist, ob die DORA-relevanten Informationen vollständig, korrekt und in der richtigen Struktur vorliegen – und ob sie durch belastbare Vertragsgrundlagen abgesichert sind. Wo dies nicht der Fall ist, entstehen Nacharbeiten.
In der Praxis liegt der Aufwand vor dem Export
Das vorangegangene Kapitel zeigt: Für ein belastbares Informationsregister müssen Datenbankbestand und Vertragsinhalt zusammenpassen. In der Praxis liegt der erste Engpass jedoch häufig nicht sofort in der Vertragsanpassung, sondern in der Qualität der bestehenden Datenbasis. Bevor fehlende Vertragsinhalte ergänzt oder Dienstleister kontaktiert werden können, muss zunächst klar sein, welche Einträge überhaupt relevant, korrekt, eindeutig und meldepflichtig sind.
Ein Projektbeispiel zur Verbesserung der Informationsregister-Qualität bei einer in einen Verbund eingebundenen Bank zeigt diesen Punkt deutlich. Der praktische Aufwand lag nicht im finalen Export des Registers, sondern in der Bereinigung, Klassifizierung und fachlichen Einordnung der Daten in einem GRC-Tool. Ausgangspunkt war ein Datenbestand mit rund 700 Einträgen. Auf den ersten Blick wirkt eine solche Menge wie eine breite Informationsbasis. In der Analyse zeigte sich jedoch: Die Menge allein sagte wenig über Meldefähigkeit oder Steuerungsqualität aus.
Die Ursachen lagen nicht nur im System. Neben begrenzten Ressourcen und fehlender Transparenz über Bearbeitungsstände zeigte sich vor allem ein Know-how-Thema: Dienstleistungssteuerer, Vertragsverantwortliche und teilweise auch das Auslagerungsmanagement mussten erst ein gemeinsames Verständnis dafür entwickeln, welche Leistungen DORA-relevant sind, wie Klassifizierung und Risikoermittlungen dokumentiert werden und welche Informationen für das Informationsregister in welcher Qualität benötigt werden. Datenqualität war damit nicht nur ein technisches Problem, sondern auch eine Frage von Befähigung, Rollenverständnis und methodischer Sicherheit.
Anpassungen im Datenbestand erfolgten anhand von drei Kriterien: Erstens enthielt der Datenbestand zahlreiche Einträge, die weiterhin steuerungsrelevant waren, aber nicht meldepflichtig im Sinne des DORA-Informationsregisters. Zweitens mussten Einträge bereinigt werden, etwa Dubletten, Dummy-Einträge, Entwürfe oder Altdaten. Drittens war der DORA-relevante Anteil zunächst nicht vollständig gesichert, sondern musste unter Zeit- und Ressourcendruck über Eingrenzungskriterien, Erfahrungswerte und fachliche Plausibilisierung identifiziert werden.
In der Ausgangslage waren rund 70 Einträge als DORA-relevant eingeordnet. Rund 530 Einträge betrafen MaRisk-relevante sowie sonstige Fremdbezüge, die weiterhin relevant für die Dienstleistersteuerung blieben, aber nicht Bestandteil der DORA-Informationsregistermeldung waren. Weitere rund 100 Einträge entfielen auf Bereinigungstatbestände.
Im Projekt wurde der Datenbestand systematisch bearbeitet: Altdaten wurden archiviert, Dubletten und Dummy-Einträge entfernt, Leistungen neu zugeordnet und die Meldefähigkeit über Testmeldungen geprüft. Parallel wurden weitere potenziell IKT-relevante Leistungen anhand von Priorisierungskriterien identifiziert und fachlich bewertet. Dazu gehörten unter anderem bestehende IKT-Einwertungen, Schlagwörter, Erfahrungswerte aus vergleichbaren Instituten sowie die Frage, ob Leistungen kritische oder wichtige Funktionen unterstützen könnten. Dadurch sank die Gesamtmenge im GRC-Tool von rund 700 auf rund 600 Einträge. Gleichzeitig stieg die Qualität des Datenbestands deutlich.
Nach der Bereinigung verblieben rund 480 Einträge als weiterhin steuerungsrelevant, aber nicht meldepflichtig im Sinne des DORA-Informationsregisters. Der DORA-relevante Anteil erhöhte sich auf rund 120 Einträge. Diese Zahl ist jedoch nicht als abschließend vollständige Grundgesamtheit zu verstehen. Sie war das Ergebnis einer risikoorientierten Eingrenzung unter begrenzten Ressourcen und begrenzter Datenqualität. Genau darin liegt eine wichtige Praxiserkenntnis: Wenn der Ausgangsdatenbestand nicht vollständig belastbar ist, kann auch das erste Informationsregister nur so gut sein wie die zugrunde liegende Datenbasis und die gewählte Priorisierung.
Die nächste Ausbaustufe setzt daher folgerichtig an zwei Stellen an: Zum einen an der weiteren Bearbeitung der noch nicht vollständig geprüften Einträge, insbesondere im MaRisk- und Fremdbezugsbestand. Zum anderen an der Erweiterung der Grundgesamtheit, weil nicht jeder relevante Vertrag bereits vollständig im GRC-Tool erfasst war. In der Praxis liegen Verträge teilweise dezentral, historisch gewachsen oder nicht mehr vollständig in aktueller Schriftform vor. Auch das zeigt: Die Herausforderung ist nicht nur „Daten im Tool pflegen“, sondern Transparenz über den tatsächlichen Vertrags- und Dienstleistungsbestand herzustellen.
Damit lässt sich die Erfahrung aus dem Praxisbeispiel auf drei Punkte verdichten: Datenqualität entsteht durch Bereinigung und fachliche Abgrenzung. Meldefähigkeit entsteht durch priorisierte Validierung und Testmeldungen. Nachhaltige Steuerungsfähigkeit entsteht erst durch Befähigung, Rollenklärung und verankerte Pflegeprozesse.
Erfolgsfaktoren des Informationsregisters zur Steuerung
Unternehmen sollten daher weitere Erfolgsfaktoren berücksichtigen, wenn sie das Informationsregister zur operativen, strategischen und risikoorientierten Steuerung nutzen wollen.
Zentrale Steuerung mit dezentraler Verantwortung
Ein belastbares Informationsregister braucht zentrale Steuerung – aber keine zentrale Allzuständigkeit. Die zentrale Funktion definiert Datenmodell, Pflichtfelder, Qualitätsstandards, Kontrolllogik und Reporting. Die fachliche Richtigkeit der Informationen liegt überwiegend dezentral bei den Dienstleistungsverantwortlichen und wird bei Bedarf durch Fachbereiche, IT, Informationssicherheit, Datenschutz oder Vertragsmanagement unterstützt.
In der Umsetzung entscheidet deshalb weniger das Tool als die Arbeitsteilung. Wer darf eine IKT-Dienstleistung anlegen? Wer bestätigt die Kritikalität? Wer prüft Subdienstleister? Wer aktualisiert SLA-Informationen? Wer validiert, dass eine Vertragsänderung im Register angekommen ist? Ohne diese Antworten bleibt das Register eine Momentaufnahme.
Erfahrungen aus der Praxis zeigen, dass in Umsetzungsprojekten der kritische Erfolgsfaktor nicht die technische Anlage in einem GRC-Tool, sondern die klare Festlegung von Ownership und Pflegeprozessen ist. Wo Fachbereiche lediglich einmalig Daten zuliefern, droht das Informationsregister bereits nach kurzer Zeit zu veralten. Dort hingegen, wo Verantwortlichkeiten, Kontrollpunkte und Pflegeprozesse nachhaltig im Regelbetrieb verankert und die beteiligten Verantwortlichen für ihre Aufgaben befähigt werden, entsteht eine dauerhaft aktuelle Steuerungsbasis.
Pilotieren statt endlos designen
Beim Aufbau des Informationsregisters ist ein naheliegender Fehler, zunächst ein vollständiges Zielbild bis ins letzte Datenfeld zu entwerfen. In der Praxis führt das häufig zu langen Designphasen, abstrakten Datenmodellen und unklaren Verantwortlichkeiten. Belastbarer ist ein Vorgehen, das mit einer begrenzten Auswahl an Verträgen startet, konkrete Datenlücken sichtbar macht und daraus das Vorgehen für den Gesamtbestand ableitet.
Ein sinnvoller Einstieg ist ein Pilotprojekt mit ausgewählten Bestandsverträgen, zum Beispiel mit zehn bis fünfzehn repräsentativen IKT-Dienstleistungsverträgen. Diese Auswahl sollte unterschiedliche Vertragstypen, Dienstleisterkonstellationen und Kritikalität abdecken. Ziel ist nicht, sofort das gesamte Register zu befüllen, sondern die Bearbeitungslogik zu testen: Welche Informationen liegen bereits in der Vertragsdatenbank vor? Welche Angaben lassen sich aus dem Bestandsvertrag ableiten? Welche Informationen fehlen vollständig und müssen beim Dienstleister oder im Fachbereich erhoben werden?
Aus dem Pilot entstehen drei konkrete Ergebnisse. Erstens wird sichtbar, wie belastbar die vorhandenen Vertrags- und Dienstleisterdaten tatsächlich sind. Zweitens lassen sich typische Datenlücken und Klärungsbedarfe identifizieren. Drittens entsteht eine Blaupause für die weitere Bearbeitung: Welche Felder sind eindeutig? Wo braucht es fachliche Bewertung? Welche Informationen müssen zentral gepflegt werden? Und welche Verantwortung verbleibt beim Fachbereich, Vertragsmanagement, Auslagerungsmanagement oder IT?
Die eigentliche Erfassung kann anschließend sprintbasiert erfolgen. Statt alle Verträge gleichzeitig zu bearbeiten, werden Gruppen von Verträgen priorisiert – idealerweise zunächst solche, die kritische oder wichtige Funktionen unterstützen. Ein regelmäßiges Statusreporting ist dabei notwendig, um Fortschritt, Datenqualität, offene Klärungen und Eskalationsbedarfe transparent zu halten.
Nachhaltige organisatorische Befähigung
Entscheidend ist auch die Befähigung der Organisation. Das Informationsregister bleibt nur dann aktuell, wenn Mitarbeitende wissen, wann eine neue IKT-Dienstleistung registerrelevant ist, welche Daten gepflegt werden müssen und welche Änderungen im Vertrags- oder Dienstleisterbestand eine Aktualisierung auslösen. Deshalb sollten Prozessbeschreibung, Rollenmodell und Schulung nicht nachgelagerte Dokumentation sein, sondern integraler Bestandteil des Aufbaus.
Der Aufbau des Informationsregisters wird so zu einem kontrollierten Lernprozess. Der Pilot schafft Transparenz über Datenqualität und Aufwand, ein Projektplan übersetzt diese Erkenntnisse in ein skalierbares Vorgehen, und die sprintbasierte Erfassung bringt den Gesamtbestand schrittweise in eine meldefähige und steuerungsfähige Struktur. Es entsteht kein einmaliges Registerprojekt, sondern ein dauerhaft betreibbarer Prozess für IKT-Drittparteieninformationen.
KI hilft – aber erst nach der Datenordnung
Der Einsatz von Künstlicher Intelligenz (KI) kann im IKT-Drittparteienmanagement ein Effizienzhebel werden – allerdings nur in einem kontrollierten Rahmen. Naheliegende Anwendungsfälle sind Vertragsanalyse, Erkennung fehlender Pflichtattribute, Plausibilitätsprüfungen zwischen Dienstleistung und Vertrag, Hinweise auf Subdienstleister oder die Vorprüfung DORA-relevanter Vertragsklauseln. Voraussetzung ist, dass vertrauliche Vertrags- und Dienstleisterdaten nicht unkontrolliert in externe KI-Tools hochgeladen werden, sondern nur in freigegebenen, datenschutz- und informationssicherheitskonformen Umgebungen verarbeitet werden.
KI ersetzt keine fachliche Datenordnung. Wenn Dienstleistungsbegriffe uneinheitlich sind, Verantwortlichkeiten fehlen oder die Zielarchitektur unklar ist, automatisiert KI vor allem Unschärfe. Erst wenn Datenmodell, Ownership, Pflichtfelder und Qualitätslogik definiert sind, kann KI sinnvoll unterstützen.
Fazit
Das DORA-Informationsregister ist regulatorisch verpflichtend. Institute müssen ihre vertraglichen Vereinbarungen mit IKT-Drittdienstleistern strukturiert, aktuell und meldefähig abbilden. Wer das Register jedoch nur als Excel- oder Tool-Export versteht, löst lediglich das kurzfristige Meldeproblem.
Operativ und strategisch kann das Informationsregister mehr sein: Es zeigt, ob ein Institut Dienstleister, Verträge, IKT-Dienstleistungen, unterstützte Funktionen, Assets, Risiken und Subdienstleister konsistent miteinander verbinden kann. Genau daran entscheidet sich, ob das Register nur formal vollständig ist oder tatsächlich zur Steuerung von IKT-Drittparteienrisiken beiträgt. Das Informationsregister ist nicht das Ende der DORA-Umsetzung, sondern der Einstieg in ein datenbasiertes IKT-Drittparteienmanagement. Wer diesen Anspruch ernst nimmt, schafft mehr als Meldefähigkeit: belastbare Risikotransparenz, prüfungssichere Entscheidungen, wirksamere Dienstleistersteuerung und mehr digitale operationelle Resilienz.
