Der Digital Operational Resilience Act (DORA) ist am 17. Januar 2025 vollständig in Kraft getreten. Zu den Kernanforderungen gehört die Pflicht für Finanzunternehmen, ein strukturiertes Register of Information zu führen – ein umfassendes Verzeichnis aller IKT-Drittanbieter-Dienstleistungsvereinbarungen, einschließlich Unterauftragnehmer und gruppeninterner Dienste.
Dieses Handbuch erklärt, was das DORA Register of Information ist, welche Organisationen es führen müssen, welche Datenfelder vorgeschrieben sind und wie ein nachhaltiges Betriebsmodell aufgebaut wird. Ob Sie ein Compliance-Beauftragter sind, der seine erste Meldung vorbereitet, ein Risikomanager, der die Datenqualität prüft, oder ein Vendor-Manager, der abteilungsübergreifende Verantwortlichkeiten koordiniert – dieses Handbuch führt Sie durch jeden Schritt.
Sie erfahren: was die Aufsichtsbehörden erwarten, welche Unternehmen betroffen sind, welche Datenkategorien verpflichtend sind, wer für jedes Feld verantwortlich sein sollte, die sieben Schritte zum Aufbau Ihres Registers, die häufigsten Fehler, die zu Meldungsfehlern führen, und wie zweckgebaute Tools die laufende Pflege vereinfachen können.
Was ist das DORA Register of Information?
Das DORA Register of Information (RoI) ist ein strukturierter Datensatz, den Finanzunternehmen gemäß Artikel 28(3) der Verordnung (EU) 2022/2554 erstellen und pflegen müssen. Es erfasst jede IKT-Drittanbieter-Dienstleistungsvereinbarung – von Cloud-Infrastrukturanbietern über SaaS-Plattformen, verwaltete Sicherheitsdienste, Zahlungsdienstleister bis hin zu gruppeninternen IKT-Beziehungen.
Der Zweck des Registers ist aufsichtlicher Natur. Die nationalen zuständigen Behörden (NZBen) und die Europäischen Aufsichtsbehörden (EBA, EIOPA, ESMA) nutzen das Register, um die IKT-Abhängigkeitslandschaft eines Unternehmens zu bewerten, Konzentrationsrisiken zu identifizieren und die operative Resilienz des gesamten Finanzsektors zu überwachen.
Regulatorischer Zweck
DORA geht über traditionelle Outsourcing-Register hinaus. Die Anforderungen an das Register of Information sind im gemeinsamen RTS zum Register of Information gemäß Artikeln 28(9) und 30(5) DORA (JC 2023 84) festgelegt. Das RTS legt genaue Datenfelder, Kardinalität und Validierungsregeln fest und schreibt vor, dass das Register kontinuierlich aktuell gehalten werden muss – nicht nur zum Zeitpunkt der Meldung.
Aufsichtsmeldung
Finanzunternehmen müssen ihr Register ihrer NZB jährlich und auf Anfrage jederzeit vorlegen. Die NZB kann die Daten an die zuständige ESA weiterleiten. Meldungen müssen den vorgeschriebenen Datenvorlagen entsprechen (typischerweise CSV oder XBRL-Format), und die Validierung kennzeichnet fehlende Felder, inkonsistente Kennzeichner und Referenzintegritätsfehler.
IKT-Drittanbieter-Risikomanagement
Das Register fließt in mehrere andere DORA-Verpflichtungen ein. Kritikalitätsbewertungen, Ausstiegsstrategien und Vertragsüberprüfungen beziehen sich alle auf dasselbe Drittanbieter-Inventar. Das Register richtig zu erstellen ist daher keine eigenständige Übung – es verankert Ihr gesamtes IKT-Drittanbieter-Risikomanagement-Framework.
Operative Resilienz
Im Kern ist das DORA Register of Information ein Instrument der operativen Resilienz. Indem Unternehmen gezwungen werden, jede IKT-Abhängigkeit – einschließlich Viertparteien – zu kartieren und zu dokumentieren, entsteht eine Transparenz, die Management und Aufsichtsbehörden nutzen können, um zu beurteilen, ob ein einzelner Anbieterausfall systemische Störungen verursachen könnte.
Wer muss ein DORA-Register führen?
DORA gilt für ein breites Spektrum von Finanzunternehmen, die in der Europäischen Union tätig sind. Artikel 2 der Verordnung definiert den Anwendungsbereich, der die meisten regulierten Finanzinstitute umfasst.
Kreditinstitute
Banken und Hypothekengeber mit CRD-Zulassung.
Wertpapierfirmen
MiFID II-zugelassene Wertpapierfirmen, die Finanzdienstleistungen erbringen.
Zahlungsinstitute
PSD2-lizenzierte Zahlungs- und E-Geld-Institute.
Versicherungsunternehmen
Solvency II-zugelassene Versicherer und Rückversicherer.
Krypto-Asset-Dienstleister
MiCA-zugelassene CASPs ab ihrer beaufsichtigten Aufnahme.
CCPs, CSDs & Transaktionsregister
Zentrale Gegenparteien, Zentralverwahrer und Datenmeldeserviceanbieter.
Das Verhältnismäßigkeitsprinzip
DORA erkennt an, dass ein kleines Zahlungsinstitut nicht dieselbe operative Resilienzinfrastruktur aufrechterhalten kann wie eine systemrelevante Bank. Artikel 4 führt das Verhältnismäßigkeitsprinzip ein: Kleinstunternehmen und kleine Unternehmen profitieren von einem vereinfachten Regime, das bestimmte Dokumentations- und Governance-Anforderungen reduziert, während die Kernregisterpflicht erhalten bleibt.
Ausnahmen
Kleinstunternehmen (weniger als 10 Mitarbeiter und Jahresumsatz oder Bilanzsumme unter 2 Millionen Euro) qualifizieren sich für ein vereinfachtes DORA-Regime. Sie sind weiterhin verpflichtet, ein Register zu führen, aber die Anforderungen an Governance, Tests und Berichterstattung sind geringer.
Unternehmen, die außerhalb der EU tätig sind, aber Dienstleistungen für EU-Finanzunternehmen erbringen, unterliegen DORA nicht direkt – aber ihre Kunden tun es und müssen DORA-konforme Verträge und Risikobewertungen für diese Vereinbarungen sicherstellen.
Welche Informationen müssen enthalten sein?
Das gemeinsame RTS legt ein detailliertes Datenmodell für das Register of Information fest. Die folgende Tabelle fasst die wichtigsten Datenkategorien und Beispiele zusammen.
| Kategorie | Beispiele |
|---|---|
| Anbieterinformationen | Rechtlicher Name, LEI, Sitzland, Konzernzugehörigkeit |
| IKT-Dienste | Hosting, SaaS, MSP, IT-Support, Cloud-Dienste, Zahlungsabwicklung |
| Kritikalitätsklassifizierung | Kritisch / Nicht kritisch, unterstützte Funktion oder Prozess |
| Vertragsdetails | Startdatum, Enddatum, Verlängerungsbedingungen, Kündigungsfrist |
| Unterauftragnehmer | IKT-Viertanbieter, Unterauftragnehmerketten, Betriebsland |
| Ausstiegsstrategie | Status des Ausstiegsplans, identifizierte Alternativanbieter, Migrationszeitplan |
| Risikobewertung | Verknüpfte Risikobewertungen, Risikoeinstufung, letztes Bewertungsdatum |
Anbieterinformationen
Jeder IKT-Drittanbieter muss, soweit vorhanden, mit einem Legal Entity Identifier (LEI) identifiziert werden. Der rechtliche Name, das Land und die Konzernstruktur des Anbieters müssen erfasst werden. Die Verwendung konsistenter und validierter Unternehmenskennzeichner ist entscheidend – Aufsichtsbehörden nutzen diese, um Daten unternehmensübergreifend zu aggregieren und Konzentrationsrisiken zu identifizieren.
IKT-Dienste
Für jede Vereinbarung müssen die bereitgestellten IKT-Dienste beschrieben werden. Das RTS verwendet ein kontrolliertes Vokabular für Diensttypen. Häufige Kategorien umfassen: Cloud-Computing-Dienste, Datenanalyse, Rechenzentrumscolocation, Software-Wartung und -Support, verwaltete IT-Dienste, Cybersicherheitsdienste und Zahlungsdienste.
Kritikalitätsklassifizierung
Die Bestimmung, ob ein IKT-Dienst eine kritische oder wichtige Funktion (CIF) unterstützt, ist eine der folgenreichsten Entscheidungen im Register. Kritische Dienste unterliegen einer verstärkten Aufsicht, strengeren Vertragsanforderungen und einer obligatorischen Dokumentation der Ausstiegsstrategie.
Vertragsdetails
Vertragsbeginn- und -enddaten, Verlängerungsbedingungen und Kündigungsfristen müssen korrekt sein und mit Ihren Vertragsmanagement-Unterlagen übereinstimmen. Abgelaufene oder automatisch verlängerte Verträge, die ohne Überprüfung geblieben sind, sind ein häufiger Qualitätsmangel.
Unterauftragnehmer
DORA erweitert die Registerpflicht auf Unterauftragnehmer – oft als Viertparteien bezeichnet –, die an der Erbringung eines kritischen oder wichtigen IKT-Dienstes beteiligt sind. Sie müssen diese Unterauftragnehmer, ihr Betriebsland und wesentliche Abhängigkeiten identifizieren.
Ausstiegsstrategie
Für jede Vereinbarung, die eine kritische oder wichtige Funktion unterstützt, muss das Register festhalten, ob eine dokumentierte Ausstiegsstrategie vorliegt, welchen Status die Identifizierung von Alternativanbietern hat und ob der Ausstiegsplan getestet wurde.
Risikobewertung
Das Register sollte jede Vereinbarung mit einer Risikobewertung verknüpfen. Dazu gehören die Gesamtrisikoeinstufung, das Datum der letzten Bewertung und alle offenen Sanierungsmaßnahmen.
DORA-Register-Eigentumsmodell
Eine der häufigsten Ursachen für schlechte Registerqualität ist das Fehlen eines klaren Eigentumsmodells. Das DORA Register of Information ist von Natur aus funktionsübergreifend: Die benötigten Daten umfassen Rechts-, Beschaffungs-, Risiko-, Informationssicherheits- und Geschäftsbereiche.
Rechtsabteilung
Vertragsverantwortung, anwendbares Recht, Kündigungsklauseln und vertragliche Zugangs- und Prüfungsrechte. Die Rechtsabteilung sollte Vertragsdaten, Kündigungsfristen validieren und bestätigen, ob DORA-erforderliche Bestimmungen in jeder Vereinbarung enthalten sind.
Beschaffung & Lieferantenmanagement
Anbieteridentifikation, LEI-Verifizierung, Anfragen zur Offenlegung von Unterauftragnehmern und Verfolgung von Verlängerungen. Die Beschaffungsabteilung verfügt in der Regel über die zentrale Lieferantenliste und ist am besten in der Lage, neue Vereinbarungen zu identifizieren, bevor sie im Register erscheinen.
Informationssicherheit
Risikoeinstufungen, Sicherheitsbewertungen, Incident-Verknüpfung und Sicherheitslage von Unterauftragnehmern. Informationssicherheitsteams halten die aktuellsten Vendor-Due-Diligence-Ergebnisse und sind für die Validierung technischer Risikodaten verantwortlich.
Fachbereiche
Dienstkritikalität, unterstützte Funktionen und operative Abhängigkeiten. Fachbereichsverantwortliche sind am besten in der Lage zu beurteilen, ob ein Dienst eine kritische oder wichtige Funktion unterstützt – diese Beurteilung kann nicht zentral ohne fachlichen Input erfolgen.
Compliance & Regulatorische Aufsicht
Gesamtvollständigkeit des Registers, Meldungsvorbereitung und Kontakt mit der NZB. Compliance sollte den Governance-Rahmen besitzen – die Qualitätsregeln, Überprüfungsintervalle und Eskalationswege – auch wenn sie nicht einzelne Datenfelder besitzen.
Ein effektives Eigentumsmodell definiert für jedes Datenfeld, welche Abteilung die Daten liefert, welche Abteilung sie validiert und in welcher Häufigkeit. Dies wird typischerweise in einer RACI-Matrix dokumentiert.
Häufige DORA-Registerfehler
Dies sind die häufigsten Ursachen für Registerqualitätsmängel und Meldungsablehnungen, basierend auf Implementierungserfahrungen bei Finanzunternehmen.
1. Fehlende Unterauftragnehmer
Die meisten Unternehmen haben ein klares Bild ihrer direkten IKT-Anbieter, aber ein unvollständiges Bild der Viertparteien. Wenn Ihr Cloud-Anbieter die Datenverarbeitung an einen Unterauftragnehmer auslagert, muss diese Beziehung für kritische Dienste in Ihrem Register erscheinen.
2. Doppelte Lieferanteneinträge
Derselbe Anbieter, der unter verschiedenen Namen, Kennzeichnern oder juristischen Personen erscheint, ist ein Datenqualitätsproblem, das sich durch das Register hindurchzieht. Konzentrationsrisikoberechnungen werden unzuverlässig. Verwenden Sie validierte LEI-Codes und eine kanonische Lieferantenstammdatei.
3. Falsche Kritikalitätsklassifizierungen
Die Überklassifizierung von Diensten als nicht kritisch reduziert den Überwachungsaufwand, schafft aber regulatorisches Risiko. Die Unterklassifizierung kritischer Dienste ist ein wesentlicher Compliance-Verstoß. Klassifizierungen müssen durch dokumentierte Auswirkungsbewertungen gestützt werden.
4. Veraltete Vertragsdaten
Abgelaufene Vertragsenddaten, Verlängerungsbedingungen, die nicht mehr der aktuellen Vereinbarung entsprechen, und fehlende Kündigungsfristen zeigen ein Register an, das nicht gepflegt wird.
5. Kein klares Eigentumsmodell
Ohne dokumentierte Dateneigentümerschaft wird das Register zur Verantwortung niemandes. Wenn Felder falsch oder fehlend sind, gibt es keinen klaren Weg zur Behebung.
6. Fehlende Ausstiegspläne
Die Dokumentation der Ausstiegsstrategie ist für kritische Dienste erforderlich, aber viele Organisationen haben nur eine allgemeine Ausstiegsstrategie anstelle dienstspezifischer Pläne. DORA erfordert, dass Sie einen plausiblen Übergangsweg für jede kritische Vereinbarung nachweisen können.
Schritt-für-Schritt-Anleitung zum Aufbau eines DORA-Registers
Der Aufbau eines meldefertigen DORA Register of Information ist ein Projekt mit sieben unterschiedlichen Phasen. Jede Phase hat klare Liefergegenstände und Abhängigkeiten.
Schritt 1
Anwendungsbereich definieren
Identifizieren Sie, welche juristischen Personen in Ihrer Gruppe DORA unterliegen und ob eine konsolidierte oder entitätsbezogene Berichterstattung erforderlich ist. Bestätigen Sie mit Ihrer NZB, welches Übermittlungsformat sie benötigen. Dokumentieren Sie die im Umfang enthaltenen Dienste, einschließlich gruppeninterner Vereinbarungen.
Schritt 2
IKT-Anbieter inventarisieren
Erstellen Sie eine vollständige Liste aller IKT-Drittanbieter-Dienstleistungsvereinbarungen. Quellen umfassen: Vertragsregister, Kreditorenbuchhaltungssysteme, IT-Asset-Inventare, Sicherheitslieferantenlisten und Interviews mit Fachbereichsverantwortlichen. Validieren Sie rechtliche Unternehmensnamen anhand von LEI-Registern.
Schritt 3
Dienste klassifizieren
Bestimmen Sie für jede Vereinbarung, ob sie eine kritische oder wichtige Funktion unterstützt. Arbeiten Sie mit Fachbereichsverantwortlichen zusammen, um die Auswirkungen einer Dienstunterbrechung zu bewerten. Dokumentieren Sie die Begründung. Wenden Sie das kontrollierte Dienststartypvokabular aus dem RTS an.
Schritt 4
Eigentümerschaft zuweisen
Erstellen Sie eine RACI-Matrix, die jedes Datenfeld einem verantwortlichen Eigentümer zuordnet. Bestätigen Sie die Eigentümerschaft mit jeder Abteilung. Legen Sie das Überprüfungsintervall für jedes Feld fest. Integrieren Sie Register-Updates in bestehende Prozesse: Vertragsunterzeichnung, Beschaffungsgenehmigung, Lieferantenbewertungszyklen.
Schritt 5
Datenqualität validieren
Führen Sie systematische Qualitätsprüfungen über alle Datenfelder durch, bevor Sie das Register als meldebereit behandeln. Prüfungen sollten umfassen: Vollständigkeit der Pflichtfelder, gültige kontrollierte Vokabularwerte, Datumslogik, referenzielle Integrität, Duplikaterkennung und Vollständigkeit der Unterauftragnehmer für kritische Dienste.
Schritt 6
Governance etablieren
Definieren Sie das laufende Governance-Modell. Dazu gehören: eine monatliche oder vierteljährliche Qualitätsüberprüfung mit allen Dateneigentümern, ein Eskalationsweg für ungelöste Qualitätsprobleme, ein Change-Management-Prozess für neue, geänderte oder beendete Vereinbarungen und ein jährlicher vollständiger Review der Kritikalitätsklassifizierungen.
Schritt 7
Regulatorische Meldungen vorbereiten
Exportieren Sie das Register in dem von Ihrer NZB geforderten Format (typischerweise CSV, ausgerichtet an den JTS-Datenvorlagen, oder XBRL). Führen Sie den ESA-Validierungsregelsatz gegen Ihren Export durch, bevor Sie ihn einreichen – intern erkannte Fehler sind weit weniger kostspielig als von Ihrer Aufsichtsbehörde gemeldete Fehler.
DORA-Register-Vorlagenbeispiel
Die folgende Struktur zeigt eine repräsentative Zeile aus einem DORA Register of Information. Jede Zeile stellt eine einzelne IKT-Dienstleistungsvereinbarung dar. Ein einzelner Anbieter kann in mehreren Zeilen erscheinen, wenn er mehrere verschiedene Dienste erbringt.
| Feld | Beispielwert |
|---|---|
| Anbieter | Acme Cloud Services B.V. |
| LEI | 5493001KJTIIGC8Y1R12 |
| Dienst | Cloud-Infrastruktur (IaaS) |
| Kritikalität | Kritisch |
| Fachbereichsverantwortlicher | Leiter IT-Betrieb |
| Vertragsbeginn | 2022-01-01 |
| Vertragsende | 2027-12-31 |
| Unterauftragnehmer | DataStore GmbH (DE), NetOps Ltd (IE) |
| Ausstiegsstrategie | Dokumentiert – Alternative identifiziert, Plan zuletzt getestet 2024-11 |
| Risikoeinstufung | Hoch |
| Letztes Überprüfungsdatum | 2025-03-15 |
DORA-Register vs. traditionelle Outsourcing-Register
Viele Finanzunternehmen pflegen bereits eine Form von Outsourcing- oder Lieferantenregister – häufig zur Erfüllung der EBA-Outsourcing-Leitlinien oder interner Beschaffungsanforderungen. Das DORA Register of Information ist deutlich anspruchsvoller.
| Dimension | Traditionelles Register | DORA-Register |
|---|---|---|
| Hauptzweck | Lieferantenverfolgung & Ausgabenverwaltung | Operative Resilienz & Aufsichtsmeldung |
| Anwendungsbereich | Alle Lieferanten oder ausgelagerten Dienste | Alle IKT-Vereinbarungen, einschließlich gruppeninterner |
| Datentiefe | Schwerpunkt Vertrag und Kosten | Risiko-, Abhängigkeits-, Unterauftragnehmer- & Ausstiegsdaten |
| Berichterstattung | Nur intern | Obligatorische jährliche Aufsichtsmeldung |
| Format | Freiform (Word, Excel) | Vorgeschriebene Vorlagen mit Validierungsregeln |
| Viertparteien | Üblicherweise nicht erfasst | Erforderlich für kritische Dienste |
| Kritikalität | Begrenzt oder informell | Formal bewertet und dokumentiert |
| Aktualisierungsfrequenz | Jährlich oder projektbasiert | Kontinuierlich, ereignisgesteuert plus periodischer Review |
Wenn Ihre Organisation bereits ein EBA-Outsourcing-Register führt, bietet es einen nützlichen Ausgangspunkt – aber es deckt typischerweise nur 60–70% der DORA-Anforderungen ab. Die Lücken liegen üblicherweise in den Unterauftragnehmerdaten, der Verknüpfung mit der Ausstiegsstrategie, der Formalität der Kritikalität und dem Format der Regulierungsmeldung.
Wie RiskNow bei der Pflege eines DORA-Registers hilft
RiskNow ist eine GRC-Plattform, die von Praktikern entwickelt wurde, die DORA-Programme in Finanzunternehmen umgesetzt haben. Die Plattform bietet ein dediziertes Register of Information-Modul, das Ihnen hilft, ein vollständiges Drittanbieter-Inventar zu pflegen, Lieferkettenabhängigkeiten nachzuverfolgen und meldeферtige regulatorische Ausgaben vorzubereiten.
Register der Drittparteien
Pflegen Sie ein strukturiertes Register der IKT-Drittparteien mit Unternehmenskennzeichnungsdaten, LEIs, Dienstzuordnungen, Kritikalitätsklassifizierung, Vertragslebenszyklus-Details und verantwortlichen Feldeigentümern.
Lieferkettentransparenz
Kartieren Sie Unterauftragnehmer und Viertparteien in Ihrer IKT-Lieferkette, verknüpfen Sie Abhängigkeiten mit kritischen Diensten und führen Sie eine prüfbare Aufzeichnung der Konzentrations- und Resilienzrisiken.
Datenqualitätsberichte (100+ Prüfungen)
Führen Sie Datenqualitätsberichte mit mehr als 100 automatisierten Prüfungen durch, die Vollständigkeit, kontrollierte Werte, Duplikaterkennung, Datumslogik und referenzielle Integrität vor der Einreichung abdecken.
Regulatorische Exporte (XBRL / CSV)
Exportieren Sie Registerdaten in regulatorisch fertige XBRL- und CSV-Formate, die an Aufsichtsvorlagen ausgerichtet sind, mit Vorab-Export-Validierung zur Erkennung von Problemen vor der Einreichung.
Durch die Verbindung von Drittparteien, Lieferkettenbeziehungen, Verträgen, Risikobewertungen und Incidents in einem Modell reduziert RiskNow manuelle Abstimmungen und hilft Teams, das Register zwischen den jährlichen Einreichungszyklen präzise zu halten.
Häufig gestellte Fragen
Was ist ein DORA Register of Information?
Das DORA Register of Information ist ein strukturiertes Inventar aller IKT-Drittanbieter-Dienstleistungsvereinbarungen, das von einem Finanzunternehmen gemäß Artikel 28(3) der Verordnung (EU) 2022/2554 geführt wird. Es umfasst Anbieter, Dienste, Kritikalität, Verträge, Unterauftragnehmer und Risikobewertungen.
Ist das DORA-Register verpflichtend?
Ja. Alle betroffenen Finanzunternehmen müssen ein Register of Information führen und es ihrer nationalen zuständigen Behörde jährlich oder auf Anfrage vorlegen. Nichteinhaltung kann zu Aufsichtsmaßnahmen führen, einschließlich öffentlicher Bekanntmachung, Bußgeldern und Sanierungsanordnungen.
Wie häufig sollte das DORA-Register aktualisiert werden?
Das Register muss kontinuierlich aktuell gehalten werden. In der Praxis bedeutet dies ereignisgesteuerte Updates für neue Vereinbarungen, wesentliche Vertragsänderungen und beendete Dienste – ergänzt durch eine periodische (monatliche oder vierteljährliche) Qualitätsprüfung und eine jährliche vollständige Aktualisierung vor dem Meldezeitraum der Aufsichtsbehörde.
Was sind kritische IKT-Dienste?
Kritische IKT-Dienste sind solche, die eine kritische oder wichtige Funktion (CIF) unterstützen – eine, deren Ausfall oder Beeinträchtigung die regulatorische Compliance, finanzielle Solidität oder Dienstleistungserbringung des Unternehmens wesentlich beeinträchtigen würde. Die Kritikalität muss durch eine dokumentierte Auswirkungsanalyse bewertet und mindestens jährlich überprüft werden.
Müssen Unterauftragnehmer in das Register aufgenommen werden?
Ja, für kritische und wichtige Dienste. Sie müssen Unterauftragnehmer (Viertparteien) identifizieren, die Teil der Lieferkette für einen kritischen Dienst sind, und sie in das Register aufnehmen. Dies erfordert eine proaktive Zusammenarbeit mit primären Lieferanten, um die Offenlegung ihrer Lieferketten zu erhalten.
Wie unterscheidet sich DORA von den EBA-Outsourcing-Leitlinien?
Die EBA-Outsourcing-Leitlinien konzentrieren sich hauptsächlich auf Governance, Vertragsanforderungen und Meldepflichten für wesentliches Outsourcing. DORA geht weiter: Es deckt alle IKT-Vereinbarungen ab (nicht nur wesentliches Outsourcing), schreibt die Offenlegung von Unterauftragnehmern für kritische Dienste vor, erfordert formell dokumentierte Ausstiegsstrategien und führt ein standardisiertes Aufsichtsmeldungsregister mit vorgeschriebenen Datenfeldern ein.
Kann Excel zur Pflege des DORA-Registers verwendet werden?
Technisch ja, aber in der Praxis schafft es erhebliche operative Risiken. Excel-Register haben Probleme mit Zugriffskontrolle, Versionsverwaltung, tabellenübergreifender referenzieller Integrität und Prüfpfaden. Für größere Unternehmen wird eine zweckgebaute Plattform dringend empfohlen.
Welche Datenfelder sind im DORA-Register erforderlich?
Das gemeinsame RTS legt Pflichtfelder fest, darunter: rechtlicher Unternehmensname und LEI des Anbieters, IKT-Diensttyp, unterstützte Funktion, Kritikalitätsklassifizierung, Vertragsbeginn- und -enddaten, Kündigungsfrist, Unterauftragnehmerdetails (für kritische Dienste), Status der Ausstiegsstrategie und Verknüpfung mit der Risikobewertung.
Was passiert, wenn das DORA-Register bei der Einreichung unvollständig ist?
Ein unvollständiges oder ungenaues Register kann dazu führen, dass die NZB die Einreichung zur Korrektur zurückgibt, ein formeller Aufsichtsdialog über Schwächen in der Datenverwaltung geführt wird oder – in hartnäckigen Fällen – verschärfte Aufsichtsmaßnahmen ergriffen werden. Wiederholte Versäumnisse werden als Hinweis auf weiterreichende operative Resilienzdefizite gewertet.