DiGA: ISO 27001 / IT-Grundschutz / Zertifikate einordnen

Die alte Frage „BSI 200-2 oder ISO 27001?“ ist seit der Einführung der DiGAs nach dem Digitale-Versorgung-Gesetz und der Digitalen Gesundheits-Anwendungen-Verordnung komplexer geworden.

Für DiGA-Hersteller geht es längst nicht mehr nur darum, ob ein ISMS eher nach ISO 27001 oder auf Basis von IT-Grundschutz aufgebaut wird. Heute zählen vor allem drei Dinge: ein belastbares ISMS, das passende Zertifikat dazu und zusätzlich der Nachweis der Datensicherheit über die aktuellen technischen Richtlinien.

Die kurze Antwort

Wer heute eine DiGA ins Verzeichnis bringen will, muss einige Hausaufgaben erledigen. Praktisch relevant sind aktuell diese Bausteine: ein ISMS-Zertifikat gemäß ISO 27001 oder ISO 27001 auf Basis von IT-Grundschutz, ein Datensicherheitszertifikat auf Basis der Technische Richtlinien BSI TR-03161 und anlassbezogen wiederholte Sicherheitstests, wenn sich die Angriffsfläche relevant ändert. Diese mittlerweile recht hohen regulatorischen Hürden sind nicht ohne.

1. Das ISMS ist längst keine Option mehr

Für DiGA-Hersteller ist ein zertifiziertes ISMS seit dem 01.04.2022 fester Bestandteil der Anforderungen. Akzeptiert werden dabei zwei Wege: entweder ein ISMS gemäß ISO 27001 oder ein ISMS gemäß ISO 27001 auf Basis von IT-Grundschutz nach BSI-Standard 200-2. Diese Entscheidung ist ein formaler Nachweis, der im Verfahren erwartet wird.

2. Seit 2025 reicht das ISMS-Zertifikat allein nicht mehr

Seit dem 01.01.2025 muss zusätzlich die Erfüllung der Anforderungen an die Datensicherheit durch ein Zertifikat nachgewiesen werden. Für bereits gelistete DiGA galt dieser Stichtag ebenfalls. Für neue und laufende Antragsverfahren ist das Zertifikat inzwischen der maßgebliche Nachweis, um in das Verzeichnis aufgenommen zu werden. Die frühere Übergangslogik bis 30.06.2025 ist damit für neue Artikel nur noch historisch interessant.

3. Die technische Messlatte läuft über die TR 03161-Familie

Für den Datensicherheitsnachweis sind die technischen Richtlinien der TR 03161-Familie der relevante Rahmen. Diese Familie richtet sich an Hersteller von Anwendungen im Gesundheitswesen und umfasst Anforderungen für mobile Anwendungen, Web-Anwendungen und Hintergrundsysteme. Genau damit ist auch klar: Das Thema ist deutlich breiter als nur „App absichern“. Es geht um die gesamte technische Lösung.

4. Penetrationstests sind kein Einmaltermin

Für DiGA endet das Thema nicht mit einem einmaligen Test vor Antragstellung. Sicherheitstests sind anlassbezogen zu wiederholen, etwa wenn neue Schnittstellen ins Internet hinzukommen oder wenn für externe Verbindungen relevante Bibliotheken aktualisiert werden. Das ist ein wichtiger Punkt, weil genau hier viele Hersteller noch zu sehr in der Logik „einmal prüfen, dann abhaken“ denken.

5. Die alte Entweder-oder-Frage ist heute zu klein

Die eigentliche Frage lautet nicht mehr: „Ist ISO 27001 besser als BSI 200-2?“ Die bessere Frage ist: „Welcher ISMS-Weg passt zu uns, wenn wir am Ende ohnehin zusätzlich den Datensicherheitsnachweis und die technischen Prüfungen sauber erbringen müssen?“ Denn selbst wenn Sie sich für den pragmatischeren Weg entscheiden, verschwindet der zusätzliche regulatorische Aufbau darüber nicht.

Wann ISO 27001 meist der pragmatischere Weg ist

Für viele DiGA-Hersteller ist ISO 27001 weiterhin der pragmatischere Ausgangspunkt. Nicht, weil IT-Grundschutz „falsch“ wäre, sondern weil ISO 27001 oft besser zu kleineren, internationalen oder stark produktorientierten Organisationen passt und sich meist leichter mit bestehenden Qualitätsmanagementsystemen zusammen denken lässt. Der zulässige regulatorische Rahmen bleibt dabei trotzdem derselbe: Das BfArM akzeptiert beide Wege, solange das geforderte Zertifikat sauber vorliegt.

Wann der Grundschutz-Weg sinnvoll sein kann

Wenn ein Hersteller ohnehin schon tief in Grundschutz-Logik arbeitet, sehr stark in behördlichen oder stark regulierten Kontexten unterwegs ist oder intern bereits mit Grundschutz-Kompendium und entsprechender Methodik vertraut ist, kann ISO 27001 auf Basis von IT-Grundschutz trotzdem sinnvoll sein. Der Punkt ist also nicht, dass der eine Weg „richtig“ und der andere „falsch“ wäre. Der Punkt ist, dass die Entscheidung heute nur einen Teil des Gesamtbilds betrifft.

Was Hersteller praktisch wirklich bauen müssen

In der Praxis braucht ein DiGA-Hersteller heute keinen Normenaufsatz, sondern eine belastbare Nachweisarchitektur. Dazu gehören ein sauber abgegrenzter Scope, klare technische und organisatorische Verantwortlichkeiten, dokumentierte Sicherheitsentscheidungen, eine nachvollziehbare Entwicklungs- und Änderungslogik, wirksame Schwachstellen- und Vorfallprozesse sowie ein belastbarer Umgang mit ausgelagerten Leistungen und Schnittstellen. Das ist keine Zusatzästhetik, sondern die Grundlage dafür, dass ISMS-Zertifikat, Datensicherheitszertifikat und Prüfungen am Ende zusammenpassen. Diese Schlussfolgerung ergibt sich aus der Kombination der formalen Nachweise und technischen Richtlinien.

Was heute gern unterschätzt wird

Zwei Punkte werden besonders oft unterschätzt.

Erstens: Der Aufwand sitzt nicht nur in der Zertifizierung, sondern in der konsistenten technischen Umsetzung über App, Web, Backend und externe Anbindungen hinweg.

Zweitens: Viele Hersteller denken bei Datensicherheit nur an „das BSI-Thema“. Datenschutzanforderungen bleiben jedoch ein eigener Prüfstrang. Hersteller müssen deshalb die aktuellen Vorgaben und Nachweise getrennt im Blick behalten.

Was die drei Nachweisstränge voneinander unterscheidet

Beim Wort Zertifikat wird schnell alles in einen Topf geworfen. Für eine DiGA müssen Sie aber drei Ebenen auseinanderhalten. Das ISMS beschreibt, wie der Hersteller Informationssicherheit organisiert: Wer entscheidet über Risiken? Wie werden Änderungen gesteuert? Wie laufen Vorfälle, Lieferantenkontrolle, interne Prüfungen und Verbesserungen? Die ISO 27001 bewertet damit nicht bloß eine App, sondern das Managementsystem des festgelegten Anwendungsbereichs.

Daneben steht der technische Datensicherheitsnachweis. § 139e Absatz 10 SGB V verlangt, dass das BSI Anforderungen an die Datensicherheit festlegt und ein Zertifizierungsverfahren anbietet. Seit dem 1. Januar 2025 ist der Nachweis unter Vorlage eines entsprechenden Zertifikats zu führen. Das steht direkt im Sozialgesetzbuch V und wird in § 7 DiGAV aufgegriffen.

Penetrationstests und andere technische Prüfungen bilden schließlich keinen Ersatz für diese beiden Ebenen. Sie liefern konkrete Aussagen über die untersuchte Version, ihre Komponenten und erreichbaren Angriffspfade. Ein ISMS kann hervorragend organisiert sein und trotzdem eine technische Schwachstelle übersehen. Umgekehrt kann eine App einen guten Pentest bestehen, obwohl der Hersteller Sicherheitsmeldungen, Änderungen oder Lieferanten völlig improvisiert steuert.

Der Scope entscheidet, was das ISMS-Zertifikat wirklich aussagt

Ein Zertifikat hilft nur, wenn der Anwendungsbereich zur tatsächlichen Leistung passt. App, Weboberfläche, Backend, Entwicklungsumgebung, Betrieb, Support und sicherheitsrelevante Dienstleister müssen deshalb gemeinsam betrachtet werden. Wer das ISMS auf eine hübsch klingende Organisationsinsel beschränkt, während Entwicklung und Betrieb daneben stattfinden, hat zwar einen Scope – aber möglicherweise nicht den richtigen.

Gerade Hersteller mit vielen Cloud- und Entwicklungsdienstleistern sollten ihre Lieferantenvereinbarungen und die laufende Überwachung ihrer Anbieter ernst nehmen. Die Verantwortung verschwindet nicht dadurch, dass Backend, Monitoring oder Support eingekauft werden. Der technische Nachweis und das ISMS müssen an denselben realen Abhängigkeiten ansetzen.

Ein sauber formulierter ISO 27001-Scope nennt deshalb nicht nur einen Produktnamen. Produktnamen ändern sich, Leistungen und Tätigkeiten sind beständiger. Sinnvoller ist eine Formulierung, die Entwicklung, Bereitstellung und Betrieb der betreffenden digitalen Gesundheitsanwendung beschreibt und die relevanten Standorte sowie organisatorischen Grenzen berücksichtigt.

Änderungen sind bei einer DiGA nie nur ein Release-Thema

Eine neue Bibliothek, eine zusätzliche Schnittstelle oder ein anderer Hostinganbieter kann mehrere Nachweise gleichzeitig berühren. Der technische Test muss möglicherweise wiederholt werden. Im ISMS sind Risiken, Lieferanten, technische Dokumentation und Freigaben anzupassen. Bei wesentlichen Veränderungen kann außerdem das regulatorische Verfahren betroffen sein.

Darum braucht ein DiGA-Hersteller ein belastbares Änderungsmanagement für das ISMS. Vor einer Änderung sollte geklärt sein:

• Welche Komponenten und Datenflüsse ändern sich?
• Entstehen neue Angriffsflächen oder externe Abhängigkeiten?
• Welche Risikoanalyse und welche Tests müssen aktualisiert werden?
• Berührt die Änderung vorhandene Zertifikate oder deren Geltungsbereich?
• Wer entscheidet über Freigabe, Nachprüfung und Kommunikation?

Das ist nicht dasselbe wie ein Releaseprozess mit fünfzig manuellen Einzelschritten. Gute technische Automatisierung kann viel Arbeit abnehmen. Die Entscheidung, welche Sicherheitsfolgen eine Änderung hat, bleibt trotzdem eine fachliche Aufgabe.

Eine praktische Reihenfolge für Hersteller

Wer am Anfang steht, sollte nicht drei voneinander getrennte Zertifizierungsprojekte starten. Sinnvoller ist ein gemeinsames Arbeitsmodell:

1. Grenzen Sie Produkt, Tätigkeiten, Systeme, Daten und Dienstleister vollständig ab.
2. Bauen Sie ein handhabbares ISMS mit Verantwortlichkeiten und Risikomanagement auf.
3. Mappen Sie die Anforderungen der TR-03161-Familie auf Architektur und Entwicklung.
4. Planen Sie technische Prüfungen früh genug in Releases und Budget ein.
5. Halten Sie Abweichungen, Risiken und Nacharbeiten in einem gemeinsamen Maßnahmenprozess zusammen.
6. Prüfen Sie vor Änderungen, welche Nachweise erneut betroffen sind.

Das verhindert den Klassiker, dass kurz vor Antragstellung drei Projektordner nebeneinanderliegen, deren Inhalte sich gegenseitig widersprechen. Ein Risikomanagement, eine belastbare Asset-Sicht und ein gemeinsamer Änderungsprozess sind wesentlich nützlicher als drei kunstvoll getrennte Dokumentationswelten.

Was Sie von Prüfstellen früh klären sollten

Auch bei sauberer fachlicher Vorbereitung können Zertifizierungswege an organisatorischen Missverständnissen hängen. Klären Sie deshalb früh, welche Stelle welchen Nachweis erbringt, welche Version der Richtlinie zugrunde liegt und welche Komponenten tatsächlich untersucht werden. Mobile App, Webanwendung und Hintergrundsystem können unterschiedliche Prüfungsteile berühren. Eine allgemeine Zusage „Wir können Gesundheitsanwendungen prüfen“ ist noch keine belastbare Leistungsbeschreibung.

Fragen Sie mindestens nach:

• dem konkreten Zertifizierungsprogramm und der zugrunde liegenden TR-Version;
• dem erwarteten Prüfgegenstand einschließlich Backend und externer Komponenten;
• benötigten Unterlagen, Testzugängen und technischen Ansprechpartnern;
• typischen Vorlaufzeiten und dem Umgang mit Nacharbeit;
• der Behandlung von Änderungen während des laufenden Verfahrens;
• der Gültigkeit, Pflege und erneuten Prüfung des Nachweises.

Dasselbe gilt für das ISMS-Zertifikat. Der Geltungsbereich auf der Urkunde muss zur Organisation passen, die die DiGA entwickelt und betreibt. Ein Zertifikat einer Konzernmutter hilft nicht automatisch einer anderen juristischen Person, nur weil beide dasselbe Logo verwenden.

Welche Nachweise im Alltag zusammengehören

In der Praxis lohnt sich ein gemeinsamer Nachweisindex. Er verbindet eine Anforderung mit zuständiger Rolle, Vorgabe, technischer Umsetzung und Beleg. Für eine Schnittstelle könnten das Architekturentscheidung, Risiko, Authentisierungskonzept, Testbericht, Freigabeticket und Monitoringnachweis sein. Für einen Dienstleister gehören Vertrag, Sicherheitsanforderungen, Bewertung und laufende Überwachung zusammen.

So wird bei einer Änderung sichtbar, welche Nachweise betroffen sind. Gleichzeitig müssen Entwickler, ISB und Prüfstellen nicht in drei Ablagen nach unterschiedlichen Versionen suchen. Gerade bei komplexen Lösungen ist Auffindbarkeit kein Nebenthema: Was niemand zuverlässig findet, lässt sich weder prüfen noch sauber aktualisieren.

Der schnelle Konsistenzcheck vor einem Meilenstein

Vor Antrag, Prüfung oder größerem Release sollten Sie dieselbe Änderung aus drei Blickwinkeln betrachten. Passt sie noch zum Scope und Risikomanagement des ISMS? Ist die technische Architektur samt Datenflüssen und Abhängigkeiten aktuell beschrieben? Sind die für Zertifikat und regulatorisches Verfahren benötigten Nachweise weiterhin gültig?

Nehmen Sie dafür einige Stichproben: Stimmen Assetverzeichnis und Architektur überein? Sind externe Dienste in Lieferantenbewertung und technischen Unterlagen enthalten? Wurden Schwachstellen aus Tests tatsächlich geschlossen? Kennt der Support den Vorfallweg? Lässt sich die freigegebene Version eindeutig dem Prüfgegenstand zuordnen?

Dieser kurze Abgleich verhindert erstaunlich viel Kokolores. Häufig sind die einzelnen Dokumente nämlich nicht falsch. Sie erzählen nur nicht mehr dieselbe Geschichte.

Benennen Sie für diesen Check einen Verantwortlichen, der fachliche und technische Beteiligte zusammenholt. Das muss kein neues Gremium sein. Ein kurzer Freigabetermin mit vorbereiteter Änderungsliste reicht häufig aus. Wichtig ist, dass offene Widersprüche nicht mit dem Satz „Das klären wir dann in der Prüfung“ in die nächste Phase geschoben werden. In der Prüfung werden sie selten billiger.

Halten Sie die Entscheidung anschließend dort fest, wo auch spätere Änderungen ansetzen. Ein Freigabeprotokoll ohne Verbindung zu Release, Risiko und Prüfgegenstand ist schnell vergessen. Eine verlinkte Entscheidung hilft dagegen beim nächsten Update unmittelbar weiter.

So bleibt der Nachweis nicht nur für die aktuelle Prüfung brauchbar, sondern auch für Entwickler, Betrieb und die nächste Person, die eine Änderung sicher bewerten muss.

Interesse geweckt?

Wenn Sie das ISMS, den technischen Datensicherheitsnachweis und Ihre Entwicklungsprozesse so aufeinander abstimmen wollen, dass daraus kein dreifaches Parallelprojekt wird, Sprechen Sie mit uns.

Dieser Artikel ordnet technische und regulatorische Anforderungen unverbindlich ein und ersetzt keine Rechtsberatung. Vorschriften, Leitfäden und Zertifizierungsprogramme können sich ändern; prüfen Sie für konkrete Entscheidungen bitte den aktuellen Stand bei BfArM und BSI.