Dieser Beitrag untersucht die strukturellen Unterschiede zwischen den schweizerischen Meldepflichten nach DSG (Datenschutz), ISG (kritische Infrastrukturen) und FINMA-RS 2023/01 (Finanzinstitute). Mit dem TLCTC-v2.0-Framework zeigen wir, dass ein einziger Cyberangriff zwar mehrere Verletzungen auslösen kann, die kausalen Auslöser jedoch unterschiedlich sind – und somit unterschiedliche Response-(RS-)Container-Logik sowie unterschiedliche Propagated-Protection-(PR-)Kontrollen erfordern.
Einleitung: Das Paradox der Mehrfachmeldung
Mit der Entwicklung von Cybersicherheitsregulierungen weg von reinen Governance-Vorgaben hin zu konkreten Meldepflichten stehen Chief Information Security Officers (CISOs) vor einer zentralen Herausforderung: semantischer Verwirrung.
In der Schweiz wird ein einziger Sicherheitsvorfall – etwa ein Ransomware-Angriff – durch mehrere regulatorische Brillen betrachtet: Datenschutz (DSG), kritische Infrastrukturen (ISG) und, für Finanzinstitute, die Aufsicht der FINMA. Die Fristen und rechtlichen Pflichten sind jedoch nicht synchronisiert. Mit dem TLCTC-2-Schichten-Modell lässt sich exakt aufzeigen, warum diese Regulierungen aneinander „vorbeigreifen“ und wie sich die Response-Container entsprechend strukturieren lassen.
Ein Cyber-Angriff löst dabei selten ein einzelnes Ereignis aus, sondern eine Ereigniskette: vom Cyber Risk Event (E1) über das Data Risk Event (E2) bis zu den Business Risk Events auf der Wirkungsseite des Bow-Tie. Gerade auf dieser Ebene kommen Compliance Risk Events zur Anwendung – die regulatorischen Meldepflichten nach ISG, DSG und FINMA. Diese ziehen ihrerseits weitere Business Risk Events nach sich: etwa eine Anzeige bzw. ein Verfahren durch den EDÖB (ebenfalls ein Compliance- bzw. Legal-Ereignis), aufsichtsrechtliche Massnahmen oder Bussen.
Strukturvergleichstabelle
| Aspekt | ISG (Art. 74b) | DSG (Art. 24) | FINMA-RS 2023/01 |
|---|---|---|---|
| Auslösendes Event | Cyber Risk Event (signifikanter Vorfall) | Data Risk Event (Personendaten, hohes Risiko) | Cyber Risk Event und Critical Data Event (separat) |
| Propagated PR verankert in | E1 RS (Incident Response) | E2 RS (Data Breach Response) | E1 RS + E2 RS |
| Meldestelle | BACS (ehem. NCSC) | EDÖB | FINMA |
| Meldefrist | 24h nach Entdeckung | „so rasch als möglich“ (kein fixer Termin) | Cyber-Event: 24h Erst- + 72h Detailmeldung · kritische Daten: gemäss RS |
| Kettenlänge | E1 → E3a (2 Events) | E1 → E2 → E3b (3 Events) | E1 → E3c und E2 → E3c (2 Zweige) |
Die zentrale Erkenntnis: Vorfall vs. Daten
Das TLCTC-Framework unterscheidet zwischen Event 1 (System-Kompromittierung) und Event 2 (Data Risk Event). Diese Unterscheidung ist für die Compliance entscheidend:
Ist der Vorfall signifikant (z. B. Beeinträchtigung der Funktionsfähigkeit einer kritischen Infrastruktur), ist die ISG-Meldung erforderlich – unabhängig davon, ob Personendaten betroffen sind. Auslöser ist der Systemzustand.
Sind keine Personendaten betroffen, besteht keine DSG-Meldepflicht – selbst bei einer erheblichen System-Kompromittierung. Auslöser ist die Verletzung der Sicherheit personenbezogener Daten mit voraussichtlich hohem Risiko.
Für beaufsichtigte Institute zählen zwei separate Auslöser: das Cyber-Event (Cyberangriff, an E1 gekoppelt) und das Critical Data Event – der Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit kritischer Daten (an E2 gekoppelt).
Das FINMA-RS 2023/01 definiert kritische Daten über die Kriterien Vertraulichkeit, Integrität und Verfügbarkeit – nicht über die Personenbezogenheit. Ein Critical Data Event kann daher eine FINMA-Meldung auslösen, ohne dass eine DSG-Meldepflicht besteht (und umgekehrt). Im TLCTC ist das exakt derselbe [DRE]-Knoten in E2, ausgewertet anhand zweier unterschiedlicher Kriterienkataloge.
Praktische Implikation für RS-Container
Ein einziger Vorfall kann mehrere Meldungen erfordern, wenn die Organisation in den Anwendungsbereich fällt und sowohl Personen- als auch kritische Daten betroffen sind. Das führt zu mehreren separaten Propagated-PR-Kontrollen in unterschiedlichen RS-Containern – mit unterschiedlichen Fristen und unterschiedlichen Behörden. Eine FINMA-beaufsichtigte Bank, die eine kritische Infrastruktur betreibt und bei der Personendaten abfliessen, kann im selben Vorfall gegenüber BACS, EDÖB und FINMA meldepflichtig werden.
Entscheidend ist die Kettenperspektive: Diese Meldepflichten sind selbst Compliance Risk Events – eine Ausprägung des Business Risk Event – und enden nicht mit der Meldung. Reagiert eine Behörde wie der EDÖB mit einer Anzeige oder einem Verfahren, entsteht ein nachgelagertes Business Risk Event (Compliance bzw. Legal), das eigene Response-Massnahmen erfordert. Die Ereigniskette kann sich also über die erste Meldung hinaus fortsetzen.
Die RS-Logik-Formel
Jede Regulierung fügt ihre eigene Propagated-PR-(Protection-)Kontrolle in den Respond-(RS-)Container des auslösenden Events ein.
Fazit
Wer versteht, dass ISG-Pfad, DSG-Pfad und FINMA-Pfad an unterschiedlichen kausalen Punkten abzweigen – und dass FINMA gleich an zwei Punkten ansetzt – kann robuste Incident-Response-Playbooks bauen. Statt einer unübersichtlichen „Melde-Checkliste“ lassen sich konkrete RS-Container-Aktionen den logischen Auslösern zuordnen, die das TLCTC-Diagramm sichtbar macht.
Hinweis: Dieser Beitrag dient der Veranschaulichung des TLCTC-Frameworks und stellt keine Rechtsberatung dar. Massgebend sind die jeweils aktuellen Gesetzestexte, Verordnungen und FINMA-Vorgaben sowie eine fachkundige rechtliche Beurteilung im Einzelfall.
Referenzen
- Kreinz, B. TLCTC Framework v2.0, White Paper.
- Bundesgesetz über den Datenschutz (DSG, SR 235.1), Art. 24 – Meldung von Verletzungen der Datensicherheit an den EDÖB.
- Informationssicherheitsgesetz (ISG, SR 128), Meldepflicht für Cyberangriffe auf kritische Infrastrukturen (Art. 74b ff.), in Kraft seit 1. April 2025 (Meldung an das BACS binnen 24h).
- FINMA-Rundschreiben 2023/1 «Operationelle Risiken und Resilienz – Banken» (in Kraft seit 1.1.2024); Meldung von Cyberangriffen nach Art. 29 Abs. 2 FINMAG (24h Erstmeldung, 72h Detailmeldung).