DORA für SaaS-Anbieter europäischer Banken: Das Subunternehmerregister, die Exitstrategie und die Pentestberichte, die du jetzt brauchst

Wenn dein SaaS-Produkt Daten oder Prozesse innerhalb einer europäischen Bank, eines Versicherers oder einer Investmentgesellschaft berührt, bist du bereits ein Betroffener des Digital Operational Resilience Act - ob deine Verträge das anerkennen oder nicht. DORA ist seit Januar 2025 vollständig durchsetzbar, und die operative Kaskade trifft seitdem Anbieter-Postfächer: Due-Diligence-Fragebogen, aktualisierte Vertragsanhänge, Anfragen nach Penetrationstest-Zusammenfassungen und gelegentliche Subunternehmer-Prüfungshinweise.

Der größte Teil der zu DORA veröffentlichten Leitlinien ist für die Finanzinstitute selbst geschrieben. Dieser Beitrag ist die andere Seite dieses Gespräches: Was ein mittelständisches SaaS-Unternehmen - eines, das eine Handvoll Bank- oder Versicherungskunden hat, aber noch nie ein Compliance-Team hatte - tatsächlich einrichten muss, um Artikel 28-30 zu erfüllen, ohne seinen gesamten Engineering-Roadmap umzuleiten. Für SaaS-Anbieter europäischer Banken läuft das auf drei Dinge hinaus: ein Subunternehmerregister, eine dokumentierte Exitstrategie und Pentestberichte, die du auf Anfrage vorlegen kannst.

Warum SaaS-Anbieter unter DORA nun IKT-Drittanbieter sind

DORA definiert einen IKT-Drittanbieter als jede Einheit, die digitale und Datendienste kontinuierlich erbringt. Wenn dein Produkt eine SaaS-Anwendung ist, die von Mitarbeitern oder Systemen eines Finanzunternehmens genutzt wird, fällt diese Definition auf dich zu. Die Verpflichtungen hängen nicht von deinem eigenen Regulierungsstatus ab; sie fließen aus dem Vertragsverhältnis des Finanzunternehmens mit dir.

Gemäß Artikel 28 muss jedes DORA-pflichtige Finanzunternehmen ein vollständiges Register aller IKT-Drittanbieter führen, einschließlich ihrer Subunternehmer, die kritische oder wichtige Funktionen bearbeiten. Das Compliance-Team deines Kunden benötigt Informationen von dir, um dieses Register zu vervollständigen - und Aufsichtsbehörden der Europäischen Zentralbank, nationale zuständige Behörden oder ESMA können jederzeit eine Kopie anfordern.

Das ist der Mechanismus, der DORA zu einem Anbieterproblem macht, nicht nur zu einem Bankenproblem. Wenn dein Kunde einen EZB-Fragebogen über seine kritischen IKT-Anbieter erhält, leitet er einen Teil dieses Fragebogens an dich weiter.

Was das IKT-Drittanbieterregister tatsächlich verlangt

Das Registerformat ist EU-weit standardisiert. Die Europäischen Aufsichtsbehörden haben 2024 eine gemeinsame Vorlage veröffentlicht, und deine Kunden sind verpflichtet, sie zu verwenden. Wenn eine Bank dich mit einer Registeranfrage kontaktiert, benötigt sie typischerweise:

• Entitätsidentifikation: deinen rechtlichen Namen, LEI-Code (oder MwSt-Nr. falls kein LEI), Gründungsland und den spezifischen SaaS-Dienstnamen und die im Scope befindliche Version
• Dienstklassifikation: ob dein Dienst eine kritische oder wichtige Funktion beim Finanzunternehmen unterstützt (das ist ihre Bestimmung, aber sie könnten dich bitten, die Funktionskategorie zu bestätigen)
• Subunternehmerkette: Namen und Länder aller IKT-Subunternehmer, die du zur Erbringung des Dienstes nutzt - Cloud-Anbieter, CDN-Vendoren, Database-as-a-Service, Monitoring-Tools - bis zur ersten Ebene, die Daten des Finanzunternehmens verarbeitet
• Datenaufenthaltsort: die Länder, in denen Daten gespeichert und verarbeitet werden, einschließlich Rechtsordnungen außerhalb der EU
• Konzentrationsindikator: ob dein Dienst von mehreren Finanzunternehmen genutzt wird (was die systemische Risikoklassifikation beeinflusst)
• Vorfallhistorie: alle IKT-bezogenen Vorfälle der letzten 12 Monate, die die Dienstverfügbarkeit oder Datenintegrität für Kunden aus dem Finanzunternehmen beeinträchtigt haben

Die praktische Konsequenz: Du brauchst ein gepflegtes, versionskontrolliertes internes Dokument, das all diese Informationen verfolgt. Wenn ein Kunde eine Registeranfrage sendet, füllst du seine Vorlage aus deinem internen Dokument aus - nicht aus dem Gedächtnis und nicht aus einem in Panik gestarteten Slack-Thread. Ein einfaches strukturiertes Dokument (JSON oder YAML in deinem Infrastruktur-Repository funktioniert gut), das quartalsweise geprüft und von einer namentlich genannten Person verantwortet wird, reicht aus.

Die Exitstrategie-Klausel: Was dein Vertrag tatsächlich erfordert

Artikel 30 der DORA legt verbindlichen Inhalt für Verträge zwischen Finanzunternehmen und ihren kritischen IKT-Drittanbietern fest. Wenn dein Dienst als Unterstützung einer kritischen oder wichtigen Funktion eingestuft wird, ist dein Kunde verpflichtet, Exitstrategie-Bestimmungen einzuschließen, die weit über die Standardkündigungsklauseln hinausgehen, die du wahrscheinlich bereits hast.

Die Exitstrategie-Klausel handelt nicht nur vom Recht zur Kündigung. Sie verlangt, dass dein Kunde die Beziehung beenden kann, ohne wesentliche Betriebsunterbrech­ungen zu erleiden - und das bedeutet, dass du den Übergang unterstützen können musst. Im Einzelnen:

Datenübertragbarkeit und -export: Dein Vertrag muss festlegen, wie das Finanzunternehmen alle seine Daten in einem nutzbaren Format innerhalb einer definierten Frist extrahieren kann. "Wir stellen auf Anfrage einen Datenexport bereit" genügt nicht. Die Klausel sollte das Format benennen (Standardformate bevorzugt - CSV, JSON, Parquet, kein proprietärer Dump), die Vollständigkeitskriterien (alle historischen Datensätze, alle Metadaten, alle Audit-Logs) und die maximale Lieferfrist.

Übergangssupport-Zeitraum: Viele aktualisierte Verträge verlangen nun, dass der Anbieter nach Kündigungserklärung eine Mindestlaufzeit des Betriebs und technischen Supports gewährt - typischerweise 12 Monate für kritische Dienste. Das gibt dem Finanzunternehmen Zeit zur Migration ohne einen Steilabfall. Du musst wissen, ob deine Servicebedingungen das beinhalten und ob deine Infrastruktur das erfüllen kann.

Runbook-Zugang: Die Exitklausel könnte auch verlangen, dass du Betriebsdokumentation bereitstellst, die ausreicht, damit das Finanzunternehmen oder ein Ersatzanbieter den Dienst unabhängig betreiben kann. Für ein SaaS-Produkt ist das ungewöhnlich, aber einige systemisch wichtige Funktionen werden infrastrukturähnlich behandelt, und Aufsichtsbehörden lesen diese Klauseln genau.

Wenn dein Kunde dir in den letzten 18 Monaten eine Vertragsänderung zugesandt hat, enthält sie fast sicher einen DORA-motivierten Exitstrategie-Anhang. Lies ihn. Bestätige, dass deine technischen Fähigkeiten tatsächlich das liefern können, was er verspricht. Wenn es eine Lücke gibt - beispielsweise produziert deine Datenexport-Pipeline derzeit keinen vollständigen historischen Export innerhalb der angegebenen Frist - ist das ein Backlog-Element mit einer Compliance-Deadline, kein Nice-to-have.

Unsere Software-Architektur- und technischen Beratungsleistungen umfassen häufig eine DORA-Vertragslückenanalyse als Teil von Engagements mit SaaS-Unternehmen, die in den europäischen Finanzsektor eintreten. Die Lücke zwischen dem, was Verträge versprechen, und dem, was die Codebasis liefern kann, ist fast immer größer, als das Engineering-Team realisiert.

Bedrohungsbasierte Penetrationstests: Der Zyklus und der Nachweis

DORA führt eine spezifische Art von Sicherheitstests ein, die als bedrohungsbasierte Penetrationstests (TLPT) bezeichnet werden, die durch ein Framework namens TIBER-EU (und seine nationalen Äquivalente - TIBER-DE, CBEST im Vereinigten Königreich) geregelt werden. TLPT ist nur für Finanzunternehmen obligatorisch, die als systemisch wichtig eingestuft sind, und gilt direkt für diese, nicht für ihre Anbieter. Jedoch können kritische IKT-Drittanbieter auf Anfrage des Finanzunternehmens in den Umfang einer TLPT-Übung einbezogen werden.

Was das für einen SaaS-Anbieter bedeutet: Du könntest von einem Bank-Kunden gebeten werden, an einer TLPT-Übung teilzunehmen, die deine Infrastruktur, APIs oder die Integrationspunkte zwischen deinem System und ihrem zielt. Das ist nicht dasselbe wie ein Standard-Penetrationstest. Ein TLPT-Engagement wird von zertifizierten Bedrohungsgeheimdienstanbietern durchgeführt, folgt einer strukturierten Kill-Chain-Methodik und produziert ein Berichtsformat, das speziell für die regulatorische Überprüfung konzipiert ist.

Wenn du vorhandene Penetrationstestberichte hast, bestimmen die folgenden Fragen ihre Nützlichkeit im DORA-Kontext:

1. Wurde der Test von einem unabhängigen qualifizierten Anbieter durchgeführt, nicht von deinem internen Sicherheitsteam?
2. Deckt der Bericht den spezifischen Dienst und die Umgebung ab, die dein Finanzunternehmen-Kunde verwendet, nicht nur deine allgemeine Produktionsumgebung?
3. Ist der Bericht innerhalb der letzten 12 Monate datiert? (Finanzunternehmen sind typischerweise verpflichtet, den Sicherheitsstatus ihrer kritischen Anbieter jährlich zu verifizieren.)
4. Enthält der Bericht Scope-Definition, Methodik, nach Schweregrad klassifizierte Erkenntnisse und einen Abhilfezeitplan?

Wenn die Antwort auf eine dieser Fragen Nein ist, kannst du den Bericht keinem Bankprüfer vorlegen und erwarten, dass er akzeptiert wird. Du brauchst einen neuen Test. Plane 6-10 Wochen von der Scope-Vereinbarung bis zum Abschlussbericht ein und budgetiere entsprechend - qualifizierte TLPT-Anbieter berechnen deutlich mehr als Commodity-Penetrationstestfirmen.

Prüfreife ohne den Engineering-Roadmap zu verbrennen

Die praktische Herausforderung für ein 10-bis-50-Person-SaaS-Unternehmen ist, dass nichts davon Kernproduktarbeit ist. Hier ist ein sequenzierter Ansatz, der Unterbrechungen minimiert:

Monat 1 - Inventar und Lückenanalyse: Mappe jeden Finanzunternehmen-Kunden und bestätigt, ob dein Dienst als kritisch oder wichtig eingestuft ist. Hole die Verträge und identifiziere alle DORA-motivierten Änderungen. Inventarisiere deine aktuelle Subunternehmerkette (Cloud-Anbieter, SaaS-Abhängigkeiten). Identifiziere die Lücken mit den nächsten harten Fristen.

Monat 2 - Registerdaten und Dokumentation: Erstelle das interne Registerdokument. Schreibe oder formalisiere das Datenexport-Runbook. Bestätige deine Export-Pipeline gegen etwaige vertragliche Spezifikationen.

Monat 3 - Sicherheitstesting: Beauftrage einen unabhängigen Penetrationstest, wenn dein letzter veraltet oder außer Scope ist. Bestätige mit dem Vendor-Management-Teams deiner Kunden, welches Format sie für den Bericht benötigen.

Laufend - Quartalsprüfung: Weise einen namentlich genannten Eigentümer für das interne Register zu. Setze eine Kalender-Erinnerung, um zu verifizieren, dass Subunternehmerinformationen und Vorfallprotokolle aktuell sind. Das erfordert keine dedizierte Compliance-Einstellung - es erfordert einen dokumentierten Eigentümer und 4 Stunden pro Quartal.

Artikel 28-30 Compliance-Checkliste

Eine komprimierte Referenz für die oben beschriebenen Punkte, den Regelungen zugeordnet:

• Artikel 28(2): Registerdaten im ESA-Vorlagenformat pflegen und bereitstellen
• Artikel 28(4)(c): Subunternehmerkette für erste IKT-Abhängigkeiten bestätigen
• Artikel 30(2)(e): Datenübertragbarkeitsklausel mit angegebenem Format, Vollständigkeit und Lieferfrist
• Artikel 30(2)(f): Übergangssupport-Zeitraum definiert und operativ unterstützt
• Artikel 30(2)(g): Betriebsdokumentation für Übergangsszenarien zugänglich
• Artikel 26(3): Jährliches unabhängiges Sicherheitstesting; TLPT-Bereitschaft für kritische Anbieter
• Artikel 19: Vorfallprotokollierung und -klassifikation ausreichend zur Unterstützung des 24-Stunden-Erstberichts, den Finanzunternehmen ihren Aufsichtsbehörden melden müssen

Der vorbereitete Anbieter gewinnt das Geschäft

Finanzunternehmen kreuzen mit ihren IKT-Anbieter-Fragebogen nicht nur DORA-Kästchen ab - sie treffen auch Beschaffungsentscheidungen. Ein Anbieter, der auf eine Due-Diligence-Anfrage mit einem vollständigen, klar strukturierten Registereintrag, einem aktuellen Penetrationstestbericht und einem Vertragsanhang antwortet, der tatsächlich seinen technischen Möglichkeiten entspricht, macht dem Compliance-Officer die Arbeit leicht. Dieser Anbieter behält das Geschäft und bekommt oft das nächste.

Wenn du gerade eine DORA-Anbieterprüfung durcharbeitest oder Hilfe benötigst zu prüfen, ob deine Verträge, Runbooks und Sicherheitstestzyklen den Anforderungen entsprechen, melde dich unter hello@wolf-tech.io. Wolf-Tech arbeitet direkt mit SaaS-Teams zusammen, die durch europäische regulatorische Anforderungen navigieren - ohne den Overhead einer großen Unternehmensberatung und ohne die Verspätung eines Beschaffungsprozesses.

Mehr zu Compliance-Architektur und anbieterseitiger regulatorischer Vorbereitung auf wolf-tech.io.