DORA Startups ist 2026 für viele Gründer:innen vor allem ein Vertriebs- und Procurement-Thema. Die EU-Verordnung zur digitalen operativen Resilienz im Finanzsektor gilt seit dem 17. Januar 2025 und trifft zunächst Banken, Zahlungsinstitute und andere regulierte Finanzunternehmen direkt. Nicht jede DORA SaaS und nicht jedes DORA Fintech ist automatisch direkt erfasst. Viele junge Anbieter geraten aber trotzdem in den Einflussbereich der Verordnung, weil regulierte Kunden ihre Anforderungen an ICT-Drittdienstleister konsequent weitergeben.
In diesem Artikel bekommst du eine klare Einordnung: Bist du direkt oder indirekt betroffen? Welche Fragen tauchen 2026 typischerweise in Einkaufsprozessen, Security Questionnaires und Vertragsverhandlungen auf? Und welche Unterlagen kann ein kleines Team in 30 Tagen realistisch aufbauen? Der Ton bleibt pragmatisch. Keine Konzern-Compliance-Sprache, kein Alarmismus, sondern konkrete nächste Schritte.
Was hinter DORA steckt und warum Gründer:innen das überhaupt interessiert
DORA steht für Digital Operational Resilience Act. Das Ziel ist klar formuliert: Finanzunternehmen sollen auch dann handlungsfähig bleiben, wenn IT-Systeme ausfallen, Sicherheitsvorfälle eintreten oder externe Dienstleister Probleme verursachen. Die Verordnung dreht sich um ICT-Risikomanagement, Vorfallmanagement, Testen der Resilienz und die Steuerung externer Technologiepartner. Es geht nicht nur um Prävention, sondern um die Fähigkeit, Störungen schnell zu erkennen, zu begrenzen und zu melden.
Für ein Startup wird DORA in der Praxis oft sichtbar, wenn ein regulierter Kunde Nachweise verlangt, bevor er einen Vertrag unterzeichnet. Deshalb ist das Thema für Gründer:innen weniger ein Thema für die Rechtsabteilung als ein echter Sales-Filter. Direkt betroffen sind Banken, Zahlungsinstitute, E-Geld-Institute, Versicherer und weitere Finanzunternehmen im Scope der Verordnung. Für die meisten Startups entscheidender ist aber, wie diese Pflichten auf Lieferanten durchschlagen.
Quelle: https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1738308404310&uri=CELEX%3A32022R2554
Direkt reguliert oder nur im Sog der Kund:innen?
Der Unterschied lässt sich einfach auf den Punkt bringen: Direkt betroffen ist meist dein Kunde, nicht automatisch dein Startup. Regulierte Finanzunternehmen fallen direkt unter DORA und müssen alle Anforderungen an ICT-Risikomanagement, Meldepflichten, Tests und Drittparteiensteuerung selbst erfüllen.
Indirekt betroffen sind Anbieter wie RegTech-Tools, Embedded-Finance-Plattformen, KYC-/AML-Software, API-Zulieferer, Cloud-Dienste und SaaS-Infrastruktur. Diese Startups geraten in DORA-Prozesse, weil ihre Services für regulierte Kunden relevant sind. Der Begriff, der dabei auftaucht, ist ICT-Drittdienstleister: ein externer Anbieter von Informations- und Kommunikationstechnologie, also Software, Infrastruktur, Plattformen, APIs, Cloud oder Betriebsservices.
Wichtig dabei: Keine SaaS ist automatisch DORA-pflichtig, und auch Cloud-Anbieter unterfallen nicht automatisch dem europäischen Oversight-Regime als kritische Anbieter. Die BaFin stellt klar, dass es auf eine Einzelfallbewertung ankommt. Was aber stimmt: Wenn dein Produkt in kritische Prozesse, Kundendaten, Authentifizierung, Zahlungsflüsse, Scoring oder Kernabläufe eingebunden ist, werden die Fragen tiefer und formeller. Das nennt sich ICT third-party risk, also die Risiken, die aus Abhängigkeiten von externen IT-Anbietern entstehen.
Quellen: https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1738308404310&uri=CELEX%3A32022R2554
Warum Banken 2026 deutlich granularere Vendor-Daten abfragen
Deals scheitern künftig oft nicht am Produkt, sondern an fehlender Vendor-Readiness. Das ist die Kernthese dieses Artikels, und sie hat einen konkreten Grund: das Register of Information.
Regulierte Unternehmen sind verpflichtet, ein strukturiertes Register all ihrer vertraglichen ICT-Beziehungen zu führen. Dieses Register dient gleichzeitig der internen Steuerung, der Aufsicht durch Behörden wie die BaFin und als Grundlage für die Bewertung, welche Drittanbieter systemisch relevant sind. Damit das Register vollständig und prüfbar ist, brauchen Kunden belastbare Informationen von ihren Lieferanten.
Für Startups bedeutet das konkret, dass folgende Angaben zunehmend abgefragt werden:
- genaue Servicebeschreibung und Funktionsabgrenzung
- klare Zuordnung des vertraglichen Partners
- Angaben zu Subdienstleistern und zur Lieferkette
- Daten- und Hosting-Standorte
- Kritikalität der erbrachten Leistung aus Kundensicht
- Rollen, Zugriffsrechte, Supportmodell und Exit-Regeln
Die Standard-Templates für das Register verlangen strukturierte Angaben bis in die Lieferkette hinein. Je nach Fall können Identifikatoren wie LEI oder EUID, Rangfolgen von Subdienstleistern und Datenqualitätsanforderungen relevant werden. Für Startups bedeutet das: Improvisierte Antworten reichen in Procurement-Prozessen seltener aus. Security Questionnaires werden länger, Vertragsanlagen spiegeln dieselben Fragen wider, und Vendor Due Diligence wird operativer und datengetriebener.
Quellen: https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act/preparation-dora-application | https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj/eng
Was junge Anbieter unter Lieferketten-Transparenz verstehen sollten
Kunden wollen nicht nur wissen, was dein Tool tut. Sie wollen auch wissen, auf welchen Schultern dein Tool steht. Konkret entstehen daraus folgende Fragen:
- Welche Unterauftragsverarbeiter oder Subdienstleister nutzt ihr?
- Welche dieser Dienste stützen kritische oder wichtige Funktionen des Kunden?
- Wo werden Daten verarbeitet, gespeichert, gespiegelt oder supportseitig eingesehen?
- Wie werden Änderungen in der Lieferkette kommuniziert?
Bei Leistungen, die kritische oder wichtige Funktionen berühren, werden Subdienstleister, Standorte, Monitoring, Sicherheitsstandards und Änderungsanzeigen besonders wichtig. Kunden wollen kein Logo-Ökosystem sehen, sondern belastbare Angaben mit klaren Verantwortlichkeiten.
Quelle: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ%3AL_202500532
Die Unterlagen, die ein kleines Team vor dem ersten Bank-Deal haben sollte
Wer zum ersten Mal einen Finanzdienstleister als Kunden gewinnen will, steht schnell vor einer langen Liste von Fragen. Die gute Nachricht: Es geht nicht um ein perfektes Enterprise-Compliance-Programm, sondern um Klarheit und Konsistenz. Hier sind die neun Unterlagen, die ein kleines Team realistisch aufbauen kann.
1. Servicebeschreibung: Was liefert dein Dienst genau, und welche Funktion übernimmt er im Prozess des Kunden? Berührt er Authentifizierung, KYC, Zahlungsprozesse, Scoring, Kommunikation, Hosting oder Reporting? Denke die Kritikalität aus Kundensicht mit, nicht nur aus eigener Produktperspektive.
2. Übersicht über Subdienstleister: Eine Liste relevanter Anbieter mit ihrer Funktion im Stack. Welche sind für Hosting, Monitoring, Kommunikation, Support, Identität, Datenverarbeitung oder KI-Services zuständig? Markiere, welche Ausfälle deinen Service spürbar beeinträchtigen würden.
3. Datenstandorte und Datenflüsse: Wo liegen Produktionsdaten, Backups, Logs und Support-Zugriffe? Welche Regionen sind involviert: EU/EWR, Drittstaaten, verteilte Replikation? Welche Datenarten werden verarbeitet?
4. Rollen und Verantwortlichkeiten: Wer ist intern verantwortlich für Security, Incident Management, Freigaben, Support und Vertragskoordination? Wenn das Team klein ist: Ehrlich dokumentieren, aber Vertretungen und Eskalationswege angeben.
5. Incident-Workflow: Ein Incident ist eine Sicherheits- oder Betriebsstörung mit Relevanz für Verfügbarkeit, Integrität, Vertraulichkeit oder Servicequalität. Dokumentiere Erkennung, Triage, Eskalation, Kundeninformation, Statusupdates und Abschlussbericht. Finanzdienstleister haben enge Meldefristen und brauchen schnell verwertbare Updates von Lieferanten.
6. Backup- und Recovery-Logik: Welche Sicherungen gibt es, wie oft wird gesichert und wie läuft ein Restore in der Praxis ab? Auch einfach gehaltene interne Zielwerte für den Wiederanlauf sind besser als keine Dokumentation.
7. Exit- und Offboarding-Logik: Wie können Kunden geordnet aus dem Vertrag aussteigen? Datenexport, Format, Übergabe, Löschung, Fristen und Unterstützung im Übergang sollten klar sein.
8. Support- und Kommunikationsmodell: Supportkanäle, Erreichbarkeit, Eskalationsstufen, Reaktionsfenster. Wer kommuniziert bei Störungen nach außen?
9. Vertragsinventar: Welche Dokumente existieren bereits: Hauptvertrag, SLA, DPA/AVV, Sicherheitsanlage, TOMs, Datenschutzanhang, Subprocessor-Liste? Ziel ist nicht Perfektion, sondern Vollständigkeit und innere Konsistenz.
Diese neun Unterlagen sind die operative Antwort auf ICT third-party risk und decken genau das ab, was als ICT-Drittdienstleister von Finanzdienstleistern erwartet wird.
Welche Fragen im Procurement und im Security Questionnaire realistisch auftauchen
Vendor Due Diligence einer Bank bedeutet meist nicht eine große Rechtsfrage, sondern viele kleine, konkrete Nachweise. Die typischen Fragen lassen sich in fünf Cluster gruppieren.
Zum Service: Was genau ist der Leistungsumfang? Unterstützt die Leistung kritische oder wichtige Funktionen des Kunden?
Zu Daten: Welche Datenkategorien verarbeitet ihr? Wo werden sie gespeichert und wer hat Zugriff?
Zu Subdienstleistern: Nutzt ihr Unterauftragnehmer oder Subprozessoren? Wie informiert ihr über Änderungen in der Lieferkette?
Zu Sicherheit und Betrieb: Wie erkennt und eskaliert ihr Incidents? Welche Backups, Wiederherstellungstests oder Notfallpläne gibt es? Wer hat privilegierte Admin-Zugriffe?
Zu Vertrag und Exit: Welche Audit- oder Informationsrechte akzeptiert ihr? Wie sieht Offboarding aus? Wie schnell kann ein Kunde Daten exportieren und den Dienst verlassen?
Das Problem vieler Startups: Die Antworten auf diese Fragen existieren oft, sie liegen aber in Slack-Kanälen, in den Köpfen der Gründer:innen oder in halbfertigen Notion-Seiten. Was fehlt, ist die freigabefähige Form, also ein Dokument, das ein Einkäufer intern weiterleiten kann, ohne das Startup nochmal anrufen zu müssen.
Vier typische Gründerfälle aus Fintech, SaaS und Infrastruktur
Wie intensiv eine Prüfung ausfällt, hängt stark vom konkreten Einsatz ab. Diese vier Fälle zeigen, wo DORA-relevante Fragen in der Praxis entstehen.
Fall 1: KYC-/AML-SaaS. Solche Tools sind nah an sensiblen Daten und haben oft hohe operative und regulatorische Nähe zur Kernfunktion des Kunden. Typische Nachfragen betreffen Datenquellen, Verfügbarkeit, Subdienstleister, Supportmodell, Incident-Kommunikation und Standortlogik. Der DORA-Blick liegt auf Betriebsstabilität und Lieferkette, nicht auf dem Geldwäscherecht selbst.
Fall 2: Embedded-Finance-Infrastruktur. Wer in Zahlungs-, Konto- oder Identitätsprozesse eingreift, ist besonders exponiert. Bei DORA Fintech entstehen konkrete Nachfragen zu Ausfallfolgen, Fallbacks, Eskalation, Monitoring, Verantwortlichkeiten und Exit-Fähigkeit. Je tiefer der Eingriff in Kernprozesse, desto formeller die Prüfung.
Fall 3: AI-Scoring-Tool. Hier verwechseln Kunden gelegentlich DORA mit KI-Regulierung. Die Trennung ist wichtig: Unter DORA interessieren Betriebsstabilität, Datenflüsse, Drittanbieter, Support und Incident-Prozesse. Modellgovernance, Risikoklassen und Transparenzpflichten für KI-Systeme gehören in den EU-AI-Act-Kontext, nicht in den DORA-Fragebogen.
Fall 4: Cloud-/API-Zulieferer. Diese Anbieter sind häufig indirekt DORA-relevant, weil sie in größere Services eingebettet sind. Bei DORA SaaS entstehen Fragen zu Abhängigkeitsketten, Regionen, Änderungsanzeigen, Konzentrationsrisiken und Supportabdeckung. Wer hier keine klaren Antworten hat, verlängert Procurement erheblich.
DORA sauber von NIS2, CRA und EU AI Act abgrenzen
Wer mit regulierten Kunden spricht, hört schnell mehrere Abkürzungen. Damit ihr nicht durcheinanderkommt, hier die wichtigsten Unterschiede in Kurzform.
DORA ist sektorspezifisch für den Finanzsektor und fokussiert digitale operative Resilienz, Vorfallmanagement und Drittparteiensteuerung. NIS2 ist ein breiterer Cybersicherheitsrahmen für wesentliche und wichtige Einrichtungen in kritischen Sektoren und kein Ersatz für DORA. CRA richtet Sicherheitsanforderungen auf Produkte mit digitalen Elementen über den gesamten Produktlebenszyklus, also eine Hersteller- und Produktperspektive. EU AI Act setzt risikobasierte Regeln für KI-Systeme, Risikoklassen, Transparenz und Hochrisiko-Anwendungen.
Ein Startup kann mehrere dieser Regelwerke gleichzeitig berühren. Wenn ein Finanzkunde aber den DORA-Fragebogen ausfüllt, bleibt sein Blick auf Resilienz, Vorfälle, Lieferkette und Vertragssteuerung gerichtet. Diese Klarheit hilft euch, Vendor-Gespräche gezielter zu führen.
Quellen: https://eur-lex.europa.eu/EN/legal-content/summary/cybersecurity-of-network-and-information-systems.html?fromSummary=31 | https://eur-lex.europa.eu/EN/legal-content/summary/horizontal-cybersecurity-requirements-for-products-with-digital-elements-cyber-resilience-act.html?fromSummary=23 | https://eur-lex.europa.eu/EN/legal-content/summary/rules-for-trustworthy-artificial-intelligence-in-the-eu.html
Der 30-Tage-Plan für eure erste belastbare Vendor-Readiness
Ihr braucht kein perfektes Enterprise-Governance-Programm. Was ihr braucht, sind nachvollziehbare, konsistente und schnell teilbare Antworten. Dieser Plan zeigt, wie ihr das in einem Monat aufbaut.
Woche 1: Transparenz schaffen. Erstellt eine Servicebeschreibung auf ein bis zwei Seiten. Erfasst Datenarten und Datenflüsse. Legt eine Subdienstleister-Liste mit Funktionen an. Benennt Verantwortliche für Security, Incidents und Vertragsfragen, auch wenn jemand mehrere Rollen trägt.
Woche 2: Betriebs- und Incident-Prozesse dokumentieren. Definiert einen Incident-Workflow mit Triage, Eskalation, Kundenkommunikation und Abschluss. Haltet Supportkanäle, Reaktionszeiten und Eskalationsstufen schriftlich fest. Bereitet Vorlagen für erste Incident-Mitteilungen an Kunden vor. Warum das besonders wichtig ist: Für große ICT-bezogene Vorfälle gelten für Finanzunternehmen enge Meldefristen, zum Beispiel eine erste Meldung grundsätzlich innerhalb von vier Stunden nach Klassifizierung. Das bedeutet, Banken brauchen früh verwertbare Informationen von ihren Vendors.
Woche 3: Recovery, Exit und Vertragslogik aufräumen. Verschriftlicht Backup- und Restore-Abläufe. Dokumentiert den Exit- und Offboarding-Prozess. Prüft bestehende Vertragsdokumente auf Konsistenz: SLA, AVV/DPA, Sicherheitsanhänge, Subprocessor-Liste.
Woche 4: Procurement-Testlauf. Simuliert intern einen Security Questionnaire aus Kundensicht. Testet eure Vendor-Readiness mit 15 bis 20 Kernfragen. Markiert Antwortlücken und priorisiert sie: sofort lösbar, in 30 Tagen lösbar, vertraglich zu klären.
Quellen: https://eur-lex.europa.eu/eli/regdel/2025/301/oj/eng
Was der Oversight-Kontext für Startups bedeutet und was nicht
Oversight bezeichnet die europäische Aufsichtsüberwachung besonders kritischer ICT-Drittdienstleister, sogenannte Critical ICT Third-Party Providers oder CTPP. Im November 2025 haben die europäischen Aufsichtsbehörden (ESAs) die erste Liste solcher Anbieter veröffentlicht. Die Einstufung basiert auf systemischer Relevanz, der Unterstützung kritischer oder wichtiger Funktionen und der Substituierbarkeit.
Die meisten Startups sind davon nicht direkt betroffen. Das Oversight-Regime verschärft aber im Markt insgesamt die Erwartungen an Transparenz, Lieferkettenkenntnis und dokumentierte Drittparteiensteuerung. Wenn große Anbieter stärker unter Aufsicht stehen, wächst auch die Sensibilität für die gesamte Lieferkette darunter. Kein Panikthema, aber ein klares Signal dafür, dass professionellere Einkaufsfragen zum Standard werden.
Fazit
DORA Startups ist für die meisten frühen B2B-Teams 2026 kein abstraktes Regulierungskapitel, sondern ein echter Vertriebsfilter. Direkt reguliert ist meist der Kunde. Indirekt unter Druck steht der Anbieter, wenn seine Antworten zu schwach, zu langsam oder zu unklar sind.
Wer als ICT-Drittdienstleister Service, Lieferkette, Datenstandorte, Incident-Workflow, Recovery und Exit-Logik sauber dokumentiert, verkürzt Procurement-Prozesse spürbar und wirkt in Vendor-Gesprächen belastbarer. Das Ziel ist nicht perfekte Konzern-Compliance, sondern eine vendor-fähige Grundordnung für den nächsten Finanzkunden.
Pro-Tip: Startet mit dem internen Procurement-Testlauf aus Woche 4 des 30-Tage-Plans und arbeitet rückwärts. Welche Fragen könnt ihr heute nicht sauber beantworten? Genau dort liegt der größte Deal-Blocker, und genau dort fängt Vendor-Readiness an.
Dieser Beitrag dient der allgemeinen Orientierung für Gründer:innen und ersetzt keine individuelle Rechtsberatung oder aufsichtsrechtliche Einzelfallprüfung.
FAQ zu DORA und Startups
Muss mein Startup DORA direkt einhalten?
Nur wenn es selbst unter die direkt regulierten Finanzunternehmen fällt, zum Beispiel als lizenziertes Zahlungsinstitut oder E-Geld-Institut. Reine SaaS- oder Infrastruktur-Anbieter sind meist nicht direkt erfasst, müssen aber mit DORA-Anforderungen ihrer Kunden umgehen können.
Was ist ein ICT-Drittdienstleister im DORA-Kontext?
Ein externer Anbieter von Informations- und Kommunikationstechnologie, also Software, Cloud, APIs, Infrastruktur oder Betriebsservices. Wenn ein regulierter Finanzkunde euren Dienst für kritische oder wichtige Prozesse nutzt, werdet ihr als ICT-Drittdienstleister betrachtet und entsprechend eingeordnet.
Was ist das Register of Information und warum fragt es meine Bank?
Regulierte Unternehmen müssen ein strukturiertes Register aller ICT-Vertragsbeziehungen führen. Dafür brauchen sie von euch genaue Angaben zu Services, Subdienstleistern, Datenstandorten, Rollen und Kritikalität. Wer diese Daten schnell und konsistent liefern kann, reduziert Procurement-Verzögerungen erheblich.
Wie unterscheidet sich DORA von NIS2 und dem EU AI Act?
DORA ist sektorspezifisch für den Finanzbereich und fokussiert operative Resilienz und Drittparteiensteuerung. NIS2 ist ein breiterer Cybersicherheitsrahmen für kritische Sektoren. Der EU AI Act regelt den Einsatz von KI-Systemen nach Risikoklassen. Alle drei können gleichzeitig relevant sein, aber im DORA-Fragebogen eines Finanzdienstleisters geht es um Resilienz, nicht um KI-Regulierung.
Was passiert, wenn ich einen Vendor-Fragebogen nicht vollständig ausfüllen kann?
Procurement verlangsamt sich oder stoppt ganz. Kunden haben intern Pflichten, ihre Lieferanten zu prüfen und zu dokumentieren. Fehlende Informationen können dazu führen, dass ein Vertrag nicht freigegeben wird, auch wenn das Produkt selbst überzeugt.
