DORA für SaaS- und IKT-Dienstleister: Was Banken und Versicherer jetzt von euch verlangen

Banken und Versicherer verlangen von ihren SaaS- und IKT-Dienstleistern seit dem 17. Januar 2025 vor allem zwei Dinge: strukturierte Angaben für ihr Informationsregister nach Art. 28 Abs. 3 DORA und Vertragsklauseln nach Art. 30 — von Datenstandorten über Service Level bis zu Exit-Regelungen. Adressat dieser Pflichten ist das Finanzunternehmen selbst, nicht du; erfüllen kann es sie aber nur, wenn du als Dienstleister die nötigen Angaben und Nachweise lieferst.

Dieser Artikel ordnet ein, was hinter den Fragebögen und Vertragsanhängen steckt, die dir Finanzkunden gerade schicken — und welche Nachweis-Artefakte du konkret liefern kannst. Er ersetzt keine Rechtsberatung.

Was ist DORA — und seit wann gilt es?

DORA ist der Digital Operational Resilience Act, formell die Verordnung (EU) 2022/2554 vom 14. Dezember 2022. Als EU-Verordnung gilt sie unmittelbar in allen Mitgliedstaaten — seit dem 17. Januar 2025, wie auch die BaFin bestätigt. Es gibt also keine Übergangsphase mehr: Deine Finanzkunden stehen seit über einem Jahr in der Pflicht.

Wen DORA erfasst, listet Art. 2 Abs. 1 in 21 Kategorien auf — darunter Kreditinstitute, Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen, Krypto-Dienstleister, Versicherungs- und Rückversicherungsunternehmen, Versicherungsvermittler und Einrichtungen der betrieblichen Altersversorgung. Kommen deine Kunden aus einer dieser Kategorien, ist DORA für dich relevant — auch wenn du selbst nie in der Verordnung erwähnt wirst.

In Deutschland hat das FinmadiG (Finanzmarktdigitalisierungsgesetz, veröffentlicht am 27. Dezember 2024) die nationalen Gesetze wie KWG und VAG an DORA angepasst; die BaFin ist der nationale Melde-Hub für IKT-Vorfälle im Finanzsektor.

Warum bekommst du DORA-Anforderungen, obwohl du kein Finanzunternehmen bist?

Weil DORA das Risikomanagement der Finanzunternehmen auf ihre gesamte IKT-Lieferkette erstreckt — und du Teil dieser Lieferkette bist. Zwei Definitionen machen das unausweichlich:

• IKT-Drittdienstleister ist nach Art. 3 Nr. 19 schlicht „ein Unternehmen, das IKT-Dienstleistungen bereitstellt” — bewusst breit, ohne Größen- oder Branchenschwelle.
• IKT-Dienstleistungen sind nach Art. 3 Nr. 21 digitale Dienste und Datendienste, die über IKT-Systeme dauerhaft bereitgestellt werden. SaaS fällt nach dieser Definition darunter — eine Subsumtion, im Einzelfall zu prüfen, in der Praxis kaum bestritten.

Wichtig für die Einordnung: Du unterliegst keiner direkten DORA-Aufsicht. Die einzige Ausnahme ist die Einstufung als „kritischer IKT-Drittdienstleister” nach Art. 31 durch die europäischen Aufsichtsbehörden — das betrifft nur systemrelevante Hyperscaler. Aber: Deine Finanzkunden müssen dich ins Informationsregister aufnehmen und die Art.-30-Klauseln mit dir vereinbaren, denn sie bleiben nach Art. 28 Abs. 1 lit. a „jederzeit in vollem Umfang” für die Einhaltung von DORA verantwortlich. Verhältnismäßigkeit ist vorgesehen (Art. 28 Abs. 1 lit. b): Die Intensität der Anforderungen richtet sich nach Risiko und Kritikalität des Dienstes.

Das Muster kennst du vielleicht schon aus anderen Branchen: Auch NIS2 erreicht Software-Anbieter über die Lieferkette ihrer Klinik-Kunden, nicht über die Behörde. Und wie im Gesundheitswesen gilt: Regulierte Kunden kaufen nicht nur Funktionen, sondern Nachweise.

Was steht im Informationsregister — und welche Angaben braucht dein Kunde von dir?

Nach Art. 28 Abs. 3 DORA führen Finanzunternehmen ein Informationsregister über alle vertraglichen Vereinbarungen mit IKT-Drittdienstleistern — nicht nur über die kritischen. Das Register unterscheidet zwischen Verträgen, die kritische oder wichtige Funktionen unterstützen, und allen übrigen. Mindestens jährlich berichten die Finanzunternehmen ihrer Aufsicht unter anderem die Anzahl neuer Vereinbarungen, die Kategorien der Dienstleister und die Art der Verträge und Dienstleistungen; auf Verlangen legen sie das vollständige Register vor. Über geplante Verträge für kritische oder wichtige Funktionen müssen sie die Aufsicht sogar vorab unterrichten.

Die Struktur des Registers ist nicht dem Zufall überlassen: Die Durchführungsverordnung (EU) 2024/2956 vom 29. November 2024 legt Standardvorlagen fest. Deshalb kommen die Fragebögen deiner Finanzkunden so gleichförmig daher: Wer bist du, was leistest du, wo verarbeitest du Daten, welche Sub-Dienstleister setzt du ein, welche Funktion unterstützt dein Dienst.

Was eine „kritische oder wichtige Funktion” ist, definiert Art. 3 Nr. 22: eine Funktion, deren Ausfall die finanzielle Leistungsfähigkeit, Solidität oder Fortführung der Geschäftstätigkeit des Finanzunternehmens erheblich beeinträchtigen würde bzw. dessen Zulassungsbedingungen gefährdet. Diese Einstufung nimmt dein Kunde selbst vor — vor Vertragsschluss (Art. 28 Abs. 4 lit. a). Du kannst sie nicht beeinflussen — aber sie entscheidet, welche Klauseln in deinem Vertrag stehen.

Welche Vertragsklauseln verlangt Art. 30 — und was ändert die Kritikalitäts-Einstufung?

Art. 30 trägt die amtliche Überschrift „Wesentliche Vertragsbestimmungen”. Abs. 1 verlangt, dass die Rechte und Pflichten schriftlich in einem vollständigen Vertrag inklusive Service-Level-Vereinbarungen festgehalten werden. Danach teilt sich der Artikel in zwei Stufen:

Stufe	Gilt für	Kerninhalte
Art. 30 Abs. 2 (lit. a–i)	alle IKT-Verträge	Leistungsbeschreibung + Bedingungen der Unterauftragsvergabe; Standorte der Leistungserbringung und Datenverarbeitung inkl. Speicherort, Vorab-Info bei Standortänderung; Verfügbarkeit, Integrität, Vertraulichkeit; Datenrückgabe bei Insolvenz oder Vertragsende in zugänglichem Format; Service-Level-Beschreibungen; IKT-Vorfall-Unterstützung ohne Zusatzkosten oder zu vorab festgelegten Kosten; Zusammenarbeit mit Behörden; Kündigungsrechte und Mindestfristen; Teilnahme an Sicherheits-Schulungsprogrammen
Art. 30 Abs. 3 (lit. a–f)	zusätzlich bei kritischen/wichtigen Funktionen	vollständige SLAs mit präzisen quantitativen und qualitativen Leistungszielen für wirksame Überwachung; Kündigungsfristen + Berichtspflichten des Dienstleisters (inkl. Entwicklungen, die die Leistung beeinträchtigen könnten); Notfallpläne implementieren und testen, IKT-Sicherheitsmaßnahmen; Mitwirkung an TLPT-Penetrationstests (Art. 26/27); uneingeschränkte Zugangs-, Inspektions- und Auditrechte für Finanzunternehmen und Behörde; Exit-Strategien mit verbindlichem Übergangszeitraum und Weiterleistung

Noch einmal in aller Klarheit: Nicht du musst „nach Art. 30” handeln — deine Finanzkunden müssen diese Klauseln mit dir vereinbaren. Für dich zählt die praktische Frage: Kannst du die Zusagen, die dein Kunde vertraglich braucht, mit belastbaren Artefakten unterlegen? Wer das kann, verkürzt Vendor-Reviews von Wochen auf Tage.

Welche Nachweise kannst du konkret liefern? Die Mapping-Tabelle

Hier ist die Übersetzung von Vertragsanforderung in Nachweis-Artefakt — das, was du deinem Finanzkunden proaktiv in die Due-Diligence-Mappe legen kannst:

Anforderung deines Finanzkunden (Informationsregister / Art.-30-Vertrag)	Nachweis-Artefakt, das du lieferst
Datenstandort und Verarbeitungsorte (Art. 30 Abs. 2 lit. b)	Dokumentierter Hosting-Standort (Region/Land, Rechenzentrum) + vollständige Sub-Processor-Liste mit Jurisdiktionen; zur Selbstprüfung deiner eigenen Tool-Kette hilft die EU Jurisdiction Database
Service Level und Verfügbarkeit (Art. 30 Abs. 2 lit. c, e / Abs. 3 lit. a)	Kontinuierlicher Verfügbarkeits-Report mit Uptime-Historie — gemessene Zahlen als Basis für die „wirksame Überwachung” aus Abs. 3 lit. a
Unterstützung bei IKT-Vorfällen (Art. 30 Abs. 2 lit. f)	Lückenlose Incident-Historie mit Zeitstempeln (Beginn, Erkennung, Behebung) + öffentliche Status-Seite als transparenter Kommunikationskanal
Berichtspflichten des Dienstleisters (Art. 30 Abs. 3 lit. b)	Automatische Incident-Benachrichtigungen (E-Mail, Webhook, Status-Seiten-Abo), die deinen Kunden ohne manuelle Zwischenschritte informieren
Datenschutz / Auftragsverarbeitung (Art. 28 DSGVO, flankierend zu Art. 30 Abs. 2 lit. c)	AVV nach Art. 28 DSGVO, sofort verfügbar statt nach Sales-Call; wie du deinen AVV in fünf Minuten prüfst, zeigt der AVV-Check für SaaS-Anbieter
Exit und Datenrückgabe (Art. 30 Abs. 2 lit. d / Abs. 3 lit. f)	Dokumentierter Datenexport in leicht zugänglichem Format + beschriebener Offboarding-Prozess mit Übergangszeitraum

Der rote Faden: Fast jede Zeile verlangt laufende, zeitgestempelte Evidenz statt einmaliger Zusicherungen. Ein PDF mit „99,9 % angestrebt” beantwortet die Frage nach Abs. 3 lit. a nicht — eine überprüfbare Uptime-Historie schon eher.

Was passiert bei einem IKT-Vorfall — und warum braucht dein Kunde deine Daten so schnell?

Weil er selbst Fristen hat. Finanzunternehmen müssen schwerwiegende IKT-Vorfälle ihrer Behörde melden (Art. 19 Abs. 1) — dreistufig mit Erst-, Zwischen- und Abschlussmeldung (Art. 19 Abs. 4) — und unter Umständen auch ihre Kunden informieren (Art. 19 Abs. 3). Liegt die Ursache in deinem Dienst, hängt die Meldung deines Kunden an deinen Informationen: Wann begann die Störung, was ist betroffen, wann war sie behoben.

Genau deshalb stehen „Unterstützung bei IKT-Vorfällen” (Art. 30 Abs. 2 lit. f) und die Berichtspflichten des Dienstleisters (Abs. 3 lit. b) im Vertrag. Ein Anbieter, der Vorfälle automatisch erkennt, mit Zeitstempeln dokumentiert und proaktiv kommuniziert, macht die Meldekette seines Kunden erst praktikabel.

Welche Rolle spielt FoundersDeck — und welche nicht?

Zuerst die Grenze: Kein Monitoring-Tool macht dich oder deinen Finanzkunden DORA-konform. DORA-Konformität ist eine organisatorische Gesamtleistung des Finanzunternehmens — Governance, Risikomanagement, Verträge, Tests. Was Monitoring leistet: Es produziert die Evidenz, die mehrere Zeilen der Tabelle oben verlangen.

FoundersDeck liefert dafür drei Bausteine: kontinuierliche Verfügbarkeitsüberwachung mit Uptime-Historie (Service-Level-Nachweis), automatische Vorfall-Erkennung mit lückenloser, zeitgestempelter Incident-Historie (Nachweis für Incident-Unterstützung und Berichtsfähigkeit) und cookie-freie Status-Seiten als transparenter Kommunikationskanal. Dazu kommt, was bei der Datenstandort-Zeile zählt: 100 % deutsche Infrastruktur (Netcup, Nürnberg), keine US-Jurisdiktion in der Kette, AVV sofort als Download. So wird dein Monitoring-Stack selbst nicht zum erklärungsbedürftigen Eintrag im Register deines Finanzkunden.

Häufige Fragen

Gilt DORA direkt für SaaS-Anbieter?

Nein — Adressat der DORA-Pflichten ist das Finanzunternehmen, nicht sein Dienstleister. Kleine und mittlere SaaS-Anbieter unterliegen keiner direkten DORA-Aufsicht; die einzige Ausnahme ist die Einstufung als „kritischer IKT-Drittdienstleister” nach Art. 31 durch die europäischen Aufsichtsbehörden, die faktisch nur die Kategorie systemrelevanter Hyperscaler betrifft. Trotzdem kommt DORA bei dir an: Deine Finanzkunden müssen jeden IKT-Vertrag in ihr Informationsregister aufnehmen (Art. 28 Abs. 3) und die Vertragsbestimmungen aus Art. 30 mit dir vereinbaren. Das Finanzunternehmen bleibt dabei nach Art. 28 Abs. 1 lit. a „jederzeit in vollem Umfang” für die Einhaltung von DORA verantwortlich — deshalb prüft es seine Dienstleister so genau.

Was ist das DORA-Informationsregister?

Nach Art. 28 Abs. 3 DORA müssen Finanzunternehmen ein Register über alle vertraglichen Vereinbarungen mit IKT-Drittdienstleistern führen — nicht nur über die kritischen. Das Register unterscheidet zwischen Verträgen, die kritische oder wichtige Funktionen unterstützen, und allen übrigen. Mindestens jährlich berichten die Finanzunternehmen ihrer Aufsichtsbehörde unter anderem die Anzahl neuer Vereinbarungen, die Kategorien der Dienstleister und die Art der vertraglich geregelten Dienstleistungen; auf Verlangen müssen sie das vollständige Register vorlegen. Die Standardvorlagen dafür legt die Durchführungsverordnung (EU) 2024/2956 fest. Für dich als Anbieter heißt das: Dein Kunde braucht von dir strukturierte Angaben zu Leistung, Standorten und Sub-Dienstleistern — in registerfähiger Form.

Welche Vertragsklauseln verlangt Art. 30 DORA?

Art. 30 („Wesentliche Vertragsbestimmungen”) verlangt, dass die Rechte und Pflichten schriftlich in einem vollständigen Vertrag inklusive Service-Level-Vereinbarungen festgehalten werden. Für alle IKT-Verträge schreibt Abs. 2 unter anderem vor: Leistungsbeschreibung samt Bedingungen der Unterauftragsvergabe, Standorte der Leistungserbringung und Datenverarbeitung inklusive Speicherort, Zusagen zu Verfügbarkeit, Integrität und Vertraulichkeit, Datenrückgabe bei Vertragsende oder Insolvenz, Service-Level-Beschreibungen, Unterstützung bei IKT-Vorfällen sowie Kündigungsrechte. Unterstützt der Dienst eine kritische oder wichtige Funktion, kommen nach Abs. 3 hinzu: vollständige SLAs mit präzisen quantitativen und qualitativen Leistungszielen, Berichtspflichten des Dienstleisters, Notfallpläne, Mitwirkung an Penetrationstests, uneingeschränkte Audit- und Inspektionsrechte sowie Exit-Strategien mit verbindlichem Übergangszeitraum.

Bin ich als kleiner SaaS-Anbieter ein IKT-Drittdienstleister im Sinne von DORA?

Sehr wahrscheinlich ja. Art. 3 Nr. 19 DORA definiert den IKT-Drittdienstleister bewusst breit als „ein Unternehmen, das IKT-Dienstleistungen bereitstellt” — ohne Größen- oder Branchenschwelle. IKT-Dienstleistungen sind nach Art. 3 Nr. 21 digitale Dienste und Datendienste, die über IKT-Systeme dauerhaft bereitgestellt werden; SaaS fällt nach dieser Definition darunter (eine Subsumtion, die im Einzelfall zu prüfen ist). Ob dein Dienst eine „kritische oder wichtige Funktion” unterstützt, entscheidest nicht du: Diese Einstufung nimmt das Finanzunternehmen selbst vor Vertragsschluss vor (Art. 28 Abs. 4 lit. a) — sie bestimmt, ob nur die Grundklauseln aus Art. 30 Abs. 2 oder auch die verschärften Anforderungen aus Abs. 3 in deinem Vertrag landen.

---

Dieser Artikel dient der Orientierung, nicht der Rechtsberatung. Maßgeblich sind der Wortlaut der Verordnung (EU) 2022/2554 (DORA), die Durchführungsverordnung (EU) 2024/2956 zu den Register-Vorlagen sowie die DORA-Überblickseite der BaFin. Stand: Juli 2026.