ISO 27001 für Klinik-Software: Was zertifiziert ist und was nicht

In nahezu jedem Klinik-Software-Vertriebsdeck steht ein Satz: „Wir sind ISO 27001 zertifiziert.“ Die Aussage stimmt meistens. Das Zertifikat existiert, das Audit ist nicht abgelaufen, das Datum trägt. Was die Aussage nicht beantwortet, ist die Frage, die in einer Klinik-IT-Beschaffung tatsächlich entscheidet: Was liegt im Geltungsbereich, und was liegt außerhalb? Bei einer Klinik-KI-Anwendung sind das in der Regel drei Komponenten — die Modell-Trainings-Infrastruktur, die Compute- und Storage-Schicht des Cloud-Providers, die Subprozessoren-Kette aus Modell-, Embedding- und Observability-Diensten. Jede dieser drei Komponenten kann mit-zertifiziert sein. Jede kann auch als Lieferanten-Beziehung daneben stehen, gestützt auf das Zertifikat eines anderen Hauses, mit einer eigenen Audit-Spur.

Die Norm ISO/IEC 27001:2022 definiert ein Information Security Management System (ISMS) und führt im Annex A 93 Kontrollen in vier Themen — organisatorisch, personell, physisch, technologisch. Sie verlangt für jedes ISMS einen erklärten Geltungsbereich (Scope) und ein Statement of Applicability (SoA), das jede der 93 Annex-A-Kontrollen entweder als anwendbar oder als ausgeschlossen mit Begründung dokumentiert. Daneben stehen drei thematisch gerichtete Standards der gleichen Familie: ISO/IEC 27017 für Cloud-Sicherheits-Kontrollen, ISO/IEC 27018 für personenbezogene Daten in öffentlichen Cloud-Diensten und ISO/IEC 42001 für Künstliche-Intelligenz-Management-Systeme, publiziert 2023. Drei Erweiterungen, drei eigene Geltungsbereiche, drei eigene Audit-Stränge — sie ersetzen ISO 27001 nicht, und sie werden nicht automatisch von einer ISO-27001-Zertifizierung mit-erfasst.

Die Zertifizierungs-Mechanik selbst arbeitet in einem dreijährigen Zyklus: ein vollständiges Erst-Audit bei der Erst-Zertifizierung, danach jährliche Überwachungs-Audits, am Ende des Zyklus ein Re-Zertifizierungs-Audit. Das Datum auf dem Zertifikat sagt aus, dass das ISMS zum Zeitpunkt des letzten Audits tragfähig war. Es sagt nichts darüber aus, wie sich der Geltungsbereich seit dem letzten Audit entwickelt hat — ob neue Subprozessoren dazugekommen sind, ob ein Cloud-Provider gewechselt wurde, ob eine Modell-Trainings-Pipeline umgezogen ist. Die Frage, seit wann der aktuelle Geltungsbereich gilt, ist deshalb operativ informativer als die Frage, seit wann das Zertifikat gültig ist.

Was ein Zertifikat aussagt — und was nicht

Ein ISO-27001-Zertifikat ist eine Aussage über ein Management-System innerhalb eines erklärten Geltungsbereichs. Der Geltungsbereich steht in zwei Dokumenten: im Scope-Statement auf dem Zertifikat selbst und ausführlicher im SoA, das die ISMS-Verantwortlichen pflegen. Das Zertifikat zeigt das Ergebnis; das SoA zeigt das Vorgehen. Ohne SoA-Einsicht weiß die Beschaffende Stelle nur eines: Im Anbieter-Haus existiert ein ISMS, das ein Audit-Haus für tragfähig hält. Sie weiß nicht, welche Annex-A-Kontrollen in den Geltungsbereich eingeschlossen sind und welche mit welcher Begründung ausgeschlossen wurden. Sie weiß nicht, ob die Kontrollen auf die KI-spezifische Verarbeitung angewendet werden oder nur auf das Verwaltungs-Backoffice. Und sie weiß nicht, an welchen Stellen das ISMS sich auf Lieferanten-Zertifikate stützt — die in der Annex-A-Kontroll-Familie A.5.19 bis A.5.23 (Lieferanten-Beziehungen) der 2022er Version dokumentiert sind. Typische SoA-Ausschlüsse sind legitim, wenn sie begründet sind: physisch getrennte Entwicklungs-Umgebungen, die nicht mit produktiven Patient:innen-Daten arbeiten; Forschungs-Pipelines mit anonymisierten Trainings-Datensätzen; Subsystem-Komponenten, die organisatorisch in einer Tochtergesellschaft mit eigenem ISMS liegen. Jeder dieser Ausschlüsse bleibt für eine Klinik-IT-Beschaffung nur dann auswertbar, wenn er sichtbar ist.

Drei Komponenten, die oft außerhalb des Geltungsbereichs liegen

Erstens, die Modell-Trainings-Infrastruktur. Klinik-KI-Anbieter trainieren ihre Modelle selten im selben Rechenzentrum, in dem die Produktiv-Software läuft. Das Training braucht Grafikprozessor-Cluster mit hohem Durchsatz, häufig in einer separaten Hyperscaler-Umgebung oder bei einem spezialisierten Compute-Anbieter. Im Trainings-Datenfluss sitzen Trainings-Datensätze in pseudonymisierter oder anonymisierter Form, Trainings-Loops mit eigenem Logging, Hyperparameter-Tuning, Modell-Versionierung — am Ende stehen Modell-Gewichte, die in die Produktiv-Umgebung übertragen werden. Diese Trainings-Umgebung kann eine eigene Sicherheits-Architektur haben — sie liegt aber typisch nicht im Geltungsbereich des Produktiv-ISMS. Das Anbieter-Zertifikat als Aussage über die Modell-Trainings-Datenflüsse zu lesen, geht am erklärten Scope vorbei. Die Frage „Wo wurden die Modell-Gewichte unter welchen Sicherheits-Kontrollen erzeugt?“ beantwortet das Produktiv-Zertifikat nicht.

Zweitens, die Cloud-Provider-Compute- und Storage-Schicht. Wenn der Anbieter seine Software in einer öffentlichen Cloud betreibt, läuft eine erhebliche Schicht der Infrastruktur unterhalb der Anbieter-Verantwortung — Hypervisor, Netzwerk, Storage-Controller, Hardware. Der Cloud-Provider hat dafür eigene Zertifikate, häufig ISO 27001, ISO 27017, ISO 27018 sowie nationale Pendants wie das C5-Testat des Bundesamts für Sicherheit in der Informationstechnik (BSI). Das Anbieter-ISMS verweist über die Annex-A-Kontroll-Familie A.5.19 bis A.5.23 auf diese Lieferanten-Zertifikate. Die Aussage ist also zweistufig: Das Anbieter-Zertifikat sagt etwas über die Anbieter-Schicht aus, und das Lieferanten-Zertifikat sagt etwas über die Cloud-Schicht aus. Beide zusammen ergeben das Bild — keine der beiden Aussagen allein. Das BSI-C5-Testat (Cloud Computing Compliance Criteria Catalogue) des Cloud-Providers — sofern der Anbieter dort liegt — gehört in dieselbe Vor-Beschaffungs-Prüfung wie das Anbieter-Zertifikat selbst. Ohne diese zweite Aussage bleibt eine Lücke im Geltungsbereichs-Bild bestehen.

Drittens, die Subprozessoren-Kette. Eine Klinik-KI-Anwendung greift in der Regel auf weitere Dienste zurück: einen Modell-Schnittstellen-Anbieter, einen Embedding-Provider für Vektor-Repräsentationen, einen Observability-Dienst für Logs und Telemetrie, manchmal einen separaten Datenbank-Service. Jeder dieser Dienste ist ein Auftragsverarbeiter oder Sub-Auftragsverarbeiter. Jeder hat ein eigenes ISMS — oder hat keines. Die Annex-A-Kontroll-Familie zur Lieferanten-Beziehung verlangt vom Anbieter, diese Kette zu pflegen, zu prüfen und vertraglich zu verankern. Sie verlangt nicht, dass jedes Glied der Kette selbst ISO-27001-zertifiziert ist. Die Frage, wer am Ende die Daten sieht und unter welchem Sicherheits-Regime, beantwortet die Lieferanten-Liste — nicht das Anbieter-Zertifikat. Im klinischen Kontext kommt eine zweite Tiefen-Schicht hinzu: Manche Subprozessoren stützen sich ihrerseits auf Sub-Subprozessoren — Cloud-Compute-Schichten, Inferenz-Endpunkte, Audit-Logging-Backends. Die Annex-A-Familie regelt diese Sub-Sub-Beziehung über Vertrags-Klauseln und Audit-Rechte; sie regelt sie nicht durch automatische Zertifikats-Übertragung von einer Ebene auf die nächste.

Was die Vor-Beschaffungs-Prüfung anfordert

Die operative Konsequenz für die Klinik-IT-Beschaffung sind drei Artefakte, nicht eines. Erstens: das Zertifikat selbst, mit dem Datum der Erst-Zertifizierung, dem aktuellen Surveillance-Stand und vor allem dem Scope-Statement. Das Scope-Statement ist der formal verbindliche Geltungsbereich; es ist die Stelle, an der „die KI-Doku-Anwendung in den Klinik-Mandanten“ stehen kann oder nicht stehen kann. Zweitens: das SoA, mit der Liste der anwendbaren Annex-A-Kontrollen und der dokumentierten Ausschlüsse. Anbieter:innen liefern das SoA in der Regel auf Anforderung unter Vertraulichkeits-Vereinbarung — eine Verweigerung ist ein operatives Signal. Drittens: die Lieferanten-Beziehungs-Dokumentation nach Annex A.5.19 bis A.5.23, mit der Subprozessoren-Liste, den Audit-Stränden zu Cloud-Provider und Modell-Trainings-Umgebung und der Verträge-Kette. Die Deutsche Krankenhausgesellschaft (DKG) empfiehlt diese strukturierte Lieferanten-Sicherheits-Prüfung in ihren branchenspezifischen Sicherheits-Empfehlungen; gematik hat den Vertragsrahmen für Cloud-Nutzung im Gesundheitswesen entlang derselben Kontrollen-Familien strukturiert.

Mit ISO/IEC 42001 ist 2023 ein eigener Management-System-Standard für Künstliche-Intelligenz-Systeme dazugekommen. Er behandelt Risiko-Klassen, die in einem klassischen ISO-27001-ISMS nicht angelegt sind: Modell-Provenienz und Trainings-Daten-Herkunft, Bias- und Fairness-Management über den Lebenszyklus, Monitoring der Modell-Drift im klinischen Betrieb, Aufgaben- und Verantwortungs-Strukturen für KI-bezogene Entscheidungen. Bei einer Klinik-KI-Anwendung berührt das die Anamnese-Strukturen, die Trainings-Daten-Provenienz, die Modell-Update-Disziplin und die Monitoring-Praxis im Routinebetrieb. Eine Anbieter-Kombination aus ISO 27001 und ISO 42001 schließt die Management-System-Schicht für klassische Informationssicherheit und für KI-spezifische Risiken — beides ist erklärt, beides ist auditiert. Eine Anbieter-Aussage zur ISO 27001 ohne ISO 42001 lässt die KI-spezifische Schicht außerhalb des Management-Systems. Das ist keine Disqualifikation; es ist eine Information über den Audit-Stand zum Beschaffungs-Zeitpunkt — und ein zweiter Punkt, der in der Geltungsbereichs-Prüfung benannt werden kann.

Die Geltungsbereichs-Prüfung ist nicht juristisch komplex. Sie ist organisatorisch aufwändig, weil sie drei Dokumente verlangt statt eines, weil sie die Lieferanten-Beziehungen liest, und weil sie unbequeme Fragen vor der Vertrags-Unterschrift stellt statt nach dem Go-Live. Eine Beschaffungs-Methodik, die diese Prüfung integriert, wirkt strukturell in einer geordneten Reihenfolge zurück: Die Anbieter-Antworten werden präziser, weil die Frage präziser wird; die Vertrags-Anhänge werden schlanker, weil die Lieferanten-Beziehungen schon vorher dokumentiert sind; die Audit-Vorbereitung in der Folge wird kürzer, weil dieselben Artefakte nicht zweimal erzeugt werden müssen. Die Disziplin sitzt vor dem Vertrag. Was vor dem Vertrag nicht geklärt wird, taucht im ersten Audit nach Go-Live auf — mit weniger Verhandlungsspielraum, in einem engeren Zeitfenster, mit einer veränderten Beweislast.

Ein Zertifikat sagt aus, was im erklärten Geltungsbereich gemessen wurde — und nichts darüber, was außerhalb liegt. Eine Klinik-Software-Beschaffung umfasst beides: die Aussage und das, was ihr Geltungsbereich nicht enthält. Nur eines steht auf dem Deckblatt.