Die BaFin hat im Juli 2026 zum ersten Mal ausgewertet, was Finanzunternehmen unter DORA gemeldet haben. Eine Zahl daraus ist für Dienstleister interessanter als für Banken: Rund 40 Prozent der 2025 gemeldeten Angriffe richteten sich nicht gegen das Finanzunternehmen selbst, sondern gegen einen seiner Dienstleister.
Wenn Sie eine Marktdaten-, Zahlungs- oder Transaktions-API betreiben, sind Sie dieser Dienstleister. Nicht im übertragenen Sinn, sondern als Eintrag in einem Register, das Ihre Kunden der Aufsicht vorlegen müssen.
| BaFin-Auswertung 2025 | Wert |
|---|---|
| Angriffe, die nicht das Institut selbst trafen, sondern einen Dienstleister | rund 40 % |
| Finanzunternehmen mit mindestens einem IKT-Vorfall | rund 1.200 |
| Probleme, die durch Störungen bei Dritten entstanden | rund die Hälfte |
| Einzelmeldungen bei der BaFin, dazu 315 Sammelmeldungen | 733 |
Was die BaFin für 2025 gemeldet bekommen hat
Rund 1.200 Finanzunternehmen waren 2025 von mindestens einem IKT-Vorfall betroffen. Bei der BaFin eingegangen sind 733 Einzelmeldungen, dazu rund 60 kaskadierende Vorfälle, die mehrere Institute gleichzeitig getroffen haben und in 315 Sammelmeldungen mündeten.
Etwa die Hälfte der gemeldeten Probleme entstand nicht im eigenen Haus, sondern durch Störungen bei Dritten. Cyberangriffe machten rund 11 Prozent der Vorfälle aus, und DDoS-Angriffe tauchen darin regelmäßig auf.
Diese 11 Prozent sind ehrlicherweise nicht die größte Kategorie. Systemausfälle und externe Ereignisse liegen deutlich darüber. Der Unterschied ist ein anderer: Ein DDoS-Angriff braucht keinen Fehler auf Ihrer Seite. Er passiert, weil jemand entschieden hat, dass Ihre Verfügbarkeit etwas wert ist.
Warum DORA Sie betrifft, auch ohne eigene Lizenz
DORA, die Verordnung (EU) 2022/2554, gilt seit dem 17. Januar 2025. Artikel 28 Absatz 3 verpflichtet jedes Finanzunternehmen, ein Informationsregister über sämtliche vertraglichen Vereinbarungen mit IKT-Drittdienstleistern zu führen und der Aufsicht vorzulegen. Format und Datenfelder legt die Durchführungsverordnung (EU) 2024/2956 fest, abzugeben maschinenlesbar als xBRL-CSV.
Sie brauchen keine eigene Lizenz, um in diesem Register zu stehen. Es reicht, dass ein Finanzunternehmen Ihre API in einem Prozess einsetzt, der ohne sie nicht läuft. Kursdaten für die Depotbewertung, Orderrouting, eine Zahlungs- oder Banking-Schnittstelle: alles Kandidaten.
Daraus folgt etwas Unbequemes und etwas Gutes. Unbequem: Ihre Kunden müssen Sie dokumentieren, bewerten und im Zweifel ersetzen können. Gut: Wer die Nachweise sauber liefert, wird zum Anbieter, der im Register keine Diskussion auslöst. Das ist ein Wechselhindernis, das für Sie arbeitet.
Das Feld, das Sie betrifft
Meldet ein Finanzunternehmen einen schwerwiegenden Vorfall, läuft das in drei Stufen: Erstmeldung, Zwischenmeldung, Abschlussmeldung. In der Erstmeldung gibt es ein eigenes Feld, Nummer 2.8, mit der Frage, ob der Vorfall von einem Drittanbieter oder einem anderen Finanzunternehmen ausgeht.
Das ist der Punkt, an dem aus Ihrem Ausfall ein Aktenvorgang bei der Aufsicht wird. Nicht Ihr Vorgang, sondern der Ihres Kunden, mit Ihrem Namen darin.
Umgekehrt gilt: Unter bestimmten Bedingungen dürfen IKT-Drittdienstleister Sammelmeldungen für die betroffenen Finanzunternehmen abgeben. Wer seine eigene Meldekette im Griff hat, nimmt seinen Kunden Arbeit ab, statt sie zu verursachen.
Was ein DDoS-Schutz dafür leisten muss
In dieser Konstellation ist die interessante Frage an einen Schutzanbieter nicht, wie viele Terabit pro Sekunde er abwehren kann. Sie lautet: Was davon können Sie vorlegen, wenn der Prüfer Ihres Kunden fragt?
- Wo wird verarbeitet. Der Ort der Traffic-Verarbeitung muss benennbar und begrenzbar sein. Ein Schutz, der Ihren Verkehr irgendwo über die Welt führt, wird im Register zur Erklärungsaufgabe.
- Wer kann zugreifen. Ein Anbieter unter CLOUD Act oder FISA 702 bringt eine Diskussion mit, die Sie nicht führen wollen.
- Was wurde wann geändert. Ein lückenloses Audit-Log jeder Konfigurationsänderung, mit Zeitstempel, Benutzer und Diff, ist der Unterschied zwischen Nachweis und Behauptung.
- Wer hängt noch mit drin. Unterauftragnehmer gehören offengelegt. Wer Mitigation zumietet, verlängert Ihre Lieferkette um ein Glied, das Sie ebenfalls dokumentieren müssen.
- Wer meldet wann an wen. Eine Eskalationskette mit festen Ansprechpartnern, die zur Meldefrist Ihres Kunden passt und nicht zu einem Ticketsystem.
Das sind Fragen nach Nachvollziehbarkeit, nicht nach Kapazität. Kapazität ist die Voraussetzung, nicht das Verkaufsargument.
Die Kurzfassung, falls Sie das intern weitergeben
Was auf Sie zukommt: Ihre Kunden führen ein Informationsregister über alle IKT-Drittdienstleister, Sie stehen darin. Format nach Durchführungsverordnung (EU) 2024/2956, maschinenlesbar als xBRL-CSV. Bei einem schwerwiegenden Vorfall meldet Ihr Kunde in drei Stufen, und Feld 2.8 der Erstmeldung fragt nach dem Drittanbieter. Sammelmeldungen dürfen Sie unter Bedingungen selbst abgeben.
Was Ihre Kunden von Ihnen hören wollen: Wo der Traffic verarbeitet wird, benennbar und begrenzbar. Wer darauf zugreifen kann und unter welchem Recht. Was wann geändert wurde, lückenlos protokolliert. Welche Unterauftragnehmer in der Kette hängen. Und wer wann an wen meldet, mit festen Ansprechpartnern statt einem Ticketsystem.
Was das praktisch heißt
Die Zero Services GmbH ist als qualifizierter DDoS-Mitigationsdienstleister nach §3 BSIG gelistet, betreibt ein eigenes autonomes System (AS215197) und eigene Rechenzentren. Die Verarbeitung läuft auf deutscher und europäischer Infrastruktur, der Geltungsbereich ist wählbar. Jede Änderung im Regelwerk landet im Audit-Log.
Wir sind in dieser Kette selbst der IKT-Drittdienstleister. Deshalb halten wir die Nachweise bereit, die Ihre Kunden brauchen, statt sie im Einzelfall zusammenzusuchen.
Wenn Sie eine API betreiben, von der Finanzunternehmen abhängen: Schreiben Sie uns, welche Dienste das sind und wie Ihr Traffic-Profil aussieht. Wir sagen Ihnen, was ein Schutz dafür kostet und was er nachweisen kann. Wenn wir nicht das richtige Werkzeug sind, sagen wir das auch.