Swiss Room · Fallstudie 360°
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. Die Namen und Unternehmen sind fiktiv. Die Dynamiken sind es nicht.
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.
«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.
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 |
|---|---|---|
| ICT-Drittanbieter-Register (Art. 28) | 6 von 31 relevanten Anbietern formal erfasst. Keine Kritikalitätsklassifikation. Keine Exit-Strategien. | Kritisch |
| Incident-Klassifikation (Art. 18) | Keine definierte Klassifikationsmatrix. Keine dokumentierten Schwellenwerte. Meldepflicht-Entscheidungen situativ. | 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 (Art. 10) | 7 kritische Systeme mit Retention unter 30 Tagen. Kein zentrales SIEM. Keine korrelierenden Use Cases. | Erhöht |
| Vertragsanforderungen (Art. 30) | Keiner der Lieferantenverträge enthielt DORA-konforme Klauseln zu Audit-Rechten, Incident-Meldung oder Exit. | Erhöht |
| Penetrationstests / TLPT (Art. 24–26) | Letzte externe Tests vor 22 Monaten. Keine Einbindung der neuen API-Gateway-Architektur. | Erhöht |
Wichtige Einordnung
Als Schweizer KMU fällt SignumPay nicht direkt unter DORA. DORA gilt für im EU-Finanzsektor regulierte Unternehmen. Der Druck auf SignumPay entsteht über Art. 28–30 DORA: Regulierte Finanzunternehmen müssen ihre ICT-Drittdienstleister – also SignumPay – vertraglich auf DORA-Anforderungen verpflichten. Der Markt übernimmt die Durchsetzungsfunktion, die sonst eine Aufsichtsbehörde hätte.
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
DORA-konforme Klauseln zu Audit-Rechten, Incident-Meldepflicht, Sub-Outsourcing-Transparenz und Exit-Bedingungen. 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.
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 ICT-Drittdienstleister nach 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.
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 Massnahmen 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
DORA Art. 19 verlangt nicht nur, schwerwiegende Incidents zu melden – es verlangt, dass Klassifikationsentscheidungen nachvollziehbar sind. Das gilt auch für Vorfälle, die nicht gemeldet werden. Die Incident-Klassifikationsmatrix bei SignumPay enthält deshalb eine explizite Dokumentationspflicht für Nicht-Meldungen: Wer entschieden hat, warum, auf welcher Grundlage.
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.