Swiss Room · Fallstudie 360°
Wie ein Schweizer FinTech DORA-Anforderungen seiner EU-Bankkunden umsetzt
Von der Betroffenheitsanalyse zur operativen Resilienz – und was dabei sichtbar wird, das vorher niemand gesehen hatte
Was diese Fallstudie Ihnen zeigt
Wie ein Schweizer FinTech-KMU DORA nicht als regulatorisches IT-Projekt behandelt hat, sondern als das, was es ist: ein Management- und Steuerungsrahmen, der Schwächen sichtbar macht, die bereits vor DORA existierten. Und was sechs Menschen mit fundamental verschiedenen Ausgangspunkten daraus gemacht haben.
Diese Fallstudie beschreibt exemplarisch, wie ein Schweizer FinTech-KMU DORA-Anforderungen als unternehmensweiten Transformationsprozess umgesetzt hat – nicht als Einzelmassnahme der IT-Abteilung. Unternehmen, Personen, Zahlen und Zitate sind fiktiv; die dargestellten Muster sind bewusst realitätsnah konstruiert.
Die Ausgangslage
Die SignumPay AG mit Sitz in St. Gallen ist ein FinTech-KMU mit rund 30 Mitarbeitenden. Das Unternehmen entwickelt und betreibt Zahlungsschnittstellen und API-basierte Services für Banken und Versicherungen in der Schweiz, Deutschland und Österreich. Das Fundament ist technisch solide. Die Plattform läuft stabil. Die Kundenzufriedenheit ist hoch.
Regulatorik war bisher ein Thema der Kunden – nicht ein unternehmerisches Steuerungsthema. Die Kunden, also die Banken, hatten Regulierungsabteilungen. SignumPay hatte Produkt- und Entwicklungsteams. Das fühlte sich richtig an.
Bis DORA kam. Nicht über eine Behörde. Über eine E-Mail.
Der Auslöser
«Sehr geehrte Damen und Herren, im Rahmen unserer DORA-Compliance-Vorbereitung sind wir verpflichtet, alle wesentlichen ICT-Drittdienstleister zu bewerten. Da SignumPay für unsere Kernprozesse als kritisch einzustufen ist, bitten wir Sie bis zum 31. März 2026 um Ihre Roadmap zur DORA-Konformität gemäss Art. 28 und 30. Ohne diesen Nachweis können wir die Zusammenarbeit in der bestehenden Form nicht fortführen.»
Absender: Vendor Management, eine der grössten Banken in Deutschland. Vertragsvolumen: 28 % des Jahresumsatzes. Beziehungsdauer: sieben Jahre.
Elena Bachmann, Geschäftsführerin, las die E-Mail im Führungsteam vor. Dann legte sie das Tablet auf den Tisch und sagte: «Das betrifft uns nicht als Regulierungsobjekt. Das betrifft uns als Lieferant. Wir sind Teil ihrer DORA-Lieferkette – ob wir wollen oder nicht.»
Das war die richtige Einschätzung. Und sie öffnete den einzig sinnvollen Pfad: nicht defensiv reagieren, sondern verstehen, was DORA von einem FinTech als ICT-Drittdienstleister tatsächlich verlangt.
Erste Erkenntnis: DORA ist kein Einzeldokument
Die Gap-Analyse, die der externe CISO in den ersten drei Wochen durchführte, war ernüchternd. Nicht weil SignumPay fahrlässig gewesen wäre – sondern weil viele der identifizierten Schwachstellen typische Merkmale von organisch gewachsenen KMU sind: funktionierende Systeme, unvollständige Strukturen.
| DORA-Anforderung | Befund bei SignumPay | Schwere |
|---|---|---|
| Internes IKT-Dienstleisterinventar (orientiert am DORA-Informationsregister der Bank) | 6 von 31 relevanten Anbietern formal erfasst. Keine Kritikalitätsklassifikation. Keine Exit-Strategien. (Das Informationsregister nach Art. 28 Abs. 3 ist eine Pflicht der Bank, nicht von SignumPay.) | Kritisch |
| Vorfall-Erkennung & Bankinformation | Keine dokumentierte Matrix zur Erkennung, internen Eskalation und Information des Bankkunden; keine Kriterien, welche Informationen der Bank für ihre Art.-18/19-Bewertung bereitzustellen sind. (Die aufsichtsrechtliche Meldeentscheidung trifft die Bank.) | Kritisch |
| Business Continuity Testing (Art. 11) | BC-Plan vorhanden, zuletzt getestet 2021 – vor der Cloud-Migration. Drei kritische Systeme seitdem nie geübt. | Kritisch |
| Logging & Monitoring | Die vorhandene Protokollierung/Überwachung wurde als für die vereinbarten Services unzureichend bewertet (kurze Aufbewahrung, kein zentrales SIEM, keine korrelierenden Use Cases). Ein SIEM und längere Aufbewahrungsfristen wurden als mögliche Massnahmen geprüft — DORA schreibt weder ein SIEM noch eine feste 30-Tage-Frist pauschal vor. | Erhöht |
| Vertragsanforderungen (Art. 30) | Keiner der Lieferantenverträge enthielt DORA-konforme Klauseln zu Audit-Rechten, Incident-Meldung oder Exit. | Erhöht |
| Technische Sicherheitstests | Der letzte externe Test (vor 22 Monaten) deckte die neue API-Gateway-Architektur nicht ab. TLPT (bedrohungsorientierte Tests, Art. 26 f.) gilt nur für ausgewählte Finanzunternehmen — ob und wie der Bankkunde entsprechende Anforderungen weitergibt, ist gesondert zu prüfen. | Erhöht |
Wichtige Einordnung
Als Schweizer KMU fällt SignumPay nicht direkt unter DORA und wurde auch nicht als kritischer ICT-Drittdienstleister im EU-Oversight-Framework benannt. DORA gilt unmittelbar für die im EU-Finanzsektor regulierten Finanzunternehmen. Der Druck auf SignumPay entsteht über Art. 28–30 DORA: Die Bank muss ihr ICT-Drittparteienrisiko steuern und SignumPay vertraglich auf konkrete Resilienz-, Informations-, Audit- und Subcontracting-Anforderungen verpflichten. Wichtig zum Lesen der folgenden Gap-Analyse: Die dort genannten DORA-Artikel (Register Art. 28, Klassifikation Art. 18, TLPT Art. 24–26) sind Pflichten der Bank bzw. vertraglich weitergegebene Erwartungen — SignumPay übernimmt sie als freiwilligen Referenzrahmen für seine interne Steuerung, nicht als eigene Aufsichtspflicht.
Der organisationsweite Ansatz
Elena Bachmann traf eine frühe Grundsatzentscheidung: DORA wird nicht an die IT delegiert. Ein DORA-Steering Committee aus Geschäftsleitung, IT, Legal, Produkt und Betrieb trifft alle wesentlichen Entscheidungen gemeinsam. Raphael Frei wird als externer CISO eingebunden – nicht als ausgelagerte Funktion, sondern als internes Mitglied des Steering Committees.
Was in acht Monaten entstand:
ICT-Register
31 Anbieter
Vollständig erfasst, nach Kritikalität klassifiziert: 4 kritisch (Zahlungsabwicklung, Authentifizierung, Core API Gateway, Cloud Hosting), 9 wesentlich, 18 Standard
Exit-Strategien
4 kritische Provider
Für jeden der vier kritischen Anbieter: dokumentierter Exit-Plan mit Migrationsdauer, alternativen Anbietern, technischen Voraussetzungen und Datenportabilität
Verträge
11 neu verhandelt
An die mit dem Bankkunden vereinbarten DORA-relevanten Anforderungen angepasst (Audit-Rechte, Incident-Information, Sub-Outsourcing-Transparenz, Exit-Bedingungen) — Umfang je nach unterstützter Funktion und weitergegebener Pflicht. Drei Anbieter haben die Anforderungen ohne Aufpreis akzeptiert.
BCM-Testing
3 Szenarien getestet
Erstes getestetes Szenario: «Core API Gateway Ausfall 4h». Ergebnis: RTO 7h statt Ziel 2h. Sofortmassnahme eingeleitet. Zweites Szenario folgte 6 Wochen später – RTO 2,5h.
Incident-Matrix
3 Klassifikationsstufen
Klare Schwellenwerte für Event / Incident / Major Incident. Verantwortlichkeiten benannt. Meldeentscheide werden dokumentiert – auch bei Nicht-Meldung.
Geschäftsergebnis
Vertrag gesichert
Der auslösende Bankkunde hat den Vertrag verlängert. Zwei weitere EU-Banken haben SignumPay als Referenz für DORA-konformes Vendor-Management zitiert.
Was DORA sichtbar gemacht hat, existierte schon vorher. Der BC-Plan, der nie getestet wurde. Die Verträge ohne Audit-Rechte. Die 31 Anbieter, von denen nur 6 erfasst waren. DORA hat nichts Neues geschaffen – es hat das Unsichtbare sichtbar gemacht.
Die Geschichte aus sechs Perspektiven
Dieselbe Regulierung, dasselbe Unternehmen, derselbe Zeitraum – erlebt durch sechs Menschen, die alle an einem anderen Ende des Systems stehen.
Als die erste DORA-Anfrage ankam, war mein erster Gedanke tatsächlich: Wir sind ein KMU. Das betrifft eher die Banken selbst. Dann las ich die E-Mail ein zweites Mal und verstand: Wir sind Teil ihrer Lieferkette. Wir sind ihr IKT-Drittdienstleister (der Begriff steht in den Definitionen des Art. 3; das Drittparteienrisiko-Management regelt Art. 28). Das ändert alles.
«Ich hätte dieses Projekt nicht an die IT delegieren dürfen. Das war meine wichtigste frühe Entscheidung – es nicht zu tun.»Die härteste Erkenntnis kam beim zweiten Steering Committee: Wir hatten einen Business-Continuity-Plan, den niemand je getestet hatte. Und das hatte niemand als Problem wahrgenommen – weil es im Alltag kein Problem war. DORA hat uns gezwungen zu fragen, was wir eigentlich tun würden, wenn etwas schiefgeht. Die Antwort war unbequem.
Was sich dauerhaft verändert hat: Ich erhalte jetzt monatlich einen Steering-Committee-Report. Ich kenne die vier kritischen Anbieter. Ich weiss, was passiert, wenn einer von ihnen ausfällt. Das klingt selbstverständlich – es war es nicht.
Mein erster nüchterner Blick galt unseren Verträgen. Ich las drei davon durch und stellte fest: Kein einziger enthielt eine DORA-relevante Klausel. Keine Audit-Rechte. Keine Incident-Meldepflicht des Lieferanten uns gegenüber. Keine Regelung zu Sub-Outsourcing-Transparenz. Das war kein Rechtsversehen – es war einfach nie ein Thema gewesen.
«Ich habe in acht Monaten mehr über unsere Technologiearchitektur gelernt als in den drei Jahren davor. Das war unbequem und notwendig.»Die Vertragsverhandlungen waren das Überraschendste: Ich hatte erwartet, dass die meisten Anbieter auf DORA-Klauseln mit Aufpreisforderungen reagieren würden. Drei der vier kritischen Anbieter haben die Anforderungen ohne Aufpreis akzeptiert – einer sagte sogar, er habe auf eine solche Anfrage gewartet, weil er sie ohnehin für alle EU-Kunden benötige.
Was ich für andere Legal-Kolleginnen mitnehme: DORA ist kein reines Compliance-Thema. Es ist eine Gelegenheit, Verträge zu bauen, die im Ernstfall tatsächlich funktionieren. Das ist gute Rechtsarbeit, nicht Bürokratie.
Als ich mir die Infrastruktur zum ersten Mal ansah, dachte ich: Das ist solide gebaut – aber nicht für DORA gedacht. Das ist kein Vorwurf; die meisten KMU bauen ihre IT so, dass sie läuft. Nicht so, dass sie auditierbar ist.
«Das ICT-Register war mein erster Test. Ich fragte: Welche Drittanbieter nutzt ihr? Die Antwort war: sechs. Meine Analyse ergab: einunddreissig. Da wusste ich, wo wir stehen.»Das erste BCM-Test-Ergebnis war schmerzhaft: Recovery Time Objective für den Core API Gateway Ausfall war 7 Stunden statt 2. Niemand hatte das als Problem erkannt – weil das Szenario nie eingetreten war. Ich habe danach eine Regel eingeführt: Jeder Plan, der nicht getestet wurde, ist eine Hypothese, kein Plan.
Was mich bei SignumPay beeindruckt hat: Elena hat sofort auf die 7-Stunden-Zahl reagiert. Keine Diskussion, kein «wir schauen das an». Sofortmassnahme beschlossen. Sechs Wochen später: 2,5 Stunden. Das ist Führung.
DORA war – ohne Übertreibung – die grösste berufliche Herausforderung, die ich bisher hatte. Nicht wegen der Technik. Wegen der Fragen, die DORA gestellt hat, und für die ich keine Antworten hatte. Wann wurde das System zuletzt auf Wiederherstellbarkeit getestet? Was ist unser Failover-Pfad, wenn der Cloud-Provider in Frankfurt ausfällt? Wie lange brauchen wir, bis die API wieder steht?
«Ich kannte die Systeme. Aber ich wusste nicht, wie sie sich im Ausfall verhalten. Das ist ein fundamentaler Unterschied.»Das Logging-Projekt war das technisch aufwändigste. Wir hatten Logs – aber keine zentrale Korrelation, keine Use Cases, keine definierten Retention-Policies für verschiedene Systemklassen. Das aufzubauen hat vier Monate gedauert. Aber jetzt sehen wir Dinge, die wir vorher nie gesehen haben – und ich verstehe zum ersten Mal wirklich, was in unserer Infrastruktur passiert.
Was ich niemandem empfehle: DORA als IT-Projekt zu beginnen. Ich habe die ersten sechs Wochen versucht, es allein zu managen. Erst als Legal und Raphael wirklich involviert waren, haben wir die richtigen Prioritäten gesetzt.
Am Anfang dachte ich: DORA betrifft doch Ops und Management – nicht uns in der Entwicklung. Dann kam das erste Steering Committee, in dem Raphael erklärte, was Art. 30 von Lieferantenverträgen verlangt – und dass neue Integrationen zu Drittanbietern ab sofort im ICT-Register erfasst werden müssen, bevor sie produktiv gehen.
«Wir haben in der Vergangenheit manchmal schnell eine neue API-Anbindung eingebaut und dann erst die Dokumentation nachgeliefert. Das geht nicht mehr. Ich finde das ehrlich gesagt richtig.»Was sich in meiner täglichen Arbeit verändert hat: Wenn ich eine neue externe Abhängigkeit einbaue, denke ich jetzt zuerst: Ist das im ICT-Register? Was passiert, wenn diese API ausfällt? Gibt es ein Timeout-Handling, das unseren Kernprozess schützt? Das klingt wie mehr Aufwand – aber es hat uns schon einmal vor einer fragilen Anbindung bewahrt, die wir sonst durchgelassen hätten.
Als DORA angekündigt wurde, dachte ich: Noch mehr Prozesse. Noch mehr Formulare, die ich ausfüllen muss, ohne zu verstehen, warum. Das Schulungsmodul, das wir dann bekamen, war anders als erwartet – es begann nicht mit dem Gesetzestext, sondern mit einer Frage: Was tust du, wenn ein Kunde anruft und sagt, dass nichts mehr funktioniert?
«Ich wusste nicht, dass ich Teil der Incident-Response-Kette bin. Jetzt weiss ich es. Und ich weiss, wen ich wann anrufen muss.»Was sich konkret verändert hat: Ich habe ein Runbook. Wenn ein Kunde ein Problem meldet, das über ein übliches Support-Ticket hinausgeht, weiss ich, welche Fragen ich stelle, was ich dokumentiere und wen ich wie schnell eskaliere. Vorher war das intuitionsgesteuert. Jetzt ist es ein Prozess. Der Unterschied zeigt sich in der Qualität der Informationen, die ich weitergebe – und in der Zeit, bis ein Incident korrekt klassifiziert ist.
Fünf Erkenntnisse, die über diese Fallstudie hinaus gültig sind
Learning 1
DORA ist kein IT-Projekt – es ist ein Steuerungsprojekt
Governance, Recht, IT, Entwicklung, Betrieb und Support sind gleichermassen betroffen. Wer DORA an die IT-Abteilung delegiert, produziert technische Maßnahmen ohne Wirkung. SignumPay hat das Steering Committee als zentrales Entscheidungsorgan eingesetzt – nicht als Berichtsorgan. Der Unterschied ist entscheidend.
Learning 2
DORA macht sichtbar, was schon vorher existierte
Der ungetestete BC-Plan, die 31 unvollständig erfassten Anbieter, die Verträge ohne Audit-Rechte – all das existierte vor DORA. DORA hat es nicht erzeugt, es hat es sichtbar gemacht. Unternehmen, die DORA als Anlass nehmen, diese Strukturen zu bauen, gewinnen mehr als Compliance: Sie gewinnen operative Steuerungsfähigkeit.
Learning 3
Ein getesteter Plan ist etwas anderes als ein Plan
Das BCM-Test-Ergebnis – 7 Stunden statt 2 – war unangenehm. Es war auch der wertvollste Befund des gesamten Projekts. Ein Plan, der nie getestet wurde, ist eine Hypothese. DORA verlangt getestete Pläne – nicht weil Regulatoren es wollen, sondern weil es der einzige Weg ist zu wissen, ob Resilienz real ist oder nur dokumentiert.
Learning 4
Auch Nicht-Meldungen müssen dokumentiert sein
Die aufsichtsrechtliche Klassifikation und Meldung schwerwiegender ICT-Vorfälle (Art. 18/19 DORA) obliegt dem Finanzunternehmen, nicht SignumPay. Vertraglich wird SignumPay aber verpflichtet, Vorfälle schnell zu erkennen, zu klassifizieren und der Bank belastbare Informationen zu liefern. Als gute Incident-Governance dokumentiert SignumPay deshalb auch Nicht-Meldungen nachvollziehbar (wer, warum, auf welcher Grundlage) — das folgt aus ordentlicher Governance und Nachweisfähigkeit, nicht aus einer wörtlichen Einzelpflicht des Art. 19.
Learning 5
DORA wirkt über den Markt – früher als über die Aufsicht
SignumPay hatte keine Interaktion mit einer Aufsichtsbehörde. Der Druck kam vom Kunden. Das ist keine Ausnahme – das ist der Regelfall für Schweizer KMU, die in EU-Wertschöpfungsketten eingebunden sind. Wer auf den Behördenkontakt wartet, hat das Spielfeld falsch gelesen.
DORA ist kein Hindernis für unternehmerisches Handeln. Es ist ein Reifegrad. Und Reifegrad hat einen Preis – den man entweder jetzt zahlt oder später, wenn es teurer ist.
Hinweis
Diese Fallstudie ist ein fiktives Beispiel. Namen und Unternehmen sind erfunden. Die beschriebenen regulatorischen Anforderungen basieren auf dem geltenden Digital Operational Resilience Act (EU) 2022/2554. Sie ersetzen keine individuelle rechtliche Beratung.
Wissen prüfen
Möchten Sie Ihr Wissen zu diesem Thema testen? Die folgenden Quiz- bzw. Lernkarten-Sets decken den Stoff dieses Stücks ab — jeweils mit Erklärung nach jeder Antwort bzw. Aufdeck-Logik.