Swiss Room · Leitfaden · Cyber-Resilienz · 9 von 15
DORA
Praxisleitfaden für Schweizer KMU
Adressaten · Vorabklärung · Tiefe
Primär für
Geschäftsleitung von Finanzunternehmen · ICT-Lieferanten an Finanzkunden · Procurement · Compliance
Auch hilfreich: IT-Security · Recht
Was vorab klar sein sollte
EU-Finanzkunden im Portfolio oder Tätigkeit als Finanzunternehmen mit EU-Bezug.
Tiefenstufe
Vertiefung — der Vollleitfaden für DORA-Lieferanten und betroffene Finanzunternehmen.
Nicht der richtige Leitfaden? Wenn Sie keine EU-Finanzkunden bedienen und kein Finanzunternehmen sind, ist DORA für Sie derzeit nicht direkt relevant. Stattdessen: NIS2 oder Regulatory-Readiness-Self-Check.
Was dieser Leitfaden Ihnen gibt
- Schnelltest: Bin ich von DORA betroffen?
- Konkrete Vertragsklauseln mit Verhandlungslinien
- Die 5 häufigsten Fehler – und wie Sie sie vermeiden
- Branchenprofile mit priorisierten Massnahmen
Digital Operational Resilience Act · Finanzsektor-Lieferketten · Typische Fehler · Vertragsrealität
Vorbemerkung
Diese Leitfadenreihe ist aus einer spezifischen Perspektive heraus geschrieben: der einer General Counsel / Senior Vice President, die über viele Jahre in leitender Inhouse-Funktion in regulierten Unternehmen gearbeitet hat – in der Schweiz und in der EU. Die Autorin verfügt über eine juristische und betriebswirtschaftliche Ausbildung in der Schweiz und in Deutschland sowie über langjährige operative Erfahrung als interne Rechts- und Compliance-Verantwortliche in internationalen Konzernen und KMU-Umfeldern.
Diese Kombination – juristische Tiefe, operatives Management-Know-how und direkte Erfahrung mit den Realitäten von Lieferketten, Vertragsverhandlungen und Aufsichtsbehörden – ist der Grund, warum die Texte so geschrieben sind, wie sie sind: nicht als formale Gesetzeskommentare, sondern als Arbeitsinstrumente. Sie richten sich gleichzeitig an Führungskräfte, die schnell einordnen müssen, was eine Regulierung für ihr Unternehmen bedeutet, und an Fachabteilungen, die wissen müssen, was operativ zu tun ist.
Der interdisziplinäre Ansatz ist bewusst: Digitale Regulierung berührt gleichzeitig IT, Recht, Procurement, Geschäftsführung, HR und Lieferkette. Eine Perspektive, die nur eine dieser Dimensionen kennt, liefert unvollständige Antworten. Die Leitfäden versuchen, alle relevanten Dimensionen gleichzeitig zu adressieren – mit dem Bewusstsein, dass in der Praxis selten ein Team allein zuständig ist und die wirklichen Herausforderungen meistens an den Schnittstellen entstehen.
Die Perspektive «Schweizer KMU im EU-Kontext» ist nicht zufällig. Sie spiegelt langjährige Arbeit an der Schnittstelle zwischen Schweizer Geschäftspraxis und europäischem Regulierungsrahmen: die Erfahrung, was es konkret bedeutet, wenn ein EU-Kundenvertrag plötzlich DORA-Klauseln enthält, wenn ein Procurement-Fragebogen AI-Act-Anforderungen stellt oder wenn ein Lieferant keine NIS2-konformen Sicherheitsnachweise liefern kann. Diese Leitfäden sind aus genau diesen Situationen heraus entstanden – nicht aus dem Lesen von Gesetzestexten, sondern aus der Erfahrung ihrer Auswirkungen.
Vorwort: Warum DORA anders ist als NIS2 und AI Act
DORA gilt seit dem 17. Januar 2025. Es ist kein Rahmenwerk wie NIS2 – es ist eine unmittelbar anwendbare EU-Verordnung mit präzisen Anforderungen für den Finanzsektor. Das macht sie strenger und konkreter als alles, was Schweizer ICT-Lieferanten bisher kennen.
Für Schweizer KMU gilt DORA gewöhnlich nicht unmittelbar. Aber kein Regime hat bisher so schnell und so konkret Anforderungen in Lieferantenverträge eingebracht. Wer EU-Finanzunternehmen bedient, bekommt DORA bereits heute zu spüren.
1. Bin ich betroffen? – Entscheidungslogik
Vorab: DORA richtet sich direkt an EU-Finanzunternehmen. Schweizer KMU sind gewöhnlich nicht unmittelbar als Finanzunternehmen DORA-pflichtig; sie können jedoch vertraglich mittelbar betroffen sein und in besonderen Konstellationen (förmliche Benennung als kritischer ICT-Drittdienstleister nach Art. 31) in den DORA-Drittparteienaufsichtsrahmen fallen. In jedem Fall verpflichtet DORA Finanzunternehmen, die Risiken ihrer ICT-Lieferkette zu steuern – Ihre Kunden stellen deshalb Anforderungen an Sie.
1.1 Der Schnelltest
1.2 Wer sind die DORA-pflichtigen EU-Kunden?
| Unternehmenstyp | Typische Beispiele | DORA-Anforderungen an Lieferanten |
|---|---|---|
| Kreditinstitute (Banken) | Grossbanken, Regionalbanken, Kantonalbanken mit in der EU zugelassener Einheit oder Zweigniederlassung | Umfassende DORA-Pflichten (mit Ausnahmen, vereinfachten Rahmen und Proportionalität je nach Einheit). |
| Versicherungsunternehmen | Lebens- und Schadenversicherer ab bestimmter Grösse | Umfassend erfasst. Ob TLPT nötig ist, richtet sich nach der behördlichen Auswahl (Art. 26), nicht nach der Branche. |
| Zahlungsdienstleister | Zahlungsabwickler, Kartennetzwerke, E-Geld-Institute | Vollständig. Besonders strenge Anforderungen an Verfügbarkeit. |
| Wertpapierfirmen | Broker, Asset Manager, Fondsgesellschaften | Abgestuft je nach Grösse. |
| Krypto-Dienstleister | CASP unter MiCA | Vollständig ab Lizenzerteilung. |
| Kleine Kreditinstitute | Sehr kleine Banken (Ausnahme) | Vereinfachte DORA-Anforderungen – aber nicht keine. |
2. Was wird konkret von mir verlangt?
Dieser Abschnitt beschreibt die DORA-nahen Anforderungen, die EU-Finanzkunden typischerweise an Schweizer ICT-Lieferanten stellen. Sie kommen nicht direkt aus dem DORA-Text – sie kommen aus den Vertragsanhängen, die bereits kursieren.
2.1 Vertragsanforderungen – was Finanzunternehmen einbauen müssen
DORA schreibt EU-Finanzunternehmen vor, welche Klauseln in ICT-Verträgen enthalten sein müssen. Das bedeutet: Diese Klauseln kommen auf Sie zu – nicht als Verhandlungsmasse, sondern als Mindestanforderung.
| DORA-Pflichtklausel | Was das für Sie bedeutet | Was Sie aushandeln können |
|---|---|---|
| Klare Beschreibung der ICT-Leistung | Ihre Leistungsbeschreibung muss präzise und vollständig sein | Scope-Anpassungen, aber keine Weglassung |
| Standort der Datenverarbeitung | Wo werden Kundendaten gespeichert und verarbeitet? | Schweizer Datenhaltung oft möglich und attraktiv |
| Zugänglichkeit für Audits | Sie müssen Audits durch den Kunden oder seine Beauftragten ermöglichen | Frequenz, Vorlauf, Scope, Kostentragung – alles verhandelbar |
| Business Continuity | Dokumentierter BCP mit RTO/RPO | Konkrete Zahlen für Ihren Dienst – realistisch verhandeln |
| Incident-Meldung | Fristen und Inhalte für Incident-Kommunikation | Fristen innerhalb der gesetzlichen Vorgaben – aber Sie setzen die internen Abläufe |
| Exit und Portabilität | Wie kommen Kunden weg, wenn sie den Vertrag beenden? | Exit-Zeitraum und Übergabeleistungen verhandeln |
| Subdienstleister-Transparenz | Welche Unterauftragnehmer setzen Sie ein? | Wesentliche vs. alle Subdienstleister – Scope verhandeln |
2.2 BCM und Disaster Recovery – was wirklich geprüft wird
Business Continuity ist das Herzstück von DORA. EU-Finanzkunden müssen nachweisen, dass kritische Prozesse auch bei ICT-Ausfällen weiterlaufen. Dafür brauchen sie von Ihnen mehr als ein Policy-Dokument.
| Was geprüft wird | Mindestanforderung | Testnachweis |
|---|---|---|
| Recovery Time Objective (RTO) | Definierter Zielwert für Wiederherstellungszeit (z.B. 4h) | Letzter Restore-Test mit tatsächlicher gemessener Zeit |
| Recovery Point Objective (RPO) | Maximaler Datenverlust in Zeit (z.B. 1h) | Backup-Konfiguration + letzter Test-Nachweis |
| Eskalationskette | 24/7-Ansprechpartner, Eskalationspfad dokumentiert | Testanruf-Protokoll – wurde die Kette getestet? |
| Kommunikation im Notfall | Vorab definierte Kommunikationsvorlagen | IR-Playbook mit Vorlagen für Erstkommunikation |
| Subdienstleister-Ausfall | Was tun Sie, wenn Ihr Cloud-Provider ausfällt? | Szenario-Dokumentation für Top-3-Abhängigkeiten |
2.3 Testbarkeit – der unterschätzte DORA-Punkt
Was viele Schweizer KMU nicht wissen: DORA verlangt von EU-Finanzunternehmen, ihre Resilienztests auf ICT-Drittanbieter auszuweiten. Das bedeutet: Ihr Kunde muss testen können, ob Ihre Systeme und Prozesse funktionieren – nicht nur, ob Sie es behaupten.
Was 'testbar' konkret bedeutet:
Sie müssen Penetrationstests durch Ihren Kunden oder seine Beauftragten ermöglichen (mit definiertem Scope und Voranmeldung)
Sie müssen Restore-Tests durchführen und die Protokolle bereitstellen können
Sie müssen an Tabletop-Übungen (simulierte Vorfälle) teilnehmen können
Für grosse Finanzkunden gilt TLPT (Threat-Led Penetration Testing) – Sie müssen in der Lage sein, daran teilzunehmen
2.4 Exit-Strategien – was viele vergessen
DORA verlangt von Finanzunternehmen nachweisbare Exit-Strategien für kritische ICT-Lieferanten. Das heisst: Ihr Kunde muss beweisen können, dass er Sie ersetzen kann. Und Sie müssen dabei helfen.
Datenportabilität: Kundendaten müssen in einem standardisierten Format exportierbar sein.
Dokumentierter Übergang: Sie müssen beschreiben können, wie ein geordneter Anbieterwechsel aussieht.
Übergangsunterstützung: Viele Verträge enthalten bereits jetzt eine Klausel, die Sie zu Übergangsleistungen verpflichtet.
Datenvernichtungsnachweis: Nach Vertragsende müssen Kundendaten nachweislich gelöscht werden.
3. Was können Sie von EU-Kunden einfordern?
Die andere Seite der DORA-Medaille: DORA legt Pflichten für Finanzunternehmen fest – aber auch Rechte und Grenzen für ihre Lieferanten. Nutzen Sie diese.
3.1 Was Sie brauchen – und verlangen dürfen
| Was Sie brauchen | Warum Sie es verlangen dürfen | Was tun bei Verweigerung? |
|---|---|---|
| Klare Kritikalitätseinstufung Ihrer Leistung | Ohne diese wissen Sie nicht, welche DORA-Anforderungen gelten | Schriftlich anfragen; eigene Einschätzung dokumentieren |
| Scope und Frequenz von Audits und Tests | Unbegrenzte Audit-Rechte sind nicht DORA-vorgeschrieben | Eigenen Standardrahmen vorschlagen |
| Definition 'schwerwiegender ICT-Vorfall' für Ihren Dienst | Ohne diese können Sie Ihre Eskalationsfristen nicht kalibrieren | Standard-Definition vorschlagen (Verfügbarkeitsverlust >X%, Daten betroffen) |
| Vertragliche Haftungsobergrenze | DORA gibt keine unbeschränkte Haftung vor | Haftungsbegrenzung auf direkten Schaden + Jahreslizenzwert |
| Exit-Bedingungen und Übergangszeitraum | Exit muss machbar sein – unrealistische Fristen schützen niemanden | Mindestens 6 Monate Übergangszeitraum als Standard |
3.2 Vertragsklauseln: Verhandlungslinien
BCM- und Recovery-Klauseln
Audit- und Test-Klauseln
Exit-Klauseln
4. Die fünf häufigsten Fehler in der Praxis
Fehler 1: Kritikalität unterschätzen
'Wir sind nur ein kleiner Zulieferer' – das hört man oft. Aber DORA macht keine Ausnahme für kleine Lieferanten, wenn die Leistung kritisch ist. Ein kleines Schweizer KMU, das das Monitoring-System einer deutschen Bank betreibt, ist hochkritisch – unabhängig von seiner eigenen Grösse.
Fehler 2: BCP ohne getestete Recovery
Der Business Continuity Plan existiert als Dokument. Aber die letzte Recovery wurde nie getestet – oder der Test ist drei Jahre alt. EU-Finanzkunden fragen explizit nach Testprotokollen. Ein alter oder fehlender Test ist schlimmer als kein Test, weil er suggeriert, dass Sie es nicht ernst nehmen.
Fehler 3: Subdienstleister-Risiken verbergen
Viele KMU listen in Vertragsverhandlungen nur ihre direkten Subdienstleister auf – nicht die Subdienstleister ihrer Subdienstleister. Bei einem Vorfall kommt dann heraus, dass kritische Infrastruktur bei einem Cloud-Provider liegt, den der Finanzkunde nicht kannte. Das zerstört Vertrauen nachhaltig.
Fehler 4: Incident-Fristen nicht kennen
DORA verlangt von Finanzunternehmen sehr kurze Meldefristen. Viele Schweizer KMU wissen nicht, dass ihre Kunden diese Fristen haben – und richten ihre interne Incident-Response entsprechend nicht aus. Wenn ein Vorfall eintritt, ist der Zeitdruck beim Kunden enorm, und der Lieferant liefert nicht.
Fehler 5: Exit-Szenarien nicht durchgedacht
'Das brauchen wir nie' – falsch. Kunden müssen DORA-konform nachweisen, dass sie Sie ersetzen können. Wenn Sie kein Exit-Konzept haben, blockieren Sie Ihren Kunden bei seinem eigenen Compliance-Nachweis. Das führt entweder dazu, dass Sie aus Lieferantenpools ausgeschlossen werden oder zu sehr ungünstigen Exit-Vertragsklauseln.
5. Branchenprofile: Was bedeutet das konkret für Sie?
Profil A: Schweizer Cloud-Provider, der Core-Banking-Systeme für EU-Regionalbanken hostet
| DORA-Exposition | Maximal. Sie sind ein kritischer ICT-Drittanbieter im Kernbereich. Direkter Regulierungsdruck möglich. |
|---|---|
| Was verlangt wird | ISO 27001, getestetes BCM mit definierten RTO/RPO, Penetrationstest-Protokolle, TLPT-Bereitschaft, vollständige Subdienstleister-Offenlegung, Exit-Konzept |
| Ihre Chance | Schweizer Datenhaltung und Rechtssicherheit sind starke Differenzierungsmerkmale. Finanzkunden zahlen Premiumpreise für Datensouveränität. |
| Priorität jetzt | DORA-Resilience Master Document erstellen, jährliche Restore-Tests mit Protokollen etablieren, Subdienstleister-Matrix bis Ebene 2 dokumentieren |
Profil B: Schweizer Managed-Security-Provider mit EU-Versicherungskunden
| DORA-Exposition | Hoch. Security-Services sind kritische ICT-Leistungen. Versicherungen sind vollständig DORA-pflichtig. |
|---|---|
| Was verlangt wird | 24/7-Incident-Response, SIEM-Protokolle auf Anfrage, Threat-Intelligence-Dokumentation, Testbereitschaft für TLPT |
| Kritischer Punkt | Sie sind Teil der Incident-Response Ihres Kunden. Wenn Sie langsam reagieren, verletzt Ihr Kunde seine eigenen Meldefristen. |
| Priorität jetzt | Kommunikations-SLA für Incident-Response vertraglich festhalten (max. 2h Erstkommunikation), IR-Playbook mit kundenspezifischen Vorlagen erstellen |
Profil C: Schweizer Softwarehaus, das Zahlungsabwicklungs-Software für EU-Fintechs liefert
| DORA-Exposition | Sehr hoch. Zahlungsdienstleister haben unter DORA besonders strenge Verfügbarkeits- und Integritätsanforderungen. |
|---|---|
| Was verlangt wird | SBOM, risikobasierte Schwachstellen-/Patch-Prozesse (DORA schreibt keine einheitliche 24–72h-Patchfrist vor), Testbereitschaft, Changelog-Dokumentation für wesentliche Updates |
| Typisches Problem | Ihr Kunde muss jede wesentliche Änderung Ihrer Software melden. Er braucht von Ihnen Vorabinformation über Updates, die seine Systeme beeinflussen. |
| Priorität jetzt | Change-Management-Prozess dokumentieren: Wann informieren Sie Kunden über Updates? Was gilt als 'wesentliche Änderung'? |
Profil D: Schweizer IT-Berater, der Digitalisierungsprojekte für EU-Retailbanken begleitet
| DORA-Exposition | Mittel. Beratungsleistungen ohne Betriebsverantwortung sind weniger kritisch – ausser Sie haben Admin-Zugriffsrechte. |
|---|---|
| Was verlangt wird | Nachweis über sichere Arbeitsumgebung, keine Speicherung von Kundendaten auf persönlichen Geräten, NDA und Zugriffsprotokollierung |
| Häufige Überraschung | Selbst als Berater ohne Betriebsverantwortung werden Sie in Lieferantenfragebögen und Audit-Prozesse einbezogen, sobald Sie regelmässig Zugang zu Kundensystemen haben. |
| Priorität jetzt | Klare Policy für Datenhaltung auf Beratergeräten, Zugangsprotokollierung, Subdienstleister-Offenlegung (auch für Freelancer im Team) |
6. Verbindung zu NIS2 und AI Act
Im Finanzsektor laufen DORA, NIS2 und AI Act oft gleichzeitig. Hier ist die Abgrenzung, die in der Praxis nützlich ist:
| Frage | DORA | NIS2 | AI Act |
|---|---|---|---|
| Wer ist direkt adressiert? | EU-Finanzunternehmen | Kritische + wichtige Einrichtungen in 18 Sektoren | Alle, die KI in Verkehr bringen oder einsetzen |
| Kernthema | Operative Resilienz im Finanzsektor | Cybersicherheit kritischer Infrastrukturen | Sicherheit und Transparenz von KI-Systemen |
| Überschneidung | Incident Response, Logging, Lieferkette | Incident Response, Logging, Lieferkette | Logging, Dokumentation, Lieferkette |
| Was Sie zusammenführen können | Gemeinsamer Incident-Response-Prozess für alle drei Regime | Deckt alle Meldefristen ab | Wenn gut designed |
7. Was Sie jetzt tun – priorisiert
| Prio | Massnahme | Warum jetzt |
|---|---|---|
| 1 | Kritikalitätseinstufung Ihrer Leistung beim Kunden anfragen | Fundament für alles weitere. DORA gilt seit Januar 2025. |
| 2 | BCP mit RTO/RPO und letztem Testprotokoll erstellen/aktualisieren | Das ist das meistgefragte Dokument in DORA-Onboarding-Prozessen. |
| 3 | Subdienstleister-Matrix bis Ebene 2 erstellen | Finanzkunden fragen explizit nach Ihrer Sub-Lieferkette. |
| 4 | Incident-Response-Playbook mit Fristen für jeden Finanzkunden | Ihre Fristen müssen kürzer sein als die gesetzlichen Fristen Ihres Kunden. |
| 5 | Exit-Konzept mit Datenportabilität und Übergangszeitraum dokumentieren | Kunden brauchen es für ihren eigenen DORA-Compliance-Nachweis. |
| 6 | DORA-Resilience Master Document proaktiv an Kunden kommunizieren | Verlagert Verhandlungsposition und verhindert Überraschungen. |
Kontakt & weitere Informationen
| NBK Legal Rechts- und Compliance-Beratung EU-Digitalregulierung · Datenschutz · Cybersicherheit Schweiz · EU | Website www.nbklegal.online Alle Leitfäden der Serie www.nbklegal.online/S_leitfaeden |
|---|
Lerngeschichte zum Thema
Ein konstruierter Compliance-Krimi macht greifbar, was sich aus Paragraphen allein nicht lesen lässt — wie Strukturen sich nicht abgesprochen haben, wie ein Befund nicht gemeldet wurde, wie das Nicht-Ereignis zum Ereignis wird.
FinTech ZentroPay verlässt sich auf Provider-Zertifikate. Sub-Drittanbieter-Risiken bleiben unsichtbar — bis ein Zero-Day in der Sub-Processing-Chain alles verändert.
Eine Versicherung lagert ihr Cashflow-Management an einen ungeprüften Sub-Drittanbieter aus. Finanzflüsse sind ICT-Infrastruktur — und müssen genauso behandelt werden.
Alle Einzelfehler der Serie auf einmal. Systeme brechen nicht wegen einzelner Fehler — sie brechen, wenn niemand erkennt, wie alles zusammenhängt.
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.