Swiss Room · Krimi 1 von 8
Der blinde Fleck
Was dieser Krimi zeigt
Wie fehlende Sub-Drittanbieter-Prüfung ein FinTech in die Krise stürzt – und warum Zertifikate kein Ersatz für eigene Governance sind. Basierend auf DORA Art. 28.
· © 2026
Kurz nach Mitternacht begannen die Latenzwerte zu springen.
Auf dem Bildschirm im Zürcher Headquarter zitterten die Kurven – unregelmässig, kaum auffällig. Wie ein Seismograph vor einem Beben, den niemand beobachtet.
CTO Lukas Bernet starrte auf das Dashboard, rieb sich die Augen und murmelte:
„Wahrscheinlich Netzwerk-Peaks. Morgen schauen wir uns das an.“
Hinter ihm blinkte eine ungelesene Warnmail. Er hatte sie nicht geöffnet. Er würde sie am nächsten Morgen öffnen. Es war dann zu spät.
Als Lukas den neuen Cloud-Provider drei Monate zuvor dem Lenkungsausschuss vorgestellt hatte, klang alles makellos:
ISO-Zertifizierung vorhanden
Regelmässige Audits bestätigt
„DORA-ready“ laut Marketingunterlagen
EU-Datenräume zugesichert
Im Meetingraum nickten alle. Niemand stellte die Frage, die später alles verändert hätte:
„Wer steckt eigentlich unter diesem Provider? Welche Sub-Drittanbieter sind eingebunden – und wer prüft sie?“
Der Provider blieb vage. Niemand bestand auf vollständiger Offenlegung. Ein klassischer blinder Fleck – genau dort, wo DORA Transparenz fordert.
ZentroPay wuchs weiter. Die Cloud hielt Schritt – zunächst.
Dann kam ein Patch. Unscheinbar. Eingespielt von einem Sub-Drittanbieter des Providers. Kein Penetrationstest. Kein Incident-Report. Kein Monitoring-Hook. Ein kleines Sandkorn im System.
Lukas bemerkte später ungewöhnliche Timeouts. Er ordnete sie „temporären Peaks“ zu. Die Compliance-Abteilung sah ein Update im Provider-Dashboard und klickte pflichtbewusst auf „geprüft“ – ohne Artefakte anzufordern.
Checklisten sind leise. Und trügerisch. Sie geben das Gefühl von Kontrolle, ohne die Substanz dahinter zu berühren.
Freitagmorgen. Die Warnmail kam erneut: Zero-Day in der Sub-Processing Chain – aktive Ausnutzung möglich.
Gleichzeitig stand der wichtigste Release des Quartals an. Lukas las die Nachricht, zögerte – und sagte schließlich:
„Wir patchen später. Erst liefern.“
Kurz darauf sprach er mit Nora Keller, der Compliance-Verantwortlichen. Ihre Antwort kam schnell:
„Der Provider ist zertifiziert. Wenn es kritisch wäre, hätten sie reagiert.“
In diesem Moment wurde eine Entscheidung nicht getroffen. Und genau das war die Entscheidung. Ein klassischer Governance-Fehler: Vertrauen ersetzt Steuerung. Zertifikate ersetzen Überprüfung. Die Lunte brannte.
Sonntag, 03:14 Uhr.
Ein automatisierter Angriff nutzte die Schwachstelle im Sub-System. Die Schadsoftware wanderte stromabwärts – direkt in den Transaktionsverkehr von ZentroPay. Kein Alarm. Kein Failover. Kein aktives Monitoring.
─ ─ ─
Montagmorgen, 07:08 Uhr. Alle Telefone klingelten gleichzeitig.
Falsche Abbuchungen. Blockierte Transaktionen. Erste Datenlecks. Kunden, die selbst noch nichts wussten, bemerkten es vor dem Unternehmen.
Als das forensische Team den Ursprung identifizierte, war das Bild eindeutig:
Drittparteienrisiken nur oberflächlich bewertet
Keine Resilienztests der Provider-Kette
Kein getesteter Exit-Plan
Incident-Reporting verspätet und fragmentiert
Der Provider erklärte schriftlich:
„Sub-Drittanbieter liegen nicht in unserem Verantwortungsbereich.“
Ein Satz, der alles beendete, was zuvor als Sicherheit gegolten hatte. Der finanzielle Schaden erreichte innerhalb weniger Tage siebenstellige Höhe.
ZentroPay hätte scheitern können. Tat es aber nicht. Nach Tagen intensiver Krisenarbeit änderte das Unternehmen grundlegend seinen Ansatz.
| 1 | Kettentransparenz erzwingen | Vollständige Offenlegung aller Sub-Processing-Services. Vertragliche Audit- und Informationsrechte entlang der gesamten ICT-Kette. |
|---|---|---|
| 2 | Resilienz technisch verankern | Monitoring statt Annahmen. Automatisierte Patch-Übersichten. Regelmässige Red-Team- und Wiederanlauf-Tests. |
| 3 | Entscheidungs-Bias adressieren | Pre-Mortems als Standard: „Was, wenn unsere Grundannahmen falsch sind?“ Governance, die unbequeme Fragen erzwingt. |
| 4 | Exit-Strategien üben | Migrationen nicht planen, sondern üben. Kommunikationsketten simulieren, nicht beschreiben. |
| 5 | Reporting industrialisieren | Klare Schwellenwerte. Automatisierte Eskalation. Ein zentrales Kipppunkt-Dashboard. |
Nach sechs Monaten: Der Großteil der Kunden blieb. Regulatorische Folgen blieben beherrschbar. Der neue Providervertrag senkte Kosten. Und der Vorfall wurde zur internen Referenz für Governance-Reife.
DORA ist kein reines Regelwerk. DORA beschreibt eine physikalische Realität: Komplexe ICT-Ketten plus menschliche Selbstüberschätzung ergeben systemisches Risiko. Wer nur den sichtbaren Teil kontrolliert, kontrolliert nichts.
Die grösste Schwäche von ZentroPay war nicht technisch. Sie war menschlich: der Glaube, dass Vertrauen in einen Provider Prüfung ersetzt. Dass ein Zertifikat eine Garantie ist. Dass eine Checkliste Substanz bedeutet.
NBK Legal ·
Die vorliegende Geschichte ersetzt keine Rechtsberatung.