B3S GKV/PV: der Sicherheitsstandard für das Verwaltungs- und Zahlungssystem der gesetzlichen Kranken- und Pflegeversicherung

Problem in der Praxis

Kassen arbeiten mit einer stark verflochtenen Dienstleisterlandschaft: Rechenzentren im Verbund, gemeinsame Verfahren, Auftragsverarbeitung nach Sozialdatenschutzrecht. Der Standard verlangt deshalb ausdrücklich, extern erbrachte Leistungen in den Geltungsbereich einzubeziehen. Die Vorstellung, ein Verbundrechenzentrum als fremde Verantwortung zu betrachten, trägt diesen Nachweis nicht.

Ein zweiter Punkt betrifft die Schutzziele. Der Standard verlangt eine Schutzbedarfsbestimmung für alle Prozesse der kritischen Dienstleistung, und er nennt dafür Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit nebeneinander. Wer bei einer Kasse zuerst an die Vertraulichkeit der Sozialdaten denkt, greift zu kurz: Wer nur sie betrachtet, lässt drei der vier Schutzziele unbearbeitet, und tragend für die Erbringung der kritischen Dienstleistung ist vor allem die Verfügbarkeit des Zahlungsverkehrs.

Der dritte Punkt ist der Sonderteil zur Angriffserkennung. Er ist in Einzelanforderungen gegliedert und deckt Planung, Protokollierung, Detektion und Reaktion ab. Wer diese Anforderungen erst kurz vor dem Nachweis liest, stellt fest, dass sie Infrastruktur verlangen: Protokollquellen, Auswertung, Alarmierung und ein Reaktionsverfahren. Das Dokument verlangt dafür eine risikobezogene Planung, die den Bestand und die rechtlichen Rahmenbedingungen einbezieht, und lässt damit erkennen, dass die Einführung ein Vorhaben ist und kein Konfigurationsschritt.

CISO-Einordnung

Der Standard beginnt ungewöhnlich, nämlich mit einem eigenen Abschnitt zur Anwendung des B3S selbst. Er verlangt, Abweichungen von seiner Vorgehensweise und von seinen Anforderungen nachvollziehbar zu begründen. Das ist mehr als eine Formalie: Es macht die Abweichung zu einem bewussten, belegten Schritt und nicht zu einer stillen Auslassung.

Darauf folgen die tragenden Kapitel. Das ISMS ist für den Anwendungsbereich der kritischen Dienstleistung zu betreiben. Wiederanlaufzeiten und Verfügbarkeitsanforderungen der beteiligten Systeme sind zu bestimmen, was bei einem Zahlungssystem der entscheidende Parameter ist. Extern erbrachte Leistungen gehören in den Geltungsbereich. Die jeweils geltenden Fassungen der einschlägigen Gesetze und Regelungen sind zu beachten, und der Schutzbedarf aller Prozesse der kritischen Dienstleistung ist hinsichtlich der Schutzziele zu bestimmen.

Der Maßnahmenteil ist zweigeteilt. Der allgemeine Teil folgt der bekannten Gliederung von Asset Management über bauliche Sicherheit bis zur Lieferantensteuerung. Der Sonderteil zur Angriffserkennung trägt auf den Seiten 37 bis 45 insgesamt 51 Anforderungen mit eigenen Kennungen; nur er vergibt solche Kennungen. Die übrigen Kapitel führen ihre Pflichten im Fließtext und zusätzlich in Tabellen, die umzusetzende Controls der ISO/IEC 27001 bei ihrer Normnummer nennen; so etwa in den Abschnitten 4.1, 4.2 und 4.4. Abschnitt 4.6 legt die Controls aus Anhang A der Norm auf sieben Kategorien technischer Sicherheitsmaßnahmen um und vermerkt je Zeile die Branchenrelevanz für GKV und PV. Der Sonderteil 4.16 vergibt als einziger durchgehend eigene Kennungen; einzelne Pflichten mit eigener Nummerierung stehen aber auch anderswo, etwa die vier Fähigkeiten, die nach Abschnitt 4.18 zu realisieren sind.

Beim Bezug zur ISO/IEC 27001 ist dieser B3S deutlich: Er benennt Controls als umzusetzen, nicht nur als Orientierung. Eine Zuordnung zwischen B3S-Anforderung und ISO-Control ruht hier deshalb auf einer Vorgabe des Dokuments und nicht auf einer eigenen Auslegung.

Umsetzungsperspektive

Ein tragfähiger Einstieg ist die Kette Zahlungsverkehr. Beginnen Sie bei der Leistung, die ausfallen darf und nicht ausfallen darf, und arbeiten Sie rückwärts zu den Systemen, Verfahren und Dienstleistern. Die Kette macht sichtbar, woran die Leistung hängt, und sie ist gegenüber Prüfern erklärbar. Sie ersetzt aber weder die Business Impact Analyse, die der Standard der Kontinuitätsplanung vorschaltet, noch die Schutzbedarfsanalyse über alle vier Schutzziele. Und nicht jede Wiederanlaufzeit ist frei zu bestimmen: Für einzelne Prozesse gibt das Dokument eine Mindestverfügbarkeit vor, etwa für die Aktualisierung und Verwaltung der elektronischen Gesundheitskarte die höchste dort verwendete Klasse. Sie deckt den Geltungsbereich aber nicht ab: Das Dokument führt als Prozesse der kritischen Dienstleistung auch die Ausstellung der elektronischen Gesundheitskarte, ihre Aktualisierung und Verwaltung über den Versichertenstammdatendienst und den Einsatz von Ersatz- und Berechtigungsbescheinigungen. Diese Prozesse sind eigens zu betrachten.

Für die Angriffserkennung empfiehlt sich eine eigene Roadmap in vier Schritten: Planung und Geltungsbereich der Protokollierung, Aufbau der Protokollquellen und der zentralen Auswertung, Detektion mit Meldewegen und Zuständigen, Reaktion mit Einstufung, Eskalation und Nachbereitung. Diese Reihenfolge entspricht dem Aufbau der Anforderungen und vermeidet, dass Detektionswerkzeuge eingekauft werden, bevor die Datenquellen stehen.

Die Dienstleistersteuerung sollte früh geklärt werden, weil sie Vertragslaufzeiten berührt. Wo eine Kasse Systeme im Verbund betreiben lässt, braucht sie Prüfrechte, Berichte und ein Verfahren für festgestellte Abweichungen. Das lässt sich nicht kurzfristig nachverhandeln.

Typische Fehler

1. Verbundrechenzentren und gemeinsame Verfahren werden als fremde Verantwortung behandelt, obwohl der Standard sie in den Geltungsbereich zieht.
2. Der Schutzbedarf wird auf die Vertraulichkeit der Sozialdaten verengt, obwohl der Standard alle vier Schutzziele verlangt und die Erbringung der kritischen Dienstleistung an der Verfügbarkeit des Zahlungssystems hängt.
3. Der Teil zur Angriffserkennung wird als Anhang gelesen, obwohl er 51 einzeln gekennzeichnete Anforderungen trägt und Infrastruktur verlangt, die erst aufzubauen ist.
4. Abweichungen von der Vorgehensweise des B3S werden vorgenommen, aber nicht begründet, obwohl der Standard genau das verlangt.
5. Wiederanlaufzeiten werden aus der IT-Perspektive gesetzt statt aus den Fristen des Zahlungsverkehrs.

Risiken und Trade-offs

Der Sonderteil zur Angriffserkennung erzeugt einen Zielkonflikt, den kein Standard auflösen kann: Protokollierung im Umfeld von Sozialdaten berührt Datenschutz und Mitbestimmung. Der Standard verlangt die Protokollierung, entbindet aber nicht von den rechtlichen Rahmenbedingungen; er nennt deren Berücksichtigung ausdrücklich als Teil der Planung. Wer die Abstimmung mit Datenschutz und Mitbestimmung erst beim Aufbau beginnt, baut deshalb womöglich zweimal.

Der zweite Trade-off liegt in der Verflechtung. Je mehr Leistungen im Verbund erbracht werden, desto größer der Nutzen gemeinsamer Sicherheitsarbeit und desto schwieriger der individuelle Nachweis. Eine Kasse kann sich auf gemeinsame Prüfungen stützen, muss deren Ergebnisse aber für den eigenen Geltungsbereich auswerten.

Entscheidungspunkte

• Welche Systeme, Verfahren und Dienstleister gehören zur Kette des Zahlungsverkehrs, und ist diese Kette dokumentiert?
• Sind die Prozesse rund um die elektronische Gesundheitskarte und die Ersatz- und Berechtigungsbescheinigungen ebenfalls im Geltungsbereich erfasst?
• Welche Wiederanlaufzeiten gelten fachlich, nicht technisch, und wer hat sie festgelegt?
• Wird der Teil zur Angriffserkennung als eigenes Vorhaben geplant oder im Maßnahmenkatalog mitgeführt?
• Welche Abweichungen von der Vorgehensweise des B3S bestehen, und wo ist ihre Begründung hinterlegt?

Praktische Empfehlungen

Führen Sie ein einziges Verzeichnis der kDL-relevanten Systeme mit Wiederanlaufzeit, Schutzbedarf, Betreiber und Vertragsgrundlage. Dieses Verzeichnis bedient gleichzeitig Geltungsbereich, Risikoanalyse und Dienstleistersteuerung und verhindert, dass drei Abteilungen drei Listen pflegen.

Klären Sie die datenschutz- und mitbestimmungsrechtliche Seite der Protokollierung, bevor Sie Werkzeuge auswählen. Die Anforderungen an die Angriffserkennung setzen Datenquellen voraus, deren Zulässigkeit intern abgestimmt sein muss.

Halten Sie jede Abweichung vom Standard an der Stelle fest, an der sie entsteht, und holen Sie dort, wo eine Sicherheitsmaßnahme unterbleibt, die Freigabe der obersten Leitung ein. Eine nachträglich gesammelte Abweichungsliste ist im Nachweisverfahren schwerer zu verteidigen als eine laufend geführte, und eine Freigabe, die erst im Prüfverfahren nachgeholt wird, kostet Zeit an der ungünstigsten Stelle.

Relevante Normreferenzen

• Branchenspezifischer Sicherheitsstandard für das Verwaltungs- und Zahlungssystem der gesetzlichen Kranken- und Pflegeversicherung (B3S-GKV/PV), Version 1.4 vom 20.1.2025, herausgegeben vom Branchenarbeitskreis Gesetzliche Krankenversicherungen im UP KRITIS. BSI-Eignungsfeststellung nach dem früheren § 8a Absatz 2 BSIG, Gültigkeit bis April 2028. Die Frist steht nicht im Dokument; sie stammt von der BSI-Detailseite zu diesem B3S (https://www.bsi.bund.de/SharedDocs/Textbausteine/DE/KRITIS/B3S/Finanz-Versicherungswesen/b3s-gkv-pv.html, abgerufen am 17.9.2026).
• BSI-Gesetz in der Fassung des NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes: Betreiberpflichten, Nachweispflicht und die gesetzliche Pflicht zu Systemen zur Angriffserkennung.
• Verordnung zur Bestimmung Kritischer Infrastrukturen (BSI-KritisV): Zuordnung des Verwaltungs- und Zahlungssystems und Schwellenwert.
• ISO/IEC 27001: Controls, die der Standard als umzusetzen benennt (reine Konzeptreferenz, kein Volltext).
• Orientierungshilfe des BSI zum Einsatz von Systemen zur Angriffserkennung: fachliche Richtschnur für den Sonderteil.