NIS2 für Schweizer KMU: Betroffenheit, Pflichten und Umsetzung

Warum NIS2 auch Schweizer KMU nicht kalt lässt

“Wir sind nicht in der EU, das betrifft uns nicht” - dieser Satz fällt in Schweizer Geschäftsleitungssitzungen zum Thema NIS2 erstaunlich oft, und er ist in dieser Pauschalität falsch. Die NIS2-Richtlinie (Network and Information Security Directive 2, EU 2022/2555) ist EU-Recht und entfaltet in der Schweiz keine direkte Rechtswirkung - das stimmt. Trotzdem läuft die Betroffenheit über drei sehr reale Kanäle: Erstens über EU-Tochtergesellschaften oder -Niederlassungen von Schweizer Konzernen, die vor Ort direkt unter die jeweilige nationale Umsetzung fallen. Zweitens über die Lieferkette: Wer als Zulieferer, Software-Anbieter oder Managed Service Provider für ein NIS2-pflichtiges EU-Unternehmen arbeitet, wird über Vertragsklauseln faktisch in die Pflicht genommen, auch ohne eigene rechtliche Bindung. Drittens über digitale Dienste, die grenzüberschreitend erbracht werden (Cloud, DNS, Managed Security Services) - hier kann NIS2 sogar direkt greifen, unabhängig vom Firmensitz.

Parallel dazu hat die Schweiz ihre eigene Antwort auf dieselbe Bedrohungslage entwickelt: das Informationssicherheitsgesetz des Bundes (ISG), den IKT-Minimalstandard und seit dem 1. April 2025 eine gesetzliche Meldepflicht für Cyberangriffe auf kritische Infrastrukturen. Diese Schweizer Regelungen sind inhaltlich näher an NIS2 als viele annehmen - wer die NIS2-Massnahmen sauber umsetzt, erfüllt die Schweizer Vorgaben grösstenteils automatisch mit. Dieser Artikel zeigt dir, wie die beiden Regelwerke zusammenspielen, wie du deine eigene Betroffenheit sauber prüfst und wie ein realistischer Umsetzungsfahrplan für ein Schweizer KMU aussieht - unabhängig davon, ob NIS2 dich direkt, indirekt oder gar nicht bindet.

Die Rechtslage im Überblick: NIS2, ISG und IKT-Minimalstandard

Drei Regelwerke prägen das Bild, und sie überschneiden sich mehr, als der Name vermuten lässt:

• NIS2 (EU-Richtlinie 2022/2555): Seit Oktober 2024 EU-weit in Kraft, wird national umgesetzt (in Deutschland z. B. über das NIS2UmsuCG, das am 6. Dezember 2025 in Kraft trat). Sie unterscheidet “wesentliche” und “wichtige” Einrichtungen in 18 Sektoren und schreibt Risikomanagement-Massnahmen, Meldepflichten und Geschäftsleitungsverantwortung vor.
• ISG (Informationssicherheitsgesetz des Bundes): Seit 1. Januar 2024 in Kraft, primär für Bundesbehörden und Betreiber kritischer Infrastrukturen. Seit 1. April 2025 gilt darin die Meldepflicht für signifikante Cyberangriffe (Art. 74a-74f ISG).
• IKT-Minimalstandard des Bundesamts für wirtschaftliche Landesversorgung (BWL): Ein freiwilliger, aber zunehmend sektorweise verbindlich erklärter Massnahmenkatalog (angelehnt an das NIST Cybersecurity Framework, ergänzt um ISO 2700x und branchenspezifische Anhänge), der Unternehmen jeder Grösse als Selbstbewertungs- und Umsetzungsrahmen dient. Für den Stromsektor ist er seit 1. Juli 2024 verbindlich, weitere Sektoren (Wasser, Fernwärme, Abwasser) ziehen nach.

Bin ich betroffen? Der Selbsttest

Die Betroffenheitsprüfung lässt sich als einfacher Entscheidungsbaum abbilden. Arbeite ihn systematisch durch, bevor du eine Aussage wie “betrifft uns nicht” triffst:

Start: Prüfe deine Situation
  |
  +-- Hat deine Firma eine Niederlassung/Tochtergesellschaft in der EU?
  |     +-- JA  -> Prüfe dort lokale NIS2-Umsetzung (Sektor + Schwellenwert
  |     |          der jeweiligen Landesgesetzgebung, z.B. NIS2UmsuCG in DE)
  |     +-- NEIN -> weiter
  |
  +-- Beliefert deine Firma EU-Kunden, die selbst NIS2-pflichtig sein könnten
  |   (Energie, Gesundheit, Finanzwesen, digitale Infrastruktur, verarbeitendes
  |   Gewerbe kritischer Produkte)?
  |     +-- JA  -> Vertraglich indirekt betroffen: Sicherheitsnachweise,
  |     |          Audits und SLA-Klauseln sind zu erwarten - siehe Kapitel
  |     |          Lieferkettensicherheit
  |     +-- NEIN -> weiter
  |
  +-- Erbringt deine Firma digitale Dienste (Cloud, DNS, Managed Services,
  |   Hosting) mit Kunden oder Infrastruktur in der EU?
  |     +-- JA  -> Direkte NIS2-Anwendbarkeit prüfen, unabhängig vom
  |     |          Firmensitz (Art. 26 NIS2 zu extraterritorialer Wirkung)
  |     +-- NEIN -> weiter
  |
  +-- Zählt deine Firma zu einem der 9 Schweizer Kritis-Sektoren (Energie,
  |   Wasser, Gesundheit, Transport, Finanzsektor, Behörden/IT, Ernährung,
  |   Abwasser, weitere gemäss ISV) oder ist Zulieferer für solche Betreiber?
  |     +-- JA  -> ISG-Meldepflicht (Art. 74a) und IKT-Minimalstandard
  |     |          prüfen - unabhängig von der Firmengrösse
  |     +-- NEIN -> Direkte Pflicht aktuell unwahrscheinlich, NIS2-Massnahmen
  |                 als freiwilliges Best-Practice-Zielbild empfohlen

Wichtig bei der Einschätzung: Die Kritikalität wird nicht an der Unternehmensgrösse, sondern an der Funktion gemessen. Ein 15-Personen-IT-Dienstleister, der die Fernwartung für ein Spitalnetzwerk betreibt, kann relevanter sein als ein 300-Personen-Betrieb ohne Bezug zu kritischen Funktionen.

Der Risikomanagement-Massnahmenkatalog nach Artikel 21 NIS2

Das Herzstück von NIS2 ist Artikel 21: zehn verbindliche Massnahmenbereiche für Cybersicherheits-Risikomanagement, die “angemessen und verhältnismässig” umzusetzen sind - also risikobasiert, nicht als starre Checkliste. Für ein KMU heisst das: nicht überall Enterprise-Tooling, sondern dort investieren, wo das grösste Risiko liegt.

Für Punkt 1 - das Asset-Inventar - lohnt sich ein automatisiertes, wiederholbares Skript statt einer einmaligen Excel-Liste. Ein einfacher Ausgangspunkt für Windows-Umgebungen:

# Einfaches Asset- und Patch-Status-Inventar fuer die Risikoanalyse (Art. 21 Nr. 1)
# Auszufuehren gegen alle Domain-Mitglieder via PowerShell Remoting (JEA-Rolle empfohlen)

$computers = Get-ADComputer -Filter {Enabled -eq $true} -Properties OperatingSystem

$report = foreach ($pc in $computers) {
    try {
        Invoke-Command -ComputerName $pc.Name -ScriptBlock {
            [PSCustomObject]@{
                Hostname       = $env:COMPUTERNAME
                OS             = (Get-CimInstance Win32_OperatingSystem).Caption
                LastBootTime   = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
                PendingUpdates = (Get-CimInstance -Namespace root\ccm\clientsdk `
                                    -ClassName CCM_SoftwareUpdate `
                                    -ErrorAction SilentlyContinue).Count
                BitLockerOn    = (Get-BitLockerVolume -MountPoint "C:").ProtectionStatus
            }
        } -ErrorAction Stop
    } catch {
        [PSCustomObject]@{ Hostname = $pc.Name; OS = "Nicht erreichbar"; LastBootTime = $null; PendingUpdates = $null; BitLockerOn = $null }
    }
}

$report | Export-Csv -Path "C:\Compliance\Asset-Inventar-$(Get-Date -Format yyyy-MM-dd).csv" -NoTypeInformation -Encoding UTF8

Dieses Inventar liefert die Datengrundlage für Risikoanalyse, Patchmanagement-Nachweis und - im Vorfallsfall - eine schnelle Aussage darüber, welche Systeme potenziell betroffen sind.

Meldepflichten: 24 Stunden, 72 Stunden, ein Monat

NIS2 kennt einen dreistufigen Meldeprozess für erhebliche Sicherheitsvorfälle, den die nationalen Umsetzungsgesetze übernehmen:

1. Frühwarnung (innert 24 Stunden nach Kenntnisnahme): Kurzmeldung an die zuständige Behörde (in Deutschland das BSI, je nach Land die jeweilige CSIRT-Stelle), ob ein Zusammenhang mit rechtswidrigen Handlungen oder grenzüberschreitenden Auswirkungen vermutet wird. Vollständigkeit ist hier nicht das Ziel - Geschwindigkeit vor Vollständigkeit.
2. Folgemeldung / detaillierte Meldung (innert 72 Stunden): Erste Einschätzung von Schweregrad, Auswirkungen und - falls bekannt - Kompromittierungsindikatoren (Indicators of Compromise).
3. Abschlussbericht (spätestens nach einem Monat): Vollständige Ursachenanalyse (Root Cause), ergriffene Massnahmen, grenzüberschreitende Auswirkungen.

Die Schweizer Regelung nach ISG ist einstufiger, aber vom Prinzip her verwandt: Betreiber kritischer Infrastruktur müssen einen signifikanten Cyberangriff innert 24 Stunden nach Entdeckung dem Bundesamt für Cybersicherheit (BACS, vormals NCSC) melden, mit einer Nachmeldefrist von 14 Tagen für die vollständigen Details. Ein Angriff gilt als signifikant, wenn er kritische Funktionen beeinträchtigt (Ausfall, Störung, Leistungsminderung) oder zu Manipulation beziehungsweise Exfiltration sicherheitsrelevanter oder personenbezogener Daten in relevantem Umfang führt.

Technisch hilft dir eine automatisierte Erkennung, die 24-Stunden-Frist überhaupt einhalten zu können. Mit Microsoft Sentinel oder Defender lässt sich zum Beispiel eine Abfrage bauen, die verdächtige Massenexfiltration frühzeitig aufzeigt - ein typischer Auslöser für die Meldepflicht:

// Hinweise auf grossvolumigen Datenabfluss ueber Cloud-Speicher-Sync erkennen
OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation in ("FileDownloaded", "FileSyncDownloadedFull")
| summarize DownloadCount = count(), TotalMB = sum(toint(column_ifexists("Size", 0))) / 1048576
    by UserId, ClientIP
| where DownloadCount > 500 or TotalMB > 5000
| order by TotalMB desc

Lieferkettensicherheit: Der am meisten unterschätzte Hebel

Artikel 21 Nr. 4 verlangt explizit die Berücksichtigung von Cybersicherheitsrisiken in der gesamten Lieferkette - inklusive der Beziehungen zu direkten Zulieferern und Dienstleistern. Für ein KMU ist das oft der Punkt mit dem grössten praktischen Aufwand, weil er nicht rein technisch, sondern vertraglich und organisatorisch gelöst werden muss.

Ein pragmatischer Einstieg ist ein Lieferanten-Risikoregister, das die wichtigsten IT-relevanten Dienstleister und Softwarelieferanten nach Kritikalität einstuft:

# vendor-risk-register.yaml - einfaches Beispiel fuer ein Lieferanten-Risikoregister
vendors:
  - name: "ERP-Cloud-Anbieter AG"
    kategorie: "SaaS - Kernsystem Produktion"
    datenzugriff: "Kundendaten, Finanzdaten"
    kritikalitaet: hoch
    zertifizierung: "ISO 27001 (gueltig bis 2027-03-31)"
    vertrag_sicherheitsklausel: ja
    letzte_ueberpruefung: "2026-02-15"
    massnahmen_offen:
      - "Penetrationstest-Bericht anfordern (letzter Test > 12 Monate her)"
  - name: "Managed-Print-Dienstleister GmbH"
    kategorie: "Vor-Ort-Service, Netzwerkzugriff auf Drucker-VLAN"
    datenzugriff: "keine direkten Kundendaten, aber Netzwerkzugang"
    kritikalitaet: mittel
    zertifizierung: "keine"
    vertrag_sicherheitsklausel: nein
    letzte_ueberpruefung: "2025-08-01"
    massnahmen_offen:
      - "Sicherheitsklausel in Vertrag nachtragen"
      - "Zugriff auf separates VLAN begrenzen (siehe VLAN-Grundlagen)"
  - name: "Freelance-Webentwicklerin"
    kategorie: "Einzelperson, punktueller Zugriff auf CMS"
    datenzugriff: "Webseiten-Content, kein Kundendatenzugriff"
    kritikalitaet: niedrig
    zertifizierung: "keine"
    vertrag_sicherheitsklausel: nein
    letzte_ueberpruefung: "2026-01-10"
    massnahmen_offen: []

Aus einem solchen Register leiten sich drei Handlungsfelder ab:

1. Vertragliche Klauseln nachrüsten - Mindestanforderungen an Informationssicherheit, Meldepflicht bei Sicherheitsvorfällen beim Lieferanten selbst, Auditrecht, Recht auf Kündigung bei gravierenden Verstössen.
2. Regelmässige Überprüfung nach Kritikalität staffeln - hochkritische Lieferanten jährlich, mittlere alle zwei Jahre, niedrige bei Vertragsverlängerung.
3. Software Bill of Materials (SBOM) bei kritischer Individual- oder Branchensoftware einfordern - insbesondere bei ERP- und Maschinensteuerungs-Software, damit bei einer neu bekanntwerdenden Schwachstelle (z. B. in einer verwendeten Bibliothek) schnell geklärt werden kann, ob das eigene System betroffen ist.

Governance: Die Geschäftsleitung in der Pflicht

NIS2 macht in Artikel 20 etwas, das viele KMU-Geschäftsleitungen überrascht: Cybersicherheit wird explizit zur Chefsache erklärt, nicht delegierbar an “die IT”. Die Leitungsorgane von wesentlichen und wichtigen Einrichtungen müssen:

• die Umsetzung der Risikomanagementmassnahmen billigen (formaler Beschluss, nicht nur zur Kenntnis nehmen),
• deren Umsetzung überwachen (regelmässiges Reporting, nicht nur einmal jährlich),
• selbst an Schulungen zur Cybersicherheit teilnehmen, damit sie Risiken und Massnahmen fachlich einordnen können,
• bei Pflichtverletzung mit persönlicher Haftung rechnen - viele nationale Umsetzungen sehen ausdrücklich vor, dass Bussgelder und Schadenersatzansprüche auch gegen die verantwortliche natürliche Person gerichtet werden können, zusätzlich zu Sanktionen gegen das Unternehmen.

Für die Schweiz gibt es keine wortgleiche gesetzliche Schulungspflicht der Geschäftsleitung wie in Artikel 20 NIS2. Die faktische Sorgfaltspflicht nach Art. 717 OR (Sorgfalts- und Treuepflicht des Verwaltungsrats) läuft aber in dieselbe Richtung: Eine Geschäftsleitung, die Cyberrisiken nachweislich ignoriert und dadurch einen vermeidbaren Schaden verursacht, kann zivilrechtlich haftbar gemacht werden. Wer als Schweizer KMU also ohnehin auf Nummer sicher gehen will, übernimmt die NIS2-Governance-Praxis unabhängig von der direkten Rechtspflicht:

• Mindestens einmal jährlich ein Cybersecurity-Traktandum mit klarer Beschlussfassung in der Geschäftsleitungssitzung, protokolliert.
• Eine namentlich benannte Person mit Gesamtverantwortung für Informationssicherheit (CISO-Rolle, auch als Teilzeitfunktion oder extern besetzt möglich).
• Ein Reporting-Set mit wenigen, verständlichen Kennzahlen (Anzahl offener kritischer Schwachstellen, Patch-Compliance-Quote, Anzahl Phishing-Klicks in der letzten Simulation, Status der Backup-Tests).

Gap-Analyse und Umsetzungsfahrplan

Ein realistischer Fahrplan für ein Schweizer KMU gliedert sich in drei Phasen. Die Reihenfolge ist bewusst so gewählt, dass zuerst die Grundlage (Transparenz über den Ist-Zustand) geschaffen wird, bevor in Tooling investiert wird - viele Projekte scheitern daran, dass zuerst ein SIEM gekauft wird, bevor überhaupt ein Asset-Inventar existiert.

Schritt-für-Schritt für die Gap-Analyse selbst

1. Massnahmenkatalog als Checkliste aufbereiten - die zehn Bereiche aus Artikel 21 (oder die Funktionsbereiche des IKT-Minimalstandards) als Tabelle mit den Spalten “Vorhanden”, “Teilweise”, “Fehlt”, “Verantwortlich”, “Zieltermin”.
2. Für jeden Bereich eine ehrliche Selbsteinschätzung mit den technisch Verantwortlichen durchführen - nicht nur “haben wir ein Tool dafür”, sondern “funktioniert es nachweislich” (z. B. nicht nur “Backup vorhanden”, sondern “Restore innert der letzten 90 Tage erfolgreich getestet”).
3. Risikobasiert priorisieren: Nicht jede Lücke ist gleich dringend. Kombiniere Eintrittswahrscheinlichkeit und Schadenspotenzial, um eine Reihenfolge festzulegen - MFA-Lücken bei Admin-Konten haben in der Regel höchste Priorität.
4. Budget und Verantwortlichkeiten dem Massnahmenplan zuordnen, mit klarem Owner und Termin je Massnahme - eine Liste ohne Owner bleibt erfahrungsgemäss liegen.
5. Ergebnis der Geschäftsleitung zur formalen Billigung vorlegen - das erfüllt gleichzeitig die Governance-Anforderung aus Artikel 20 respektive die Sorgfaltspflicht nach Art. 717 OR.
6. Wiederholung mindestens jährlich, bei wesentlichen Änderungen (neue Systeme, neue Lieferanten, Vorfälle) früher.

Typische Fallstricke in der Praxis

• Betroffenheit wird einmalig geprüft und nie wieder aktualisiert. Ein neuer Grosskunde in der EU, ein neuer Cloud-Vertrag oder eine Umsatzsteigerung können die Einstufung verändern - die Betroffenheitsprüfung gehört in den jährlichen Compliance-Zyklus.
• Die Lieferkette wird nur bis zur ersten Stufe betrachtet. Der eigene direkte Cloud-Anbieter mag zertifiziert sein, dessen Subunternehmer für Rechenzentrumsbetrieb aber nicht - frage nach der gesamten Kette, nicht nur nach der Fassade.
• Meldeprozesse existieren nur auf Papier. Ein Prozess, der nie unter Zeitdruck geübt wurde, versagt fast garantiert in der echten 24-Stunden-Frist - eine kurze jährliche Simulationsübung deckt das zuverlässig auf.
• Awareness-Schulungen werden als einmalige Pflichtübung behandelt. Ein jährliches 20-Minuten-Video ohne Wiederholung und ohne Phishing-Simulation erfüllt weder den Geist von Artikel 21 Nr. 7 noch bringt es echten Schutz.
• Die Geschäftsleitung delegiert die Governance-Pflicht vollständig an die IT. Genau das ist der Kernpunkt, den Artikel 20 verhindern will - Cybersicherheit ist ein Unternehmensrisiko, kein reines IT-Thema.

Weiterlernen

• EUR-Lex - Richtlinie (EU) 2022/2555 (NIS2) - der vollständige Richtlinientext mit allen Artikeln
• BACS - Meldepflicht für Cyberangriffe auf kritische Infrastrukturen - offizielle Schweizer Informationen zur 24-Stunden-Meldepflicht
• NCSC/BACS - IKT-Minimalstandards - Übersicht und Downloads der sektorspezifischen Minimalstandards
• BSI - NIS-2-Risikomanagementmassnahmen - detaillierte Erläuterung zu Artikel 21 mit deutscher Umsetzung als Referenz
• ENISA - NIS Cooperation Group - Leitlinien und Referenzmaterial der EU-Cybersicherheitsagentur
• Fedlex - Informationssicherheitsgesetz (ISG) - der vollständige Schweizer Gesetzestext

Verwandte Themen: Incident Response Plan für KMU, DSGVO/nDSG in der IT-Praxis, Zero-Trust-Architektur für KMU, Backup-Strategie 3-2-1-Regel, SIEM- und SOC-Grundlagen, IT-Notfallplanung und Disaster Recovery.

Videos

YouTube

YouTube