Gesundheits-Vertical: Mapping zu NIS2/KRITIS/ISO und die CISO-Roadmap

Problem in der Praxis

In der Praxis entstehen die sektorspezifischen Pflichten historisch und organisatorisch getrennt: Die Krankenhaus-IT bedient die Pflicht aus dem Sozialrecht, das Qualitätsmanagement den branchenspezifischen Standard, die Medizintechnik das Produktrecht, ein TI-Team die Telematikanbindung, jede Einheit mit eigenen Risikoanalysen, Maßnahmenlisten und Nachweisen.

Das Ergebnis ist regelmäßig ein Flickenteppich: Dieselbe Serverlandschaft wird mehrfach bewertet, und niemand kann auf Managementebene belegen, ob die Summe der Aktivitäten die Pflichten abdeckt. Besonders kritisch ist die Doppelbetroffenheit: Ein Krankenhaus oberhalb der KRITIS-Schwellenwerte unterliegt sowohl der Krankenhauspflicht als auch dem KRITIS-Regime der NIS2-Umsetzung. Beide Ebenen unkoordiniert zu bedienen, kostet Ressourcen und erzeugt trotzdem Lücken.

CISO-Einordnung

Die sektorspezifischen Anforderungen teilen einen gemeinsamen methodischen Kern (Scope, Risikoanalyse, angemessene Maßnahmen nach dem Stand der Technik, Notfall- und Kontinuitätsmanagement, Lieferantensicherheit, Angriffserkennung, Wirksamkeitsprüfung), den ein ISMS abbildet. Die wichtigsten Bezugspunkte:

• § 391 SGB V (Digital-Gesetz, in Kraft seit 26.03.2024) verpflichtet alle Krankenhäuser zu angemessenen Vorkehrungen nach dem Stand der Technik; er löst § 75c SGB V ab, der branchenspezifische Standard ist als Umsetzungsweg vorgesehen.
• B3S "Medizinische Versorgung" (Deutsche Krankenhausgesellschaft) adressiert primär KRITIS-Krankenhäuser, dient aber auch Nicht-KRITIS-Häusern als Orientierung und ist ISMS-orientiert aufgebaut.
• Telematikinfrastruktur / gematik (§§ 306, 311 ff. SGB V) betrifft angebundene Leistungserbringer und TI-Hersteller; Datensicherheits-Maßnahmen legt die gematik im Benehmen mit dem BSI fest (TI 2.0 mit Zero-Trust-Ansatz ZETA).
• MDR/IVDR (VO (EU) 2017/745 und 2017/746) verlangt Cybersecurity über den gesamten Produktlebenszyklus; relevant für Hersteller von Medizinprodukten und Software als Medizinprodukt.

Behördenzuordnung: Zuständig sind das BSI (KRITIS, Sicherheitsbestätigungen), die gematik im Benehmen mit dem BSI (TI-Datensicherheit) und das BfArM gemeinsam mit dem BSI (DiGA/DiPA). Die Bundesnetzagentur ist für den Gesundheitssektor nicht zuständig.

Umsetzungsperspektive

Ein tragfähiges Mapping ordnet die Regime als Anwendungen unter das ISMS:

• Gemeinsamer Scope und Asset-Basis. Kritische Prozesse, Systeme und Datenflüsse werden einmal erfasst; darauf wird markiert, welche Anlagen KRITIS-relevant sind und welche TI- oder Medizinprodukte-Bezug haben.
• Eine Risikomethodik, mehrere Sichten. Die Ergebnisse der Risikoanalyse werden auf § 391, den branchenspezifischen Standard und gegebenenfalls das Produktrecht gemappt.
• Maßnahmen und Nachweise als gemeinsamer Pool. Eine Zugriffskontrolle, ein Notfallplan oder ein Patchprozess erfüllt meist mehrere Anforderungen gleichzeitig; das ISMS verwaltet beides zentral und verweist auf die jeweiligen Pflichten.

Eine Besonderheit für Hersteller: Seit dem 01.01.2025 ist ein Konformitätsnachweis nach BSI TR-03161 Voraussetzung für die DiGA/DiPA-Listung im BfArM-Verzeichnis; für Medizinprodukte dient die MDCG-Guidance 2019-16 als frei verfügbare Orientierung.

Eine sinnvolle Roadmap läuft typischerweise in vier Wellen: zuerst ISMS-Grundstruktur und gemeinsamer Scope; dann § 391 für alle Häuser; danach das KRITIS-/B3S-Regime für kritische Anlagen samt Nachweisplanung; schließlich produkt- und TI-spezifische Themen dort, wo die Einrichtung als Hersteller oder Anbieter auftritt.

Typische Fehler

1. Jedes Regime wird als eigenes Projekt mit eigener Risikoanalyse und eigenen Nachweisen geführt, statt auf einer gemeinsamen ISMS-Basis aufzusetzen.
2. Es wird angenommen, ein ISO/IEC-27001-Zertifikat decke den KRITIS-Nachweis automatisch ab. Das gilt nur, wenn der Scope die kritische Anlage und die KRITIS-Pflichten erfasst.
3. Die Doppelbetroffenheit aus Krankenhauspflicht und KRITIS-Regime wird übersehen, sodass eine der beiden Ebenen unbedient bleibt.
4. Behördenzuständigkeiten werden verwechselt, etwa die Bundesnetzagentur fälschlich als Aufsicht im Gesundheitssektor angenommen.
5. Der starre Zyklus "alle zwei Jahre" aus dem alten § 75c wird fortgeschrieben, obwohl § 391 diese Formulierung nicht mehr enthält.

Risiken und Trade-offs

Die Konsolidierung über ein ISMS reduziert Doppelarbeit, schafft aber eine Abhängigkeit von der Qualität der gemeinsamen Basis: Ist der Scope unsauber, vervielfältigen sich Fehler über alle Regime hinweg. Eine belastbare Asset- und Prozesslandkarte ist daher Voraussetzung, bevor Mappings entstehen.

Ein zweiter Trade-off betrifft die Tiefe je Regime: Ein generischer ISMS-Control kann eine Pflicht formal adressieren, ohne die fachliche Tiefe zu liefern, die Produktrecht oder TI-Sicherheitsarchitektur verlangen. Schließlich ist die Rechtslage in Bewegung: Die NIS2-Umsetzung hat Paragrafenverweise neu strukturiert, sodass auf Paragrafen festgeschriebene Mappings regelmäßig gegen den geltenden Gesetzestext zu prüfen sind.

Entscheidungspunkte

• Ist die Einrichtung tatsächlich KRITIS-Betreiber im Gesundheitssektor, oder gilt allein die allgemeine Krankenhauspflicht? Die Antwort entscheidet über Umfang und Nachweispflichten.
• Soll das ISMS auf ISO/IEC 27001 oder auf dem BSI IT-Grundschutz aufsetzen, und deckt der gewählte Scope die kritische Anlage vollständig ab?
• Tritt die Einrichtung auch als Hersteller oder TI-Anbieter auf, sodass MDR/IVDR, TR-03161 oder TI-Sicherheitsanforderungen zusätzlich greifen?
• Welche Maßnahmen und Nachweise lassen sich regimeübergreifend nutzen, und wo ist fachspezifische Tiefe unverzichtbar?

Praktische Empfehlungen

1. Errichten Sie zuerst die gemeinsame ISMS-Basis mit einem sauberen Scope und einer einheitlichen Risikomethodik, bevor Sie sektorspezifische Mappings anlegen.
2. Führen Sie eine Betroffenheitsmatrix: je Regime, ob es greift, mit welchem Geltungsbereich und welcher Behördenzuständigkeit.
3. Klären Sie frühzeitig den KRITIS-Status und planen Sie den Nachweis als wiederkehrende Pflicht, nicht als Einmalprojekt.
4. Verknüpfen Sie jede zentrale Maßnahme mit den Pflichten, die sie bedient, damit ein Nachweis mehrfach wirkt, und prüfen Sie Paragrafenverweise regelmäßig gegen den geltenden Gesetzestext.
5. Integrieren Sie produkt- und TI-spezifische Anforderungen in die jeweiligen Entwicklungs- und Betriebsprozesse, statt sie nachgelagert dem ISMS aufzubürden.

Relevante Normreferenzen

Frei zitierfähig: § 391 SGB V (IT-Sicherheit in Krankenhäusern), §§ 306, 311 ff. SGB V (gematik/TI), BSIG i. d. F. des NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes (NIS2UmsuCG) (Umsetzung der NIS2-Richtlinie, RL (EU) 2022/2555; Paragrafenverweise neu strukturiert, am geltenden Text zu prüfen), VO (EU) 2017/745 (MDR) und VO (EU) 2017/746 (IVDR), MDCG 2019-16 sowie BSI TR-03161 (DiGA/DiPA-Konformitätsnachweis).

Nur konzeptionell referenziert (kostenpflichtig bzw. lizenzsensibel): DKG-B3S "Medizinische Versorgung", gematik-Spezifikationen, ISO/IEC 27001, IEC 81001-5-1, IEC 62304. Ohne deutschen Rechtsbezug, optionales Mapping-Raster: NIST CSF / SP 800-53.