NIS2 für Medizinsoftware-Anbieter — welche Verfügbarkeits- und Meldepflichten 2026 gelten

Lange war NIS2 ein Zukunftsthema, das man auf später verschieben konnte. Das ist vorbei. Das deutsche NIS2-Umsetzungsgesetz ist seit Dezember 2025 geltendes Recht — und es betrifft Anbieter von Medizinsoftware auf zwei Wegen: die einen direkt, die meisten über die Lieferkette ihrer Klinik- und Praxiskunden.

Dieser Artikel ordnet ein, was konkret gilt, wer betroffen ist und welche Rolle Verfügbarkeitsüberwachung und Nachweise dabei spielen. Er ersetzt keine Rechtsberatung — die individuelle Betroffenheit ist im Einzelfall zu prüfen.

NIS2 ist in Deutschland in Kraft — seit dem 6. Dezember 2025

Die wichtigste Aktualisierung zuerst, weil sich hier seit 2024 alles geändert hat: Das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) wurde am 13. November 2025 vom Bundestag beschlossen, am 21. November 2025 vom Bundesrat gebilligt und am 5. Dezember 2025 im Bundesgesetzblatt verkündet (BGBl. I 2025 Nr. 301). Es ist am 6. Dezember 2025 in Kraft getreten (BSI-Pressemitteilung).

Die ursprüngliche EU-Frist zur Umsetzung der NIS2-Richtlinie (EU) 2022/2555 war der 17. Oktober 2024 — Deutschland hat sie deutlich gerissen. Diese Verzögerung ist jetzt beendet. Das NIS2UmsuCG ist ein Artikelgesetz; die materiellen Pflichten stehen in der Neufassung des BSI-Gesetzes, dem BSIG 2025. Wenn dieser Artikel von „§ 28”, „§ 30”, „§ 32” oder „§ 65” spricht, sind das Paragrafen dieses neuen BSIG.

Wichtig für die Einordnung: Es gibt keine generelle Übergangsfrist für die materiellen Pflichten — Risikomanagement und Meldepflichten gelten seit dem 6. Dezember 2025. Die Pflicht, sich beim BSI zu registrieren, lief sogar schon am 6. März 2026 ab. Bis dahin hatten sich erst rund 11.500 von geschätzt 29.500 betroffenen Unternehmen registriert. NIS2 ist also nicht nur in Kraft, sondern bei vielen Betroffenen noch gar nicht umgesetzt — ein realer Handlungsdruck, kein theoretisches Szenario.

Bin ich als Software-Anbieter überhaupt betroffen?

Das ist die heikelste Frage — und die, bei der pauschale Aussagen schaden. Die Betroffenheit ergibt sich aus zwei Dingen: der Größe und dem Sektor.

Die Größenschwellen (§ 28 BSIG)

NIS2 kennt zwei Stufen:

Kategorie	Schwelle (Richtwert)	Beispiele im Gesundheitswesen
Besonders wichtige Einrichtungen	ab 250 Beschäftigten oder über 50 Mio. € Umsatz und über 43 Mio. € Bilanzsumme	große Kliniken, Krankenhauskonzerne
Wichtige Einrichtungen	ab 50 Beschäftigten oder über 10 Mio. € Umsatz und über 10 Mio. € Bilanzsumme	mittlere Kliniken, Reha, größere MVZ

Die Untergrenze für direkte Betroffenheit liegt damit bei rund 50 Beschäftigten oder 10 Mio. Euro Umsatz (berechnet nach der EU-KMU-Definition 2003/361/EG, inklusive verbundener Unternehmen). Einzel- und kleine Gemeinschaftspraxen fallen in der Regel nicht direkt darunter. Den genauen Wortlaut der Schwellen solltest du im Zweifel direkt in § 28 BSIG prüfen.

Der Sektor — und warum „Medizinsoftware” kein eigener ist

Das Gesundheitswesen ist ein hochkritischer Sektor nach Anlage 1 des BSIG. Erfasst sind dort vor allem Gesundheitsdienstleister (stationäre Versorgung), Labore, Pharma-Hersteller und Hersteller bestimmter kritischer Medizinprodukte (BSI zum Sektor Gesundheit).

Hier liegt der entscheidende Punkt für Software-Anbieter: „Software-Hersteller” ist kein eigener NIS2-Sektor. Ob du direkt betroffen bist, hängt davon ab, wie du tätig bist:

• Direkt betroffen kannst du sein, wenn du nicht nur Software lieferst, sondern sie auch betreibst — als Managed-Service-Provider, Cloud- oder SaaS-Anbieter, etwa mit einer gehosteten Praxis- oder Kliniksoftware. Dann greift der Sektor „Digitale Infrastruktur / Verwaltung von IKT-Diensten (B2B)”, sofern du zusätzlich die Größenschwellen erreichst.
• Eher nicht direkt betroffen sind reine Software-Hersteller ohne eigene Betriebsleistung. Software oder Apps als Medizinprodukt sind kein eigener NIS2-Sektor.

Diese Zuordnung ist eine Einzelfallprüfung. Das BSI stellt dafür eine sektorspezifische FAQ und eine Betroffenheitsprüfung bereit. Verlass dich nicht auf ein pauschales „betrifft mich nicht”.

Der Pfad, der fast alle trifft: die Lieferkette

Selbst wenn du nicht direkt betroffen bist, kommt NIS2 mit hoher Wahrscheinlichkeit über deine Kunden zu dir. NIS2-pflichtige Einrichtungen müssen nach § 30 Abs. 2 Nr. 4 BSIG (Umsetzung von Art. 21 Abs. 2 lit. d NIS2) die Sicherheit ihrer Lieferkette steuern. Für Kliniken und größere Praxen heißt das: Sie geben ihre Pflichten vertraglich an ihre Software- und IT-Dienstleister weiter (Erläuterung zur Lieferkettensicherheit, BSI).

In der Praxis erreichen dich dadurch:

• Sicherheits- und Verfügbarkeitsanforderungen in Verträgen und Ausschreibungen
• Lieferanten-Fragebögen und Nachweis-/Audit-Anforderungen
• definierte Meldewege, über die du Vorfälle an deinen Kunden melden musst

NIS2 wirkt für die meisten Software-Anbieter also über den Markt, nicht über die Behörde. Wer seinen Klinik-Kunden Sicherheit und Verfügbarkeit sauber nachweisen kann, hat im Vergabe- und Vertragsprozess einen messbaren Vorteil — wer es nicht kann, fliegt zunehmend aus der engeren Auswahl.

Was NIS2 konkret verlangt: die Risikomanagement-Pflichten (§ 30 BSIG)

§ 30 BSIG nennt als Schutzziele ausdrücklich Verfügbarkeit, Integrität und Vertraulichkeit. Die Maßnahmen müssen geeignet, verhältnismäßig und wirksam sein und dem Stand der Technik entsprechen. Der Katalog umfasst zehn Mindestmaßnahmen (BSI zu den Risikomanagementmaßnahmen):

1. Risikoanalyse- und IT-Sicherheitskonzepte
2. Bewältigung von Sicherheitsvorfällen (Incident Handling)
3. Aufrechterhaltung des Betriebs — Backup-Management, Notfallwiederherstellung, Krisenmanagement
4. Sicherheit der Lieferkette, einschließlich der Beziehungen zu unmittelbaren Anbietern
5. Sicherheit bei Erwerb, Entwicklung und Wartung von IT-Systemen
6. Konzepte zur Bewertung der Wirksamkeit der Maßnahmen
7. Cyberhygiene und Schulungen zur Cybersicherheit
8. Kryptografie und Verschlüsselung
9. Personalsicherheit, Zugriffskontrolle und Asset-Management
10. Multi-Faktor-Authentisierung und gesicherte Kommunikation

Für das Thema Verfügbarkeit besonders relevant ist die Maßnahme zur Aufrechterhaltung des Betriebs: Business Continuity, Backup-Management, Disaster Recovery und Krisenmanagement. Entscheidend ist, dass Backups allein nicht genügen — gefordert ist ein getesteter Wiederherstellungsprozess mit definierten Wiederanlaufzeiten (RTO) und Datenverlust-Grenzen (RPO).

Genau hier setzt kontinuierliche Verfügbarkeitsüberwachung an: Sie liefert die laufenden Daten darüber, ob ein Dienst erreichbar ist, erkennt Vorfälle automatisch und dokumentiert sie lückenlos. Das ist eine Grundlage, um die Verfügbarkeits- und Incident-Handling-Anforderungen zu unterstützen — die organisatorische Umsetzung und Konformität bleibt Aufgabe des Unternehmens.

Die Meldepflichten: 24 Stunden, 72 Stunden, ein Monat (§ 32 BSIG)

Tritt ein erheblicher Sicherheitsvorfall ein, gilt eine dreistufige Meldung an die gemeinsame Meldestelle von BSI und BBK (BSI-Meldeprozess):

1. Erstmeldung — unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung; mit Angabe, ob eine rechtswidrige oder böswillige Handlung bzw. grenzüberschreitende Auswirkungen vermutet werden.
2. Folgemeldung — spätestens innerhalb von 72 Stunden nach Kenntniserlangung; Bestätigung oder Aktualisierung der Erstmeldung samt erster Bewertung des Schweregrads und gegebenenfalls Kompromittierungsindikatoren.
3. Abschlussmeldung — spätestens einen Monat nach der Meldung. Dauert der Vorfall länger an, tritt eine Fortschrittsmeldung an ihre Stelle; die finale Meldung folgt nach Abschluss der Bearbeitung.

Wann ein Vorfall erheblich ist, konkretisiert die EU-Durchführungsverordnung (EU) 2024/2690: unter anderem bei finanziellem Schaden über 500.000 Euro oder über 5 Prozent des Jahresumsatzes, beim Abfluss von Geschäftsgeheimnissen, bei Tod oder schwerer Gesundheitsschädigung einer Person, bei unbefugtem Zugriff mit Potenzial für schwere Störungen oder bei einem wiederholten gleichartigen Vorfall. Fällt eine kritische Dienstleistung aus oder wird beeinträchtigt, gilt der Vorfall stets als erheblich.

Für die 24-Stunden-Frist zählt jede Minute. Eine automatische Vorfall-Erkennung mit Zeitstempel und eine durchsuchbare Incident-Historie helfen, eine Meldung überhaupt fristgerecht erstellen und später belegen zu können.

Abgrenzung: NIS2, KRITIS-Dachgesetz und DSGVO

Drei Regelwerke werden oft verwechselt:

• NIS2 / BSIG 2025 regelt die Cyber- und IT-Sicherheit; zuständig ist das BSI.
• Das KRITIS-Dachgesetz setzt die EU-CER-Richtlinie um und regelt die physische Resilienz (Sabotage, Naturereignisse, physischer Ausfall); zuständig ist das BBK. KRITIS-Betreiber sind automatisch auch besonders wichtige Einrichtungen nach NIS2 — dann kann eine doppelte Registrierung nötig sein. Den genauen Stand und die Fristen des KRITIS-Dachgesetzes solltest du separat prüfen, da es einen eigenen Gesetzgebungspfad hat.
• Die DSGVO schützt personenbezogene Daten. Ein Cyber-Vorfall kann beide Meldepflichten parallel auslösen: die NIS2-Meldung ans BSI und — bei einer Datenpanne — die Meldung nach Art. 33 DSGVO an die Datenschutzaufsicht. Unterschiedliche Adressaten, unterschiedliche Fristen.

BSI-Grundschutz und ISO 27001 sind keine eigenen Gesetze, sondern anerkannte Rahmen, um die § 30-Maßnahmen umzusetzen und nachzuweisen. NIS2 schreibt keinen bestimmten Standard zwingend vor, aber diese Rahmen sind die praktischen Erfüllungswege.

Sanktionen — und warum die Geschäftsleitung persönlich haftet

§ 65 BSIG sieht spürbare Bußgelder vor (Übersicht zu den Bußgeldern):

• Besonders wichtige Einrichtungen: bis 10 Mio. Euro oder 2 Prozent des weltweiten Jahresumsatzes — der höhere Wert.
• Wichtige Einrichtungen: bis 7 Mio. Euro oder 1,4 Prozent des weltweiten Jahresumsatzes.

Zwei Punkte machen das ernst: Erstens wird nicht erst der Vorfall sanktioniert, sondern bereits fehlende oder unzureichende Risikomaßnahmen sowie Melde- und Dokumentationsverstöße. Zweitens haftet die Geschäftsleitung persönlich — sie muss die Maßnahmen billigen und überwachen, und eine Enthaftung durch das Unternehmen ist ausgeschlossen.

Was das für deine Tool- und Dienstleisterauswahl bedeutet

Egal über welchen Pfad NIS2 dich erreicht — direkt oder über die Lieferkette: Du brauchst belastbare Bausteine, mit denen du Verfügbarkeit und Vorfallbearbeitung nachweisen kannst. Drei davon lohnt es sich gezielt auszuwählen:

• Kontinuierliche Verfügbarkeitsüberwachung mit automatischer Vorfall-Erkennung und lückenloser Incident-Historie — als Grundlage für die Verfügbarkeits- und Meldeanforderungen.
• Datenhoheit beim Dienstleister. Ein Monitoring-Tool, dessen Daten die EU verlassen oder das von einem US-Unternehmen betrieben wird, ist nach Schrems II selbst ein dokumentationspflichtiges Thema. Mehr dazu in unserem Beitrag zum US CLOUD Act beim Monitoring und in der EU Jurisdiction Database, die über 60 Tools nach Jurisdiktion und CLOUD-Act-Exposition aufschlüsselt.
• Saubere Auftragsverarbeitung. Für die Lieferkette zählt ein sofort verfügbarer AVV. Wie du als Anbieter genau diese Prüfung bestehst, zeigt unser AVV-Check für SaaS-Anbieter.

Wichtig zur Einordnung: Ein Monitoring-Tool macht dich nicht NIS2-konform — Konformität ist eine organisatorische Gesamtleistung deines Unternehmens. Ein gut gewähltes Tool unterstützt aber gezielt die technischen Nachweise, die NIS2 und deine Klinik-Kunden von dir verlangen.

Wie das speziell für Anbieter und Einrichtungen im Gesundheitswesen zusammenkommt — deutsche Infrastruktur, sofortiger AVV, cookie-freie Status-Seiten als Verfügbarkeitsnachweis — haben wir auf unserer Seite zu Monitoring für das Gesundheitswesen zusammengefasst. Eine breitere Übersicht DSGVO-konformer Optionen bietet der Vergleich DSGVO-konformer Monitoring-Tools 2026.

---

Dieser Artikel gibt den Rechtsstand zum Juni 2026 wieder und dient der Orientierung, nicht der Rechtsberatung. Maßgeblich sind der Gesetzeswortlaut des BSIG 2025 und die individuelle Prüfung deiner Betroffenheit. Quellen: BSI, Bundesgesetzblatt (BGBl. I 2025 Nr. 301), NIS2-Richtlinie (EU) 2022/2555.