C5-Pflicht: Braucht Ihr Unternehmen ein C5-Testat?

„Wir verarbeiten doch keine Gesundheitsdaten. Wir hosten nur die Software, in der die Gesundheitsdaten stehen.“

So ein Satz klingt auf den ersten Blick nach einer sauberen Abgrenzung. Auf den zweiten Blick klingt er eher nach dem Versuch, sich mit einer Berufsbezeichnung aus einer gesetzlichen Regelung herauszudefinieren. Ob ein Unternehmen Softwarehersteller, Hosting-Anbieter, IT-Dienstleister oder Cloud-Anbieter auf seine Website schreibt, entscheidet aber nicht darüber, ob die C5-Pflicht nach § 393 SGB V greift.

Entscheidend ist, wer für wen welche Daten mit welchem technischen Dienst verarbeitet. Und die Substantive in diesem Satz sind keineswegs so frei verfügbar, wie man es sich beim ersten Lesen des Gesetzes vielleicht wünschen würde.

Die kurze Antwort

Die rechtliche Grundlage ist § 393 SGB V zum Cloud-Einsatz im Gesundheitswesen. Die Vorschrift sagt nicht schlicht: „Unternehmen im Gesundheitswesen müssen C5 machen.“ Sie ist als Erlaubnistatbestand formuliert. Bestimmte Stellen dürfen Sozialdaten und Gesundheitsdaten über einen Cloud-Computing-Dienst verarbeiten, wenn die dort genannten Voraussetzungen erfüllt sind.

Eine C5-Pflicht wird praktisch relevant, wenn diese Fragen nacheinander mit Ja beantwortet werden:

1. Gehören Sie oder Ihr Auftraggeber zu den erfassten Stellen?
2. Werden Gesundheitsdaten oder Sozialdaten verarbeitet?
3. Verarbeiten Sie diese Daten selbst oder als Auftragsdatenverarbeiter?
4. Geschieht das über einen Cloud-Computing-Dienst im gesetzlichen Sinne?
5. Sind die eingesetzten Cloud-Systeme und die zugrunde liegende Technik vom erforderlichen Testat erfasst?

Erst diese Kombination macht das Thema heiß. „Wir haben irgendetwas mit Gesundheit zu tun“ reicht nicht. „Wir sind nur ein technischer Anbieter“ rettet umgekehrt auch nicht automatisch.

Warum im Gesetz nicht einfach „C5-Pflicht“ steht

§ 393 SGB V richtet sich zunächst an Leistungserbringer im Sinne des vierten Kapitels, Kranken- und Pflegekassen sowie deren jeweilige Auftragsdatenverarbeiter. Diese Stellen dürfen Gesundheits- und Sozialdaten in der Cloud nur unter den Voraussetzungen der Absätze 2 bis 4 verarbeiten.

Das ist sprachlich etwas anderes als die Anordnung, jedes betroffene Unternehmen müsse sich pauschal testieren lassen. Der Leistungserbringer oder die Kasse muss einen geeigneten Cloud-Dienst auswählen. Der Cloud-Anbieter benötigt für den verwendeten Dienst den passenden Nachweis, damit dieser Dienst für die betreffende Verarbeitung eingesetzt werden kann.

Die handliche Kurzform lautet deshalb:

Nicht das Unternehmen als solches braucht für alles C5. Der für die betreffende Verarbeitung eingesetzte Cloud-Dienst muss mit seinen relevanten Systemen und seiner Technik vom notwendigen Nachweis erfasst sein.

Prüfung 1: Gehören Sie zum erfassten Personenkreis?

Das Bundesgesundheitsministerium erläutert § 393 SGB V für folgende Gruppen:

• Leistungserbringer nach dem vierten Kapitel des SGB V, beispielsweise Vertragsärzte und Vertragszahnärzte, zugelassene Krankenhäuser, Psychotherapeuten und Apotheken,
• gesetzliche Kranken- und Pflegekassen,
• Auftragsdatenverarbeiter dieser beiden Gruppen, wenn sie mit der Verarbeitung von Gesundheits- oder Sozialdaten beauftragt sind.

Der Anwendungsbereich des vierten Kapitels in § 69 SGB V erfasst außerdem sonstige Leistungserbringer und ihre Rechtsbeziehungen zu den Krankenkassen. Deshalb sollte ein Unternehmen nicht allein anhand einer kurzen Branchenliste entscheiden, ob es dazugehört.

Ein Möbelhersteller fällt nicht deshalb unter § 393, weil er Schreibtische an Arztpraxen liefert. Ein Softwareanbieter kann dagegen sehr wohl erfasst sein, wenn er im Auftrag einer Praxis, eines Krankenhauses oder einer Kasse relevante Daten verarbeitet.

Prüfung 2: Was sind Gesundheitsdaten?

Gesundheitsdaten sind nicht einfach alle Daten, die zufällig in einem Krankenhaus vorkommen. Sie sind aber auch nicht auf Diagnosen und Arztbriefe beschränkt.

Artikel 4 Nummer 15 der Datenschutz-Grundverordnung beschreibt Gesundheitsdaten als personenbezogene Daten, die sich auf die körperliche oder geistige Gesundheit einer Person einschließlich der Erbringung von Gesundheitsdienstleistungen beziehen und aus denen Informationen über ihren Gesundheitszustand hervorgehen.

Dazu können je nach Zusammenhang beispielsweise gehören:

• Diagnosen, Befunde und Laborwerte,
• Medikationsdaten und Verordnungen,
• Angaben zu Behandlungen und Terminen,
• Röntgenbilder und andere medizinische Aufnahmen,
• Informationen über Behinderungen oder psychische Erkrankungen,
• Abrechnungsdaten, wenn daraus eine Behandlung oder ein Gesundheitszustand hervorgeht,
• Geräte- und Messdaten, die einer Person zugeordnet werden können und gesundheitliche Aussagen ermöglichen.

Ein Name allein ist noch keine medizinische Diagnose. In Verbindung mit einer bestimmten Behandlung, Fachabteilung oder Leistung kann aber bereits eine gesundheitliche Aussage entstehen. Wer eine Tabelle mit „Patientenname, Onkologie, nächster Termin“ verarbeitet, sollte sich deshalb nicht daran festhalten, dass in der Datei kein Feld mit der Überschrift Diagnose existiert.

Auch pseudonymisierte Daten sind nicht automatisch aus dem Spiel. Solange eine Zuordnung mit zusätzlichen Informationen möglich bleibt, handelt es sich regelmäßig weiterhin um personenbezogene Daten. Anonymisierung ist eine wesentlich höhere Hürde als das Ersetzen eines Namens durch eine Kennnummer.

Mehr zur praktischen Abgrenzung und zum Schutz solcher Informationen behandeln wir im Artikel Personenbezogene Daten richtig schützen.

Prüfung 3: Was sind Sozialdaten?

Sozialdaten sind ebenfalls kein Begriff, den ein Unternehmen für seine Produktbeschreibung selbst festlegen kann. Nach § 67 Absatz 2 SGB X sind es personenbezogene Daten, die eine in § 35 SGB I genannte Stelle im Hinblick auf ihre Aufgaben nach dem Sozialgesetzbuch verarbeitet.

Das können Gesundheitsdaten sein, müssen es aber nicht. Auch Versicherungsverhältnisse, Leistungsansprüche, Beitragsdaten, Pflegegrade, Abrechnungsinformationen oder Korrespondenz zu einem konkreten Sozialleistungsfall können Sozialdaten sein.

Die Frage lautet deshalb nicht: „Sieht diese Information für uns besonders sensibel aus?“ Sie lautet: Wer verarbeitet die personenbezogenen Daten in welchem gesetzlichen Aufgabenzusammenhang?

Prüfung 4: Wann sind Sie Auftragsdatenverarbeiter?

§ 393 verwendet den Ausdruck Auftragsdatenverarbeiter. Inhaltlich geht es um Unternehmen, die personenbezogene Daten im Auftrag einer verantwortlichen Stelle verarbeiten. Typische Kandidaten sind:

• Betreiber einer SaaS-Anwendung für Praxen oder Krankenhäuser,
• Hosting- und Rechenzentrumsanbieter,
• Anbieter von Datensicherung, Archivierung oder Dokumentenverarbeitung,
• IT-Dienstleister mit administrativem Zugriff auf Systeme und Daten,
• Unterauftragnehmer in der technischen Lieferkette.

Der Satz „Wir speichern die Daten nur“ ist dabei kein Gegenargument. Speichern ist eine Form der Verarbeitung. Auch die Behauptung „Unsere Mitarbeiter schauen da normalerweise nicht hinein“ erledigt die Einordnung nicht automatisch.

Ob ein Unternehmen Verantwortlicher, Auftragsverarbeiter oder in einer komplizierteren Rollenverteilung tätig ist, hängt von der tatsächlichen Entscheidungsmacht und Aufgabenverteilung ab. Genau deshalb gehören solche Rollen auch in die rechtlichen und vertraglichen Anforderungen eines ISMS und in belastbare Vereinbarungen.

Prüfung 5: Was ist ein Cloud-Computing-Dienst?

Der Gesetzgeber hat auch Cloud nicht als Gefühl definiert. § 384 Nummer 5 SGB V nennt mehrere Merkmale. Ein Cloud-Computing-Dienst ist demnach ein digitaler Dienst, der auf Abruf die Verwaltung und den umfassenden Fernzugang zu einem skalierbaren und elastischen Pool gemeinsam nutzbarer Rechenressourcen ermöglicht – auch über mehrere Standorte hinweg.

In normales Deutsch übersetzt, stecken darin insbesondere diese Gedanken:

• digitaler Dienst: Es geht um eine elektronisch erbrachte Leistung und nicht bloß um den Verkauf eines Geräts;
• auf Abruf: Ressourcen oder Funktionen können bedarfsgerecht bereitgestellt oder genutzt werden;
• Fernzugang: Die Nutzung und Verwaltung erfolgen nicht nur unmittelbar an einer lokalen Maschine;
• skalierbar und elastisch: Ressourcen lassen sich an den Bedarf anpassen;
• gemeinsam nutzbarer Ressourcenpool: Die technische Basis wird typischerweise für mehrere Kunden oder Dienste verwendet, auch wenn Mandanten sauber getrennt sind.

Typische SaaS-, PaaS- und IaaS-Angebote werden diese Merkmale häufig erfüllen. Nicht jeder fernadministrierte Einzelserver und nicht jede lokal installierte Software ist deshalb automatisch ein Cloud-Dienst. Die Abgrenzung hängt von der tatsächlichen Architektur und Bereitstellung ab.

Eine Produktbezeichnung wie Cloud, Hosted oder Online ersetzt diese Prüfung nicht. Lassen Sie sich die tatsächliche Architektur, Skalierung, Mandantentrennung und Bereitstellung beschreiben, statt aus dem Namen des Angebots eine rechtliche Einordnung abzuleiten.

Prüfung 6: Welcher Dienst und welche Technik müssen erfasst sein?

Nach § 393 Absatz 3 Nummer 2 muss das Testat die C5-Basiskriterien für die im Cloud-Dienst eingesetzten Cloud-Systeme und die eingesetzte Technik abdecken. Das BMG erläutert dies als Software und zugrunde liegende Hardware.

Bei einer SaaS-Lösung kann die Kette beispielsweise so aussehen:

1. Fachanwendung des SaaS-Anbieters,
2. verwendete Datenbank- und Plattformdienste,
3. Infrastruktur eines Hyperscalers oder Rechenzentrums,
4. weitere technische Unterauftragnehmer.

Ein C5-Bericht des Infrastrukturbetreibers ist nicht automatisch ein C5-Bericht für die darauf betriebene Fachanwendung. Umgekehrt kann der SaaS-Anbieter Abhängigkeiten von Unterauftragnehmern in seinem Prüfbericht auf unterschiedliche Weise behandeln. Entscheidend sind Systemgrenzen, Leistungsbeschreibung, Prüfungsumfang und die Behandlung der Subdienstleister.

Das ist klassische IKT-Lieferkette. Wer sich nur die erste Vertragspartei ansieht, übersieht schnell die weiteren technischen Ebenen. Wie sich solche Abhängigkeiten praktisch dokumentieren lassen, zeigt unser Beitrag zum Lieferantenmanagement mit Jira. Für die fachliche Prüfung des Dienstes passt außerdem unser Leitfaden zur sicheren Auswahl und Steuerung von Cloud-Diensten.

Das Testat allein genügt dem Kunden nicht

§ 393 verlangt zusätzlich, dass die im Prüfbericht enthaltenen korrespondierenden Kriterien für Kunden umgesetzt werden. Das sind Verantwortlichkeiten, die der Cloud-Anbieter gerade nicht übernimmt, sondern beim Kunden voraussetzt.

Das kann je nach Servicemodell beispielsweise betreffen:

• sichere Benutzer- und Berechtigungsverwaltung,
• Mehrfaktor-Authentisierung,
• Konfiguration des Mandanten,
• Schutz eigener Schlüssel und Zugangsdaten,
• Patchen selbst verwalteter Systeme,
• Kontrolle von Protokollen und Sicherheitsmeldungen,
• geregelte Löschung und Rückgabe von Daten.

„Unser Anbieter hat C5“ ist deshalb noch keine vollständige Antwort. Wer die Kundenkriterien ignoriert, kann einen testierten Dienst trotzdem ausgesprochen kreativ unsicher betreiben.

Typ 1, Typ 2 und ein wirklich neues System

Seit dem 1. Juli 2025 gilt nach § 393 grundsätzlich ein aktuelles C5-Typ-2-Testat. Typ 2 betrachtet zusätzlich, ob die Kontrollen über einen Prüfungszeitraum wirksam funktioniert haben.

Für ein informationstechnisches System, das nach dem 30. Juni 2025 erstmals in Verkehr gebracht wurde, enthält das Gesetz eine Anlaufregel:

• während der ersten 18 Monate kann ein C5-Typ-1-Testat ausreichen,
• ab dem 19. Monat ist ein C5-Typ-2-Testat erforderlich.

Auch Inverkehrbringen ist in § 384 beschrieben. Ein Anbieter sollte daraus nicht ableiten, mit jedem größeren Release beginne eine frische 18-Monats-Frist. Bei einem kontinuierlich weiterentwickelten SaaS-Dienst kann die rechtliche Einordnung anspruchsvoll werden.

Der derzeitige Kriterienkatalog ist C5:2026 des Bundesamts für Sicherheit in der Informationstechnik. Für den Übergang von C5:2020 gelten eigene Fristen. Deshalb müssen Anbieter und Kunden nicht nur auf das Wort C5, sondern auch auf Kriterienversion, Prüfungszeitpunkt und Prüfungszeitraum schauen.

Reicht ISO 27001 stattdessen?

Die C5-Gleichwertigkeitsverordnung nennt unter anderem eine Zertifizierung nach ISO 27001 als möglichen alternativen Nachweis. Wer an dieser Stelle aufhört zu lesen, produziert allerdings den nächsten Kokolores.

Zusätzlich braucht der Cloud-Dienst insbesondere:

• eine dokumentierte Analyse der materiell nicht abgedeckten C5-Basiskriterien,
• konkrete technische und organisatorische Vorkehrungen zum Schließen der Lücken,
• eine Meilensteinplanung mit höchstens zwölf Monaten für die Lückenschließung,
• Maßnahmen zur Erlangung von C5 Typ 1 innerhalb von 18 Monaten,
• Maßnahmen zur Erlangung von C5 Typ 2 innerhalb von 24 Monaten.

ISO 27001 ist hier also keine dauerhafte Ausweichroute um C5 herum. Sie kann unter den Bedingungen der Verordnung eine zeitlich begrenzte Brücke auf dem Weg zum C5-Testat sein. Den grundsätzlichen Unterschied erklärt unser Artikel C5 und ISO 27001: Warum Zertifikat und Testat nicht dasselbe sind.

Der Entscheidungsbaum: Fallen Sie unter die C5-Pflicht?

Gehen Sie in dieser Reihenfolge vor:

1. Erfasste Stelle: Sind Sie Leistungserbringer nach dem vierten Kapitel, Kranken- oder Pflegekasse – oder arbeiten Sie als Auftragsverarbeiter für eine solche Stelle?
2. Daten: Werden personenbezogene Gesundheitsdaten oder Sozialdaten verarbeitet?
3. Cloud: Erfüllt der eingesetzte Dienst die Merkmale des Cloud-Computing-Dienstes aus § 384 Nummer 5?
4. Verarbeitungskette: Welche Unternehmen, Systeme und Unterauftragnehmer sind tatsächlich an der Verarbeitung beteiligt?
5. Prüfungsumfang: Deckt das Testat genau den verwendeten Dienst, seine relevanten Systeme und seine Technik ab?
6. Berichtstyp und Version: Ist das Testat aktuell und ist Typ 2 erforderlich oder greift eine belastbare Ausnahme?
7. Kundenkriterien: Wer setzt die im Bericht genannten korrespondierenden Kriterien um und weist dies nach?

Wenn eine der ersten drei Fragen mit Nein beantwortet wird, kann § 393 für den konkreten Anwendungsfall ausscheiden. Das bedeutet nicht automatisch, dass keine anderen Datenschutz-, Sicherheits-, Vertrags- oder Branchenanforderungen gelten. Es bedeutet nur, dass man die C5-Pflicht nicht mit dem falschen Paragraphen begründen sollte.

Typische Fehler

• Das Unternehmen entscheidet anhand seiner Branche statt anhand der konkreten Verarbeitung.
• Pseudonymisierte Daten werden vorschnell als anonym behandelt.
• Ein SaaS-Anbieter erklärt sich zum reinen Softwarehersteller, obwohl er Daten im Auftrag verarbeitet.
• Der C5-Bericht eines Hyperscalers wird mit einem Testat der darauf betriebenen Fachanwendung verwechselt.
• Ein ISO 27001-Zertifikat wird ohne Lückenanalyse und Maßnahmenplan als dauerhafter Ersatz betrachtet.
• Die korrespondierenden Kriterien für Kunden bleiben ungelesen im Prüfbericht.
• Typ 1 wird bei einem etablierten Dienst weiterverwendet, obwohl Typ 2 erforderlich ist.

Interesse geweckt?

Sie möchten belastbar klären, ob Ihr Unternehmen oder Ihr Cloud-Dienst von § 393 SGB V betroffen ist und wie C5 und ein vorhandenes ISMS zusammenspielen? Sprechen Sie mit uns.

Rechtlicher Hinweis: Dieser Artikel ist keine Rechtsberatung. Er erläutert den derzeitigen Regelungsstand und typische Prüfschritte. Gesetze, Verordnungen und laufende Gesetzgebungsverfahren können sich ändern – und der Gesetzgeber ruft uns leider nicht persönlich an, wenn er einen Satz umstellt. Lassen Sie schwierige Einzelfälle rechtlich prüfen.