Zwölf Schritte zum Zertifikat für Health-Startups und digitale Versorger. Plus: warum ISO 27001 für DiGA-Hersteller Zulassungsvoraussetzung ist.

Gesundheitsdaten sind besondere Kategorien nach Artikel 9 DSGVO, und in diesem Umfeld ist ISO 27001 selten nur ein Vertriebsargument. Für einen Teil der Zielgruppe ist das Zertifikat sogar Zulassungsvoraussetzung. Wer die zwölf Schritte abarbeitet, sollte deshalb vorher wissen, welche Pflicht für ihn gilt, welche Vorschrift dahintersteht und welche Rolle die eigenen Dienstleister dabei spielen.
Zwei Teile. Der erste sind die Anforderungen der Kapitel 4 bis 10, also das Managementsystem: Kontext, Führung, Planung, Betrieb, Bewertung, Verbesserung. Der zweite ist der Annex A mit 93 Maßnahmen in vier Themen, 37 organisatorischen, 8 personenbezogenen, 14 physischen und 34 technologischen, aus denen risikobasiert ausgewählt wird.
Die Reihenfolge folgt Abhängigkeiten, und der erste Schritt ist hier besonders folgenreich. Der Geltungsbereich muss die Datenkategorien benennen, also Patienten-, Behandlungs- und Abrechnungsdaten, und die Schnittstellen zu Kliniken, Kassen und Dienstleistern erfassen. Alles, was später als Nachweis dienen soll, muss innerhalb dieses Zuschnitts liegen.
Für Hersteller digitaler Gesundheitsanwendungen. Wer eine DiGA in das Verzeichnis des BfArM bringen will, braucht seit dem 1. April 2022 ein zertifiziertes Informationssicherheits-Managementsystem nach ISO/IEC 27001 oder nach ISO 27001 auf Basis IT-Grundschutz. Die Anforderung kam mit der ersten Änderungsverordnung zur DiGAV und gilt für neue Hersteller genauso wie für bereits gelistete Anwendungen.
Dazu kommt seit dem 1. Januar 2025 eine zweite Hürde. Nach § 139e Absatz 10 SGB V müssen Hersteller die Erfüllung der Datensicherheitsanforderungen durch ein Zertifikat nach der Technischen Richtlinie des BSI nachweisen, für Pflegeanwendungen entsprechend über § 78a Absatz 7 SGB XI. Der Unterschied ist wichtig: Die ISO 27001 zertifiziert das Unternehmen und seine Prozesse, die Technische Richtlinie TR-03161 prüft das Produkt, also Architektur, Code, Kryptografie und Authentisierung. Beides ist nötig, und eines ersetzt das andere nicht.
Hier lohnt ein Blick auf die Paragraphennummern, weil sie sich geändert haben. Die IT-Sicherheitspflicht für die vertragsärztliche und vertragszahnärztliche Versorgung stand früher in § 75b SGB V. Diese Vorschrift ist aufgehoben. Seit dem Digital-Gesetz trägt sie die Nummer § 390 SGB V und gilt in dieser Fassung seit dem 26. März 2024. Sie verpflichtet nicht direkt einzelne Unternehmen, sondern gibt der Kassenärztlichen Bundesvereinigung auf, die Anforderungen in einer Richtlinie festzulegen, im Einvernehmen mit dem BSI und den Datenschutzaufsichtsbehörden. Für Krankenhäuser gilt die Parallelvorschrift § 391 SGB V.
Adressiert sind damit Leistungserbringer, nicht digitale Anbieter. Ein Health-Startup fällt also nicht selbst unter § 390, wird aber über seine Kunden mitgeregelt: Was die Richtlinie den Praxen vorgibt, landet anschließend im Sicherheitsfragebogen an den Anbieter. Wer mit einer Liste arbeitet, die noch § 75b zitiert, arbeitet mit einer veralteten Vorlage.
Weil hier neben dem Datenschutzrecht das Strafrecht mitläuft. Seit der Neuregelung von 2017 erfasst § 203 StGB ausdrücklich sonstige mitwirkende Personen, und dazu gehören externe Dienstleister, die IT-Anlagen bereitstellen, einrichten oder warten und dabei Zugang zu geschützten Geheimnissen erhalten. Diese Dienstleister können sich selbst strafbar machen, und der Berufsgeheimnisträger haftet, wenn er sie nicht sorgfältig auswählt, überwacht und zur Geheimhaltung verpflichtet.
Praktisch heißt das: Der Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO ist die eine Ebene, die Verpflichtung zur Geheimhaltung nach § 203 StGB die andere, und beide sind nachzuweisen. In der Liste steht das im Schritt zur Lieferantensteuerung, und es ist der Punkt, an dem Kliniken und Kassen in der Prüfung am genauesten hinsehen. Es reicht dabei nicht, die Verträge zu haben: Verlangt sind Auswahlkriterien, eine wiederkehrende Bewertung und der Nachweis, dass die Verpflichtung tatsächlich vorliegt.
Drei. Erstens die Pseudonymisierung. Sie ist eine wirksame Maßnahme und zu Recht in der Liste, aber sie ist keine Anonymisierung: Pseudonymisierte Daten bleiben personenbezogen, und die Pflichten aus der DSGVO bleiben bestehen. Wer das verwechselt, begründet Ausschlüsse in der Erklärung zur Anwendbarkeit auf falscher Grundlage.
Zweitens Testdaten. Echte Patientendaten in Entwicklungs- oder Testumgebungen sind der Klassiker unter den Feststellungen, und weil es um Artikel-9-Daten geht, ist das kein Formfehler. Verlangt ist entweder eine belastbare Begründung samt Schutzmaßnahmen oder die Umstellung auf synthetische Daten. Drittens der Zuschnitt des Zertifikats: Für eine DiGA-Listung muss der Geltungsbereich die Entwicklung und den Betrieb der Anwendung tatsächlich umfassen. Ein Zertifikat, das nur die Verwaltungs-IT abdeckt, ist formal gültig und für diesen Zweck trotzdem wertlos.
Die Checkliste richtet sich an Geschäftsführungen, CTOs sowie Datenschutz- und Sicherheitsverantwortliche in Gesundheits-Startups, DiGA-Herstellern und digitalen Versorgungsunternehmen. Laden Sie sie kostenfrei herunter.
Sprechen Sie mit unseren Expert:innen und erfahren Sie, wie das Digital Compliance Office Ihre Compliance automatisiert.
Gespräch vereinbaren