C5-Pflicht, neues C3A-Framework: Was SaaS-Anbieter im Gesundheitswesen jetzt beachten müssen

• Leistungserbringer nach SGB V (Krankenhäuser, Praxen, MVZ, Apotheken, Rehakliniken)
• Gesetzliche Kranken- und Pflegekassen
• SaaS-Anbieter, die Gesundheits- oder Sozialdaten im Auftrag dieser Stellen verarbeiten
• Unterauftragnehmer, die in die Datenverarbeitung eingebunden sind

Diese erste Domäne stellt die Grundsatzfrage: Unter wessen Kontrolle steht der Anbieter? Sie prüft Jurisdiktion, Eigentumsstruktur und die effektive Entscheidungsgewalt über den Cloud-Dienst.

• Jurisdiktion (C1): Der Anbieter und alle relevanten Tochtergesellschaften müssen dem Recht eines EU-Mitgliedstaats unterliegen. Keine Möglichkeit zur Datenherausgabe an Drittstaaten außerhalb EU-rechtlicher Rahmen.
• Hauptsitz (C1): Der Hauptsitz des Anbieters muss sich in der EU befinden.
• Effektive Kontrolle (C1/C2): Die Mehrheit der Stimmrechte und Eigentumsanteile muss bei EU-Unternehmen oder EU-Bürgern liegen. Das Zusatzkriterium C2 verschärft dies auf deutsche Eigentumsstrukturen.
• Kein Cloud Act, kein FISA: Kein Unternehmensteil darf extraterritorialen US-Gesetzen wie dem CLOUD Act oder FISA Section 702 unterliegen.

Praxishinweis: US-Hyperscaler wie AWS, Azure und Google Cloud erfüllen SOV-1 strukturell nicht – sie unterliegen US-Recht und haben US-amerikanische Muttergesellschaften. SaaS-Anbieter, die auf diesen Infrastrukturen aufbauen, sollten dies transparent kommunizieren und das Risiko im Rahmen ihrer Datenschutzfolgenabschätzung bewerten.

SOV-2 konkretisiert, wie der Anbieter mit extraterritorialen Rechtsnormen umgeht und welche Audit-Rechte Kunden haben. Es geht um die Frage, ob ein Anbieter tatsächlich in der Lage ist, Kundendaten vor dem Zugriff fremder Behörden zu schützen.

• Jährliche Risikoanalyse (C): Der Anbieter muss jedes Jahr systematisch prüfen, welche außereuropäischen Gesetze mit grenzüberschreitender Wirkung (z.B. CLOUD Act, FISA 702) potenziell Auswirkungen auf seine Dienste haben könnten – und diesen Bericht Kunden auf Anfrage bereitstellen. 
• Keine unilaterale Offenlegung (C): Erhält der Anbieter eine Behördenanfrage, die EU-Datenschutzrecht entgegenstehen würde, muss er alle verfügbaren Rechtsmittel ausschöpfen und den Kunden informieren, soweit rechtlich zulässig. 
• Audit-Rechte (C): Kunden müssen das Recht haben, die Einhaltung der Souveränitätskriterien durch eigene Prüfungen oder beauftragte Dritte zu verifizieren. 
• Notfallpläne (AC): Erweiterte Kriterien fordern dokumentierte Verfahren, wie der Dienst im Verteidigungsfall oder bei staatlicher Einflussnahme weiter betrieben werden kann.

Praxishinweis: Für Krankenhäuser und GKV ist SOV-2 besonders relevant: Die jährliche Risikoanalyse des Anbieters gibt ihnen ein objektives Instrument, die Rechtslage zu beurteilen und gegenüber Datenschutzaufsichtsbehörden zu dokumentieren.

SOV-3 regelt, wo Daten gespeichert werden und wer die Kontrolle über Verschlüsslung und Zugang hat. Diese Domäne ist für den Gesundheitssektor besonders sensibel, da es um Patienten- und Sozialdaten mit sehr hohem Schutzbedarf geht.

• Datenspeicherort (C1): Alle Daten müssen im EU-Raum gespeichert werden. Der Anbieter muss den Speicherort transparent ausweisen. Für C2 (Deutschland-Niveau) gilt: ausschließlich Speicherung im Bundesgebiet.
• External Key Management (C): Kunden müssen die Möglichkeit haben, Verschlüsselungsschlüssel außerhalb der Anbieterumgebung zu verwalten – in einem von ihnen kontrollierten Key Management System (KMS). Dies schließt aus, dass der Anbieter ohne Kundenwissen auf Klardaten zugreifen kann. 
• Externer Identity Provider (C): Kunden sollen einen eigenen, EU-basierten Identity Provider einbinden können, anstatt den des Cloud-Anbieters nutzen zu müssen. 
• Vollständige Access Logs (C): Kunden müssen Zugang zu lückenlosen Protokollen erhalten, die zeigen, wer wann auf ihre Daten zugegriffen hat – auch Zugriffe durch den Anbieter selbst.
• Client-Side Encryption (AC): Das Zusatzkriterium verlangt die Möglichkeit zur vollständigen clientseitigen Verschlüsslung, bei der Daten den Kunden-Endpoint nur noch verschlüsselt verlassen. 

Praxishinweis: External Key Management ist für SaaS-Anbieter im Gesundheitswesen ein zentrales Differenzierungsmerkmal: Wer es anbietet, gibt Krankenhäusern und Kassen die Kontrolle, die das Datenschutzrecht faktisch erfordert – und erleichtert ihnen die Erfüllung ihrer eigenen Dokumentationspflichten nach § 393 SGB V. 

SOV-4 ist die operativste und für viele Anbieter anspruchsvollste Domäne. Sie regelt, wer den Dienst betreibt, von wo aus zugegriffen wird – und ob der Dienst auch dann weiterläuft, wenn alle Verbindungen in Nicht-EU-Länder gekappt werden.

• Personal (SOV-4-01-C1): Alle Personen mit logischem oder physischem Zugang zu betriebsrelevanten Systemen müssen EU-Bürger mit EU-Wohnsitz sein. Die verschärfte Variante C2 verlangt Wohnsitz in Deutschland – relevant für Hochsicherheitsumgebungen. 
• Administrative Zugriffe nur aus der EU (C): Fernzugriffe auf Administrationssysteme dürfen technisch ausschließlich aus dem EU-Raum erfolgen. VPN-Lösungen, die diesen Zugriff auf EU-Standorte beschränken, sind zu implementieren. 
• Disconnect-Fähigkeit (SOV-4-09-C): Der Dienst muss vollständig und ohne Funktionsverlust betrieben werden können, wenn sämtliche Netzwerkverbindungen außerhalb der EU getrennt werden. Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit dürfen dabei nicht beeinträchtigt werden. 
• Jährlicher Disconnect-Test (C): Die Abkoppelungsfähigkeit ist nicht nur zu behaupten, sondern jährlich durch einen dokumentierten Test nachzuweisen. 
• Testergebnisse (AC): Das Zusatzkriterium verlangt, dass Testergebnisse auf Anfrage der zuständigen IT-Sicherheitsbehörde bereitgestellt werden. 

Praxishinweis: Das Disconnect-Kriterium SOV-4-09 ist für US-Hyperscaler strukturell unerfüllbar: Ihre Architekturen benötigen dauerhaft US-seitige Verbindungen für Lizenzen, Updates und Betrieb. SaaS-Anbieter, die auf diesen Infrastrukturen aufbauen, erben dieses Problem.

SOV-5 richtet den Blick auf die Transparenz der technischen Lieferkette: Welche Software- und Hardwarekomponenten stecken im Cloud-Dienst, aus welchen Ländern stammen sie, und wie wird mit kritischen Abhängigkeiten umgegangen?

• Software Bill of Materials (SBOM, C): Der Anbieter muss eine vollständige Dokumentation aller Software-Komponenten vorhalten und Kunden auf Anfrage zugänglich machen. Idealerweise erfolgt dies als standardisiertes SBOM-Dokument. 
• Externe Dienstabhängigkeiten (C): Alle eingesetzten Drittdienste (z.B. CDNs, externe APIs, Authentifizierungsdienste) müssen dokumentiert und hinsichtlich ihrer Herkunft, Jurisdiktion und Austauschbarkeit bewertet sein. 
• Risikominimierung kritischer Abhängigkeiten (C): Für identifizierte kritische Abhängigkeiten von außereuropäischen Komponenten müssen Maßnahmen und Notfallpläne vorgehalten werden. 
• Bevorzugung europäischer Komponenten (AC): Das Zusatzkriterium fordert eine aktive Strategie zur schrittweisen Ersetzung kritischer Nicht-EU-Komponenten durch europäische Alternativen. 

Praxishinweis: Für SaaS-Anbieter bedeutet SOV-5 erheblichen Dokumentationsaufwand – bietet aber gleichzeitig die Chance, Vertrauen bei Einkäufern im Gesundheitswesen zu schaffen: Wer seine Lieferkette transparent macht, hat gegenüber Wettbewerbern einen klaren Vorteil bei Ausschreibungen. 

SOV-6 ist die weitestgehende Domäne: Sie stellt sicher, dass ein Cloud-Dienst auch dann weiter betrieben werden kann, wenn der ursprüngliche Anbieter wegfällt – durch Insolvenz, Rückzug aus dem Markt oder staatliche Maßnahmen.

• Quellcode-Verwahrung (C): Der vollständige, ausführbare Quellcode aller Dienste muss aktuell, versioniert und mit vollständiger Dokumentation im EU-Raum hinterlegt sein – so dass ein Betrieb ohne den Originalanbieter möglich ist. 
• Portabilität und Migrationsdokumentation (C): Kunden müssen ihre Daten und Konfigurationen vollständig und in standardisierten Formaten exportieren können. Migrationsanleitungen müssen bereitgestellt werden.
• API-Interoperabilität (C): Offene, dokumentierte APIs müssen die Integration mit anderen Systemen und den Wechsel zu alternativen Anbietern ermöglichen. 
• Open Source als Zusatzkriterium (AC): Die höchste Souveränitätsstufe verlangt, dass zumindest die Kerndienste als Open-Source-Software bereitgestellt werden, damit Betreiber den Code prüfen, anpassen und eigenständig betreiben können. 

Praxishinweis: SOV-6 ist für viele proprietäre SaaS-Anbieter die herausforderndste Domäne – vor allem das Open-Source-Kriterium. Gleichzeitig adressiert sie ein echtes Risiko im Gesundheitswesen: Vendor Lock-in und der plötzliche Wegfall eines Anbieters können kritische Versorgungsinfrastruktur gefährden.