Cloud oder On-Premise im Krankenhaus: Was IT-Sicherheit und Haftungsrecht tatsächlich verlangen

Der deutsche Gesetzgeber hat den Cloud-Einsatz für Gesundheitsdaten seit 2024 in § 393 SGB V ausdrücklich erlaubt — unter klar definierten, prüfbaren Bedingungen: Verarbeitung im Inland oder in der EU, Niederlassung der verarbeitenden Stelle im Inland, technische und organisatorische Maßnahmen nach dem Stand der Technik und ein aktuelles BSI-C5-Testat. Ein pauschales „Cloud geht bei uns nicht“ ist damit keine rechtliche Position mehr, sondern eine Betriebsentscheidung, die denselben Nachweispflichten unterliegt wie jede andere. Entscheidend ist nicht der Ort der Verarbeitung, sondern die Frage, wer einen internetexponierten Dienst betreibt — und wer die Angemessenheit der Schutzmaßnahmen im Streitfall beweisen kann.

Warum „Cloud oder On-Premise“ die falsche erste Frage ist

Die Alternative „Cloud gegen On-Premise“ beschreibt nur den Standort der Server. Sie sagt nichts über das Sicherheitsniveau aus. Sobald Patient:innen einen Anamnesebogen von zu Hause ausfüllen sollen, existiert in jedem Betriebsmodell ein aus dem Internet erreichbarer Dienst. Die einzig relevante Frage lautet: Wer betreibt diesen Dienst, mit welchen Kontrollen — und wie wird das belegt?

In Gesprächen mit Klinik-IT- und Rechtsabteilungen begegnet uns regelmäßig ein Muster: Cloud-Hosting wird als Ausschlusskriterium behandelt, während gleichzeitig Eigenbau-Lösungen vorgeschlagen werden, die dieselbe Internetexponierung erzeugen — nur ohne die Kontrollen, die bei einem testierten Cloud-Dienst geprüft und dokumentiert sind. Ein konkreter Vorschlag, den wir in dieser Form mehrfach gehört haben: einen Rechner in der Klinik aufstellen, ihn in die DMZ hängen und Patient:innen von zu Hause darauf zugreifen lassen (Beobachtung aus medudoc-Klinikgesprächen, Stand August 2026).

Der Vorschlag ist nachvollziehbar motiviert — die Daten sollen das Haus nicht verlassen. Er verändert die Angriffsfläche aber nicht, er verschiebt sie nur: vom gehärteten, überwachten Mandanten eines testierten Dienstleisters in das eigene Klinik-Netzwerk. Dieser Artikel stellt die technischen Varianten gegenüber, ordnet sie am geltenden Recht ein und benennt, wo Haftungsrisiken entstehen.

Welche Betriebsmodelle stehen für eine digitale Patientenaufnahme überhaupt zur Verfügung?

Es gibt nicht zwei, sondern fünf praktisch relevante Betriebsmodelle. Sie unterscheiden sich weniger im Speicherort als in der Frage, wer für Härtung, Patch-Management, Monitoring und Nachweisführung verantwortlich ist.

Modell A scheidet für die präoperative Patientenaufnahme faktisch aus, sobald Patient:innen vor dem Klinikaufenthalt von zu Hause aus teilnehmen sollen — genau das ist der Zweck des Verfahrens. Damit bleiben B bis E. Und zwischen B und C liegt der eigentliche Unterschied dieses Themas: nicht Cloud gegen On-Premise, sondern kontrollierter gegen unkontrollierter Fernzugriff.

Was sagt das deutsche Recht zum Cloud-Einsatz mit Gesundheitsdaten?

§ 393 SGB V erlaubt Leistungserbringern, Kranken- und Pflegekassen sowie deren Auftragsverarbeitern seit 2024 ausdrücklich die Verarbeitung von Sozial- und Gesundheitsdaten im Wege eines Cloud-Computing-Dienstes. Die Norm ist keine Ausnahme- oder Duldungsregelung, sondern eine Erlaubnisnorm mit vier Bedingungen.

Die Vorschrift wurde mit dem Digital-Gesetz (DigiG) eingeführt. Sie verlangt kumulativ:

1. Verarbeitungsregion: im Inland, in einem EU-Mitgliedstaat, in einem nach § 35 Abs. 7 SGB I gleichgestellten Staat oder — bei Vorliegen eines Angemessenheitsbeschlusses nach Art. 45 DSGVO — in einem Drittstaat (§ 393 Abs. 2 SGB V).
2. Niederlassung: Die datenverarbeitende Stelle muss über eine Niederlassung im Inland verfügen (§ 393 Abs. 2 SGB V).
3. Stand der Technik: Es müssen nach dem Stand der Technik angemessene technische und organisatorische Maßnahmen zur Gewährleistung der Informationssicherheit ergriffen sein (§ 393 Abs. 3 Nr. 1 SGB V).
4. C5-Testat und Kundenpflichten: Es muss ein aktuelles C5-Testat der datenverarbeitenden Stelle vorliegen, und die im Prüfbericht enthaltenen korrespondierenden Kriterien für Kunden müssen umgesetzt sein (§ 393 Abs. 3 Nr. 2 und 3 SGB V).

Zum vierten Punkt enthält Absatz 4 eine Stufung: Bis zum 30. Juni 2025 genügte ein C5-Typ-1-Testat, das die Angemessenheit der Kontrollen zu einem Stichtag bescheinigt. Seit dem 1. Juli 2025 ist grundsätzlich ein aktuelles C5-Typ-2-Testat maßgeblich, das zusätzlich die Wirksamkeit der Kontrollen über einen Berichtszeitraum belegt. Für informationstechnische Systeme, die nach dem 30. Juni 2025 erstmalig in Verkehr gebracht werden, gilt in den ersten 18 Monaten nach Inverkehrbringen ein Typ-1-Testat, ab dem 19. Monat ein Typ-2-Testat. Zulässig sind außerdem Testate oder Zertifikate nach Standards mit vergleichbarem oder höherem Sicherheitsniveau.

Wichtig für die Angemessenheitsprüfung: § 393 Abs. 5 SGB V verweist für zugelassene Krankenhäuser ausdrücklich auf § 391 SGB V. Der Maßstab für „angemessen“ ist also derselbe wie im Eigenbetrieb. Das Gesetz privilegiert die Cloud nicht — es zieht beide Modelle auf dieselbe Linie und verlangt für die Cloud zusätzlich einen externen Prüfnachweis.

Die zentrale Konsequenz: Wer den Cloud-Einsatz mit dem Argument ablehnt, das Recht verbiete ihn, argumentiert gegen den Wortlaut einer Erlaubnisnorm. Wer ihn ablehnt, weil ein konkreter Anbieter das C5-Testat nicht vorlegen kann, argumentiert sachlich richtig — und das ist ein anderer, prüfbarer Einwand.

Welche Anforderungen stellt § 391 SGB V an selbst betriebene Systeme?

§ 391 SGB V verpflichtet Krankenhäuser, nach dem Stand der Technik angemessene organisatorische und technische Vorkehrungen zur Vermeidung von Störungen der Verfügbarkeit, Integrität und Vertraulichkeit ihrer informationstechnischen Systeme, Komponenten oder Prozesse zu treffen. Diese Pflicht gilt unabhängig davon, ob ein System zugekauft oder selbst gebaut ist.

Drei Aspekte der Norm werden in der Praxis unterschätzt:

• Der Angemessenheitsmaßstab ist relativ, nicht absolut. Nach § 391 Abs. 3 SGB V sind Vorkehrungen angemessen, wenn der erforderliche Aufwand nicht außer Verhältnis zu den Folgen eines Ausfalls oder zum Schutzbedarf der verarbeiteten Patienteninformationen steht. Bei Gesundheitsdaten — besondere Kategorien nach Art. 9 DSGVO — ist der Schutzbedarf hoch. Der zumutbare Aufwand steigt entsprechend.
• Security-Awareness ist Pflichtbestandteil. § 391 Abs. 2 SGB V zählt verpflichtende Maßnahmen zur Steigerung der Security-Awareness von Mitarbeitenden ausdrücklich zu den Vorkehrungen nach Absatz 1.
• Der branchenspezifische Sicherheitsstandard ist der einfachste Erfüllungsweg, nicht der einzige. Nach § 391 Abs. 4 SGB V können Krankenhäuser die Pflichten insbesondere durch Anwendung eines vom BSI als geeignet festgestellten B3S erfüllen. „Insbesondere“ heißt: Andere Wege sind möglich — sie müssen dann aber eigenständig belegt werden.

Seit Dezember 2025 kommt die NIS2-Regulierung hinzu. Das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) trat am 6. Dezember 2025 ohne Übergangsfrist in Kraft und überführt die Anforderungen in das BSI-Gesetz; die Registrierungsfrist beim BSI lief am 6. März 2026 ab. Der Sektor Gesundheit ist erfasst, der Anwendungsbereich reicht deutlich unter die bisherigen KRITIS-Schwellen. Für Leitungsorgane besonders relevant: Das Gesetz verpflichtet sie, Risikomanagementmaßnahmen zu billigen und deren Umsetzung zu überwachen, sieht persönliche Haftung bei Pflichtverletzung vor und eröffnet der Aufsicht bei schwerwiegenden Verstößen die Möglichkeit, Leitungspersonen vorübergehend von ihrer Funktion auszuschließen. Der Bußgeldrahmen reicht bis 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes.

In Österreich verläuft der Zeitplan anders: Das NISG 2026 wurde am 23. Dezember 2025 kundgemacht (BGBl. I Nr. 94/2025) und tritt am 1. Oktober 2026 in Kraft, mit Registrierungsfrist bis Ende 2026. Bis dahin gilt das NISG 2018 fort. Die Schweiz ist als Nicht-EU-Staat nicht unmittelbar erfasst, wird aber über Lieferkettenanforderungen mittelbar berührt. Die deutschen Spezialnormen §§ 391 und 393 SGB V haben in Österreich und der Schweiz keine direkte Entsprechung — die Pflicht zu risikoangemessenen Maßnahmen nach Art. 32 DSGVO gilt in Österreich jedoch identisch.

Ist der „Rechner in der DMZ“ eine zulässige Alternative zur Cloud?

In der typischerweise vorgeschlagenen Form: nein — allerdings nicht, weil On-Premise-Betrieb unzulässig wäre, sondern weil dieselben Anforderungen gelten und in dieser Variante regelmäßig nicht erfüllt werden. Ein aus dem Internet erreichbares Endsystem in der DMZ verlagert die Angriffsfläche in das Klinik-Netzwerk, ohne die Kontrollen mitzuliefern, die ein testierter Dienst nachweisbar vorhält.

Gemessen an § 391 SGB V und Art. 32 DSGVO fehlen in dieser Konstruktion regelmäßig:

• Identitäts- und Zugriffskontrolle: Ein für „jeden von zu Hause“ erreichbares System hat per Definition keine belastbare Authentifizierung der zugreifenden Person. Ohne verlässliche Identifikation ist weder die Zuordnung von Anamnesedaten noch eine spätere Einwilligung beweissicher.
• Segmentierung und Blast Radius: Ein kompromittiertes System in der DMZ ist ein Brückenkopf im Klinik-Netz. Bei einem mandantenfähigen externen Dienst endet ein erfolgreicher Angriff auf die Anwendung nicht im KIS.
• Patch- und Schwachstellenmanagement mit Reaktionszeit: Internetexponierte Komponenten benötigen definierte SLAs für kritische Schwachstellen — in Stunden, nicht in Wartungsfenstern.
• Durchgehendes Monitoring: Angriffe auf exponierte Systeme laufen rund um die Uhr. 24/7-Protokollierung und -Auswertung sind bei einem Einzelsystem organisatorisch kaum darstellbar.
• Nachweisführung: Es existiert kein Prüfbericht, kein Testat, keine unabhängige Bestätigung der Wirksamkeit. Genau dieser Nachweis wird im Streitfall verlangt (siehe nächster Abschnitt).

Die Variante C — gehärteter, überwachter Fernzugriff mit Reverse Proxy, Web Application Firewall, MFA, Segmentierung, Schwachstellenmanagement und SOC-Anbindung — ist demgegenüber ein legitimes und tragfähiges Modell. Sie ist rechtlich nicht schlechter gestellt als ein Cloud-Dienst. Sie ist nur nicht billiger, nicht schneller und nicht einfacher nachzuweisen. Wer sie wählt, sollte das aus einer Betriebsentscheidung heraus tun, nicht aus einem Missverständnis über die Rechtslage.

Welche Haftungsfolgen drohen — und gibt es dazu bereits Urteile?

Zum konkreten Szenario „ungehärtetes Endsystem in der DMZ“ existiert nach unserer Kenntnis keine veröffentlichte Entscheidung. Der Maßstab lässt sich aber aus gefestigter Rechtsprechung zu Art. 32 DSGVO ableiten — und dieser Maßstab ist für Betreiber ungünstig, weil die Beweislast bei ihnen liegt.

1. Die Beweislast trägt der Verantwortliche (EuGH, Urteil vom 14.12.2023, C-340/21 — Natsionalna agentsia za prihodite). Der Gerichtshof hat entschieden, dass ein unbefugter Zugriff Dritter für sich genommen noch nicht belegt, dass die getroffenen Maßnahmen ungeeignet waren — die DSGVO etabliert ein Risikomanagementsystem und verspricht keine Risikofreiheit. Umgekehrt gilt jedoch: Im Rahmen einer Schadensersatzklage nach Art. 82 DSGVO muss der Verantwortliche darlegen und beweisen, dass seine Sicherheitsmaßnahmen im Sinne von Art. 32 DSGVO geeignet waren. Die Geeignetheit ist von den nationalen Gerichten konkret zu beurteilen, unter Berücksichtigung der mit der Verarbeitung verbundenen Risiken. Ein Sachverständigengutachten kann dabei Beweismittel sein, ist aber weder zwingend erforderlich noch für sich ausreichend.

Für die Praxis heißt das: Nach einem Vorfall muss die Klinik aktiv nachweisen, dass ihr Schutzniveau risikoangemessen war. Wer dafür auf einen C5-Prüfbericht und ein zertifiziertes ISMS verweisen kann, ist in einer strukturell anderen Beweislage als wer ein selbst aufgestelltes Einzelsystem verteidigen muss.

2. Risikoangemessenheit wird streng ausgelegt (Schleswig-Holsteinisches OLG, Urteil vom 18.12.2024, 12 U 9/24). Ein Handwerksbetrieb hatte eine Schlussrechnung über rund 15.000 Euro lediglich transportverschlüsselt per E-Mail versandt; Angreifer manipulierten die Bankverbindung. Das Gericht sprach der Empfängerin einen Schadensersatzanspruch aus Art. 82 DSGVO in Höhe der Werklohnforderung zu, den sie der Forderung entgegenhalten konnte — im Ergebnis blieb der Betrieb auf seiner Rechnung sitzen. Bei hohem finanziellem Risiko sei nur eine Ende-zu-Ende-Verschlüsselung geeignet; der dafür erforderliche technische und finanzielle Aufwand könne auch von einem mittelständischen Betrieb erwartet werden, wenn er nicht per Post versende. Bemerkenswert ist die Begründungslinie: Das Gericht verlangt Voraussicht und proaktives Handeln gegenüber Risiken, die einem digitalen Verfahren inhärent sind.

3. Es gibt eine Gegenposition (OLG Karlsruhe, Urteil vom 27.07.2023, 19 U 83/22). In einem vergleichbaren B2B-Fall kam das OLG Karlsruhe zu einem anderen Ergebnis: Das Fehlen bestimmter Maßnahmen führe nicht automatisch zur Haftung; maßgeblich seien die berechtigten Sicherheitserwartungen des jeweiligen Geschäftsverkehrs. Die divergierende Rechtsprechung ist noch nicht höchstrichterlich geklärt. Für Gesundheitsdaten dürfte die strengere Linie näher liegen, weil die Sicherheitserwartung an ein Krankenhaus messbar höher ist als an einen Handwerksbetrieb — belegen lässt sich das derzeit aber nicht mit einer einschlägigen Entscheidung.

4. Persönliche Verantwortung der Leitungsebene. Unabhängig von zivilrechtlicher Haftung adressiert das NIS2UmsuCG die Geschäftsleitung direkt: Billigung und Überwachung der Risikomanagementmaßnahmen, persönliche Haftung bei Pflichtverletzung, im Extremfall vorübergehendes Tätigkeitsverbot. Die Entscheidung, ein internetexponiertes System ohne Härtung und ohne Nachweisführung zu betreiben, ist damit keine reine IT-Entscheidung mehr.

5. Der Betriebsrisiko-Referenzfall. Der Ransomware-Vorfall am Universitätsklinikum Düsseldorf im September 2020 begann nach übereinstimmenden Berichten über eine seit Dezember 2019 bekannte Schwachstelle in einem Citrix-Gateway (CVE-2019-19781); das BSI hatte wiederholt gewarnt, dass Systeme bereits vor dem Einspielen der Patches kompromittiert worden sein konnten. Rund 30 Server wurden verschlüsselt, die Notfallversorgung musste ausgesetzt werden. Zur Einordnung, ehrlicherweise: Die Staatsanwaltschaft stellte die Ermittlungen wegen Todesfolge mangels Kausalität ein — der Fall belegt kein Haftungsurteil. Er belegt etwas anderes, und das genügt: dass die Perimeter-Komponente, die Fernzugriff ermöglicht, das Einfallstor ist, und dass ihr Betrieb dauerhafte, spezialisierte Aufmerksamkeit erfordert.

Hinweis: medudoc ist keine Rechtsberatung. Die Darstellung ersetzt keine Prüfung des Einzelfalls durch Ihre Rechtsabteilung oder Ihre:n Datenschutzbeauftragte:n. Rechtsprechung zu Art. 32 DSGVO ist in Bewegung; die hier zitierten Entscheidungen sind Landesgerichtsentscheidungen bzw. EuGH-Vorabentscheidungen, keine höchstrichterliche deutsche Klärung.

Verbietet die ärztliche Schweigepflicht nach § 203 StGB den Einsatz externer Dienstleister?

Nein. Seit der Reform des § 203 StGB im Jahr 2017 dürfen Berufsgeheimnisträger:innen Geheimnisse gegenüber „sonstigen mitwirkenden Personen“ offenbaren, soweit dies für deren Tätigkeit erforderlich ist. IT-Dienstleister und Rechenzentren fallen unter diesen Begriff. Die Erlaubnis ist allerdings an Pflichten geknüpft, die vertraglich umgesetzt werden müssen.

Die wesentlichen Anforderungen: Die Offenbarung muss auf das für die beauftragte Tätigkeit Erforderliche beschränkt bleiben. Die mitwirkenden Personen sind sorgfältig auszuwählen und förmlich zur Geheimhaltung zu verpflichten — einschließlich eingeschalteter Unterauftragnehmer. Wer diese Verpflichtung unterlässt, kann sich nach § 203 Abs. 4 StGB selbst strafbar machen.

Zwei Klarstellungen, die in der Diskussion häufig fehlen: § 203 StGB adressiert Berufe, nicht Einrichtungen — verpflichtet sind die behandelnden Ärzt:innen, nicht das Krankenhaus als juristische Person. Und ein Auftragsverarbeitungsvertrag allein löst die strafrechtliche Frage nicht; er ist die datenschutzrechtliche, nicht die strafrechtliche Grundlage. Beides ist zu regeln. Beides ist regelbar. Ein Verbot lässt sich aus § 203 StGB nicht ableiten.

Wie prüfen Kliniken einen Anbieter belastbar?

Die Prüfung sollte nicht am Hosting-Modell ansetzen, sondern an den Nachweisen. Ein Anbieter, der die folgenden Dokumente vorlegen kann, erfüllt die Voraussetzungen des § 393 SGB V nachvollziehbar. Ein Anbieter, der sie nicht vorlegen kann, ist unabhängig vom Betriebsmodell kritisch zu bewerten.

Zwei Hinweise aus der Praxis: Erstens ist ein Typ-1-Testat kein Typ-2-Testat — der Unterschied zwischen Angemessenheit zu einem Stichtag und Wirksamkeit über einen Zeitraum ist der eigentliche Prüfgehalt. Zweitens gilt die C5-Prüfung nur für den testierten Leistungsumfang; der Geltungsbereich gehört in jede Bewertung.

Wie medudoc arbeitet — und wo die Grenzen liegen

medudoc wird als cloud-native Plattform betrieben. Die Datenspeicherung erfolgt in Deutschland, eingesetzte KI-Modelle werden ausschließlich innerhalb der EU betrieben. Gegenüber der Klinik agiert medudoc als Auftragsverarbeiter; Verantwortliche im Sinne von Art. 4 Nr. 7 DSGVO bleibt die Klinik.

Der regulatorische Status im Einzelnen:

• ISO/IEC 27001:2022 — zertifiziert seit April 2026, gültig bis März 2029.
• BSI C5 — Typ 1 zum Stichtag 08. Mai 2026 erfolgreich abgeschlossen; Typ 2 im Betrachtungszeitraum bis Oktober 2026. Bis zum Vorliegen des Typ-2-Prüfberichts formuliert medudoc bewusst nicht „C5-zertifiziert“.
• MDR — medudoc ist kein Medizinprodukt. Die finale medizinische Entscheidung verbleibt stets bei der ärztlichen Person; die Plattform strukturiert ausschließlich Informationen für die ärztliche Beurteilung.

Was medudoc nicht leistet, gehört in dieselbe Darstellung: Ein vollständiger Betrieb im Klinikrechenzentrum ohne Anbindung an die medudoc-Plattform ist nicht Teil des Leistungsmodells. Kliniken, für die ein reiner Eigenbetrieb aus strategischen Gründen gesetzt ist, sind bei uns nicht richtig — das sagen wir lieber vorher als nachher. Ebenso wenig ersetzt ein Testat die klinikseitigen Pflichten: Die korrespondierenden Kundenkriterien aus dem C5-Prüfbericht müssen von der Klinik umgesetzt werden, und die Verantwortlichkeit nach DSGVO bleibt bei ihr.

Technisch bindet sich medudoc über FHIR-Schnittstellen an bestehende KIS- und Patientenportal-Landschaften an; eine Übersicht dazu finden Sie unter Schnittstellen und Integrationen. Wie sich die Plattform in den klinischen Ablauf einfügt, beschreibt die Pillar Page zum digitalen präoperativen Workflow. Sicherheitsrelevante Angaben und Kontaktwege für Responsible Disclosure finden Sie unter Sicherheitshinweise, den medizinisch-redaktionellen Prozess hinter den Inhalten unter Qualitätsstandards. Zertifikate und Prüfberichte stellen wir im medudoc Trust Center bereit.

Häufige Fragen

Quellen

• § 391 SGB V — IT-Sicherheit in Krankenhäusern: https://www.sozialgesetzbuch-sgb.de/sgbv/391.html
• § 393 SGB V — Cloud-Einsatz im Gesundheitswesen: https://www.sozialgesetzbuch-sgb.de/sgbv/393.html
• BSI, Kriterienkatalog C5: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html
• EuGH, Urteil vom 14.12.2023, C-340/21 (Natsionalna agentsia za prihodite) Schleswig-Holsteinisches OLG, Urteil vom 18.12.2024, 12 U 9/24 (Pressemitteilung): https://www.schleswig-holstein.de/DE/justiz/gerichte-und-justizbehoerden/OLG/Presse/PI/202501Werklohnrechnung
• OLG Karlsruhe, Urteil vom 27.07.2023, 19 U 83/22 NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG), in Kraft seit 06.12.2025
• NISG 2026 (Österreich), BGBl. I Nr. 94/2025, in Kraft ab 01.10.2026
• BSI, Pressemitteilung zum Cyber-Angriff auf die Uniklinik Düsseldorf (17.09.2020)