IT-Grundschutz im Krankenhaus: klinische Abhängigkeiten sichtbar machen

§ 391 Abs. 1 SGB V verpflichtet Krankenhäuser, „nach dem Stand der Technik angemessene organisatorische und technische Vorkehrungen zur Vermeidung von Störungen der Verfügbarkeit, Integrität und Vertraulichkeit ihrer informationstechnischen Systeme, Komponenten oder Prozesse zu treffen, die für die Funktionsfähigkeit des jeweiligen Krankenhauses und den Schutzbedarf der verarbeiteten Patienteninformationen maßgeblich sind.“ Nach Absatz 2 gehören verpflichtende Maßnahmen zur Steigerung der Security-Awareness der Mitarbeitenden dazu, nach Absatz 3 sind die Vorkehrungen angemessen, wenn der Aufwand nicht außer Verhältnis zu den Folgen eines Ausfalls oder einer Beeinträchtigung des Krankenhauses oder zum Schutzbedarf der Patienteninformationen steht.

Einen bestimmten Rahmen schreibt § 391 nicht vor. Absatz 4 nennt einen Weg ausdrücklich: Krankenhäuser können die Pflichten „insbesondere“ erfüllen, indem sie einen branchenspezifischen Sicherheitsstandard anwenden, dessen Eignung das BSI nach § 30 Abs. 8 BSIG festgestellt hat. IT-Grundschutz oder Grundschutz++ nennt die Vorschrift nicht. Nach Absatz 5 gilt die Pflicht für alle Krankenhäuser, soweit sie nicht ohnehin als Betreiber kritischer Anlagen nach §§ 30, 31 und 39 BSIG Vorkehrungen zu treffen haben.

Das BSI führt den „B3S Krankenhaus“ der Deutschen Krankenhausgesellschaft in Version 1.3.1 mit Ablauf der Eignungsfeststellung im November 2028. Auf der Übersichtsseite des BSI steht er im Abschnitt der Standards, die bis zum 05.12.2025 nach § 8a Abs. 2 BSIG in der alten Fassung eignungsfestgestellt wurden. § 391 Abs. 4 SGB V verweist auf eine Feststellung nach § 30 Abs. 8 BSIG in der neuen Fassung. Ob die Feststellung nach altem Recht für Absatz 4 genügt, ist eine Rechtsfrage, die diese Seite nicht beantwortet. Zur Erarbeitung schreibt das BSI: „Eine gesetzliche Pflicht zur Erarbeitung eines B3S besteht nicht.“

Ob Ihr Krankenhaus Betreiber einer kritischen Anlage ist oder als besonders wichtige oder wichtige Einrichtung nach § 28 BSIG gilt, klärt Ihre Rechtsabteilung. Für den Begriff der kritischen Anlage verweist § 2 Nr. 22 BSIG auf das KRITIS-Dachgesetz; nach § 66 BSIG ist diese Fassung aber erst anzuwenden, wenn eine Rechtsverordnung nach § 4 Abs. 3 und § 5 Abs. 1 des KRITIS-Dachgesetzes in Kraft getreten ist, bis dahin gilt § 2 Nr. 22 in der bis einschließlich 16. März 2026 geltenden Fassung weiter. Für Betreiber kritischer Anlagen verlangt § 39 BSIG Nachweise durch Sicherheitsaudits, Prüfungen oder Zertifizierungen; § 31 Abs. 2 verlangt Systeme zur Angriffserkennung. § 61 BSIG regelt Aufsichtsmaßnahmen gegenüber besonders wichtigen Einrichtungen. Nach Absatz 3 Satz 5 kann das BSI dabei gegenüber zugelassenen Krankenhäusern nach § 108 SGB V Nachweise frühestens fünf Jahre nach Inkrafttreten des Gesetzes anordnen, soweit nicht eine Rechtsverordnung nach § 56 Abs. 6 BSIG einen früheren Zeitpunkt bestimmt. Wir ordnen die Vorgaben ein, die Sie nennen oder die in Ihren Unterlagen stehen; ob sie rechtlich gelten, prüft Ihre Rechtsabteilung.

Grundschutz++ setzt beim Geschäftsprozess an. Unter Geschäftsprozessen „können Abläufe, Verwaltungsverfahren und Fachverfahren verstanden werden“ (300-1 Kap. 2.5); im Krankenhaus sind das neben Verwaltung und Abrechnung vor allem die Behandlungsprozesse, etwa Aufnahme, Diagnostik, Medikation, Operation und Entlassung. Der Schutzbedarf wird je Prozess für Vertraulichkeit, Integrität und Verfügbarkeit festgelegt, in den Kategorien „normal“ und „hoch“. Hoch bedeutet nach Kapitel 2.6, dass die Auswirkungen beträchtlich sein können. Als Hilfestellung nennt der Standard Schadensszenarien, darunter die „Beeinträchtigung der persönlichen Unversehrtheit“. Die Szenarien sind eine Hilfestellung; die Einstufung trifft die Institution und gibt die Leitung frei (Kap. 2.10).

Für Behandlungsprozesse liegt der Gedanke nahe, dass eine verfälschte Medikationsangabe oder ein nicht verfügbarer Befund die Unversehrtheit von Patientinnen und Patienten beeinträchtigen kann. Wird ein Prozess deshalb mit „hoch“ eingestuft, folgen zwei Pflichten. Erstens ist eine explizite Risikobetrachtung erforderlich, wenn ein Geschäftsprozess bei mindestens einem Schutzziel hohen Schutzbedarf hat (Kap. 2.11). Zweitens sind die Zugehörigkeit und Abhängigkeit der Assets zu diesem Prozess zu dokumentieren (Kap. 3.2). Der Standard empfiehlt, beim erstmaligen Aufbau mit dem wichtigsten Geschäftsprozess aus der höchsten Schutzbedarfskategorie zu beginnen (Kap. 2.6); sukzessive sind alle Prozesse im Anwendungsbereich zu untersuchen.

Den Anwendungsbereich legt die Institutionsleitung fest. Er kann das ganze Krankenhaus oder einen Teilbereich umfassen (300-1 Kap. 2.3). Gehört das Krankenhaus zu einem Verbund mit mehreren Standorten, einer zentralen IT-Gesellschaft oder einem Medizinischen Versorgungszentrum, sind diese Grenzen und ihre Schnittstellen bei der Abgrenzung zu klären.

BSI-Standard 300-1 unterscheidet bei der Dokumentation der Assets nach Schutzbedarf. Bei normalem Schutzbedarf reichen die Abhängigkeiten zwischen Anwendungen und IT-Systemen sowie zwischen IT-Systemen und Räumen. Bei hohem Schutzbedarf sind Zugehörigkeit und Abhängigkeit der Assets zum Geschäftsprozess zu dokumentieren; die Dokumentation ist laut Kapitel 3.2 „unter anderem für die spätere Risikobetrachtung erforderlich, da diese auf Ebene des Geschäftsprozesses und entlang des Ressourcenpfades durchgeführt wird.“ Die Form ist frei: Tabelle, CMDB, Service-Map, Netzplan oder Abhängigkeitsübersicht.

Für das Krankenhaus heißt das: Der Pfad endet nicht am Krankenhausinformationssystem. Zu einem Behandlungsprozess gehören auch Schnittstellen zwischen Systemen, vernetzte Geräte, die Netzsegmente, in denen sie hängen, Fernwartungszugänge der Hersteller, Serverräume, die Stromversorgung und externe Dienstleister. Kapitel 3.1 verlangt außerdem, die Schnittstellen des Informationsverbunds zu externen Prozessen und Systemen eindeutig zu dokumentieren, organisatorisch, technisch und infrastrukturell. Die Abhängigkeitskarte unten zeigt den Pfad an einem fiktiven Beispiel, mit der Zielobjektkategorie aus Anhang 1 von 300-1 und dem Katalogbezug je Asset.

Das Beispiel ist fiktiv: ein Krankenhaus der Regelversorgung mit eigener Notaufnahme, Zentrallabor und Krankenhausinformationssystem. Der Geschäftsprozess „GP-K01 Notfallversorgung mit Laborbefund“ ist für Integrität und Verfügbarkeit mit „hoch“ eingestuft, weil ein verfälschter oder verspäteter Befund die Behandlung beeinträchtigen kann. Bezeichnungen, Abhängigkeiten und Rückfallebenen sind Annahmen für das Beispiel. Die Karte ist ein vereinfachter Ausschnitt: Telefonanlage, Drucker, Anmeldedienst, Probentransport und weitere Ressourcen fehlen. Die Spalte „hängt ab von“ unterscheidet Abhängigkeiten im Betrieb von Abhängigkeiten für Wartung. Die Karte betrachtet vor allem Ausfälle; für die Integrität gehört ein zweiter Fall dazu: Die Systeme laufen, aber Befunde oder Zuordnungen zu Patientinnen und Patienten könnten verfälscht sein. Halten Sie fest, wer dann die Nutzung der betroffenen Informationen einschränkt, ihre Verlässlichkeit prüfen lässt und sie wieder freigibt.

Jedes Asset bekommt nach der Erläuterung zur Methodik-Anforderung STM.2.1.2 eine verantwortliche Rolle oder einen Asset-Owner. Für Behandlungsprozesse gehört die klinische Seite dazu: Ausfallfolgen, Rückfallebenen und die Rückkehr zum Regelbetrieb bestätigen die ärztliche und pflegerische Leitung des Bereichs und die Laborleitung, nicht IT oder Medizintechnik allein. Diese Aufteilung ist unser Vorschlag.

Anhang 1 von 300-1 kennt keine eigene Zielobjektkategorie für Medizingeräte. Vernetzte Geräte lassen sich der Kategorie IT-Systeme zuordnen, die der Standard als „Informationstechnische Systeme zur elektronischen Datenverarbeitung“ definiert. Ob die Anforderungen dieser Kategorie ein Gerät hinreichend abdecken, prüfen Sie je Gerätetyp. Ist das nicht der Fall, verlangt Kapitel 2.11 eine explizite Risikobetrachtung, „wenn ein für den Informationsverbund relevantes Asset durch die bestehenden Zielobjektkategorien und die ihnen zugeordneten Anforderungen nicht hinreichend abgedeckt wird“. Kapitel 3.4.3 sieht dafür ergänzende Anforderungen im Format des Katalogs vor. Pflichten aus dem Medizinprodukterecht sind nicht Gegenstand dieser Seite.

Kann eine Anforderung an einem Gerät nicht umgesetzt werden, etwa weil der Hersteller keine Änderung der Konfiguration zulässt, ist „nicht anwendbar“ nach 300-1 Kapitel 4.1.1 nur mit einem der beiden dort genannten Gründe zulässig: Die zugrunde liegende Komponente existiert im Informationsverbund nicht, oder die Anforderung kann funktional nicht erfüllt werden. Die Begründung ist zu dokumentieren. Bleibt eine anwendbare SOLLTE-Anforderung auf absehbare Zeit unerfüllt, folgt nach Kapitel 2.11 ebenfalls eine explizite Risikobetrachtung.

Die Spalte „Rückfallebene“ der Abhängigkeitskarte führt zur Notfallplanung. Der Anwenderkatalog verlangt einen Wiederanlaufplan für zeitkritische Systeme und Anwendungen (NOT.3.1, SOLLTE). Laut Erläuterung legt er fest, wie eine ausgefallene Ressource innerhalb einer Wiederanlaufzeit auf ein vorgesehenes Notbetriebsniveau gebracht wird; ohne BCMS lassen sich die zeitkritischen Ressourcen über die Schutzbedarfsfeststellung mit hohem Schutzbedarf für Verfügbarkeit bestimmen. Ein Geschäftsfortführungsplan für zeitkritische Geschäftsprozesse ist im Katalog eine KANN-Anforderung (NOT.3.2). Die Erläuterung nennt als Beispiel für einen Notbetrieb ausdrücklich, dass ein digital unterstützter Prozess wieder analog durchgeführt wird, und ordnet Geschäftsfortführungspläne der Verantwortung eines BCMS zu.

Die Einstufung „hoch“ ersetzt keine zeitliche Planung. Wie lange ein Prozess unterbrochen sein darf, welches Notbetriebsniveau mindestens nötig ist und wie lange der manuelle Betrieb durchgehalten werden kann, legen Sie mit den klinisch Verantwortlichen fest; der Wiederanlaufplan nach NOT.3.1 setzt solche Wiederanlaufzeiten voraus. Besteht ein BCMS, entstehen sie in der Business-Impact-Analyse nach BSI-Standard 200-4 Kapitel 7. Für ein Krankenhaus bedeutet das außerdem: Die Papierformulare, Telefonlisten und Botengänge aus der Abhängigkeitskarte sind erst dann eine Rückfallebene, wenn sie dokumentiert, verteilt und geübt sind. Der Katalog verlangt, Nutzende zur Vorgehensweise in Notfällen und Krisen zu sensibilisieren (NOT.3.3, SOLLTE), und als MUSS-Anforderung ein Verfahren zur rollenspezifischen Schulung und Sensibilisierung (SENS.1.1). Damit gibt es einen Anknüpfungspunkt für die Awareness-Maßnahmen nach § 391 Abs. 2 SGB V; ob Ihre Maßnahmen die gesetzliche Pflicht erfüllen, ist eine Rechtsfrage.

Ein Krankenhaus, das den B3S anwendet oder anwenden will, kann trotzdem nach Grundschutz++ arbeiten wollen, etwa weil der Träger mehrere Einrichtungen nach einer einheitlichen Methodik führt oder ein Zertifikat nach ISO 27001 auf Basis von IT-Grundschutz anstrebt. Eine Zuordnung zwischen dem B3S Krankenhaus und dem Anwenderkatalog Grundschutz++ hat das BSI in den ausgewerteten Quellen (Stand 1. November 2026) nicht veröffentlicht. Wer beides nutzt, stellt die Zuordnung selbst her und kennzeichnet sie als eigene.

Den Inhalt des B3S beschreibt diese Seite nicht; er steht laut BSI auf der Website der Deutschen Krankenhausgesellschaft zum Download bereit. Methodisch lassen sich Vorgaben aus dem B3S wie jede andere vertragliche oder branchenbezogene Verpflichtung behandeln: Sie gehören in das Compliance-Management (300-1 Kap. 2.2), und was der Anwenderkatalog nicht abbildet, ergänzt das Anforderungspaket (Kap. 3.4.3). Welcher Rahmen für Ihr Haus der führende ist und ob er die Pflichten aus § 391 SGB V oder dem BSI-Gesetz erfüllt, entscheiden Leitung und Rechtsabteilung.

Die Schritte folgen den Prozessschritten aus 300-1; die Reihenfolge und die Verbindung zur Abhängigkeitskarte sind unser Vorschlag.