DORA fuer SaaS-Anbieter europaeischer Banken: Das Subunternehmerregister, die Exitstrategie und die Pentestberichte, die du jetzt brauchst

Wenn dein SaaS-Produkt Daten oder Prozesse innerhalb einer europaeischen Bank, eines Versicherers oder einer Investmentgesellschaft beruehrt, bist du bereits ein Betroffener des Digital Operational Resilience Act - ob deine Vertraege das anerkennen oder nicht. DORA ist seit Januar 2025 vollstaendig durchsetzbar, und die operative Kaskade trifft seitdem Anbieter-Postfaecher: Due-Diligence-Fragebogen, aktualisierte Vertragsanhange, Anfragen nach Penetrationstest-Zusammenfassungen und gelegentliche Subunternehmer-Pruefungshinweise.

Der groesste Teil der zu DORA veroffentlichten Leitlinien ist fuer die Finanzinstitute selbst geschrieben. Dieser Beitrag ist die andere Seite dieses Gespraeches: Was ein mittelstaendisches SaaS-Unternehmen - eines, das eine Handvoll Bank- oder Versicherungskunden hat, aber noch nie ein Compliance-Team hatte - tatsaechlich einrichten muss, um Artikel 28-30 zu erfuellen, ohne seinen gesamten Engineering-Roadmap umzuleiten.

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, faellt diese Definition auf dich zu. Die Verpflichtungen haengen nicht von deinem eigenen Regulierungsstatus ab; sie fliesssen aus dem Vertragsverhaeltnis des Finanzunternehmens mit dir.

Gemaess Artikel 28 muss jedes DORA-pflichtige Finanzunternehmen ein vollstaendiges Register aller IKT-Drittanbieter fuehren, einschliesslich ihrer Subunternehmer, die kritische oder wichtige Funktionen bearbeiten. Das Compliance-Team deines Kunden benoetigt Informationen von dir, um dieses Register zu vervollstaendigen - und Aufsichtsbehoerden der Europaeischen Zentralbank, nationale zustaendige Behoerden oder ESMA koennen 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 ueber seine kritischen IKT-Anbieter erhaelt, leitet er einen Teil dieses Fragebogens an dich weiter.

Was das IKT-Drittanbieterregister tatsaechlich verlangt

Das Registerformat ist EU-weit standardisiert. Die Europaeischen Aufsichtsbehoerden haben 2024 eine gemeinsame Vorlage veroffentlicht, und deine Kunden sind verpflichtet, sie zu verwenden. Wenn eine Bank dich mit einer Registeranfrage kontaktiert, benoetigt sie typischerweise:

• Entitaetsidentifikation: deinen rechtlichen Namen, LEI-Code (oder MwSt-Nr. falls kein LEI), Gruendungsland und den spezifischen SaaS-Dienstnamen und die im Scope befindliche Version
• Dienstklassifikation: ob dein Dienst eine kritische oder wichtige Funktion beim Finanzunternehmen unterstuetzt (das ist ihre Bestimmung, aber sie koennten dich bitten, die Funktionskategorie zu bestaetigen)
• Subunternehmerkette: Namen und Laender 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 Laender, in denen Daten gespeichert und verarbeitet werden, einschliesslich Rechtsordnungen ausserhalb der EU
• Konzentrationsindikator: ob dein Dienst von mehreren Finanzunternehmen genutzt wird (was die systemische Risikoklassifikation beeinflusst)
• Vorfallhistorie: alle IKT-bezogenen Vorfaelle der letzten 12 Monate, die die Dienstverfuegbarkeit oder Datenintegritaet fuer Kunden aus dem Finanzunternehmen beeintraechtigt haben

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

Die Exitstrategie-Klausel: Was dein Vertrag tatsaechlich erfordert

Artikel 30 der DORA legt verbindlichen Inhalt fuer Vertraege zwischen Finanzunternehmen und ihren kritischen IKT-Drittanbietern fest. Wenn dein Dienst als Unterstuetzung einer kritischen oder wichtigen Funktion eingestuft wird, ist dein Kunde verpflichtet, Exitstrategie-Bestimmungen einzuschliessen, die weit ueber die Standardkuendigungsklauseln hinausgehen, die du wahrscheinlich bereits hast.

Die Exitstrategie-Klausel handelt nicht nur vom Recht zur Kuendigung. Sie verlangt, dass dein Kunde die Beziehung beenden kann, ohne wesentliche Betriebsunterbrech­ungen zu erleiden - und das bedeutet, dass du den Uebergang unterstuetzen koennen musst. Im Einzelnen:

Datenuebertragbarkeit 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" genuegt nicht. Die Klausel sollte das Format benennen (Standardformate bevorzugt - CSV, JSON, Parquet, kein proprietaerer Dump), die Vollstaendigkeitskriterien (alle historischen Datensaetze, alle Metadaten, alle Audit-Logs) und die maximale Lieferfrist.

Uebergangssupport-Zeitraum: Viele aktualisierte Vertraege verlangen nun, dass der Anbieter nach Kuendigungserklarung eine Mindestlaufzeit des Betriebs und technischen Supports gewaehrt - typischerweise 12 Monate fuer 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 erfuellen kann.

Runbook-Zugang: Die Exitklausel koennte auch verlangen, dass du Betriebsdokumentation bereitstellst, die ausreicht, damit das Finanzunternehmen oder ein Ersatzanbieter den Dienst unabhaengig betreiben kann. Fuer ein SaaS-Produkt ist das ungewoehnlich, aber einige systemisch wichtige Funktionen werden infrastrukturaehnlich behandelt, und Aufsichtsbehoerden lesen diese Klauseln genau.

Wenn dein Kunde dir in den letzten 18 Monaten eine Vertragsaenderung zugesandt hat, enthaelt sie fast sicher einen DORA-motivierten Exitstrategie-Anhang. Lies ihn. Bestaetigt, dass deine technischen Faehigkeiten tatsaechlich das liefern koennen, was er verspricht. Wenn es eine Luecke gibt - beispielsweise produziert deine Datenexport-Pipeline derzeit keinen vollstaendigen 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 haeufig eine DORA-Vertragsluekenanalyse als Teil von Engagements mit SaaS-Unternehmen, die in den europaeischen Finanzsektor eintreten. Die Luecke zwischen dem, was Vertraege versprechen, und dem, was die Codebasis liefern kann, ist fast immer groesser, als das Engineering-Team realisiert.

Bedrohungsbasierte Penetrationstests: Der Zyklus und der Nachweis

DORA fuehrt eine spezifische Art von Sicherheitstests ein, die als bedrohungsbasierte Penetrationstests (TLPT) bezeichnet werden, die durch ein Framework namens TIBER-EU (und seine nationalen Aequivalente - TIBER-DE, CBEST im Vereinigten Koenigreich) geregelt werden. TLPT ist nur fuer Finanzunternehmen obligatorisch, die als systemisch wichtig eingestuft sind, und gilt direkt fuer diese, nicht fuer ihre Anbieter. Jedoch koennen kritische IKT-Drittanbieter auf Anfrage des Finanzunternehmens in den Umfang einer TLPT-Uebung einbezogen werden.

Was das fuer einen SaaS-Anbieter bedeutet: Du koenntest von einem Bank-Kunden gebeten werden, an einer TLPT-Uebung 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 durchgefuehrt, folgt einer strukturierten Kill-Chain-Methodik und produziert ein Berichtsformat, das speziell fuer die regulatorische Ueberpruefung konzipiert ist.

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

1. Wurde der Test von einem unabhaengigen qualifizierten Anbieter durchgefuehrt, 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 jaehrlich zu verifizieren.)
4. Enthaelt 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 Bankpruefe 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.

Pruefreife ohne den Engineering-Roadmap zu verbrennen

Die praktische Herausforderung fuer 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 Lueckenanalyse: Mappe jeden Finanzunternehmen-Kunden und bestaetigt, ob dein Dienst als kritisch oder wichtig eingestuft ist. Hole die Vertraege und identifiziere alle DORA-motivierten Aenderungen. Inventarisiere deine aktuelle Subunternehmerkette (Cloud-Anbieter, SaaS-Abhaengigkeiten). Identifiziere die Luecken mit den naechsten harten Fristen.

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

Monat 3 - Sicherheitstesting: Beauftrage einen unabhaengigen Penetrationstest, wenn dein letzter veraltet oder ausser Scope ist. Bestaetigt mit den Vendor-Management-Teams deiner Kunden, welches Format sie fuer den Bericht benoetigen.

Laufend - Quartalspruefung: Weise einen namentlich genannten Eigentuemer fuer 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 Eigentuemer und 4 Stunden pro Quartal.

Artikel 28-30 Compliance-Checkliste

Eine komprimierte Referenz fuer die oben beschriebenen Punkte, den Regelungen zugeordnet:

• Artikel 28(2): Registerdaten im ESA-Vorlagenformat pflegen und bereitstellen
• Artikel 28(4)(c): Subunternehmerkette fuer erste IKT-Abhaengigkeiten bestaetigen
• Artikel 30(2)(e): Datenuebertragbarkeitsklausel mit angegebenem Format, Vollstaendigkeit und Lieferfrist
• Artikel 30(2)(f): Uebergangssupport-Zeitraum definiert und operativ unterstuetzt
• Artikel 30(2)(g): Betriebsdokumentation fuer Uebergangsszenarien zugaenglich
• Artikel 26(3): Jaehrliches unabhaengiges Sicherheitstesting; TLPT-Bereitschaft fuer kritische Anbieter
• Artikel 19: Vorfallprotokollierung und -klassifikation ausreichend zur Unterstuetzung des 24-Stunden-Erstberichts, den Finanzunternehmen ihren Aufsichtsbehoerden melden muessen

Der vorbereitete Anbieter gewinnt das Geschaeft

Finanzunternehmen kreuzen mit ihren IKT-Anbieter-Fragebogen nicht nur DORA-Kaestchen ab - sie treffen auch Beschaffungsentscheidungen. Ein Anbieter, der auf eine Due-Diligence-Anfrage mit einem vollstaendigen, klar strukturierten Registereintrag, einem aktuellen Penetrationstestbericht und einem Vertragsanhang antwortet, der tatsaechlich seinen technischen Moeglichkeiten entspricht, macht dem Compliance-Officer die Arbeit leicht. Dieser Anbieter behaelt das Geschaeft und bekommt oft das naechste.

Wenn du gerade eine DORA-Anbieterpruefung durcharbeitest oder Hilfe benotigst zu pruefen, ob deine Vertraege, Runbooks und Sicherheitstestzyklen den Anforderungen entsprechen, melde dich unter hello@wolf-tech.io. Wolf-Tech arbeitet direkt mit SaaS-Teams zusammen, die durch europaeische regulatorische Anforderungen navigieren - ohne den Overhead einer grossen Unternehmensberatung und ohne die Verspaetung eines Beschaffungsprozesses.

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