DORA-Compliance fur FinTech SaaS: Was ICT-Drittanbieter bis Ende 2026 liefern mussen

Der Digital Operational Resilience Act gilt seit Januar 2025 EU-weit. Inzwischen haben Banken, Versicherungsunternehmen und Investmentplattformen begonnen, Fragebögen an ihre Softwareanbieter zu schicken - und viele dieser Anbieter haben festgestellt, dass sie erheblich unvorbereitet sind. DORA-Compliance fur FinTech SaaS ist keine Zukunftspflicht mehr. Es ist eine gegenwärtige kommerzielle Realität: Finanzinstitute, die ihren Aufsichtsbehörden die Resilienz ihrer ICT-Drittanbieter nicht nachweisen können, kündigen Verträge und blockieren neue Deals.

Wenn du SaaS an EU-Finanzdienstleister verkaufst und deine DORA-Pflichten noch nicht erfasst hast, zeigt dir dieser Beitrag die konkreten technischen Anforderungen. Du brauchst kein Compliance-Team, um das richtig zu machen. Du musst verstehen, was Banken tatsächlich fragen - und die Features bauen, die diese Fragen beantworten.

Was DORA fur SaaS-Anbieter konkret bedeutet

DORA gilt direkt fur Finanzinstitute. Artikel 28 verpflichtet diese Institute jedoch, vertragliche und Auditrechte an ihre ICT-Drittanbieter weiterzugeben - das schließt praktisch jedes SaaS-Produkt ein, das Daten im Auftrag einer regulierten Einheit verarbeitet. Ob du ein Zahlungs-Gateway, eine KYC-API, ein Dokumentenmanagementsystem oder eine Datenanalyseplattform anbietest - wenn dein Produkt die operativen Systeme einer Bank beruhrt, bist du betroffen.

Die Pflichten, die auf dein Produkt zukommen, lassen sich in vier Kategorien einteilen: Incident-Reporting-Infrastruktur, Threat-Led-Penetration-Testing-Bereitschaft, Register-of-Information-Exporte und Exit-Plan-Dokumentation. Jede erfordert Engineering-Arbeit, nicht nur Policy-Dokumente.

Incident-Klassifizierung und das 4-Stunden-Problem

DORA setzt ein hartes 4-Stunden-Fenster fur Finanzinstitute, um wesentliche ICT-Incidents an ihre nationale Aufsichtsbehörde zu melden. Dein SaaS-Produkt ist Teil ihrer Incident-Timeline. Wenn dein Dienst ausfällt, sich verschlechtert oder kompromittiert wird, brauchen deine Kunden strukturierte Informationen von dir - schnell - damit sie ihre eigenen Meldepflichten erfullen können.

Was Banken in ihren DORA-Fragebögen fragen:

• Sendet deine Plattform strukturierte Incident-Benachrichtigungen mit Schweregrad-Klassifizierung, geschätzter Wiederherstellungszeit und betroffenen Funktionen?
• Pflegst du eine Klassifizierungstaxonomie, die auf DORAs Major/Significant/Minor-Incident-Stufen abbildet?
• Wird die Benachrichtigung innerhalb von 30 Minuten nach interner Meldung an einen designierten Sicherheitskontakt gesendet, mit Updates in definierten Intervallen bis zur Lösung?

Der erforderliche Engineering-Aufwand ist real, aber nicht außergewöhnlich. Du brauchst ein Incident-Klassifizierungsframework im Engineering-Runbook - einen Entscheidungsbaum, der beobachtbare Plattformereignisse (API-Fehlerrate, Datenbank-Replikationsverzögerung, Authentifizierungsfehlerrate) auf DORA-Schweregrade abbildet. Du benötigst einen internen Kommunikationskanal, der eine externe Statusseite und einen direkten E-Mail/Webhook-Kanal zu jedem Finanzinstitut-Kunden speist. Und du brauchst Dokumentation, die zeigt, dass dein Engineering-Team diesen Prozess probt.

Wenn dein aktuelles Incident-Management aus informellen Slack-Threads und Ad-hoc-E-Mails besteht, muss sich das ändern, bevor eine Unternehmensbank einen Vertrag unterschreibt.

TLPT-Bereitschaft: Threat-Led Penetration Testing

DORA schreibt Threat-Led Penetration Testing (TLPT) fur bedeutende Finanzeinheiten vor, und diese Einheiten sind vertraglich verpflichtet, sicherzustellen, dass ihre kritischen ICT-Drittanbieter bei Bedarf teilnehmen. TLPT ist kein Standard-Penetrationstest - es ist eine Red-Team-Ubung basierend auf aktueller Bedrohungsintelligenz, durchgefuhrt von akkreditierten Testern, auf Produktionssystemen.

Es ist unwahrscheinlich, dass du in ein vollständiges TLPT-Engagement einbezogen wirst, es sei denn, du bist ein kritischer Anbieter fur eine große Institution. Aber jeder Banken-Fragebogen fragt, ob du TLPT-bereit bist: Kannst du einem Red Team kontrollierten Zugang zu produktionsähnlicher Infrastruktur gewähren, ohne andere Kunden zu stören? Und kannst du deren Erkenntnisse unter NDA empfangen und innerhalb eines dokumentierten Zeitrahmens beheben?

Was du bauen oder dokumentieren musst:

• Eine Staging- oder Shadow-Umgebung, die die Produktionsarchitektur eng genug spiegelt, um fur einen Penetrationstest nutzlich zu sein
• Ein NDA- und Testscoping-Prozess, den dein Rechts- und Engineering-Team in unter zwei Wochen abwickeln kann
• Eine Schwachstellen-Behebungs-SLA mit Zeitplänen nach Schweregrad (kritisch, hoch, mittel) und Nachweis der historischen Einhaltung
• Einen designierten Ansprechpartner fur Sicherheitstestengagements

Die Umgebungsisolierung ist die größte Engineering-Investition - insbesondere bei Multi-Tenant-SaaS, wo ein Test gegen die Daten eines Mandanten laterale Bewegungen fur andere haben könnte. Die Lösung ist entweder eine dedizierte Single-Tenant-Testumgebung oder ein Mandantentrennungs-Audit, das nachweist, dass der Blast Radius begrenzt ist.

Informationsregister: Was deine Kunden einreichen mussen

DORA verpflichtet Finanzeinheiten, ein umfassendes Informationsregister fur alle ICT-Drittanbieterverträge zu fuhren. Die Europäischen Aufsichtsbehörden haben spezifische Datenvorlagen veröffentlicht - das Register muss Vertragslaufzeiten, Kritikalitätsklassifizierung, verarbeitete Datenkategorien, Unterauftragsverarbeiterketten und Kundigungsbestimmungen erfassen.

Deine Kunden werden auf dich zukommen, um das auszufüllen. Wenn du diesen Prozess schwierig oder langsam machst, wirst du zur Compliance-Belastung. Wenn du ihn reibungslos gestaltest, wirst du zum bevorzugten Anbieter.

So sieht es gut aus: ein dediziertes DORA-Dokumentationspaket, das du pflegst und versionierst. Dies umfasst typischerweise eine ausgefullte Informationsregistervorlage (mit deinen Feldern vorausgefullt), eine Liste deiner eigenen Unterauftragsverarbeiter und deren Standorte, eine Zusammenfassung deines Business-Continuity-Plans und deine Datenverarbeitungsvereinbarung. Manche Anbieter exponieren dies uber ein Trust Center; andere liefern es auf Anfrage als PDF. Beides funktioniert, aber es muss existieren und aktuell sein.

Die Unterauftragsverarbeiter-Frage verdient besondere Aufmerksamkeit. Wenn du AWS, Azure oder GCP als Infrastruktur verwendest, ist das unkompliziert zu dokumentieren. Wenn du Drittanbieter-Anreicherungsdienste, Betrugs-APIs oder KI-Inferenzanbieter nutzt, die Kundendaten beruhren, muss jeder in deiner Unterauftragsverarbeiterliste erscheinen - mit Verarbeitungsland und vertraglicher Grundlage.

Exit-Plan-Engineering

Das ist der Teil, den die meisten SaaS-Anbieter falsch machen, weil er kontraintuitiv wirkt: Die DORA-Compliance deiner Kunden erfordert einen glaubwurdigen Plan zur Kundigung ihres Vertrags mit dir und zur Migration zu einer Alternative - ohne operativen Unterbrechung. Du musst diesen Plan aktiv unterstutzen, nicht weil du Kunden verlieren willst, sondern weil Finanzinstitute vertraglich verpflichtet sind nachzuweisen, dass dies machbar ist.

Was ein DORA-konformer Exit-Plan von deiner Seite erfordert:

• Eine Datenexportfähigkeit, die einen vollständigen, maschinenlesbaren Export aller Kundendaten innerhalb eines definierten Zeitrahmens (typischerweise 30 Tage) produzieren kann
• Dokumentation aller proprietären Datenformate und ihrer Abbildung auf offene Standards
• Eine Ubergangsunterstützungszusage - ein dokumentierter Zeitraum, in dem du einen abwandernden Kunden unterstutzst, einschließlich API-Zugang während der Abwicklung
• Ein Wissenstransferpaket: API-Dokumentation, Datenwörterbücher, Integrationsspezifikationen

Die praktische Engineering-Implikation: Wenn dein SaaS undurchsichtige interne Datenmodelle verwendet oder Bulk-Export noch kein unterstutzes Feature ist, musst du es bauen. Banken verweigern zunehmend Vertragsabschlusse mit Anbietern, die keinen glaubwurdigen Exit-Plan vorweisen können. Das ist keine Drohung; es ist ein Beschaffungskriterium.

Wo du anfangen solltest, wenn du im Ruckstand bist

Wenn du das als Produktverantwortlicher oder CTO eines FinTech SaaS liest, das an EU-Finanzinstitute verkauft, und du diese Arbeit noch nicht begonnen hast: Du bist im Ruckstand - aber nicht katastrophal, wenn du jetzt anfängst.

Die Sequenz, die den schnellsten sinnvollen Fortschritt bringt:

Erstens: Erstelle ein Informationsregisterpaket. Das ist uberwiegend Dokumentationsarbeit und gibt dir sofort ein nutzliches Artefakt fur Enterprise-Interessenten. Zweitens: Implementiere strukturierte Incident-Benachrichtigungen. Das erfordert Engineering, hat aber einen klaren Umfang und einen schnellen Lieferzyklus. Drittens: Prufe deine Unterauftragsverarbeiterkette und aktualisiere deine Datenverarbeitungsvereinbarungen. Viertens: Baue die Datenexportfähigkeit auf, wenn sie noch nicht existiert. Funftens: Erstelle die Exit-Plan-Dokumentation.

TLPT-Bereitschaft ist wichtig, hat aber die längste Vorlaufzeit und den geringsten unmittelbaren kommerziellen Nutzen - priorisiere sie nach den anderen.

Das Geschäftskalkul ist eindeutig

Jedes Finanzinstitut, das DORA unterliegt, pruft seine ICT-Drittanbieter. Diese Audits haben Beschaffungskonsequenzen. Anbieter, die operative Resilienz nachweisen können, gewinnen Verträge, die nicht-konforme Anbieter verlieren. Wenn du im FinTech-Bereich in Europa tätig bist, ist DORA-Compliance keine Kosten - es ist eine Marktzugangsvoraussetzung.

Der erforderliche Engineering-Aufwand ist real, aber bewältigbar. Fur die meisten mittelgroßen SaaS-Produkte ist die vollständige Implementierung - Incident-Infrastruktur, Dokumentationspaket, Exportfähigkeit, Exit-Plan - ein Drei-bis-Sechs-Monats-Projekt mit einem fokussierten Team.

Wenn dein Produkt betroffen ist und du eine ehrliche Einschätzung deines aktuellen Stands und des Umsetzungspfads möchtest, ist der Ausgangspunkt eine strukturierte technische Uberprufung. Du erreichst das Wolf-Tech-Team unter hello@wolf-tech.io oder buchst einen Discovery-Call auf wolf-tech.io. Wir haben DORA-Implementierungen mit FinTech-SaaS-Produkten von Seed-Stage-Startups bis zu Series-B-Plattformen begleitet und können dir ein klares Bild deiner Lucken und einen realistischen Zeitplan zu deren Schließung geben.

Häufig gestellte Fragen

Gilt DORA fur SaaS-Anbieter, die selbst keine Finanzinstitute sind?

DORA gilt direkt fur EU-regulierte Finanzeinheiten. Artikel 28 verpflichtet diese Einheiten jedoch, DORA-konforme Vertragsklauseln in ihre Vereinbarungen mit ICT-Drittanbietern - einschließlich SaaS-Anbieter - aufzunehmen. In der Praxis begegnest du DORA-abgeleiteten Anforderungen uber deine Verträge, wenn du an EU-Banken oder Investmentfirmen verkaufst, unabhängig davon, wo dein Unternehmen ansässig ist.

Was ist der Unterschied zwischen einem wesentlichen und einem bedeutenden ICT-Incident nach DORA?

Die Europäischen Aufsichtsbehörden haben Klassifizierungskriterien veröffentlicht, die auf betroffener Kundenzahl, Unterbrechungsdauer, geografischer Reichweite und wirtschaftlichen Auswirkungen basieren. Ein wesentlicher Incident löst den 4-Stunden-Erstbericht und die 72-Stunden-Detailberichtspflicht aus. Bedeutende Incidents haben ein leichteres Meldeverfahren. Deine Plattform braucht einen Incident-Klassifizierungsprozess, der diese Bestimmung zuverlässig und schnell treffen kann.

Unterliegen Nicht-EU-SaaS-Anbieter DORA?

Ja, wenn sie Dienste fur EU-regulierte Finanzeinheiten erbringen. DORA kennt keine Ausnahme fur Anbieter außerhalb der EU. Ein US-amerikanischer SaaS-Anbieter, der Dienste fur eine deutsche Bank erbringt, unterliegt denselben vertraglichen DORA-Verpflichtungen wie ein Berliner Anbieter.

Wie sieht ein DORA-Audit durch ein Finanzinstitut tatsächlich aus?

Meistens nimmt es die Form eines detaillierten Fragebogens (häufig auf einer standardisierten Vorlage basierend) an, gefolgt von einer Nachweispruung. Fur kritische ICT-Anbieter sind Vor-Ort-Audits möglich. Der Fragebogen deckt typischerweise deinen Business-Continuity-Plan, Incident-Management-Prozess, Sicherheitstestpraktiken, Unterauftragsverarbeiterkette und Exit-Plan ab. Eine gut vorbereitete Dokumentation verkurzt die Zeit fur diese Audits erheblich.