Die C5-Testate sind für Leistungserbringer und ggf. für Medizinproduktehersteller relevant. Denn das Anfang 2024 in Kraft getretene Digital-Gesetz (DigiG) definiert die Anforderungen an Cloud-Dienste im Gesundheitswesen neu.
Dieser Artikel erklärt die wichtigsten Aspekte der C5-Zertifizierung bzw. C5-Testate für Medizinproduktehersteller und Leistungserbringer wie etwa Krankenhäuser.
1. Grundlagen der C5-Zertifizierung / C5-Testate
1.1 Zielsetzung
Der Kriterienkatalog C5 (Cloud Computing Compliance Criteria Catalogue) ist ein vom Bundesamt für Sicherheit in der Informationstechnik (BSI) entwickelter Standard. Anhand dieser Kriterien können sowohl Anbieter als auch Kunden die IT-Sicherheit der Cloud-Dienste überprüfen.
Der C5-Standard regelt auch, wie Prüfungen durchgeführt und die Ergebnisse berichtet werden sollen.
Wirtschaftsprüfer dürfen bei erfolgreicher Prüfung ein C5-Testat ausstellen.
1.2 Aufbau des Kriterienkatalogs
Der Kriterienkatalog umfasst 17 Themengebiete mit insgesamt 125 Prüfkriterien. Diese sind pro Themengebiet unterteilt in Basiskriterien für grundlegende Sicherheit und Zusatzkriterien für erhöhten Schutzbedarf.
Das Themengebiet „Physische Sicherheit (PS)“ fordert als Basiskriterien, dass Gefährdungen „adressiert“ werden, wie „Unberechtigter Zutritt“, „Unzureichende Klimatisierung“, „Wasser“ und „Ausfall der Stromversorgung“.
Als Zusatzkriterien werden beispielsweise genannt „Zeitvorgaben für den autarken Betrieb beim Eintritt außergewöhnlicher Ereignisse (z. B. länger anhaltender Stromausfall, Hitzeperioden, Niedrigwasser bei Kälteversorgung mit Flusswasser) sowie maximal tolerierbare Ausfallzeiten von Versorgungseinrichtungen.“
1.3 Verhältnis zu anderen Standards
Das BSI hat den C5-Kriterienkatalog aus den Anforderungen der ISO 27001 abgeleitet. Die Behörde hat eine Kreuzreferenztabelle zwischen C5 und ISO 27001:2022 publiziert.
Eine Zertifizierung nach ISO 27001 ist dauerhaft weder notwendig noch hinreichend, um die Forderung nach einem C5-Testat zu erfüllen. Mehr dazu im Fazit.
Allerdings erlaubt die C5-Gleichwertigkeitsverordnung temporär alternative Nachweise:
- ISO/IEC 27001
- ISO 27001 mit IT-Grundschutz
- Cloud Controls Matrix 4.0
Zusätzlich erforderlich sind:
- Detaillierter Maßnahmenplan
- Lückendokumentation
- Umsetzungsplan (max. 12 Monate)
- C5-Typ1-Testat binnen 18 Monaten
- C5-Typ2-Testat binnen 24 Monaten
2. Notwendigkeit der C5-Testate
das positive Prüfergebnis über einen sicheren Cloud-Computing-Dienst anhand des Kriterienkatalogs C5 (Cloud Computing Compliance Criteria Catalogue) des Bundesamtes für Sicherheit in der Informationstechnik in der jeweils gültigen Fassung;
2.1 Gesetzliche Anforderungen
Die Relevanz für Leistungserbringer/Betreiber und ggf. für Hersteller von Medizinprodukten ergibt sich aus § 393 SGB V. Dieser Paragraf wurde aufgrund des Digital-Gesetzes (DigiG) eingefügt. Er schreibt die C5-Zertifizierung bzw. C5-Testate für Cloud-Dienste im Gesundheitswesen vor.
(1) Leistungserbringer im Sinne des vierten Kapitels und Kranken- und Pflegekassen sowie ihre jeweiligen Auftragsdatenverarbeiter dürfen Sozialdaten und Gesundheitsdaten auch im Wege des Cloud-Computing-Dienstes verarbeiten, sofern die Voraussetzungen der Absätze 2 bis 4 erfüllt sind.
(3) Eine Verarbeitung nach Absatz 1 ist nur zulässig, wenn zusätzlich zu den Anforderungen des Absatzes 2
1. dem Stand der Technik angemessene technische und organisatorische Maßnahmen zur Gewährleistung der Informationssicherheit ergriffen worden sind,
2. ein aktuelles C5-Testat der datenverarbeitenden Stelle im Hinblick auf die C5-Basiskriterien für die im Rahmen des Cloud-Computing-Dienstes eingesetzten Cloud-Systeme und die eingesetzte Technik vorliegt und
3. die im Prüfbericht des Testats enthaltenen, korrespondierenden Kriterien für Kunden umgesetzt sind.
Zudem verlangt § 393 SGB V, dass die Datenverarbeitung in der EU oder einem Staat erfolgt, für den ein „Angemessenheitsbeschluss“ gemäß Artikel 45 der Datenschutzgrundverordnung vorliegt. Diese Beschränkung findet sich nicht im C5-Kriterienkatalog.
2.2 Anforderungen an die Betreiber
2.2.1 Übersicht über die Anforderungen
Laut § 393 SGB V Absatz (4) benötigen die Betreiber ein aktuelles C5-Testat, wenn sie Gesundheitsdaten in der Cloud verarbeiten oder verarbeiten lassen. Das wäre etwa der Fall, wenn sie
- medizinische Informationssysteme in der Cloud betreiben,
- medizinische Daten in der Cloud abspeichern oder
- eine Software as a Service (SaaS) für Gesundheitsdaten nutzen.
Bis zum 30. Juni 2025 genügt ein C5-Typ1-Testat, danach bedarf es eines C5-Typ2-Testats. Alternative Testate oder Zertifikate mit vergleichbarem oder höherem Sicherheitsniveau sind noch zulässig.
C5-Typ1-Testate beziehen sich auf einen Zeitpunkt der Prüfung und bedingen Implementierungsnachweise. C5-Typ2-Testate beziehen sich auf einen zu prüfenden Zeitraum und bedingen zudem Wirksamkeitsnachweise.
Die Betreiber müssen daher diese Zertifikate von ihren Anbietern einfordern. § 393 SGB V besteht aber nicht darauf, dass auch die Zusatzkriterien des C5-Kriterienkatalogs erfüllt sind.
- Bei Nutzung von Unterauftragnehmern müssen sowohl der Hauptanbieter als auch der Cloud-Dienstleister ein C5-Testat vorweisen, oder der Hauptanbieter integriert die Prüfung des Unterauftragnehmers in seine C5-Überprüfung. Mehr dazu weiter unten im Abschnitt zu „Carve-in und Carve-out“.
- Zusätzlich müssen die Betreiber die Anforderungen an die technischen und organisatorischen Maßnahmen gemäß § 393 bzw. § 391 SGB V erfüllen.
2.2.2 Unklarheit über die Anforderungen
Derzeit sind sich die Juristen nicht einig, ob ein Krankenhaus selbst ein C5-Testat benötigt oder ob es ausreicht, das C5-Testat des Cloud-Anbieters vorzulegen.
Die Antwort auf diese Frage hängt auch davon ab, was als die datenverarbeitende Stelle definiert wird.
Argumente, dass das Krankenhaus selbst ein Testat benötigt
Es gibt Argumente, die dafürsprechen, dass (auch) das Krankenhaus als datenverarbeitende Stelle gilt, denn der Absatz (1) des § 393 SGB V schreibt, dass die Leistungserbringer die Daten auch im Wege des Cloud-Computings nur verarbeiten dürften, falls gewisse Anforderungen erfüllt sind. Zu diesen zählt das Testat.
Auch lässt sich argumentieren, dass der Gesetzgeber generell die Sicherheit von Gesundheitsdaten schützen will. Viele Krankenhäuser haben besonderen Nachholbedarf, weshalb eine C5-Zertifizierung des Krankenhauses selbst sinnvoll und mit dem Gesetz beabsichtigt sei.
Argumente, dass das Krankenhaus selbst KEIN Testat benötigt
Andere argumentieren, dass der Gesetzgeber nur auf die Verarbeitung der Daten beim Cloud-Computing-Dienstleister abzielt. Das würde im Absatz (2) des § 393 SGB V deutlich, der über die Orte der Datenverarbeitung spricht. Dieser Ort sei nur bei den Dienstleistern relevant, weil das Gesetz nur deutsche Krankenhäuser betreffe.
Auch die Begründung des Gesetzgebers selbst würde zeigen, dass das Zertifikat der Dienstleister genügt (Quelle):
„Im Rahmen des § 393 SGB V können für Unternehmen, die cloudbasierte informationstechnische Anwendungen einsetzen wollen, initial geringfügige Mehrkosten im unteren fünfstelligen Bereich für die Durchführung einer C5-Testierung entstehen, sofern der konkrete Anbieter des Clouddienstes nicht bereits über ein C5-Testat verfügt“
2.3 Anforderungen an Hersteller
2.3.1 Fallunterscheidung
Die Anforderungen an Hersteller hängen davon ab, welcher Fall vorliegt:
- Im ersten Fall bietet ein Hersteller den Patienten eine cloudbasierte Software „as a Service“ an. Dann werden die Hersteller ggf. selbst zu Betreibern.
- Im zweiten Fall bietet ein Hersteller den Leistungserbringern eine cloudbasierte Software „as a Service“ an (s. Abb. 2).
- Im dritten Fall verkauft bzw. vermietet ein Hersteller den Leistungserbringern eine Software, welche die Leistungserbringer selbst in der Cloud betreiben (s. Abb. 2).
Ausschließlich aus dem Ort, an dem die Software entwickelt, betrieben und genutzt wird, kann man nicht schlussfolgern, welcher der drei Fälle vorliegt. Daher sollten die Hersteller mit ihren Kunden die jeweiligen Rollen vertraglich klar regeln.
2.3.2 Fall 1: Hersteller ist auch Leistungserbringer
Ein Hersteller von Medizinprodukten oder IVD, der Cloud-Computing-Dienste für Patienten nutzt, ist direkt betroffen: Er zählt als Leistungserbringer, muss den Anforderungen des § 393 SGB V genügen und daher ein C5-Testat oder ggf. mehrere C5-Testate vorweisen.
digitaler Dienst, der auf Abruf die Verwaltung und den umfassenden Fernzugang zu einem skalierbaren und elastischen Pool gemeinsam nutzbarer Rechenressourcen ermöglicht, auch wenn diese Ressourcen auf mehrere Standorte verteilt sind;
Als Leistungserbringer zählen im deutschen Gesundheitssystem all diejenigen Personengruppen, die Leistungen für die Versicherten der Krankenkassen erbringen.
Ein DiGA-Hersteller nutzt für seine Mobile App einen Hyperscaler. Der Betrieb eines eigenen Servers würde nicht als Cloud-Computing-Dienst zählen.
Falls ein Hersteller für sein Angebot einen Cloud-Dienstleister unterbeauftragt, muss er entweder dessen Testat vorlegen oder seinen Unterauftragnehmer (Cloud-Dienstleister) in die eigene Prüfung und Testierung einbeziehen.
2.3.3 Fall 2: Hersteller bietet Leistungserbringern seine Produkte als SaaS an
Wenn ein Hersteller seine Software as a Service anbietet, betrifft ihn der § 393 SGB V zumindest indirekt. Denn viele seiner Kunden, die Leistungserbringer, werden ein C5-Testat von ihm verlangen. Damit werden für den Hersteller beispielsweise zur Pflicht:
- Suche nach Schwachstellen durch statische und dynamische Code-Analysen, Code-Reviews und Penetrations-Tests durch qualifizierte externe Dritte (Letzteres ist ein Zusatzkriterium.)
- Aktive Suche nach Schwachstellen auch in verwendeten Bibliotheken und Information der Kunden über Schwachstellen
- Vorgaben für die Kunden zum gesetzeskonformen Betrieb wie der sicheren Konfiguration
- Implementierung von Audit-Logs / Protokollen
- Implementierung von geeigneten Authentifizierungs- und Autorisierungsmechanismen
Falls der Hersteller für sein SaaS-Angebot einen Cloud-Dienst nutzt, so zählt der Cloud-Dienste-Anbieter als Unterauftragnehmer des Herstellers. Dann ist der Hersteller direkt betroffen und muss ein C5-Testat vorlegen, ggf. auch das seines Cloud-Dienste-Anbieters. Denn § 393 SGB V urteilt nur, ob Gesundheitsdaten mit einem Cloud-Computing-Dienst verarbeitet werden – unabhängig von den Vertragsverhältnissen.
Der C5-Kriterienkatalog unterscheidet nicht zwischen den Software-Entwicklungsaktivitäten der Cloud-Anbieter und den Software-Entwicklungsaktivitäten der Hersteller, deren Software in der Cloud betrieben wird.
2.3.4 Fall 3: Hersteller ist nicht Betreiber / Leistungserbringer
Ein Hersteller kann auch indirekt betroffen sein, wenn er Produkte verkauft, welche seine Kunden, die Leistungserbringer, in der Cloud eines Dritten betreiben (lassen).
Dann müssen sie ihre Produkte so entwickeln und gestalten, dass ihre Kunden die notwendigen Nachweise erbringen können. Daher ähneln die Anforderungen denen von Fall 2, auch wenn der Hersteller diese Anforderungen nicht selbst erfüllen muss.
2.3.5 Weitere Anforderungen
MDR und IVDR fordern die IT-Sicherheit nach Stand der Technik. Damit wird der C5-Kriterienkatalog BSI quasi verbindlich.
Zudem sollten Hersteller die zukünftig harmonisierte Norm IEC 81001-5-1 beachten und erfüllen.
Für Hersteller, die ihre Produkte in den USA vermarkten wollen, gelten die Anforderungen der FDA an die IT Security.
3. Praktische Umsetzung
3.1 Carve-in versus Carve-out
Falls ein datenverarbeitendes Unternehmen, das ein C5-Testat benötigt, ein weiteres Unternehmen mit der Datenverarbeitung unterbeauftragt, hat es zwei Ansätze:
- Carve-in-Methode: Das Unternehmen überprüft alle Sicherheitsmaßnahmen bei sich und dem Unterauftragnehmer. Das bedeutet einen höheren Aufwand, aber auch vollständige Kontrolle.
- Carve-out-Methode: Das Unternehmen verweist auf die C5-Testate der Unterauftragnehmer. Die Folgen sind ein geringerer Aufwand, aber auch eine höhere Abhängigkeit.
Der C5-Kriterienkatalog beschreibt die beiden Varianten genauer.
3.2 Herausforderungen und Kosten
Zu den typischen Hauptherausforderungen zählen:
- Komplexe Koordination bei mehreren Cloud-Dienstleistern und Integration internationaler Dienstleister. Letzteres ist gerade in den USA mit Unsicherheiten behaftet.
- Anforderungen, die über die ISO 27001 hinausgehen, und Vielfalt der Zertifikate und Testate (z. B. BSI Grundschutz, ISO 27001, SOC2, Trusted Cloud)
- Hohe Aufwände für Dokumentation und kontinuierliche Überwachung
- Verfügbarkeit von Wirtschaftsprüfern, welche die Zertifikate/Testate ausstellen können
- Rechtliche Unklarheiten und Behörden bzw. Betreiber, die im Zweifel zu viele als zu wenige C5-Testate einfordern
Meist gilt es bei den Betreibern mehrere Abteilungen zu koordinieren: Einkauf, IT (z. B. CISO) und Rechtsabteilung.
Auch die Kosten stellen Herausforderungen dar. Diese entstehen durch:
- Externe Beratung
- Prüfung, Zertifizierung, Testierung
- Interne Ressourcen
- Fortlaufende Überwachung
4. Fazit und Zusammenfassung
4.1 Auswirkungen auf die Leistungserbringer
Die Leistungserbringer müssen die Anforderungen des § 393 SGB V erfüllen. Daher müssen sie ein C5-Testat ihres Cloud-Dienstleisters vorlegen. Auch Hersteller von Medizinprodukten können als Cloud-Dienstleister zählen.
Zusätzlich müssen die Leistungserbringer die territorialen Beschränkungen bei der Auswahl ihres Cloud-Dienstleisters beachten.
Ob die Leistungserbringer (Krankenhäuser) selbst ein eigenes Testat benötigen, ist derzeit noch strittig (s. Abschnitt 2.2.2). Daher sollten sie die Diskussion darüber aufmerksam verfolgen.
Im kostenlosen Instituts-Journal informiert das Johner Institut wöchentlich über regulatorische Änderungen, die neben Herstellern auch die Betreiber betreffen.
4.2 Auswirkungen auf die Hersteller von Medizinprodukten und IVD
Hersteller müssen für absolute Klarheit darüber sorgen, in welcher Rolle sie den Betreibern ihre Produkte und Dienstleistungen anbieten. In jedem Fall müssen sie auf Forderungen ihrer Kunden nach einem C5-Testat vorbereitet sein. Unabhängig davon, ob diese Forderungen berechtigt sind.
Für Hersteller mit Cloud-Diensten ist die C5-Zertifizierung unverzichtbar geworden.
4.3 Auswirkungen auf das Gesundheitssystem
Die Sicherheit von Gesundheitsdaten ist wichtig. Die Versorgung von Patientinnen und Patienten mit Medizinprodukten und IVD ist es auch.
Die zusätzlichen Anforderungen drohen, insbesondere kleinere und mittlere Hersteller und Betreiber zu überfordern und Ressourcen zu binden, welche für die Herstellung von Produkten und für die Patientenversorgung wichtig wären.
Der enorme finanzielle und organisatorische Aufwand zur Erlangung eines C5-Testats, insbesondere für kleinere Unternehmen und Startups, steht in keinem Verhältnis zum Nutzen.
Quelle: Bitkom
Wäre eine Zertifizierung nach ISO 27001 nicht ausreichend gewesen?
„Eine Sichtung des C5-Kriterienkatalogs in Verbindung mit den vom BSI erstellten Kreuzreferenztabellen zeigt, dass das BSI nur an wenigen Stellen ein vergleichbares oder höheres Sicherheitsniveau der referenzierten internationalen Standards feststellt. Auch finden sich viele Kriterien aus dem C5 nicht in den referenzierten internationalen Standards wieder.
Folglich bedeutet eine Umsetzung der C5-Kriterien für einen Cloud-Anbieter in der Tat einen größeren Mehraufwand als die reine Umsetzung z. B. eines ISMS nach ISO/IEC 27001.“
4.4 Auswirkungen auf das politische System
Die Tatsache, dass den Wirtschaftsprüfern eine prominente Rolle zugebilligt wird, kann zum Verdacht führen, dass deren Interessenvertreter an der Gesetzgebung mitgewirkt haben. Bereits der Verdacht schadet dem Vertrauen in das politische System und die Sinnhaftigkeit der gesetzlichen Anforderungen.
Eine scharfe Kritik am C5-Kriterienkatalog findet sich bei Golem.
Die zielführenden Vorschläge des Bitkom zur C5-Äquivalenzverordnung hat der Gesetzgeber nicht aufgegriffen.
Das Johner Institut unterstützt Hersteller bei der gesetzeskonformen Entwicklung und Überwachung ihrer Medizinprodukte und IVD:
- Prüfung, dass die Produktanforderungen alle regulatorischen Anforderungen an die IT-Sicherheit umfassen
- IT-Sicherheits-Risikoanalysen und Threat-Modeling
- Penetration-Testing
- Prüfen, Verbessern und Erstellen der für die IT-Sicherheit notwendigen Verfahrens- und Arbeitsanweisungen und Aufbau von IT-Sicherheitsmanagementsystemen
