24-Stunden-Meldepflicht für Spitäler – ISG/BACS in der Praxis
Worum es geht
Seit dem 1. April 2025 gilt in der Schweiz eine gesetzliche Pflicht, Cyberangriffe auf kritische Infrastrukturen dem Bundesamt für Cybersicherheit (BACS) zu melden. Rechtsgrundlage ist das Informationssicherheitsgesetz (ISG) in der revidierten Fassung; die operativen Details ergeben sich aus der zugehörigen Verordnung. Spitäler gehören zu den ausdrücklich erfassten Betreiberinnen kritischer Infrastrukturen im Gesundheitsbereich – sofern sie die in der Verordnung definierten Schwellen (etwa Bettenzahl oder Versorgungsbedeutung) erreichen.
Für die Spitalleitung bedeutet das einen Paradigmenwechsel: Ein Ransomware-Vorfall, der den Betrieb der Notfallaufnahme oder des Klinikinformationssystems beeinträchtigt, ist nicht mehr nur ein IT-Problem, sondern ein meldepflichtiges Ereignis mit eigener Frist. Dieser Beitrag erklärt, was meldepflichtig ist, wie die Uhr läuft, was das BACS erwartet, wie sich Haftungsrisiken vermeiden lassen und wie sich das Ganze von der EU-Richtlinie NIS2 unterscheidet.
Wichtiger Hinweis vorab: Die genauen Fristen, Schwellenwerte und der meldepflichtige Vorfallskatalog werden in der Verordnung konkretisiert und können sich ändern. Prüfen Sie die für Ihr Spital geltenden Detailfristen im Einzelfall. Dieser Beitrag liefert die Struktur, nicht den verbindlichen Stichtag.
Was ist meldepflichtig?
Meldepflichtig ist ein Cyberangriff, der die Funktionsfähigkeit der kritischen Infrastruktur gefährdet, der zu Manipulation oder Abfluss von Informationen geführt hat, oder der über einen längeren Zeitraum unentdeckt blieb beziehungsweise mit Erpressung, Drohung oder Nötigung verbunden ist. Für ein Spital sind das typischerweise: Ransomware mit Verschlüsselung produktiver Systeme, ein bestätigter unbefugter Zugriff auf das Klinik- oder Laborinformationssystem, die Kompromittierung von Fernzugängen (VPN, Wartungszugänge von Medizingeräte-Lieferanten) oder ein erfolgreicher Angriff auf die E-Mail-Infrastruktur mit Datenabfluss.
Abzugrenzen ist die ISG/BACS-Meldung von zwei anderen Meldewegen, die parallel laufen können: Erstens die Datenschutz-Meldung an den EDÖB nach Art. 24 DSG, wenn der Vorfall zu einer Verletzung der Datensicherheit von Personendaten führt und ein hohes Risiko besteht. Zweitens – bei besonders schützenswerten Gesundheitsdaten – die Information der betroffenen Personen. Ein einziger Ransomware-Vorfall in einem Spital kann also drei Meldepflichten auslösen, mit unterschiedlichen Adressaten, Fristen und Schwellen. Wer nur an den EDÖB denkt, übersieht die ISG/BACS-Meldung – und umgekehrt.
Wie die Uhr läuft
Das ISG sieht eine kurze Erstmeldefrist nach Kenntnisnahme des Cyberangriffs vor. Die Verordnung konkretisiert die Frist (in der Diskussion und Umsetzung steht eine 24-Stunden-Erstmeldung) und sieht eine ergänzende, detailliertere Folgemeldung innert weniger Tage vor. Massgeblich ist der Zeitpunkt der Kenntnisnahme, nicht der Zeitpunkt des Angriffs. Das verschiebt die kritische Frage von der Technik auf die Organisation: Wann genau «weiss» das Spital, dass ein meldepflichtiger Vorfall vorliegt? Sobald der diensthabende IT-Verantwortliche eine glaubhafte Indikation hat – oder schon, wenn der Helpdesk drei verschlüsselte Stationen meldet?
Prüfen Sie die exakten Fristen für Ihr Spital im Einzelfall, denn sie ergeben sich aus der jeweils geltenden Verordnungsfassung. Praktisch entscheidend ist: Die Uhr ist kurz, und sie startet, bevor der volle Sachverhalt geklärt ist. Eine Erstmeldung ist ausdrücklich auch dann abzugeben, wenn noch nicht alle Details bekannt sind. Wer auf die «vollständige Forensik» wartet, verpasst die Frist. Genau dafür braucht es einen vorbereiteten, geprobten Meldeprozess statt einer Ad-hoc-Entscheidung um drei Uhr morgens.
Was das BACS erwartet
Das BACS will keine fertige Forensik, sondern eine strukturierte, ehrliche Erstlage. Erwartet werden in der Regel: Angaben zur meldenden Organisation und zur Kontaktperson, Art und Zeitpunkt des Vorfalls (bzw. der Kenntnisnahme), betroffene Systeme und absehbare Auswirkungen auf die Versorgung, bereits ergriffene Sofortmassnahmen sowie die Frage, ob eine Erpressung vorliegt. Die Meldung erfolgt über das vom BACS bereitgestellte Meldeformular bzw. die Meldeplattform. Das BACS nutzt diese Informationen zur Lagebildgewinnung und kann Unterstützung sowie technische Hinweise (z. B. zu bekannten Indikatoren) zurückspielen.
Wichtig für die Spitalleitung: Die BACS-Meldung ist keine Selbstanzeige und löst keine Aufsichtsstrafe für den Angriff selbst aus. Sanktionsbewehrt ist die Verletzung der Meldepflicht, nicht der Umstand, Opfer geworden zu sein. Die Botschaft an Geschäftsleitung und Verwaltungsrat lautet daher: Melden schützt, Schweigen exponiert. Das BACS ist Partner für das nationale Lagebild – nicht Strafverfolgungsbehörde. Das senkt die Hemmschwelle, eine Erstmeldung auch bei unklarer Lage abzusetzen.
Meldeworkflow als Entscheidungsbaum (fürs Tabletop)
Den folgenden Ablauf sollten Sie nicht erst im Ernstfall lesen, sondern in einer Tabletop-Übung durchspielen. Schritt 1 – Erkennung: Auffälligkeit gemeldet (Helpdesk, Monitoring, externer Hinweis). Schritt 2 – Triage: Liegt ein Cyberangriff vor, der Funktionsfähigkeit, Datenintegrität oder Versorgung gefährdet? Ja → weiter. Nein/unklar → dokumentieren, beobachten, Schwelle erneut prüfen. Schritt 3 – Kenntnisnahme festhalten: Datum/Uhrzeit der ersten glaubhaften Indikation protokollieren. Das ist der Fristbeginn.
Schritt 4 – Parallele Pflichten prüfen: (a) ISG/BACS-Meldung erforderlich? (b) DSG-Meldung an EDÖB (Personendaten betroffen, hohes Risiko)? (c) Information betroffener Personen? Schritt 5 – Erstmeldung BACS absetzen mit dem bekannten Stand, ohne auf vollständige Forensik zu warten. Schritt 6 – Eskalation intern: Krisenstab, CISO/vCISO, Rechtsdienst, Kommunikation, Geschäftsleitung, bei Bedarf Verwaltungsratspräsidium. Schritt 7 – Externe Stellen koordinieren: benannter externer Incident-Response-Dienstleister und Cyberversicherung gemäss vorbereiteter Kontaktliste aktivieren. Schritt 8 – Folgemeldung BACS innert der vorgesehenen Frist; Lessons Learned dokumentieren. Jede Verzweigung sollte eine benannte verantwortliche Person und einen Stellvertreter haben.
Verantwortung des Verwaltungsrats
Die Meldepflicht ist Organisationspflicht, und Organisationspflichten enden beim obersten Organ. Verwaltungsrat bzw. Spitalrat müssen sicherstellen, dass eine Meldeorganisation existiert, dass Zuständigkeiten und Stellvertretungen definiert sind, dass der Meldeprozess geprobt wurde und dass die nötigen externen Verträge (Incident Response, Cyberversicherung) vorbereitet sind. Das ist Teil der gesetzlichen Sorgfalts- und Oberaufsichtspflicht. Wer als Mitglied des obersten Organs eine erkennbare Lücke im Krisendispositiv duldet, riskiert eine persönliche Verantwortlichkeit – unabhängig von der ISG-Sanktion gegenüber der Organisation.
Konkret empfehlen wir dem Verwaltungsrat drei Nachweise: erstens ein verabschiedetes Incident-Response- und Meldekonzept mit klaren Fristen und Rollen; zweitens das Protokoll mindestens einer durchgeführten Tabletop-Übung mit der Meldepflicht als Szenario; drittens eine aktuelle Kontakt- und Eskalationsliste inklusive externem IR-Dienstleister, Cyberversicherer und BACS-Meldeweg. Diese drei Dokumente verwandeln eine abstrakte Pflicht in einen prüfbaren Governance-Nachweis – und sie sind genau das, was im Ernstfall den Unterschied zwischen einer fristgerechten Meldung und einer verpassten Frist ausmacht.
Unterschied zu NIS2
Spitäler hören im selben Atemzug oft von «NIS2» und «24-Stunden-Meldung» und vermischen beide Regime. Das ist gefährlich, weil sie unterschiedliche Adressaten und Auslöser haben. NIS2 ist eine EU-Richtlinie (2022/2555), die die Schweiz nicht übernommen hat. Sie bindet ein Schweizer Spital nur dann, wenn dieses über eine Niederlassung oder relevante Tätigkeit in der EU verfügt – etwa eine Tochtergesellschaft, eine Betriebsstätte oder eine wesentliche Diensterbringung in einem EU-Mitgliedstaat. Ein rein in der Schweiz tätiges Spital fällt nicht unter NIS2.
Für das rein schweizerisch tätige Spital ist und bleibt die ISG/BACS-Meldepflicht der relevante Mechanismus. NIS2 kennt zwar ebenfalls ein gestaffeltes Meldesystem (frühe Erstmeldung, Folgemeldung, Abschlussbericht), aber an eine nationale EU-Behörde (CSIRT) des jeweiligen Mitgliedstaats, nicht an das BACS. Wer beide Welten berührt (CH-Spitalgruppe mit EU-Standort), muss beide Pflichten getrennt erfüllen und darf sie nicht gegeneinander aufrechnen. Halten Sie die beiden Regime in Ihrem Krisenhandbuch sauber auseinander – mit einer klaren Zuordnung, welcher Standort welcher Behörde meldet.
Wo Governance endet und Managed IR beginnt – und wie SIDD unterstützt
SIDD ist eine juristisch geführte Datenschutz- und Informationssicherheitsberatung – kein Security Operations Center. Wir setzen klar an, wo Governance den Unterschied macht: Wir konzipieren und dokumentieren Ihr Meldekonzept entlang der ISG/BACS-Anforderungen, bauen den Entscheidungsbaum, definieren Rollen und Fristen, bereiten die Schnittstellen und Eskalationswege zu externem Incident-Response-Dienstleister, Cyberversicherung und BACS vor und proben das Ganze mit Ihrer Leitung in einer Tabletop-Übung. Als vCISO begleiten wir die laufende Meldeorganisation und die jährliche Aktualisierung der Playbooks.
Die Grenze ist bewusst gezogen: Die technische Bewältigung im Ernstfall – Forensik, Eindämmung, Wiederherstellung, das Live-Incident-Handling rund um die Uhr – leistet ein darauf spezialisierter Incident-Response-Dienstleister, den wir im Vorfeld einbinden und mit dem wir die Schnittstellen vorbereiten. SIDD koordiniert die Vorbereitung und die Governance, betreibt aber selbst kein SOC und übernimmt keine managed Incident Response im Live-Betrieb. Mehr zu unseren Leistungen unter vCISO, ISMS / ISO 27001 und Datenschutzberatung (nDSG). Ein erstes Gespräch zur Meldeorganisation Ihres Spitals vereinbaren Sie über das Kontaktformular; eine Offerte für ein Meldekonzept-Mandat über unser Offerte-Formular.
