DORA für IT-Dienstleister — Anforderungen an Zulieferer

Die DORA-Verordnung (EU 2022/2554) stellt umfassende Anforderungen an IT-Dienstleister, die für Finanzunternehmen tätig sind. Für die Zielgruppe dieses Beitrags lautet die wichtigste Einordnung deshalb zuerst: DORA für IT-Dienstleister bedeutet meist keine vollständige Direktregulierung wie bei Banken oder Versicherern, aber sehr wohl harte Anforderungen an Zulieferer über Verträge, Prüfungen, Registerdaten, Exit-Fähigkeit und Lieferkettenkontrolle.

Wenn Sie die Grundlagen der Verordnung zuerst im Gesamtbild einordnen wollen, lesen Sie parallel unseren Überblick zur DORA-Verordnung, den Praxisleitfaden zu DORA-Anforderungen und die Branchenseite für IT-Dienstleister. Für Teams, die Governance nicht nur im Finanzsektor, sondern auch beim KI-Einsatz strukturieren wollen, ist außerdem der Beitrag zur KI-Verordnung im Mittelstand relevant.

Warum DORA auch IT-Dienstleister betrifft

DORA betrifft IT-Dienstleister, weil Finanzunternehmen ihre digitale Resilienz nicht isoliert erfüllen können, sondern über ihre Auslagerungen, Cloud-Services, Managed Services, SaaS-Plattformen, Rechenzentren, Support-Partner und Subunternehmer hinweg absichern müssen. Genau deshalb verankert Kapitel V der Verordnung die Steuerung von IKT-Drittparteirisiken in Art. 28 bis 30 und baut für kritische Anbieter in Art. 31 bis 44 zusätzlich eine europäische Aufsicht auf.

Für die meisten Zulieferer ist die Rechtslage zweistufig. Erstens bleibt die Primärverantwortung bei den Finanzunternehmen. Art. 28 Abs. 1 stellt klar, dass Finanzunternehmen IKT-Drittparteirisiken als integralen Teil ihres IKT-Risikomanagements behandeln müssen und für die Einhaltung der DORA-Anforderungen verantwortlich bleiben. Zweitens werden IT-Dienstleister in diese Governance hineingezogen, weil die Kunden nur dann compliant sein können, wenn der Dienstleister vertraglich, technisch und organisatorisch mitspielt.

Für IT-Dienstleister ist deshalb nicht die Frage entscheidend, ob DORA „formal direkt“ gilt, sondern an welcher Stelle die eigenen Leistungen kritische oder wichtige Funktionen eines Finanzunternehmens stützen. Wer Kernbankensysteme hostet, Identity- und Access-Management bereitstellt, Zahlungsverkehrsplattformen betreibt, regulatorische Reports verarbeitet, Security-Monitoring übernimmt oder Recovery-Services liefert, sitzt regelmäßig in einem DORA-relevanten Bereich.

Das hat konkrete Folgen für Vertrieb, Legal, Informationssicherheit und Delivery. Vertragsverhandlungen werden detaillierter. Kunden verlangen Vorfallfristen, Audit-Rechte, Mitwirkung bei Resilienztests, Transparenz zu Datenstandorten, Offenlegung von Subunternehmern und Nachweise zur Exit-Fähigkeit. Wer diese Punkte erst im letzten Vertragsredlining entdeckt, verliert Zeit, Marge und im Zweifel den Auftrag.

Die operative Empfehlung lautet daher: Behandeln Sie DORA als Beschaffungs- und Governance-Standard Ihrer Finanzkunden. Sobald Ihr Unternehmen Leistungen in den regulierten Betrieb eines Finanzunternehmens einbringt, sollten Sie Standardvertragsbausteine, Audit-Antworten, Lieferketteninformationen, Notfallprozesse und Datenportabilität so vorbereiten, dass ein Kunde seine Pflichten aus Art. 28 bis 30 ohne Sonderprojekt nachweisen kann.

Kritische IKT-Drittanbieter — Wann greift die direkte Aufsicht?

Die direkte Aufsicht greift nicht für jeden IT-Dienstleister, sondern nur für Anbieter, die nach Art. 31 als kritische IKT-Drittanbieter eingestuft werden. Das ist die entscheidende Abgrenzung gegen verbreitete Missverständnisse: DORA macht nicht jeden SaaS- oder Managed-Service-Anbieter automatisch zum direkt beaufsichtigten Unternehmen.

Art. 31 nennt vier Kernkriterien für die Einstufung. Erstens geht es um den systemischen Einfluss eines Ausfalls auf Stabilität, Kontinuität oder Qualität von Finanzdienstleistungen. Zweitens wird betrachtet, wie systemisch wichtig die Finanzunternehmen sind, die den Anbieter nutzen. Drittens zählt die Abhängigkeit von Leistungen, die kritische oder wichtige Funktionen betreffen, auch bei indirekter Nutzung über Subunternehmer. Viertens ist die Substituierbarkeit zentral: Wenn es kaum Alternativen gibt oder eine Migration technisch, finanziell oder operativ kaum beherrschbar ist, steigt das Risiko einer kritischen Einstufung.

Damit ist auch klar, warum große Cloud-, Plattform- oder Infrastruktur-Anbieter besonders im Fokus stehen. Wer in vielen Instituten gleichzeitig läuft, tief in kritische Prozesse integriert ist und sich nur schwer ersetzen lässt, erfüllt eher die Logik des Art. 31. Für kleinere IT-Dienstleister ist die direkte Aufsicht seltener, aber nicht ausgeschlossen, wenn sie in einer hochkonzentrierten Nische tätig sind oder eine sehr spezielle technische Abhängigkeit erzeugen.

Mit der Einstufung beginnt der Oversight-Rahmen aus Art. 32 bis 44. Das ist mehr als eine bloße Beobachtung. Der zuständige Lead Overseer wird nach Art. 31 benannt; Art. 32 regelt das Oversight Forum; Art. 33 beschreibt die Aufgaben des Lead Overseer bei der Bewertung von Sicherheits-, Governance-, Incident- und Kontinuitätsmaßnahmen. In der Praxis bedeutet das für kritische Anbieter zusätzliche Informationspflichten, Prüfungen, Empfehlungen und einen engeren Dialog mit europäischen Aufsichtsstellen.

Für Zulieferer ist besonders relevant, dass die Aufsicht nicht bei abstrakter Governance stehen bleibt. Art. 35 ermöglicht Empfehlungen an kritische Anbieter. Art. 41 und Art. 42 geben dem Lead Overseer weitgehende Untersuchungs- und Inspektionsrechte. Art. 43 und Art. 44 regeln Gebühren und internationale Zusammenarbeit. Zusätzlich können nationale Behörden gegenüber Finanzunternehmen als letztes Mittel verlangen, Services vorübergehend auszusetzen oder Verträge zu beenden, wenn wesentliche Risiken nicht behoben werden.

Für IT-Dienstleister folgt daraus ein nüchterner Schluss: Auch wenn Ihr Unternehmen nicht als kritisch eingestuft ist, orientieren sich große Finanzkunden oft an genau dieser Oversight-Logik. Sie fragen nach Governance, Reporting, Vorfallprozessen, Auditrechten und Lieferkettenstabilität schon heute so, als müsste Ihr Unternehmen im Ernstfall einer deutlich intensiveren Prüfung standhalten.

Vertragliche Anforderungen nach DORA Art. 30

Art. 30 ist für IT-Dienstleister der praktisch wichtigste Einzelartikel, weil er den Mindestinhalt von Verträgen über IKT-Services vorgibt. Für Anbieter bedeutet das: Wer Finanzkunden bedient, braucht belastbare Standardklauseln, nicht nur gute Technik.

Bereits Art. 30 Abs. 1 verlangt, dass Rechte und Pflichten des Finanzunternehmens und des IKT-Drittanbieters klar zugeordnet und schriftlich festgelegt werden. Das klingt banal, hat aber operative Wirkung. Lose Leistungsbeschreibungen, widersprüchliche Anhänge oder unklare Rollen bei Incident Response, Datenrückgabe und Subunternehmern passen nicht zu DORA.

Art. 30 Abs. 2 nennt den Mindestkatalog für alle IKT-Verträge. Dazu gehören eine klare Beschreibung der Leistungen, Angaben zu Regionen oder Ländern der Leistungserbringung und Datenverarbeitung, Regeln zu Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit, Vorgaben für Zugriff, Recovery und Rückgabe von Daten, Service Levels, Hilfe bei IKT-bezogenen Vorfällen, Kooperation mit zuständigen Behörden sowie Kündigungsrechte. Schon hier zeigt sich: DORA ist nicht nur ein Security-Thema, sondern auch ein Daten-, Betriebs- und Vertragsarchitektur-Thema.

Noch schärfer wird es, wenn der Service eine kritische oder wichtige Funktion unterstützt. Art. 30 Abs. 3 verlangt dann zusätzliche Vertragsinhalte wie präzise quantitative und qualitative Leistungsziele, Meldepflichten bei Entwicklungen mit wesentlichem Einfluss auf die Leistungserbringung, getestete Business-Contingency-Pläne, angemessene Sicherheitsmaßnahmen, die Mitwirkung an Threat-Led Penetration Testing nach Art. 26 und 27, laufende Monitoring-Rechte sowie umfassende Zugangs-, Inspektions- und Audit-Rechte für Finanzunternehmen, beauftragte Dritte, zuständige Behörden und gegebenenfalls den Lead Overseer.

Für IT-Dienstleister ist besonders wichtig, dass DORA keine rein symbolischen Audit-Klauseln verlangt. Der Vertrag muss die tatsächliche Durchsetzbarkeit der Rechte sicherstellen. Wenn interne Policies, Subunternehmerverträge oder technische Betriebsmodelle Vor-Ort-Prüfungen, Dokumentenzugriff oder Testmitwirkung faktisch ausschließen, entsteht ein Compliance-Problem auf Kundenseite und damit sehr schnell ein Vertriebsproblem auf Dienstleisterseite.

Die folgende Übersicht zeigt, welche Klauseln regelmäßig vorbereitet werden sollten:

Die pragmatische Konsequenz lautet: IT-Dienstleister sollten DORA-fähige Vertragsmodule zentral pflegen. Wer weiterhin jeden Kundenvertrag individuell improvisiert, skaliert im Finanzsektor schlecht.

Register aller IKT-Drittparteienverträge (Art. 28 Abs. 3)

Art. 28 Abs. 3 verpflichtet Finanzunternehmen dazu, ein Register aller vertraglichen Vereinbarungen über IKT-Services mit IKT-Drittanbietern zu führen und aktuell zu halten. Diese Pflicht liegt formell beim Finanzunternehmen. Für IT-Dienstleister ist sie trotzdem hochrelevant, weil sie die Daten liefern müssen, die im Register landen.

Das Register muss zwischen Verträgen für kritische oder wichtige Funktionen und sonstigen IKT-Services unterscheiden. Außerdem müssen Finanzunternehmen der zuständigen Behörde mindestens jährlich Informationen über neue Verträge, Anbietergruppen, Vertragsarten sowie die betroffenen IKT-Services und Funktionen melden und auf Anfrage das vollständige Register vorlegen. Daraus folgt für Dienstleister: Unvollständige Stammdaten, unklare Leistungsabgrenzungen oder untransparente Subunternehmer erschweren unmittelbar die Compliance des Kunden.

In der Praxis sollten IT-Dienstleister deshalb ein standardisiertes DORA-Informationsblatt pflegen. Darin gehören mindestens Leistungsbeschreibung, betroffene Systeme, Betriebsmodell, Datenstandorte, Aufbewahrungs- und Rückgabeprozesse, Subunternehmer, Ansprechpartner, relevante Zertifizierungen, Business-Continuity-Angaben und Änderungen mit potenzieller Wesentlichkeit. Je besser diese Informationen strukturiert vorliegen, desto schneller können Beschaffung, Legal und Vendor Management des Kunden das Register pflegen.

Art. 28 Abs. 4 verlangt vor Vertragsschluss zusätzlich mehrere Bewertungen durch das Finanzunternehmen: Ist die Funktion kritisch oder wichtig? Sind aufsichtsrechtliche Voraussetzungen erfüllt? Welche Risiken entstehen? Gibt es Konzentrationsrisiken? Ist der Anbieter geeignet? Entstehen Interessenkonflikte? IT-Dienstleister sollten diese Fragen antizipieren und passende Antworten nicht erst nach einer Eskalation an den Kunden liefern.

Gerade hier zeigt sich der Unterschied zwischen einem generischen IT-Anbieter und einem finanzsektorfähigen Zulieferer. Der zweite liefert nicht nur ein Produkt, sondern auch belastbare Governance-Informationen. Das reduziert Rückfragen, beschleunigt Procurement und erhöht die Chance, in standardisierte Lieferantenlisten aufgenommen zu werden.

Ausstiegsstrategien und Exit-Pläne — Pflicht für Auftraggeber

Exit-Pläne sind nach DORA Pflicht für die Auftraggeber, aber faktisch nur mit dem Dienstleister umsetzbar. Art. 28 Abs. 8 verlangt für IKT-Services, die kritische oder wichtige Funktionen unterstützen, dokumentierte, getestete und regelmäßig überprüfte Exit-Strategien.

Die Anforderungen sind anspruchsvoll. Finanzunternehmen müssen aus einem Vertrag aussteigen können, ohne ihre Geschäftstätigkeit zu unterbrechen, regulatorische Anforderungen zu verletzen oder die Kontinuität und Qualität ihrer Leistungen gegenüber Kunden zu gefährden. Art. 28 Abs. 8 verlangt außerdem alternative Lösungen, Übergangspläne, sichere und vollständige Datenübertragungen sowie Kontinuitätsmaßnahmen für den Ausstiegsfall.

Für IT-Dienstleister heißt das: „Kündbar“ reicht nicht. Ein DORA-fähiger Anbieter muss beschreiben können, wie Daten exportiert werden, welche Formate verfügbar sind, wie lange Parallelbetrieb oder Übergangsunterstützung möglich ist, welche Abhängigkeiten in Identitäten, APIs, Logs, Backups und Schlüsselverwaltung bestehen und welche Mitwirkung der Kunde für einen Wechsel braucht.

Besonders kritisch sind proprietäre Datenmodelle, intransparente API-Limits, fehlende Exportfunktionen, unklare Löschroutinen oder Subunternehmer, die einen Exit faktisch blockieren. Solche Punkte sind unter DORA nicht nur unangenehm, sondern können im Procurement oder in laufenden Vertragsbeziehungen zum echten Ausschlussgrund werden. Denn Art. 29 und Art. 31 stellen die Substituierbarkeit ausdrücklich in den Mittelpunkt.

Die beste Vorbereitung für Dienstleister ist ein dokumentiertes Exit-Paket. Dazu gehören Datenrückgabeprozesse, technische Migrationsoptionen, definierte Transition-Services, Verantwortlichkeiten im Offboarding, Fristen, Support-Level und Nachweise, dass der Exit nicht nur vertraglich versprochen, sondern betrieblich beherrscht wird.

Subunternehmer-Ketten — Anforderungen an die Lieferkette

DORA verlangt keine vollständige vertikale Kontrolle über das gesamte Internet, aber sehr wohl Transparenz und Steuerbarkeit in der Lieferkette. Art. 29 und Art. 30 sind hier der zentrale Maßstab.

Art. 29 verlangt vor allem bei Leistungen für kritische oder wichtige Funktionen eine Vorabbewertung von Konzentrationsrisiken und der Substituierbarkeit. Wenn mehrere kritische Services auf demselben Anbieter oder auf eng verbundenen Anbietern hängen, steigt das Risiko. Zusätzlich müssen Finanzunternehmen bei möglicher Weitervergabe an weitere IKT-Dienstleister die Vorteile und Risiken solcher Subunternehmerketten abwägen, gerade bei Drittländern, Insolvenzrecht, Datenzugriff und komplexen Ketten.

Art. 30 Abs. 2 und Abs. 3 greift diese Logik vertraglich auf. Der Vertrag muss offenlegen, ob Unterbeauftragung für kritische oder wichtige Funktionen zulässig ist und unter welchen Bedingungen. Außerdem müssen lange oder komplexe Subunternehmerketten so gesteuert werden, dass der Auftraggeber seine Leistung vollständig überwachen kann und die zuständige Behörde die Finanzinstitution weiterhin wirksam beaufsichtigen kann.

Für IT-Dienstleister ist das ein klassisches Lieferkettenproblem mit Compliance-Folge. Viele Anbieter wissen sehr genau, wer ihr direkter Cloud- oder Security-Partner ist, aber deutlich weniger genau, wo Daten tatsächlich landen, welche Support-Dienstleister im Hintergrund agieren oder welche kritischen Betriebsleistungen an weitere Spezialanbieter delegiert werden. Unter DORA reicht diese Unschärfe nicht mehr aus, wenn Finanzunternehmen auf die Informationen angewiesen sind.

Die praktische Erwartung an Zulieferer ist deshalb dreifach:

1. Sie müssen kritische Subunternehmer transparent benennen und Änderungen rechtzeitig ankündigen.
2. Sie müssen vertraglich sicherstellen, dass Pflichten zu Sicherheit, Audit, Incident Support, Datenrückgabe und Kontinuität entlang der Kette weitergereicht werden.
3. Sie müssen intern nachvollziehen können, an welcher Stelle in der Lieferkette Konzentrations- oder Exit-Risiken entstehen.

Wer diese Transparenz nicht liefern kann, wird im Finanzsektor schnell als Black Box wahrgenommen. Das ist nicht nur ein Rechtsrisiko für den Kunden, sondern ein Wettbewerbsnachteil für den Dienstleister.

Was IT-Dienstleister jetzt tun müssen — Checkliste

IT-Dienstleister sollten DORA jetzt nicht als Rechtsabteilungsthema ablegen, sondern als Vertriebs-, Delivery- und Security-Programm behandeln. Die folgenden Schritte schaffen in den meisten Unternehmen die nötige Baseline:

1. DORA-relevante Kunden und Leistungen kartieren. Identifizieren Sie alle Finanzkunden und markieren Sie, welche Services kritische oder wichtige Funktionen stützen könnten.
2. Vertragsmodule nach Art. 30 vorbereiten. Hinterlegen Sie Standardklauseln zu SLA, Standorten, Incident Support, Audit, Subunternehmern, Exit und Testmitwirkung.
3. Registerdaten standardisieren. Stellen Sie strukturierte Informationen für Kunderegister nach Art. 28 Abs. 3 bereit, inklusive Leistungsumfang, Datenstandorten, Subunternehmern und Ansprechpartnern.
4. Exit-Fähigkeit dokumentieren. Definieren Sie Datenexporte, Übergangsservices, Offboarding-Prozesse und technische Migrationspfade.
5. Subunternehmer steuern. Prüfen Sie, welche Unterauftragnehmer kritisch sind, welche Drittländer betroffen sind und wo Pflichten vertraglich weitergereicht werden müssen.
6. Audit- und Prüfprozesse operationalisieren. Benennen Sie Verantwortliche, bauen Sie einen Nachweisraum auf und legen Sie fest, wie Audits, Vor-Ort-Besuche und Fragen von Kunden oder Prüfern beantwortet werden.
7. Vorfallkommunikation schärfen. Klären Sie Meldewege, Ansprechpartner, Reaktionszeiten und Unterstützungsleistungen bei IKT-bezogenen Vorfällen.
8. Management sensibilisieren. Geschäftsführung, Legal, Vertrieb, Service Management und Security sollten dieselbe DORA-Logik verstehen, insbesondere die Artikel 28 bis 44.

Die zentrale Botschaft dieser Checkliste lautet: Finanzsektorfähigkeit ist unter DORA ein Produktmerkmal. Kunden kaufen nicht nur Funktionen, sondern belastbare Resilienz, Prüfbarkeit und Exit-Fähigkeit mit ein.

Häufig gestellte Fragen (FAQ)

Gilt DORA direkt für IT-Dienstleister?

In der Regel nicht unmittelbar in vollem Umfang. Die Verordnung (EU) 2022/2554 richtet sich primär an Finanzunternehmen. IT-Dienstleister werden aber mittelbar stark eingebunden, weil ihre Kunden aus dem Finanzsektor die Anforderungen aus Art. 28 bis 30 vertraglich und organisatorisch an sie weitergeben. Eine direkte europäische Aufsicht greift nur, wenn ein Anbieter als kritischer IKT-Drittanbieter nach Art. 31 ff. eingestuft wird.

Was bedeutet „kritischer IKT-Drittanbieter“?

Ein kritischer IKT-Drittanbieter ist ein Dienstleister, den die europäischen Aufsichtsbehörden wegen seiner Bedeutung für kritische oder wichtige Funktionen von Finanzunternehmen als systemisch relevant einstufen. Maßgeblich sind nach Art. 31 insbesondere Reichweite, Abhängigkeit, Substituierbarkeit und potenzielle Auswirkungen eines Ausfalls. Dann greifen die Oversight-Regeln aus Art. 32 bis 44.

Welche Verträge müssen angepasst werden?

Angepasst werden müssen vor allem Verträge über IKT-Services für Finanzunternehmen, insbesondere wenn diese Services kritische oder wichtige Funktionen unterstützen. Art. 30 verlangt unter anderem klare Leistungsbeschreibungen, Angaben zu Leistungsorten und Datenstandorten, Unterstützung bei Vorfällen, Audit- und Zugangsrechte, Mitwirkung bei Tests, Kündigungsrechte und Übergangsregelungen für den Exit.

Können kleine IT-Dienstleister betroffen sein?

Ja. Die Unternehmensgröße des Dienstleisters schützt nicht vor DORA-Anforderungen, wenn Banken, Versicherer oder andere Finanzunternehmen auf seine Leistung für wichtige Prozesse angewiesen sind. Kleine Anbieter sind oft nicht direkt beaufsichtigt, müssen aber dieselben vertraglichen, technischen und dokumentarischen Erwartungen ihrer regulierten Kunden erfüllen.

Brauchen IT-Dienstleister eine eigene DORA-Schulung?

Eine gesetzlich vorgeschriebene Standard-Schulung nur für IT-Dienstleister nennt DORA nicht. Praktisch brauchen Vertrieb, Legal, Service Management, Security und Delivery aber ein gemeinsames Verständnis der Anforderungen aus Art. 28 bis 30 sowie der Oversight-Logik aus Art. 31 bis 44, damit Verträge, Audits, Subunternehmer und Vorfallprozesse belastbar umgesetzt werden.

Der nächste Schritt für Ihr Unternehmen

Wenn Ihr Unternehmen Banken, Versicherer, Zahlungsdienstleister oder andere Finanzunternehmen beliefert, sollten Sie DORA nicht erst beim nächsten Vertragsanhang zum Thema machen. Der schnellste Weg ist ein internes Enablement für Vertrieb, Legal, Service Management und Security, damit Art. 28 bis 30 sowie die Logik der kritischen IKT-Drittanbieter nach Art. 31 bis 44 in Standardverträge, Audit-Prozesse und Lieferkettensteuerung übersetzt werden.

Wenn Sie Governance-Pflichten systematisch in Ihr Unternehmen tragen wollen, nutzen Sie unsere EU AI Act Schulung als kompakten Einstieg in dokumentierbare Compliance-Kompetenz und kombinieren Sie sie mit den Beiträgen zur DORA-Verordnung und zu den DORA-Anforderungen. So wird aus regulatorischem Druck ein belastbarer Umsetzungsstandard für Kundengespräche, Verträge und Delivery.