Fachbeitrag · ISMS · 3. September 2026
ISMS einführen: die ersten 90 Tage in einer Klinik
Ein ISMS im Krankenhaus aufbauen, ohne im Papier zu versinken: Geltungsbereich, Erfassung, Risiken und Nachweise — Woche für Woche, mit den fünf typischen Fehlern.
Die meisten ISMS-Projekte in Kliniken scheitern nicht an der Norm. Sie scheitern in den ersten sechs Wochen, weil zu breit angefangen wird. Dieser Beitrag beschreibt einen Ablauf, der sich in Häusern zwischen 200 und 1.200 Betten bewährt hat — und benennt die Stellen, an denen es regelmäßig kippt.
Woche 1 bis 2: den Geltungsbereich schmal schneiden
Die erste Entscheidung ist die folgenreichste, und sie fällt fast immer zu großzügig aus: „Das ganze Haus.“ Das klingt nach Gründlichkeit und ist der zuverlässigste Weg, nach vier Monaten nichts Vorzeigbares zu haben.
Ein tragfähiger Geltungsbereich für den Start umfasst die Systeme, ohne die die Versorgung steht: KIS, LIS, PACS, die Netzinfrastruktur dahinter, die Verzeichnisdienste. Nicht die Verwaltung, nicht die Küche, nicht die Haustechnik — die kommen in der zweiten Runde.
Wichtig ist, dass der Ausschluss begründet dokumentiert wird. Ein bewusst geschnittener Geltungsbereich ist normkonform. Ein unklarer ist ein Prüfbefund.
Ebenfalls in diese zwei Wochen gehört die Benennung: Wer ist Informationssicherheitsbeauftragter, mit welchem Zeitbudget, und an wen berichtet er? Wenn die Antwort „der IT-Leiter, nebenbei“ lautet, ist das ein Konflikt, den die Norm ausdrücklich adressiert — die Person, die den Betrieb verantwortet, kann ihn nicht unabhängig prüfen.
Woche 3 bis 6: erfassen, was da ist
Jetzt kommt der Teil, der Zeit kostet und keinen Applaus bringt. Erfasst wird nicht „alles“, sondern das, was im Geltungsbereich liegt: Anwendungen, Server, Netzsegmente, Schnittstellen, und die Verantwortlichen dazu.
Zwei Dinge machen den Unterschied zwischen einer nützlichen Erfassung und einer Fleißarbeit. Erstens: Die Liste führt Prozesse, nicht nur Technik. „Server SRV-KIS-03“ sagt in einer Risikobewertung nichts; „stationäre Dokumentation“ sagt alles. Zweitens: Zu jedem Eintrag gehört eine Person mit Namen, nicht eine Abteilung. Abteilungen treffen keine Entscheidungen.
Ziehen Sie die Quellen, die es schon gibt — CMDB, Inventarliste der Medizintechnik, das Verarbeitungsverzeichnis aus dem Datenschutz. Das Verarbeitungsverzeichnis ist dabei die meistübersehene Abkürzung: Es listet bereits die Verfahren mit Zweck, Daten und Verantwortlichen. Für ein ISMS fehlen nur noch Schutzbedarf und technische Zuordnung.
Woche 7 bis 10: Risiken bewerten, ohne in der Matrix zu ertrinken
Hier verliert sich die Mehrzahl der Projekte. Die Ursache ist immer dieselbe: Es wird zu fein bewertet. Fünfstufige Skalen, Eintrittswahrscheinlichkeit in Prozent, Schadenshöhe in Euro — für 400 Objekte. Das erzeugt Wochen an Arbeit und keine einzige zusätzliche Erkenntnis.
Drei Stufen reichen: hoch, mittel, niedrig, je für Schaden und Wahrscheinlichkeit. Bewertet wird auf Ebene der Prozesse und Systemgruppen, nicht je Gerät. Und die Bewertung trifft nicht der ISB allein am Schreibtisch, sondern eine Runde mit Fachseite und IT — anderthalb Stunden, protokolliert.
Was am Ende zählt, ist nicht die Zahl, sondern die Begründung dahinter. Eine Prüfstelle rechnet Ihre Matrix nicht nach. Sie fragt, warum dieses Risiko hoch und jenes mittel ist, und ob die Antwort mehr ist als ein Gefühl.
Woche 11 bis 13: Maßnahmen und der Nachweis, dass sie wirken
Aus der Bewertung entstehen Maßnahmen. Der Fehler an dieser Stelle ist ein anderer als vorher: Es wird zu viel auf einmal beschlossen. Ein Maßnahmenplan mit sechzig Punkten wird nicht abgearbeitet, er wird verwaltet.
Nehmen Sie die zehn, die den größten Anteil des bewerteten Risikos abdecken, mit Termin und Verantwortlichem. Der Rest steht dokumentiert als bekannt und terminiert für die nächste Runde — auch das ist ein zulässiger Zustand und deutlich belastbarer als eine Liste, an der seit Monaten niemand arbeitet.
Und zu jeder umgesetzten Maßnahme gehört ein Nachweis, der ohne Rückfrage verständlich ist: das Protokoll der Schulung mit Teilnehmerliste, der Screenshot der geänderten Richtlinie mit Datum, das Ticket mit Abschlussvermerk. Nachweise, die man im Prüfungstermin erst suchen muss, existieren für die Prüfung nicht.
Die fünf Fehler, die ein ISMS zum Aktenordner machen
Erstens: der zu weite Geltungsbereich. Er ist die häufigste Einzelursache für Projekte, die nach einem halben Jahr nichts vorzuweisen haben.
Zweitens: die Bewertung ohne die Fachseite. Ein ISMS, das nur die IT erarbeitet hat, beschreibt IT-Risiken und übersieht die Versorgungsrisiken — und genau die sind gemeint.
Drittens: Dokumente statt Nachweise. Eine Richtlinie beweist nicht, dass jemand danach handelt.
Viertens: keine Wiedervorlage. Ein ISMS ist ein Zyklus. Ohne festen Termin für die nächste Bewertung ist es eine einmalige Anstrengung mit Verfallsdatum.
Fünftens: die fehlende Geschäftsführungsentscheidung. Restrisiken müssen von der Leitung getragen werden, schriftlich. Fehlt das, hängt die Verantwortung faktisch beim ISB — und das hält keiner Prüfung stand, arbeitsrechtlich übrigens auch nicht.
Was nach 90 Tagen dasteht
Ein begründeter Geltungsbereich. Eine Erfassung der versorgungskritischen Systeme mit Verantwortlichen. Eine Risikobewertung, die eine Runde mit der Fachseite überstanden hat. Zehn umgesetzte Maßnahmen mit Nachweis. Eine Entscheidung der Leitung zu den verbleibenden Risiken. Und ein Termin für die nächste Runde.
Das ist kein zertifizierungsreifes ISMS. Es ist der Zustand, in dem eine Aufsicht sieht, dass gearbeitet wird — und der Punkt, ab dem die Weiterarbeit nicht mehr am Anfangen scheitert.
Wir bringen diesen Ablauf als fertigen Standard mit, statt ihn in jedem Haus neu zu erfinden. Deshalb reden wir über vier bis sechs Monate und nicht über achtzehn.
Weiterführend: B3S im Krankenhaus: was der Standard verlangt · Das Medizingerät im Netz: NIS2 für die Medizintechnik · BCM im Krankenhaus nach BSI 200-4