Cloud-Compliance 2026: Das Zusammenspiel von Sicherheit (C5) und Souveränität (C3A)

In der Cloud-Welt von 2026 reicht „Sicherheit“ allein nicht mehr aus. Während der aktualisierte BSI C5:2026 den Goldstandard für die technische Absicherung definiert, bringen die neuen C3A-Kriterien (Criteria enabling Cloud Computing Autonomy) die strategische Komponente der digitalen Souveränität ins Spiel. Besonders für regulierte Branchen wie das Gesundheitswesen verschärft sich die Lage.

1. C5:2026 – Mehr als nur ein Update

Der C5:2026 ist nun offiziell in Kraft und bringt neben der Maschinenlesbarkeit vor allem technische Verschärfungen in den Bereichen Container-Management und Post-Quanten-Kryptografie. Ein zentraler Punkt für Anbieter: Die logische Struktur der Prüfung bleibt zwar erhalten, doch die Anforderungen an die Transparenz – insbesondere bezüglich der Rechtsräume von Mutterkonzernen – sind gestiegen.

2. Der Gesundheitssektor unter Zugzwang (§ 393 SGB V)

Ein aktuelles Thema ist die Testatpflicht nach § 393 SGB V. Hier zeigt sich eine kritische Hürde für SaaS-Anbieter:

• Keine Abkürzung durch Hyperscaler: Ein C5-Testat von Anbietern wie AWS oder Azure reicht für SaaS-Lösungen im Gesundheitswesen nicht aus.
• Eigene Testierungspflicht: Wer Gesundheitsdaten verarbeitet, muss in der Regel ein eigenes C5-Testat vorweisen, da der SaaS-Anbieter für Schichten wie Applikation und Datenhaltung selbst verantwortlich ist.
• Wettbewerbsvorteil: In einem Markt, in dem die Rechtslage zur „datenverarbeitenden Stelle“ noch nicht final geklärt ist, wird ein eigenes Testat zum entscheidenden Verkaufsargument für Kliniken und Krankenkassen.

3. C3A: Die neue Stufe der Souveränität

Ergänzend zum C5 adressiert der C3A-Katalog die Abhängigkeit von außereuropäischen Anbietern. Er fordert Autonomie in sechs Domänen – von der rechtlichen Kontrolle bis zur technologischen Unabhängigkeit (z. B. Zugriff auf Quellcode oder „Disconnect“-Fähigkeit).

Vor- und Nachteile der C3A-Kriterien

• Vorteile: Maximale Transparenz über Lieferketten und Schutz vor extraterritorialem Datenzugriff (z. B. US Cloud Act). Es ermöglicht eine risikobasierte Wahl des Souveränitätslevels.
• Nachteile/Kritik: Die Testierung ist wie beim C5 kostenintensiv und komplex. Kritiker warnen zudem, dass extrem strenge Souveränitätsvorgaben (wie lokale Personalvorgaben) die Auswahl an hochinnovativen globalen Diensten einschränken könnten. Zudem fehlt es dem C3A aktuell noch an einer direkten gesetzlichen Bindung, er fungiert primär als Handlungsrahmen.

4. Prüfprogramm für Auditoren

Ein offizieller, detaillierter Leitfaden für C3A-Audits wird seitens des BSI noch finalisiert. Da C3A jedoch auf dem C5-Prozess aufsetzt, nutzen Auditoren bereits jetzt die C5-Methodik als Basis.

Ein vorläufiges Prüfprogramm umfasst:

1. Rechtssouveränität: Prüfung der Gerichtsbarkeit und Konzernstruktur.
2. Datensouveränität: Nachweis über BYOK (Bring Your Own Key) und lokale Speicherung.
3. Operationelle Souveränität: Überprüfung, ob der Dienst auch bei gekappter Verbindung zum Ausland („Disconnect“) weiterläuft.
4. Technologische Souveränität: Einsicht in Software-Stücklisten (SBOM) und Quellcode-Hinterlegungen.

Fazit: Der Trend geht klar zur Dual-Zertifizierung. Während C5 das Fundament für das Vertrauen in die Technik legt, sichert C3A die politische und strategische Handlungsfähigkeit der Unternehmen ab.

Was sind die Voraussetzungen nach § 393 SGB V?

Gemäß § 393 SGB V, der durch das Digitalgesetz (DigiG) im März 2024 eingeführt wurde, dürfen Leistungserbringer (wie Krankenhäuser oder Arztpraxen) sowie Krankenkassen Sozial- und Gesundheitsdaten in der Cloud verarbeiten. Dies ist jedoch an drei kumulative Voraussetzungen geknüpft, die gleichzeitig erfüllt sein müssen:

• Verarbeitungsort: Die Datenverarbeitung muss im Inland, in einem Mitgliedstaat der EU oder des EWR oder in einem Land mit einem Angemessenheitsbeschluss der EU-Kommission stattfinden (§ 393 Abs. 3 Nr. 1 SGB V).
• Aktuelles C5-Testat: Es muss ein aktuelles C5-Testat der „datenverarbeitenden Stelle“ vorliegen (§ 393 Abs. 3 Nr. 2 SGB V). Als datenverarbeitende Stelle gilt der Cloud-Anbieter, der die Daten technisch verarbeitet.
• Umsetzung der Kundenkriterien: Die im Prüfbericht des C5-Testats enthaltenen Kriterien für Kunden müssen vom Nutzer (dem Leistungserbringer oder der Krankenkasse) tatsächlich umgesetzt sein (§ 393 Abs. 3 Nr. 3 SGB V).

Wichtige Präzisierungen aus den Quellen:

• Eigenes Testat für SaaS-Anbieter: Nach Auslegung des Bundesgesundheitsministeriums (BMG) benötigen SaaS-Anbieter in der Regel ein eigenes C5-Testat für ihre spezifische Software und die zugrunde liegende Technik. Das Testat eines genutzten Hyperscalers (z. B. AWS oder Azure) reicht allein nicht aus, da dieses nur die physische Infrastruktur abdeckt, nicht aber die Applikations- und Datenhaltungsebene des SaaS-Produkts.
• Nachweispflichten in der Praxis: Neben dem C5-Testat muss zwischen dem Leistungserbringer und dem Cloud-Anbieter ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO bestehen, der die Testierungspflicht explizit adressiert. Zudem müssen eingesetzte Subdienstleister lückenlos dokumentiert werden.
• Rolle des Prüfberichts: Leistungserbringer sind verpflichtet, sich aktiv mit dem Prüfbericht des Anbieters auseinanderzusetzen, um die für sie relevanten Kundenkriterien zu identifizieren und zu erfüllen.

Obwohl der C5:2026 eine technische Überarbeitung des Kriterienkatalogs darstellt, ändern sich die grundsätzlichen Anforderungen und die Scope-Logik des § 393 SGB V dadurch nicht. In der Beratungspraxis wird empfohlen, dass Anbieter von Gesundheits-Cloud-Diensten im Zweifelsfall immer ein eigenes Testat anstreben sollten, um die gesetzlichen Anforderungen rechtssicher zu erfüllen.

Welche Sanktionen drohen bei Verstößen gegen § 393 SGB V?

Meine Recherchen lieferten keine explizite Auflistung spezifischer Bußgelder oder Strafmaße, die direkt in § 393 SGB V definiert sind. Dennoch lassen sich aus den Texten und dem rechtlichen Kontext mehrere schwerwiegende Konsequenzen und Risiken bei Verstößen ableiten:

• Unzulässigkeit der Datenverarbeitung: Da § 393 SGB V die Cloud-Verarbeitung von Sozial- und Gesundheitsdaten nur unter strengen, kumulativen Voraussetzungen erlaubt, stellt eine Verarbeitung ohne gültiges C5-Testat einen Verstoß gegen die gesetzliche Erlaubnisnorm dar.
• Datenschutzrechtliche Konsequenzen (DSGVO): Die Quellen weisen darauf hin, dass zwischen dem Cloud-Nutzer und dem Anbieter ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO bestehen muss, der die C5-Testierungspflicht explizit adressiert. Ein Verstoß gegen diese vertraglichen oder gesetzlichen Pflichten zur Datensicherheit kann somit aufsichtsrechtliche Maßnahmen nach der DSGVO nach sich ziehen.
• Rechtliche Unsicherheit für Verantwortliche: Da Leistungserbringer (Krankenhäuser, Ärzte) und Krankenkassen gesetzlich verpflichtet sind, die Umsetzung der Kundenkriterien aus dem C5-Prüfbericht nachzuweisen, führt ein fehlendes oder unzureichendes Testat dazu, dass diese Stellen ihren gesetzlichen Sorgfalts- und Nachweispflichten nicht nachkommen können.
• Marktausschluss für Anbieter: Für SaaS-Anbieter im Gesundheitswesen wirkt ein fehlendes Testat faktisch wie eine Marktschranke. Da Kunden gesetzlich zur Nutzung testierter Dienste verpflichtet sind, führt ein Verstoß bzw. das Nichtvorhandensein des Testats zu einem massiven Wettbewerbsnachteil oder dem Ausschluss von Ausschreibungen.
• Haftungsrisiken: Die Quelle empfiehlt eine risikominimierende Auslegung, da die Rechtslage zur „datenverarbeitenden Stelle“ noch nicht abschließend gerichtlich geklärt ist. Werden sensible Gesundheitsdaten ohne die erforderlichen Sicherheitsnachweise verarbeitet, entstehen erhebliche Haftungsrisiken gegenüber den Betroffenen und Aufsichtsbehörden.

Hinweis: In der Praxis können Verstöße gegen die Sicherheitsvorschriften des SGB V je nach Schweregrad als Ordnungswidrigkeiten geahndet werden. Zudem können die zuständigen Aufsichtsbehörden (wie der BfDI für Krankenkassen oder die Landesdatenschutzbeauftragten für Krankenhäuser) die Untersagung der Datenverarbeitung anordnen, was den Betrieb der entsprechenden IT-Systeme zum Erliegen bringen könnte. Dies sollten Sie bei Bedarf unabhängig verifizieren.