DORA-Informationsregister und TLPT: Was im Zyklus 2027 auf dich zukommt

Seit dem 17. Januar 2025 gilt DORA, und im zweiten Jahr zeigt sich, wo der Aufwand wirklich liegt: nicht im Grundlagenprojekt, sondern im Dauerbetrieb. Das Informationsregister über alle IKT-Drittdienstleister geht jedes Jahr erneut an die Aufsicht, Dienstleister müssen ihren Finanzkunden dafür Daten liefern, und die Frage nach TLPT und Exit-Strategien steht im Raum. Wer die Grundlagen von DORA im Finanzsektor schon kennt, findet hier den Betrieb und den nächsten Zyklus.

Was gilt im zweiten DORA-Jahr? Die Termine im Überblick

DORA ist eine EU-Verordnung und gilt ohne nationale Umsetzung. Für das Informationsregister gab es bisher zwei Runden, und aus ihnen lässt sich der Rhythmus für 2027 ableiten.

Die Einreichung läuft ausschließlich über das MVP-Portal der BaFin, entweder als xBRL-Datei nach der ESA-Taxonomie oder mit der Excel-Vorlage der BaFin. Für 2026 hat die BaFin ab dem 4. Februar eine Testumgebung angeboten und klargestellt: Bis zum 30. März musste ein inhaltlich vollständiges Register vorliegen, auch wenn es die Prüfungen von BaFin und europäischen Aufsichtsbehörden noch nicht fehlerfrei durchlaufen hatte. Die Korrekturphase bis 24. April war allein für Fehler in fristgerecht eingereichten Registern gedacht.

Was lässt sich für 2027 sagen? Die BaFin schreibt auf ihrer Seite zum Informationsregister, dass der Einreichungsprozess jährlich bis spätestens 31. März vollständig zu durchlaufen ist und das Register den Stand zum 31. Dezember des Vorjahres abbildet. Für den Zyklus 2027 sind laut BaFin keine Taxonomie-Änderungen vorgesehen. Der Stichtag 31. Dezember 2026 ist damit die logische Folge, ein verbindliches Einreichungsfenster nennt die BaFin nach unserem Stand im Oktober 2026 noch nicht. Wann die Annahme startet, gibt sie nach eigener Aussage zu Jahresbeginn bekannt.

Neben der jährlichen Einreichung gibt es eine zweite Pflicht, die gern untergeht. Nach Artikel 28 Absatz 3 DORA musst du die Aufsicht zeitnah informieren, wenn du einen Vertrag über IKT-Dienstleistungen für eine kritische oder wichtige Funktion planst, und auch dann, wenn eine Funktion nachträglich kritisch oder wichtig wird. Diese Anzeige hängt nicht am Märztermin.

Wer muss ein Informationsregister führen und wer liefert die Daten?

Die Pflicht trifft Finanzunternehmen, die unter DORA fallen: Banken, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Versicherer, Verwalter von Investmentfonds und weitere. Das Register muss auf Unternehmensebene geführt werden, bei Gruppen zusätzlich teilkonsolidiert und konsolidiert. Es erfasst alle vertraglichen Vereinbarungen über IKT-Dienstleistungen von IKT-Drittdienstleistern und unterscheidet dabei, ob die Dienstleistung eine kritische oder wichtige Funktion unterstützt oder nicht.

Ausgenommen sind nur wenige Gruppen. Artikel 2 Absatz 3 DORA nennt unter anderem Versicherungsvermittler, die Kleinst-, kleine oder mittlere Unternehmen sind, sowie Verwalter alternativer Investmentfonds und Versicherer unterhalb der dort genannten Schwellen. Wenn du unsicher bist, ob du darunter fällst, klär das mit deiner Rechtsabteilung oder Kanzlei. Das ist keine Rechtsberatung, sondern eine Orientierung.

Kleine Institute bekommen bei DORA Erleichterungen, etwa beim ICT-Risikomanagement-Rahmen. Ob du ein Register führst, hängt nach dem Wortlaut von Artikel 28 Absatz 3 nicht davon ab. Die Verhältnismäßigkeit nach Artikel 28 Absatz 1 steuert eher, wie tief du Bewertung und Überwachung der Dienstleister treibst.

Ein Beispiel für den weiteren Text: Ein Zahlungsinstitut mit 100 Mitarbeitenden hat angenommen 70 Verträge mit IKT-Dienstleistern, vom Kernsystem für die Zahlungsabwicklung über Cloud-Hosting und einen MSP für die Arbeitsplätze bis zu kleinen Werkzeugen, die Fachabteilungen selbst gebucht haben. Alle 70 gehören ins Register. Nur bei einem Teil, etwa dem Kernsystem, geht es um eine kritische oder wichtige Funktion mit den strengeren Anforderungen.

Was steht im DORA-Informationsregister?

Das Format ist in der Durchführungsverordnung (EU) 2024/2956 festgelegt. Sie definiert Standardvorlagen, die miteinander verknüpft sind. Fürs Verständnis reicht die Gruppierung nach Inhalt.

Drei Punkte aus den Ausfüllhinweisen verdienen mehr Aufmerksamkeit, als sie meist bekommen.

Der Rang in der Dienstleistungskette. Dein direkter Vertragspartner hat Rang 1, dessen Unterauftragnehmer Rang 2 und so weiter. Für alle IKT-Dienstleistungen musst du die direkten Dienstleister erfassen. Unterauftragnehmer musst du aufführen, wenn sie Dienstleistungen für kritische oder wichtige Funktionen oder wesentliche Teile davon sicherstellen. Das heißt: Du musst von deinem MSP oder deinem Hoster wissen, auf wen er seinerseits angewiesen ist. Ohne diese Auskunft bleibt das Register an genau der wichtigsten Stelle leer.

Die Kennung. Für Dienstleister, die juristische Personen sind, verlangt die Verordnung eine gültige und aktive LEI oder die europäische Kennung EUID. Bei Unterauftragnehmern kritischer Dienste musst du über den direkten Dienstleister sicherstellen, dass sie ebenfalls eine solche Kennung nutzen. Die BaFin lässt in ihren FAQ zwar weitere Kennungen wie die Handelsregisternummer zu, schließt aber Dummy-LEIs ausdrücklich aus, weil sie den Zweck der eindeutigen Identifizierung aushebeln würden.

Die Bewertungsfelder. Bei Dienstleistungen für kritische oder wichtige Funktionen fragt das Register nach Ausstiegsplan, Wiedereingliederbarkeit, Alternativen und Datum des letzten Audits. Wer hier „Nein" oder „kein Audit" eintragen muss, zeigt der Aufsicht schwarz auf weiß, wo die Lücke liegt, und hat damit den Anlass, sie zu schließen.

Wie pflegst du das Register das ganze Jahr statt kurz vor der Meldung?

Die Durchführungsverordnung verlangt in Artikel 3, dass du die Angaben regelmäßig überprüfst und festgestellte Fehler oder Unstimmigkeiten unverzüglich korrigierst. Gemeint ist also ein laufend geführtes Register, aus dem du zum Stichtag eine Fassung ziehst, keine Momentaufnahme im März. Der praktikable Ansatz ist ereignisgetrieben, ergänzt um zwei feste Termine.

Ereignisse, die immer einen Registereintrag auslösen

Lege fest, welche Vorgänge das Register aktualisieren, und hänge diese Pflicht an die Prozesse, die sie ohnehin auslösen:

• Neuer Vertrag oder neue IKT-Dienstleistung. Der Registereintrag gehört in den Beschaffungsprozess, bevor die Unterschrift fällt. Artikel 28 Absatz 4 verlangt vor Vertragsschluss ohnehin die Einstufung als kritisch oder wichtig, die Risikobewertung und die Due Diligence. Die Ergebnisse sind genau die Registerdaten.
• Vertragsänderung, Verlängerung, Kündigung. Enddatum, Kündigungsfristen und Standorte ändern sich hier. Ein Vertrag, der im Register noch läuft, aber längst gekündigt ist, ist ein klassischer Fehler.
• Änderung bei einem Dienstleister. Neuer Unterauftragnehmer, neuer Rechenzentrumsstandort, Übernahme oder Wechsel der Rechtsform. Verpflichte deine Dienstleister vertraglich, dir solche Änderungen vorab mitzuteilen. Artikel 30 Absatz 2 Buchstabe b verlangt das für Standortänderungen ausdrücklich.
• Änderung der Funktionslandschaft. Wird eine Funktion neu als kritisch oder wichtig eingestuft, ändert sich nicht nur der Registereintrag, sondern es entsteht auch die Anzeigepflicht gegenüber der Aufsicht.

Zwei feste Termine im Jahr

Quartalscheck. Einmal pro Quartal vergleichst du das Register mit den Quellen: Vertragsablage, Buchhaltung (welche Dienstleister bekommen Geld?), Einkaufssysteme, Kreditkartenabrechnungen. Die Buchhaltung ist der beste Spürhund für Dienste, die an Einkauf und IT vorbeigebucht wurden, und deckt Shadow IT auf, die sonst im Register fehlt.

Freeze im Dezember. Zum Stichtag 31. Dezember friert ihr den Stand ein, prüft die Pflichtfelder und lasst das Register vor dem Jahreswechsel fachlich gegenlesen. Ab Januar bleibt die Meldung dann eine technische Aufgabe: Datei erzeugen, in der Testumgebung prüfen, einreichen. Die BaFin hat 2026 ab Anfang Februar eine Testumgebung bereitgestellt, plane den Probelauf für 2027 genauso ein.

Datenqualität: Woran Register scheitern

Die Durchführungsverordnung nennt sechs Grundsätze für die Datenqualität: Richtigkeit, Vollständigkeit, Kohärenz, Integrität, Einheitlichkeit und Gültigkeit. Die europäischen Aufsichtsbehörden prüfen eingereichte Register mit Validierungsregeln, und die BaFin stellt Fehlercodes und Abhilfehinweise bereit. Aus den Ausfüllhinweisen ergeben sich die typischen Stolpersteine:

• Ungültige, abgelaufene oder erfundene Kennungen (LEI muss aktiv sein, Dummy-Werte sind unzulässig).
• Widersprüche zwischen Vorlagen, etwa ein Unterauftragnehmer in der Dienstleistungskette, der nicht als Dienstleister angelegt ist.
• Fehlende Pflichtfelder bei kritischen oder wichtigen Funktionen, etwa Sensibilität der Daten oder Wiederherstellungsziele.
• Sonderwerte falsch genutzt, zum Beispiel das Datum „9999-12-31" für unbefristete Verträge oder ein nicht durchgeführtes Audit.

Plane die Validierung deshalb als regelmäßige Aufgabe ein, nicht als Schritt am letzten Tag. Hilfreich ist ein Datenmodell, das jede Angabe nur einmal führt: Pflegst du die LEI eines Dienstleisters an einer Stelle und alle Registerzeilen zeigen darauf, musst du einen Fehler beheben statt zwanzig.

Welche Rolle spielen ISMS und Lieferantenbewertung?

Ein Informationsregister, das separat in einer Tabelle lebt, veraltet schneller, als du es pflegen kannst. Die meisten Angaben stehen anderswo im Haus schon: die Verträge beim Einkauf, die Kritikalität im Risikomanagement, die Standorte in der Dienstleisterbewertung, die Wiederherstellungsziele im BCM. Die Aufgabe des ISMS ist, diese Quellen zu verbinden, damit das Register eine Sicht auf gepflegte Daten ist und kein zweites Archiv.

Drei Verbindungen tragen die Hauptlast:

Assets und Funktionen. Ob eine IKT-Dienstleistung eine kritische oder wichtige Funktion unterstützt, hängt davon ab, welche Systeme und Prozesse daran hängen. Ein sauberes IT-Asset-Management mit Abhängigkeiten liefert genau diese Zuordnung: Welche Anwendung läuft bei welchem Dienstleister, welche Geschäftsfunktion hängt daran, welche Wiederherstellungszeit gilt dafür?

Dienstleisterbewertung. Vor dem Vertragsschluss und danach regelmäßig bewertest du deine Dienstleister, das fordern Artikel 28 Absatz 4 und Artikel 28 Absatz 5 (nur Verträge mit Dienstleistern, die angemessene Standards für Informationssicherheit einhalten). Mit einer strukturierten Lieferantenbewertung per Sicherheitsfragebogen entstehen die Angaben zu Sicherheitsniveau, Unterauftragnehmern und Standorten gleich mit, die du fürs Register brauchst. Ergänze für DORA gezielt Fragen zu Rang-2-Dienstleistern und zur LEI.

Fristen. Enddatum, Kündigungsfrist, Wiederbewertung und das Datum des letzten Audits sind Stichtagsdaten mit Ablaufdatum. In ISMS Lite hältst du pro Dienstleister Kritikalität, Verträge und Sicherheitsbewertung fest, verknüpfst ihn mit den genutzten Assets und führst Vertragsende, Kündigungsfrist, Erinnerungstermin und Folgebewertung als getrennte Fristen. Die Meldedatei selbst baust du weiterhin mit der BaFin-Excel-Vorlage oder einem Werkzeug, das die ESA-Taxonomie beherrscht, aber die Datenpflege dahinter muss nicht doppelt laufen.

Dazu gehört eine klare Zuständigkeit: Der Einkauf pflegt Vertragsdaten, die Fachabteilung die Funktionen, der Informationssicherheitsbeauftragte die Bewertung. Die Gesamtverantwortung liegt bei einer Stelle, die die Validierung vor der Meldung gegenzeichnet.

Welche Vertragsinhalte verlangt DORA Artikel 30?

Das Register dokumentiert Verträge, Artikel 30 sagt, was drinstehen muss. Das Prinzip ist zweistufig: Alle IKT-Verträge brauchen eine Grundausstattung, Verträge für kritische oder wichtige Funktionen zusätzliche Klauseln.

Für alle Verträge (Artikel 30 Absatz 2):

• Klare und vollständige Beschreibung der Funktionen und IKT-Dienstleistungen, einschließlich der Angabe, ob und unter welchen Bedingungen Unterauftragnehmer zulässig sind.
• Standorte (Regionen oder Länder) der Leistungserbringung und Datenverarbeitung, mit der Pflicht des Dienstleisters, Änderungen vorab mitzuteilen.
• Bestimmungen zu Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit der Daten.
• Zugang zu den Daten und deren Rückgabe in einem leicht zugänglichen Format bei Insolvenz, Abwicklung, Einstellung der Geschäftstätigkeit oder Vertragsende.
• Beschreibung der Dienstleistungsgüte.
• Unterstützung bei IKT-Vorfällen ohne zusätzliche Kosten oder zu vorab festgelegten Kosten.
• Pflicht zur Zusammenarbeit mit den zuständigen Behörden und Abwicklungsbehörden.
• Kündigungsrechte und Mindestkündigungsfristen.
• Bedingungen für die Teilnahme an deinen Schulungen zur IKT-Sicherheit und digitalen operationalen Resilienz.

Zusätzlich bei kritischen oder wichtigen Funktionen (Artikel 30 Absatz 3):

• Präzise quantitative und qualitative Leistungsziele innerhalb der Dienstleistungsgüte.
• Kündigungsfristen und Berichtspflichten des Dienstleisters, auch bei Entwicklungen, die seine Leistungsfähigkeit wesentlich beeinträchtigen können.
• Pflicht, Notfallpläne zu implementieren und zu testen und über angemessene Sicherheitsmaßnahmen und -richtlinien zu verfügen.
• Pflicht, an deinem TLPT teilzunehmen und uneingeschränkt mitzuwirken.
• Uneingeschränkte Zugangs-, Inspektions- und Auditrechte für dich, einen beauftragten Dritten und die zuständige Behörde.
• Ausstiegsstrategien mit einem verbindlichen, angemessenen Übergangszeitraum, in dem der Dienstleister weiter leistet.

Die Auditrechte sind der Punkt, an dem Verträge mit großen Anbietern oft hängen. Artikel 30 Absatz 3 erlaubt in solchen Fällen, alternative Bestätigungsniveaus zu vereinbaren, wenn Rechte anderer Kunden betroffen sind, zum Beispiel Sammelaudits oder Zertifikate. Absatz 4 empfiehlt außerdem, Standardvertragsklauseln der Behörden zu erwägen.

Für die Praxis lohnt ein Abgleich in zwei Schritten. Zuerst klärst du, welche der 70 Verträge im Beispiel eine kritische oder wichtige Funktion stützen. Dann prüfst du genau diese gegen die Liste oben und gibst Lücken an den Einkauf. Für Unterauftragnehmer kommt die Delegierte Verordnung (EU) 2025/532 dazu, die festlegt, was du bei der Untervergabe kritischer Dienstleistungen bestimmen und bewerten musst.

Exit-Strategien: Was Artikel 28 Absatz 8 verlangt und wie du sie testest

Für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, brauchst du nach Artikel 28 Absatz 8 Ausstiegsstrategien. Sie müssen den Fall des Dienstleisterausfalls, schlechter Qualität, Unterbrechung der Geschäftstätigkeit und der Kündigung nach Artikel 28 Absatz 7 abdecken. Du musst aus dem Vertrag aussteigen können, ohne dass die Geschäftstätigkeit unterbrochen wird, regulatorische Anforderungen leiden oder die Qualität für Kunden sinkt.

Der Text fordert drei Dinge, die über ein Papierkonzept hinausgehen. Ausstiegspläne müssen umfassend, dokumentiert und ausreichend getestet sein und regelmäßig überprüft werden. Du ermittelst alternative Lösungen und entwickelst Übergangspläne, um Dienstleistungen und Daten sicher und vollständig an einen anderen Anbieter oder zurück ins eigene Haus zu übertragen. Und du hältst Notfallmaßnahmen bereit, falls der Dienstleister ausfällt, bevor der Wechsel abgeschlossen ist.

Ein tragfähiger Exit-Plan für einen kritischen Dienstleister enthält:

• Auslöser: Welche Ereignisse lösen den Ausstieg aus (Kündigungsgründe nach Artikel 28 Absatz 7, Insolvenz, Ausfall über die vereinbarte Zeit)?
• Zielzustand: Wechsel zu einem benannten alternativen Anbieter oder Reintegration ins eigene Haus, jeweils mit realistischem Zeitplan.
• Daten: Welche Daten in welchem Format zurückkommen, wo sie liegen, wie lange der Anbieter sie nach Vertragsende noch bereithält.
• Übergangszeitraum: Dauer, in der der alte Anbieter laut Vertrag weiterleistet (Artikel 30 Absatz 3 Buchstabe f).
• Testnachweis: Datum und Ergebnis der letzten Übung.

Das Register fragt diese Angaben ab: Ausstiegsplan vorhanden (ja oder nein), Möglichkeit der Wiedereingliederung (problemlos, schwierig, äußerst kompliziert) und ob alternative Anbieter existieren. Wer dort ehrlich „schwierig" einträgt, sollte im Plan erklären, was dagegen unternommen wird. Im ISMS legst du dafür eine Maßnahme an, verknüpfst sie mit dem Dienstleister und dem Risiko und planst die nächste Übung als Termin, zum Beispiel in ISMS Lite.

Testen kannst du in Stufen. Der Anfang ist ein Schreibtischtest: Ihr geht den Plan in einer Tabletop-Übung mit dem Szenario „Dienstleister ist nicht mehr erreichbar" durch und prüft, ob die benannten Alternativen wirklich verfügbar sind. Danach folgt der technische Datenexport: Kannst du die Daten in einem brauchbaren Format ziehen, und lassen sie sich anderswo einlesen? Gerade bei Cloud-Diensten hilft hier der EU Data Act und seine Regeln zum Cloud-Wechsel, weil er Anbieter zu Wechselmöglichkeiten verpflichtet und die vertragliche Seite der Portabilität stützt.

Was bedeutet DORA für IKT-Dienstleister und MSPs?

Wenn du Finanzunternehmen bedienst, reichst du selbst nichts bei der BaFin ein. Dein Kunde trägt dich im Register ein und braucht dafür Auskünfte von dir. Wer diese Anfragen sauber und schnell beantwortet, ist der bequemere Partner und hat bei Vertragsverlängerungen ein Argument mehr. Was Finanzkunden von dir in der Regel anfordern, lässt sich direkt aus den Registerfeldern und aus Artikel 30 ableiten:

• Kennung: Deine LEI (oder EUID), gültig und aktiv. Besorg sie, bevor der erste Kunde fragt.
• Leistungsbeschreibung: Welche Dienstleistungen genau, für welche Funktion, mit welchen Leistungskennzahlen.
• Standorte: Länder, in denen du leistest und Daten verarbeitest, einschließlich Backup und Support.
• Unterauftragnehmer: Wer bei dir mitwirkt (Hoster, Rechenzentrum, Fernwartungs- und Monitoringwerkzeuge, Ticketsystem), mit Kennung und Land. Bei Dienstleistungen für kritische Funktionen musst du die Kette offenlegen.
• Vertragsklauseln: Auditrechte, Mitteilung von Standortänderungen, Unterstützung bei Vorfällen, Kooperation mit der Aufsicht, Exit-Unterstützung mit Übergangszeitraum, Teilnahme an TLPT-Tests des Kunden.
• Nachweise: Zertifikate, Auditberichte, Notfallpläne.

Praktisch bedeutet das: Lege dir einen Standarddatensatz an, der diese Angaben für alle Finanzkunden einmal vorhält, und aktualisiere ihn bei jeder Änderung deiner Unterauftragnehmer oder Standorte. Fällst du selbst als IT-Dienstleister unter NIS2, kommen deren Pflichten zu den Kundenanforderungen aus DORA dazu.

Eine Besonderheit für Kunden aus dem Finanzsektor: Artikel 30 Absatz 3 Buchstabe d verpflichtet dich, an TLPT-Tests des Kunden mitzuwirken, sofern deine Dienstleistung in dessen Testumfang fällt. Prüf deine Standardverträge darauf und stimm mit dem Kunden ab, wie Tests an gemeinsam genutzten Systemen ablaufen, damit andere Kunden nicht betroffen sind. DORA sieht dafür einen gebündelten Test vor, bei dem mehrere Finanzunternehmen unter Leitung eines benannten Finanzunternehmens gemeinsam mit dem Dienstleister getestet werden.

TLPT: Wer muss, wer nicht?

TLPT steht für Threat-Led Penetration Testing, bedrohungsorientierte Penetrationstests. Anders als ein klassischer Penetrationstest läuft er an Live-Produktionssystemen, die kritische oder wichtige Funktionen unterstützen, und beruht auf einer Bedrohungsanalyse für genau dein Unternehmen. Die Methodik folgt dem TIBER-EU-Rahmen.

Die Pflicht trifft nicht alle. Artikel 26 DORA verpflichtet Finanzunternehmen, die die Aufsicht dafür auswählt, mindestens alle drei Jahre zu einem TLPT. Die Aufsicht kann die Frequenz je nach Risikoprofil verringern oder erhöhen. Kleinstunternehmen und die in Artikel 16 genannten Unternehmen mit vereinfachtem Rahmen sind von der TLPT-Pflicht ausgenommen.

Die Auswahlkriterien stehen in der Delegierten Verordnung (EU) 2025/1190. Artikel 2 verpflichtet die Behörden, bestimmte Finanzunternehmen zu TLPT heranzuziehen, es sei denn, ihre Bewertung ergibt, dass Auswirkungen, Finanzstabilität oder IKT-Risikoprofil das nicht rechtfertigen. Genannt werden:

Dazu kommt eine qualitative Prüfung: Die Behörden können auch andere Finanzunternehmen heranziehen, wenn Auswirkungen, Finanzstabilität oder IKT-Risikoprofil das rechtfertigen.

Für die Zielgruppe dieses Artikels heißt das: Ein Zahlungsinstitut mit 100 Mitarbeitenden, ein Fintech, ein Vermögensverwalter oder ein mittelständischer Versicherer liegt in aller Regel weit unter diesen Schwellen. Sicher bist du erst, wenn die Aufsicht dich nicht benennt, denn die Entscheidung trifft sie. In Deutschland ist die BaFin für die Identifizierung zuständig und teilt es per Verpflichtungsbescheid mit, den konkreten Teststart ordnet sie nach den BaFin-Angaben mit der Bundesbank per Testanordnung an. Die Bundesbank begleitet alle Tests operativ. Nach der Testanordnung bleiben sechs Monate, um den Testumfang zur Validierung einzureichen.

Gibt es eine Erstfrist? Das oft genannte Datum 17. Januar 2028 ist keine TLPT-Frist. Es stammt aus Artikel 58 DORA und ist der Termin, bis zu dem die Kommission die Verordnung überprüft und dem Parlament und dem Rat berichtet. Eine feste Frist für den ersten TLPT nennt DORA nicht, der Zeitpunkt hängt vom Bescheid der Aufsicht ab.

Was ist mit allen, die nicht benannt werden?

Für alle anderen gilt nicht „kein Test", sondern der Normalbetrieb. Artikel 24 DORA verlangt ein Programm zum Testen der digitalen operationalen Resilienz, das nach Artikel 25 unter anderem Schwachstellenscans, Netzwerksicherheitsbewertungen, Szenariotests und Penetrationstests umfasst. Bei allen IKT-Systemen und Anwendungen, die kritische oder wichtige Funktionen unterstützen, schreibt Artikel 24 Absatz 6 mindestens jährliche Tests vor. Für das Zahlungsinstitut aus unserem Beispiel heißt das: ein jährlicher Penetrationstest der Zahlungsplattform, regelmäßige Schwachstellenscans und einmal im Jahr eine Notfallübung. Das sind Aufgaben, die ein ISMS ohnehin trägt, nur mit den Fristen von DORA im Kalender.

Was ändert die Aufsicht über kritische IKT-Drittdienstleister?

DORA stellt kritische IKT-Drittdienstleister unter eine direkte Aufsicht der europäischen Aufsichtsbehörden EBA, ESMA und EIOPA. Die Kriterien stehen in Artikel 31: systemische Auswirkungen, Bedeutung der abhängigen Finanzunternehmen, Abhängigkeit bei kritischen Funktionen und Substituierbarkeit. Am 18. November 2025 haben die Aufsichtsbehörden die erste Liste veröffentlicht, mit 19 benannten Anbietern. Dazu gehören laut den Veröffentlichungen unter anderem Amazon Web Services, Google Cloud, Microsoft, SAP und die Deutsche Telekom. Die vollständige Liste führt die EBA auf ihrer Website. Die Behörden aktualisieren die Liste nach Artikel 31 Absatz 9 jährlich.

Was bedeutet das für dich? Erstens: Die Benennung ersetzt deine Pflichten nicht. Du bleibst für deine Verträge, dein Register und deine Exit-Strategie voll verantwortlich, auch wenn dein Dienstleister direkt beaufsichtigt wird. Zweitens: Die Aufsicht kann Empfehlungen aussprechen, und im äußersten Fall kann sich daraus für dich die Frage ergeben, ob du einen Dienst aussetzen oder beenden musst. Auch deshalb gehören Konzentrationsrisiko und Exit-Plan in dein Register. Drittens: Die Aufsichtsbehörden ziehen die Daten für ihre Bewertung aus den Registern der Finanzunternehmen. Dein Register ist also ein Baustein dafür, wer als kritisch eingestuft wird.

Für kleinere Dienstleister wie MSPs ist die Benennung kaum ein Thema. Artikel 31 Absatz 8 nimmt etwa Dienstleister aus, die nur in einem Mitgliedstaat Finanzunternehmen bedienen, die ebenfalls nur dort tätig sind. Aber auch kleine Dienstleister hängen oft in Ketten, in denen ein benannter Anbieter weiter hinten steht. Wie sich Risiken aus solchen Ketten auf EU-Ebene weiter verschärfen, beschreibt der Artikel zu Hochrisiko-Lieferanten und ICT-Lieferkettensicherheit im Cybersecurity Act 2.

Pflichten im Überblick: Wer macht was in welchem Rhythmus?

Checkliste: Register-Pflege

Aufbau und Verantwortung

• Eine verantwortliche Stelle für das Register benannt, Stellvertretung geregelt
• Für jeden Dienstleister einen Eigentümer im Haus benannt (Einkauf, Fachbereich oder IT)
• Datenmodell festgelegt, in dem jede Angabe nur einmal gepflegt wird (LEI, Standort, Vertrag)
• Kriterien für „kritisch oder wichtig" dokumentiert und von der Leitung genehmigt

Laufende Pflege

• Registereintrag ist Pflichtschritt im Beschaffungsprozess, vor der Vertragsunterschrift
• Vertragsänderungen, Verlängerungen und Kündigungen lösen eine Aktualisierung aus
• Dienstleister müssen Änderungen bei Unterauftragnehmern und Standorten vorab melden (vertraglich geregelt)
• Quartalsabgleich mit Buchhaltung, Einkauf und Vertragsablage, um nicht erfasste Dienste zu finden
• Anzeige an die Aufsicht bei neuen Verträgen für kritische oder wichtige Funktionen geprüft

Datenqualität

• Alle Kennungen gegen das öffentliche LEI-Register geprüft, keine Dummy-Werte
• Unterauftragnehmer mit Rang in der Dienstleistungskette erfasst, bei kritischen Diensten vollständig
• Pflichtfelder bei kritischen Funktionen gefüllt (Sensibilität, Wiederherstellungsziele, Auswirkung)
• Sonderwerte korrekt genutzt (unbefristete Verträge, fehlendes Audit)
• Validierungslauf in der Testumgebung der BaFin eingeplant, nicht erst am letzten Tag

Stichtag und Meldung

• Freeze zum 31. Dezember durchgeführt, Fachbereiche haben ihre Zeilen gegengelesen
• Zugang zum MVP-Portal und zum DORA-Fachverfahren vor Jahresende geprüft
• Meldefenster der BaFin im Kalender (sobald veröffentlicht), Puffer vor dem 31. März
• Rückmeldungen und Fehlerprotokolle ausgewertet, Korrekturen eingearbeitet

Verträge und Exit

• Verträge für kritische oder wichtige Funktionen gegen Artikel 30 Absatz 2 und 3 geprüft
• Ausstiegsplan je kritischem Dienstleister vorhanden, mit Auslösern, Alternative und Übergangszeitraum
• Letzter Exit-Test oder Tabletop-Übung dokumentiert, Termin für den nächsten gesetzt
• Datum des letzten Audits je Dienstleister im Register, Folgeaudit geplant

Für Dienstleister und MSPs

• LEI oder EUID beantragt und gültig
• Standarddatensatz zu Leistungen, Standorten und Unterauftragnehmern für Finanzkunden aktuell
• Vertragsvorlage mit Artikel-30-Klauseln, insbesondere Audit, Exit und Mitwirkung bei TLPT
• Prozess, der Änderungen an Unterauftragnehmern und Standorten rechtzeitig an Finanzkunden meldet

Häufige Fehler beim Informationsregister

Das Register als Märzprojekt behandeln. Wer erst im Februar Verträge einsammelt, findet fehlende Kennungen, unklare Kündigungsfristen und vergessene Dienste zu einem Zeitpunkt, an dem die Lieferanten nicht schnell antworten. Aktualisiere ereignisgetrieben und ergänze Quartalschecks.

Nur die direkten Dienstleister erfassen. Bei kritischen oder wichtigen Funktionen verlangt das Register Unterauftragnehmer. Wer seinen MSP nie nach dessen Hoster gefragt hat, kann diese Zeilen nicht füllen. Hol die Auskunft vertraglich und bei der Bewertung ein.

Kritikalität aus dem Bauch festlegen. Wenn „kritisch oder wichtig" je nach Bearbeiter unterschiedlich ausgelegt wird, ist das Register inkonsistent und die Anzeigepflicht nicht prüfbar. Dokumentiere die Kriterien, verknüpfe sie mit den Funktionen und lass die Leitung sie freigeben.

Exit-Pläne, die nie getestet wurden. Ein Plan, der nur im Ordner liegt, erfüllt Artikel 28 Absatz 8 nicht. Der Gesetzestext verlangt ausdrücklich ausreichende Tests. Plane mindestens eine Tabletop-Übung pro Jahr für die wichtigsten Dienstleister.

Dummy-Kennungen und ungeprüfte Daten. Eine ausgedachte LEI besteht keine Validierung und verfehlt ihren Zweck. Prüfe jede Kennung gegen das offizielle Register und halte sie aktuell.

Fazit: Das Register ist ein Dauerbetrieb, kein Märzprojekt

Der Zyklus 2027 bringt nach BaFin-Angaben keine neue Taxonomie, aber den gleichen Anspruch an Datenqualität. Plane den Stichtag 31. Dezember 2026 als Freeze ein, prüfe bis dahin Kennungen, Unterauftragnehmer und Exit-Angaben für deine kritischen Dienstleister und teste mindestens einen Ausstiegsplan. Als Dienstleister legst du deinen Finanzkunden einen aktuellen Standarddatensatz vor, bevor sie fragen. Wenn du Dienstleister, Verträge und Fristen ohnehin in ISMS Lite führst, hast du die Datenbasis fürs Register schon beisammen.

Weiterführende Artikel

• DORA für den Finanzsektor: Was kommt nach NIS2?
• Lieferantenbewertung mit Sicherheitsfragebogen: Vorlage und Vorgehen
• NIS2 für IT-Dienstleister und MSPs: Doppelrolle als Betroffener und Berater
• IT-Sicherheitsklauseln in Verträgen: Was du von Dienstleistern fordern solltest
• Supply-Chain-Angriffe: Wie du dich vor kompromittierten Lieferanten schützt