Wartungs- und Supportzugriffe unter § 393 SGB V: geltendes Recht und GeDIG-Entwurf

Diese Seite trennt zwei Dinge: was § 393 SGB V heute für Wartung und Support sagt, und was der Gesetzentwurf zum GeDIG daran ändern würde. Die Rechtsgrundlage insgesamt, also Verarbeitungsort, Niederlassung, Testat und Fristen, beschreibt die Seite § 393 SGB V. Die Seite ordnet fachlich ein und ist keine Rechtsberatung. Der Entwurf kann sich im parlamentarischen Verfahren noch ändern.

Was heute gilt

§ 393 Abs. 1 SGB V hat in der geltenden Fassung nur einen Satz: Leistungserbringer, Kranken- und Pflegekassen und ihre Auftragsdatenverarbeiter dürfen Sozial- und Gesundheitsdaten auch im Wege des Cloud-Computing-Dienstes verarbeiten, wenn die Voraussetzungen der Absätze 2 bis 4 erfüllt sind. Eine Sonderregel für Wartung, Support oder Fehleranalyse enthält die Norm nicht (Wortlaut geprüft am 1. November 2026).

Ein Zugriff auf ein Cloud-System mit Gesundheitsdaten, etwa durch ein Support-Team mit Administratorrechten oder einen externen Dienstleister zur Fernwartung, ist nach unserer Einordnung am vollen § 393 zu messen, soweit er eine Verarbeitung ist: Ort der Verarbeitung, Niederlassung im Inland, technische und organisatorische Maßnahmen und ein aktuelles C5-Testat. Ob ein bestimmter Zugriff eine Verarbeitung im Sinne von § 393 ist, beantwortet der Wortlaut nicht ausdrücklich; das ist im Einzelfall zu prüfen.

Was der GeDIG-Entwurf ändern würde

Die Bundesregierung hat am 30. September 2026 den Entwurf eines Gesetzes für Daten und digitale Innovation im Gesundheitswesen vorgelegt (Bundestagsdrucksache 21/8279; das Bundesministerium für Gesundheit kürzt es GeDIG ab). Nach Art. 1 Nr. 100 würde § 393 Abs. 1 neu gefasst. Satz 1 bliebe inhaltlich gleich; statt „Auftragsdatenverarbeiter“ hieße es dort „Auftragsverarbeiter“, wie in der DSGVO. Neu wäre Satz 2:

„Ein Zugriff zu Wartungs- und Supportzwecken gilt nicht als Verarbeitung nach Satz 1, wenn durch technische Vorkehrungen nach dem Stand der Technik, insbesondere durch Verschlüsselung, sichergestellt ist, dass die Daten dabei nicht zur Kenntnis genommen oder auf sonstige Weise verarbeitet werden können.“

Die Begründung zu Nr. 100 (Drucksache S. 187 f.) bezeichnet Satz 1 als unverändert und erläutert die Absicht des neuen Satzes 2:

• Anknüpfung ist der technische Schutz. Nach der Begründung knüpft die Ausnahme allein an die technisch nachgewiesene Unzugänglichkeit der Daten an; der Zweck des Zugriffs reicht dafür nicht.
• Verschlüsselung nur ohne Schlüssel. Eine Verschlüsselung genügt nur, wenn die zugreifende Stelle nicht über die Mittel zur Entschlüsselung verfügt. Rein organisatorische oder vertragliche Zusicherungen genügen nicht.
• Technikoffen. Genannt werden vertrauenswürdige Ausführungsumgebungen, eine wirksame Trennung der Wartungsumgebung vom produktiven Datenbestand und Tokenisierung. Die Aufzählung ist nicht abschließend.
• Folge. Für so abgeschottete Zugriffe müssten die Anforderungen der Absätze 2 bis 4 nicht gesondert erfüllt werden. Die Begründung nennt ausdrücklich einen auch standortunabhängigen Wartungs- und Supportbetrieb.
• Grenze. Die Ausnahme reicht so weit wie der technische Schutz. Bleiben die Daten nicht durchgängig verschlossen, gilt § 393 mit allen Anforderungen. Die auf dem C5-Testat beruhende Sicherheitslogik bleibt nach der Begründung vollständig erhalten, Absatz 8 bleibt unberührt.
• Cloud-Migration. Der Umzug bestehender Systeme von On-Premise in die Cloud soll nicht allein wegen des Hosting-Wechsels zu einer anderen Bewertung etablierter Wartungsprozesse führen.

Geltendes Recht und Entwurf im Vergleich

Verfahrensstand

Stand unserer Prüfung am 1. November 2026:

• Kabinettsbeschluss am 15. Juli 2026, erster Durchgang im Bundesrat am 25. September 2026 (Angaben des Bundesministeriums für Gesundheit).
• Gesetzentwurf als Drucksache 21/8279 vom 30. September 2026. Die veröffentlichte Fassung ist als Vorabfassung gekennzeichnet, die durch eine lektorierte Fassung ersetzt wird.
• Erste Beratung im Bundestag am 8. Oktober 2026, Überweisung an den federführenden Ausschuss für Gesundheit; öffentliche Anhörung im Ausschuss am 14. Oktober 2026 (Angaben des Bundestages).
• Das Ministerium führt das Gesetz als laufendes Verfahren. Einen Gesetzesbeschluss des Bundestages haben wir nicht gefunden.

Nach Art. 16 Abs. 1 des Entwurfs träte das Gesetz grundsätzlich am Tag nach der Verkündung in Kraft; für Nr. 100 sieht der Entwurf keinen abweichenden Termin vor. Wann das sein wird, hängt vom weiteren Verfahren ab. Bis dahin gilt § 393 in der heutigen Fassung.

Beispiel: zwei Support-Wege desselben Anbieters

Fiktives Beispiel. Ein Anbieter einer Kliniksoftware betreibt seinen Dienst in einem Rechenzentrum in Deutschland. Den Support in der zweiten Ebene übernimmt ein Dienstleister außerhalb der EU.

• Weg A: Der Dienstleister meldet sich mit Administratorrechten an der Produktivdatenbank an und kann Datensätze lesen. Die Daten sind erreichbar. Nach unserer Einordnung ist dieser Zugriff heute und nach dem Entwurf am vollen § 393 zu messen, einschließlich Verarbeitungsort nach Absatz 2.
• Weg B: Der Dienstleister arbeitet in einer getrennten Wartungsumgebung mit tokenisierten Kopien. Die Schlüssel und die Zuordnungstabelle liegen in einem Schlüsselspeicher, den nur der Anbieter in Deutschland verwaltet; der Dienstleister hat technisch keinen Zugriff darauf. Nach dem Entwurf käme die neue Ausnahme in Betracht. Der Anbieter müsste belegen können, dass der Schutz durchgängig greift.

Datenschutzrechtliche Vorgaben, etwa zur Übermittlung in Drittstaaten, bleiben in beiden Fällen gesondert zu prüfen.

Was das für das C5-Testat heißt

Die Ausnahme würde einzelne Zugriffe aus § 393 herausnehmen, das Testat für den Cloud-Dienst aber nicht ersetzen. Nach unserer Einordnung gehören Wartungs- und Supportwege weiter in den Prüfungsgegenstand des C5-Testats, denn sie berühren Kontrollen, die der Prüfer ohnehin ansieht:

• Privilegierte Zugriffe im Themengebiet IAM (Identitäts- und Berechtigungsmanagement), siehe Themengebiet IAM umsetzen.
• Schlüsselverwaltung im Themengebiet CRY; wer welche Schlüssel hält, ist für die neue Ausnahme der Kern des Nachweises. C5:2026 enthält dazu etwa CRY-18 zu externen Schlüsselverwaltungssystemen.
• Trennung der Umgebungen nach DEV-12, wenn eine Wartungsumgebung vom Produktivbestand getrennt sein soll; DEV-12 lässt Produktivdaten in Test- oder Entwicklungsumgebungen nur mit ausdrücklicher Genehmigung der Kunden zu. Bei gemeinsam genutzten Ressourcen kommt die Mandantentrennung nach OPS-30 und OPS-31 hinzu.
• Dienstleister: Ein externer Support-Dienstleister kann ein Subdienstleister (Subservice-Organisation) sein. Die Systembeschreibung nennt dann Firmenname und Verarbeitungsort auf Länderebene, im Carve-out bleibt der Anbieter für die Überwachung verantwortlich. Im Subdienstleisterinventar hält der Anbieter dafür je Dienstleister Leistung, Verarbeitungsort, vorliegende Berichte und die Ergebnisse seiner Überwachung fest.

Wie ein Hersteller von Praxissoftware Support-Zugriffe auf Praxisdaten nach IAM-07 regelt und belegt, zeigt die Seite Praxissoftware aus der Cloud.

Was sich jetzt vorbereiten lässt

Einige Schritte lohnen sich unabhängig davon, in welcher Fassung das Gesetz kommt:

1. Zugriffswege erfassen. Wer greift zu welchem Zweck von wo auf Systeme mit Gesundheitsdaten zu: eigene Teams, Dienstleister, Unterauftragnehmer. Für jeden Weg festhalten, ob die Daten dabei technisch erreichbar sind.
2. Schlüsselhoheit belegen. Dokumentieren, wo Schlüssel liegen, wer sie verwaltet und wie technisch durchgesetzt wird, dass Wartungspersonal sie nicht nutzen kann.
3. Wartungsumgebung trennen. Wo möglich, Fehleranalyse mit tokenisierten oder synthetischen Daten statt am Produktivbestand.
4. Nachweise sammeln. Konfigurationen, Protokolle und Freigaben so ablegen, dass sie in einer Typ-2-Prüfung über den gesamten Zeitraum vorliegen.
5. Verträge nicht überschätzen. Eine Vertraulichkeitszusage des Dienstleisters wäre nach der Begründung kein Ersatz für technischen Schutz.

Wo Zugriffswege, Schlüsselhoheit und Nachweise heute gegenüber den C5-Kriterien stehen, zeigt eine C5-Gap-Analyse.

Was der Entwurf sonst mit § 393 verbindet

Nach Art. 1 Nr. 24 des Entwurfs gälten für Abrechnungsstellen nach § 295a SGB V, die Cloud-Dienste nutzen, die Anforderungen des § 393 entsprechend. Die Begründung nennt ausdrücklich Verarbeitungsort, Niederlassung im Inland, C5-Testat und technische und organisatorische Vorkehrungen, und zwar für den Fall, dass eine Abrechnungsstelle als Auftragsverarbeiter ihrerseits einen Cloud-Dienst in Anspruch nimmt. Der Entwurf enthält daneben weitere Regelungen für Gesundheitssoftware, etwa zu privaten Endgeräten im Krankenhaus (§ 363f neu), zu Meldepflichten gegenüber der gematik (§ 329) und zur Marktüberwachung für EHR-Systeme durch das BSI (§ 383b neu). Diese Seite behandelt sie nicht im Einzelnen.