DORA und IKT-Drittparteienrisiko: Kontrollen, die FinTech-SaaS noch in diesem Quartal ausliefern kann

Der Digital Operational Resilience Act ist seit dem 17. Januar 2025 anwendbar, und DORA Compliance ist für FinTech-Teams keine reine Abhak-Übung. Die Artikel 28 bis 44 der DORA führen einen strukturierten Rahmen für das Management von IKT-Drittparteienrisiken ein, der jeden SaaS-Anbieter betrifft, der in den europäischen Finanzsektor verkauft. Wenn dein Produkt Zahlungen verarbeitet, Anlagedaten hostet oder an das Kernsystem einer Bank angebunden ist, dann ist das Finanzunternehmen auf der anderen Seite des Vertrags nun verpflichtet, dir DORA-konforme Pflichten aufzuerlegen.

Dieser Beitrag übersetzt drei konkrete Anforderungen in Engineering-Aufgaben: den Aufbau eines Dienstleisterregisters, das Schreiben von Ausstiegsplänen, die einer Aufsicht standhalten, und die Durchführung von Resilienztests, die dein Team noch vor Jahresende abschließen kann.

Warum das IKT-Drittparteienrisiko die DORA-Anforderung ist, die die meisten SaaS-Teams ignorieren

Die Vorgaben mit der größten Aufmerksamkeit, also Meldefristen für Vorfälle und bedrohungsgeleitete Penetrationstests, erfordern erhebliche Vorbereitung, deshalb kümmern sich Teams zuerst darum. Das Management von Drittparteienrisiken fühlt sich wie ein Einkaufsthema an und nicht wie ein Software-Thema. Diese Einordnung ist falsch.

Finanzunternehmen müssen unter DORA ein vollständiges Register aller genutzten IKT-Drittdienstleister führen (Artikel 28 Absatz 3). Wenn dein Kunde geprüft wird, legt er dieses Register vor. Steht dein Produkt darin und du kannst deine eigenen Kontrollen gegenüber Dritten nicht belegen, gefährdest du die Compliance-Position deines Kunden. Praktisch relevanter: Immer mehr Ausschreibungsfragebögen für Verträge im Finanzsektor verlangen von Anbietern inzwischen direkt eine Beschreibung ihres IKT-Dienstleisterregisters und ihrer Ausstiegsplanung.

Der zweite Druckpunkt ist das Konzentrationsrisiko. DORA (Artikel 29) verpflichtet Finanzunternehmen dazu, Situationen zu identifizieren, in denen kritische Funktionen von wenigen Drittdienstleistern abhängen. Cloud-Anbieter, CDNs, DNS-Resolver, Zahlungsdienstleister: Wenn deine SaaS-Anwendung für eine kritische Fähigkeit wesentlich von einem einzigen Anbieter abhängt und du keine dokumentierte Ausstiegsstrategie hast, ist das ein Konzentrationsrisiko, das dein Kunde seiner Aufsicht offenlegen muss.

Dem zuvorzukommen ist unkompliziert. Keine der drei folgenden Kontrollen braucht Monate an Arbeit.

Kontrolle 1: Ein Dienstleisterregister in einer Woche aufbauen

Das Register selbst muss nicht ausgefeilt sein. Es braucht Vollständigkeit und strukturierte Daten. Erfasse für jeden IKT-Dienstleister, auf den du dich stützt:

• Name und Rechtsträger des Anbieters - die Vertragspartei, nicht nur der Produktname
• Servicekategorie - Cloud-Infrastruktur, Zahlungsabwicklung, Identität und Authentifizierung, Monitoring, CDN, DNS, Datenspeicherung, Unterauftragsverarbeiter
• Kritikalitätseinstufung - ob der Dienst eine Funktion trägt, deren Ausfall dein Produkt vollständig lahmlegen würde (kritisch) oder es beeinträchtigt, ohne es komplett auszuschalten (wichtig)
• Datenklassifizierung - ob der Dienst personenbezogene Daten, Finanzdaten oder keines von beidem verarbeitet
• Land der Datenverarbeitung - relevant für die Überschneidung mit der DSGVO und für die aufsichtliche Meldung
• Vertragsreferenz und Prüfdatum - der Vertrag, der deine Nutzung des Dienstes regelt
• Konzentrationsmarkierung - ob es innerhalb von 30 Tagen keine praktikable Alternative zu diesem Anbieter gibt

Eine Tabelle genügt. Eine Übersicht im internen Dokumentations-Wiki genügt ebenfalls. Entscheidend ist, dass jede Person im Team sie findet, jede Compliance-Verantwortliche auf Kundenseite sie lesen kann und sie aktuell bleibt, wenn Anbieter hinzukommen oder wegfallen.

Am einfachsten startest du das Register, indem du alle aktiven Dienste aus deinem Cloud-Abrechnungskonto exportierst und anschließend die SaaS-Werkzeuge ergänzt, die Produktionssysteme oder Produktionsdaten berühren. Zahlungsdienstleister, Error-Tracking-Tools, die Stacktraces mit Kunden-IDs aufnehmen, Analyseplattformen, die Events empfangen, Dienste für den E-Mail-Versand: All das gehört ins Register. Werkzeuge, die ausschließlich intern für interne Prozesse genutzt werden, in der Regel nicht.

Plane eine quartalsweise Überprüfung fest in den Engineering-Kalender ein. Ein Register, das an Tag eins korrekt ist, aber nicht gepflegt wird, erzeugt ein trügerisches Gefühl von Kontrolle.

Kontrolle 2: Ausstiegspläne schreiben, die eine Aufsicht akzeptiert

Ein Ausstiegsplan ist kein Runbook für das Abschalten eines Dienstes. Er ist eine dokumentierte Antwort auf die Frage: Wenn dieser Anbieter morgen nicht mehr verfügbar oder nicht mehr geeignet wäre, was würden wir tun und wie lange würde es dauern?

DORA verlangt Ausstiegspläne nicht für jeden Anbieter, sondern nur für jene, die kritische oder wichtige Funktionen tragen. Für die meisten FinTech-SaaS-Produkte bedeutet das typischerweise den primären Cloud-Anbieter, den Zahlungsdienstleister und jeden Identitäts- oder Authentifizierungsdienst, der im Produktfluss eingebettet ist.

Ein tragfähiger Ausstiegsplan deckt vier Dinge ab:

Auslösebedingungen. Was würde den Ausstieg auslösen? Aufsichtliche Maßnahmen gegen den Anbieter, ein anhaltender Ausfall über dein RTO hinaus, eine Vertragsänderung, die mit den DORA-Pflichten deines Kunden unvereinbar ist, eine Preiserhöhung über einer definierten Schwelle. Konkrete Auslöser vermeiden Unklarheit darüber, wann der Plan überhaupt greift.

Bewertung alternativer Anbieter. Benenne mindestens eine Alternative. Für die meisten Cloud-Workloads ist das eine Konkurrenzregion oder eine konkurrierende Cloud. Bei Zahlungsdienstleistern kann es eine zweite Acquirer-Beziehung sein, die du in Bereitschaft hältst. Bei Identitätsanbietern kann es eine selbst gehostete Option oder ein Zweitanbieter sein. Die Bewertung muss nicht vollständig durchkalkuliert sein, sie muss aber existieren.

Migrationsschritte auf hoher Flughöhe. Eine Aufzählung der wesentlichen technischen Schritte für den Wechsel zur Alternative. Format des Datenexports, Lücken in der API-Kompatibilität, Konfigurationsunterschiede, Schritte für die DNS-Umstellung. Der Detailgrad sollte ausreichen, damit eine kompetente Person, die das System aktuell nicht kennt, den Plan unter Druck befolgen könnte.

Zeitschätzung. Wie lange würde eine vollständige Migration im besten Fall dauern? Und unter realistischen Bedingungen? Wenn deine realistische Schätzung für den Wechsel weg vom primären Cloud-Anbieter bei achtzehn Monaten liegt, muss dein Kunde das wissen, denn es verändert seine Bewertung des Konzentrationsrisikos.

Ausstiegspläne müssen nicht durch eine tatsächliche Migration validiert werden, wobei sich für kritische Anbieter eine jährliche Teilmigrationsübung durchaus lohnt. Was sie sein müssen, ist ehrlich. Ein Plan, der eine 72-Stunden-Migration beschreibt, die in Wirklichkeit sechs Monate dauern würde, ist schlechter als gar kein Plan, weil er eine falsche Sicherheit erzeugt, die bei einer echten Störung übel auffliegt.

Wenn du eine externe Perspektive einbeziehen willst, ist eine Tech-Stack-Strategie-Prüfung ein sinnvoller Weg, um vor dem Schreiben der Pläne zu bewerten, welche deiner Abhängigkeiten die höchste Ausstiegskomplexität tragen.

Kontrolle 3: Resilienztests, die du in diesem Quartal abschließen kannst

Artikel 25 der DORA verlangt Tests der digitalen operationalen Resilienz. Die anspruchsvollste Form, das bedrohungsgeleitete Penetrationstesten (TLPT), gilt nur für bedeutende Finanzunternehmen und deren kritische IKT-Dienstleister, mit einem Dreijahreszyklus. Für die meisten FinTech-SaaS-Anbieter zählt vor allem, gegenüber nachfragenden Kunden ein funktionierendes Testprogramm nachweisen zu können.

Ein glaubwürdiges Testprogramm für dieses Quartal umfasst drei Bestandteile:

Szenariobasierte Verfügbarkeitstests. Wähle die drei Ausfallszenarien, die deine Kunden am wahrscheinlichsten treffen: Nichtverfügbarkeit der primären Datenbank, Ausfall der primären Cloud-Region, Ausfall des externen Authentifizierungsanbieters. Bestätige für jedes, dass ein Runbook existiert, dass das Team es in den letzten zwölf Monaten geübt hat und dass dein Recovery Time Objective dokumentiert und realistisch ist. Wenn du noch nie in einer Produktionsumgebung auf eine Read Replica oder eine Backup-Region umgeschaltet hast, plane ein Wartungsfenster und tu es.

Fehlerinjektion bei Abhängigkeiten. Simuliere in deiner Staging-Umgebung den Ausfall jeweils einer externen Abhängigkeit, also nicht deiner eigenen Infrastruktur, sondern der Drittdienste aus deinem Register. Was passiert, wenn dein Zahlungsdienstleister zwei Minuten lang 503 zurückgibt? Was passiert, wenn dein CDN nicht erreichbar ist? Lautet die Antwort "unbehandelte Exception, die die Nutzersitzung zerstört", ist das ein Befund, den du beheben solltest, bevor der Prüfer eines Kunden danach fragt. Ein fokussiertes Code-Quality-Consulting legt solche Integrations-Fehlermuster schnell offen, wenn dein Team keine Zeit für eine gründliche interne Prüfung hat.

Verifikation von Backup und Wiederherstellung. Die Meldepflichten der DORA für IKT-bezogene Vorfälle (Artikel 17) setzen voraus, dass du Systeme und Daten wiederherstellen kannst. Wenn du im letzten Quartal keine vollständige Wiederherstellung aus dem Backup in einer produktionsäquivalenten Umgebung verifiziert hast, ist das die wirkungsvollste Maßnahme, die du diese Woche angehen kannst. Dokumentiere die Wiederherstellungszeit. Dokumentiere das Fenster des möglichen Datenverlusts. Diese Zahlen gehören in die oben beschriebenen Ausstiegspläne.

Keiner dieser Tests braucht spezialisierte Werkzeuge. Sie brauchen Terminplanung, Disziplin und Dokumentation. Das Ergebnis, also ein Testprotokoll mit Datum, Szenario, Ausgang und etwaigen Maßnahmen, ist genau das, wonach das Compliance-Team eines Finanzunternehmens bei der Prüfung von Drittparteien fragt.

Damit die Kontrollen dauerhaft halten

Die Herausforderung bei DORA-Kontrollen für Drittparteienrisiken liegt nicht im einmaligen Aufbau. Sie liegt darin, sie aktuell zu halten, während sich dein Produkt weiterentwickelt. Dienste kommen hinzu und fallen weg. Verträge verlängern sich mit geänderten Bedingungen. Entwicklerinnen und Entwickler binden neue Werkzeuge ein, ohne das Register zu aktualisieren.

Der kleinste tragfähige Prozess ist ein quartalsweises Review-Meeting: Register aktualisieren, Ausstiegspläne auf Aktualität prüfen, Testprotokoll durchgehen. Blocke zwei Stunden im Kalender, benenne eine verantwortliche Person und behandle es wie jede andere wiederkehrende Compliance-Pflicht. Wenn du in den Finanzsektor verkaufst, ist der Zeitaufwand klein im Verhältnis zu den Kosten, einen Kunden zu verlieren, weil sein Audit Lücken in deinem Drittparteien-Risikoprogramm gefunden hat.

Wenn du dieses Compliance-Fundament aufbaust und eine zweite Perspektive auf deine aktuelle Architektur, deine technischen Abhängigkeiten oder deinen Testansatz möchtest, melde dich unter hello@wolf-tech.io oder schau auf wolf-tech.io vorbei. Wir arbeiten mit FinTech-SaaS-Teams an genau dieser Art strukturierter Engineering-Arbeit.