Wer eine DiGA entwickelt, merkt oft erst kurz vor der BfArM-Einreichung, wie teuer unklare Sicherheitsentscheidungen werden können. Die sieben DiGA Sicherheitsanforderungen sind keine Aufgabe für die letzte Projektphase. Sie beeinflussen Architektur, UX, Lieferantenauswahl, Entwicklungsprozess und späteren Betrieb von Anfang an.
Bei Gesundheitsanwendungen geht es nicht nur darum, ob eine App gut funktioniert. Sie verarbeitet besonders schützenswerte Gesundheitsdaten, begleitet Menschen häufig in belastenden Situationen und muss über ihren gesamten Lebenszyklus nachvollziehbar sicher betrieben werden. Ein schicker Prototyp und ein funktionierendes Backend reichen deshalb nicht aus. Gefragt sind belastbare Prozesse, technische Maßnahmen und Nachweise, die zusammenpassen.
Warum Sicherheit bei DiGA ein Systemthema ist
Die Anforderungen aus DiGAV und dem BfArM-Leitfaden zur DiGA-Fast-Track-Listung lassen sich nicht sinnvoll mit einer einzelnen Maßnahme abhaken. Ein Penetrationstest ist notwendig, ersetzt aber kein geregeltes Berechtigungsmodell. Verschlüsselung hilft, beantwortet aber nicht die Frage, wer im Ernstfall entscheidet, informiert und dokumentiert.
In der Praxis scheitern Vorhaben selten an einer fehlenden Verschlüsselungsbibliothek. Häufiger fehlen klare Verantwortlichkeiten, nachvollziehbare Datenflüsse oder ein Prozess für Sicherheitslücken in verwendeten Komponenten. Besonders kritisch wird es bei gewachsenen Lieferketten: mobile App, Cloud-Infrastruktur, Analysewerkzeug, Videodienst, Support-System und medizinische Schnittstellen. Jede zusätzliche Komponente schafft Abhängigkeiten, die technisch und vertraglich beherrscht werden müssen.
Datenschutz und Informationssicherheit greifen dabei ineinander, sind aber nicht dasselbe. Datenschutz fragt unter anderem, ob Daten rechtmäßig verarbeitet und auf das erforderliche Maß begrenzt werden. Informationssicherheit schützt Vertraulichkeit, Integrität und Verfügbarkeit dieser Daten und Systeme. Für eine listungsfähige DiGA müssen beide Seiten sauber zusammenspielen.
Die sieben DiGA-Sicherheitsanforderungen in der Praxis
1. Schutzbedarf und Datenflüsse konkret erfassen
Der erste Schritt klingt banal, entscheidet aber über die Qualität aller folgenden Maßnahmen: Welche Daten verarbeitet die DiGA, wo entstehen sie, wohin fließen sie und wer greift darauf zu? Neben Stammdaten können Symptomtagebücher, Fragebögen, Therapieverläufe, Nutzungsdaten und Kommunikationsinhalte dazugehören.
Eine einfache Datenflussgrafik ist dafür wertvoller als eine allgemeine Aussage wie „Wir hosten sicher in der Cloud“. Sie macht sichtbar, ob Daten etwa über Push-Dienste, Support-Tickets oder externe SDKs aus dem vorgesehenen Schutzbereich herausgelangen könnten. Auch Daten, die nicht dauerhaft gespeichert werden, müssen betrachtet werden. Entscheidend ist die tatsächliche Verarbeitung, nicht nur die Datenbank.
2. Informationssicherheit verbindlich organisieren
Sicherheit braucht Eigentümer. Es muss klar sein, wer Risiken bewertet, Freigaben erteilt, Vorfälle steuert und Maßnahmen nachhält. Ein Informationssicherheitsmanagementsystem muss für ein kleines DiGA-Team nicht unnötig bürokratisch sein. Es muss aber nachweisbar funktionieren.
Dazu gehören eine Sicherheitsleitlinie, definierte Rollen, regelmäßige Risikobewertungen und eine dokumentierte Behandlung offener Risiken. Die Geschäftsführung kann Verantwortung nicht vollständig an eine Entwicklungsagentur oder einen Cloud-Anbieter delegieren. Externe Partner übernehmen technische und operative Aufgaben, die Gesamtverantwortung für das Produkt und seine Steuerung bleibt beim DiGA-Hersteller.
3. Architektur, Zugriff und Verschlüsselung zusammendenken
Eine sichere Architektur trennt Funktionen, Daten und Berechtigungen so, dass ein einzelner Fehler nicht sofort das gesamte System offenlegt. Nutzerkonten, Fachadministration, Support und Entwicklung benötigen unterschiedliche Rechte. Das Prinzip lautet: nur so viel Zugriff wie für die jeweilige Aufgabe nötig.
Mehrfaktor-Authentifizierung ist insbesondere für administrative Zugänge ein naheliegender Standard. Zugangsdaten dürfen nicht in Quellcode, Tickets oder ungeschützten Tabellen landen. Daten müssen bei der Übertragung und Speicherung angemessen geschützt werden, während Schlüssel und Geheimnisse getrennt verwaltet werden.
Hier zeigt sich ein typischer Zielkonflikt: Ein schneller Supportzugriff kann im Einzelfall hilfreich sein, darf aber keine dauerhafte Hintertür schaffen. Besser sind zeitlich begrenzte, protokollierte Zugriffe mit einem nachvollziehbaren Freigabeprozess. Das kostet etwas mehr Vorbereitung und verhindert später Diskussionen über unklare Berechtigungen.
4. Sichere Entwicklung fest in den Ablauf einbauen
Sicherheit entsteht nicht erst vor dem Go-Live. Sie gehört in Tickets, Designs, Code-Reviews, Tests und Releases. Schon bei neuen Funktionen sollte das Team prüfen, welche Missbrauchsszenarien denkbar sind: Kann jemand fremde Therapiedaten sehen? Lässt sich eine Schnittstelle automatisiert missbrauchen? Werden Fehlermeldungen zu gesprächig?
Ein sinnvoller Secure-Development-Prozess umfasst sichere Codierstandards, Vier-Augen-Prinzip bei kritischen Änderungen, automatisierte Prüfungen und ein geregeltes Release-Verfahren. Auch Abhängigkeiten verdienen Aufmerksamkeit. Mobile Apps und Backends enthalten oft zahlreiche Open-Source-Komponenten. Ohne Inventar, Versionspflege und klare Verantwortlichkeit wird daraus schnell ein blinder Fleck.
Wichtig ist die Verhältnismäßigkeit. Nicht jede Änderung braucht denselben Prüfaufwand. Eine Anpassung an einem Text benötigt eine andere Freigabe als ein neues Authentifizierungsverfahren. Ein risikobasierter Prozess hält das Team handlungsfähig, ohne Sicherheitsprüfungen zur reinen Formalität zu machen.
5. Schwachstellen erkennen und sauber behandeln
Keine Software bleibt dauerhaft fehlerfrei. Relevant ist deshalb, wie professionell ein Hersteller mit Schwachstellen umgeht. Dazu gehören automatisierte Prüfungen, regelmäßige Sicherheitsbewertungen und unabhängige Penetrationstests mit passendem Umfang.
Ein Testbericht allein genügt nicht. Für gefundene Schwächen braucht es eine nachvollziehbare Bewertung, Priorisierung, Behebung und Wirksamkeitskontrolle. Kritische Lücken müssen zügig geschlossen werden. Bei weniger kritischen Punkten kann eine begründete Risikoakzeptanz möglich sein, sofern sie dokumentiert und verantwortet wird.
Besondere Aufmerksamkeit verdienen Bibliotheken, Betriebssysteme und Cloud-Dienste. Wenn ein Anbieter eine kritische Sicherheitslücke meldet, darf nicht erst geklärt werden müssen, ob die betroffene Version überhaupt eingesetzt wird. Ein gepflegtes Komponentenverzeichnis spart im Ernstfall wertvolle Zeit.
6. Verfügbarkeit und Wiederanlauf planen
Eine DiGA kann medizinisch sinnvoll sein und trotzdem für Nutzende unbrauchbar werden, wenn sie nach einem Ausfall tagelang nicht erreichbar ist. Verfügbarkeit ist daher mehr als ein Hosting-Versprechen. Benötigt werden Backups, Wiederherstellungstests, Überwachung und definierte Wiederanlaufziele.
Entscheidend ist nicht nur, ob ein Backup existiert, sondern ob es sich innerhalb einer vertretbaren Zeit vollständig wiederherstellen lässt. Das sollte regelmäßig getestet und dokumentiert werden. Auch Szenarien wie ein fehlgeschlagenes App-Update, ein Ausfall eines externen Dienstes oder eine fehlerhafte Datenmigration gehören in die Planung.
Nicht jede DiGA braucht eine hochkomplexe Multi-Region-Architektur. Der angemessene Aufwand hängt vom Versorgungskontext, den zugesagten Funktionen und dem Schadenspotenzial eines Ausfalls ab. Ein klarer Notfallplan ist jedoch immer günstiger als ein improvisierter Go-Live-Rollback mit Schweißperlen.
7. Vorfälle, Protokolle und Dienstleister beherrschen
Sicherheitsrelevante Ereignisse müssen erkennbar sein, ohne dass unnötig viele Gesundheitsdaten in Logdateien landen. Protokollierung braucht deshalb ein klares Konzept: Was wird erfasst, wie lange aufbewahrt, wer darf es einsehen und wie werden Auffälligkeiten bewertet?
Genauso wichtig ist ein Incident-Response-Prozess. Wer wird bei einem möglichen Vorfall informiert? Wie werden Systeme abgesichert, Beweise gesichert, Betroffene bewertet und Entscheidungen dokumentiert? Diese Fragen sollten nicht erstmals beantwortet werden, wenn ein verdächtiger Zugriff auffällt.
Dienstleister sind Teil dieses Prozesses. Cloud-Provider, Versanddienste, Monitoring-Tools und externe Entwicklungsteams benötigen klare Sicherheitsanforderungen, Ansprechpartner und geregelte Meldewege. Gerade bei internationalen Diensten lohnt ein kritischer Blick: Ist der Nutzen tatsächlich erforderlich, oder schafft das Tool nur eine weitere schwer kontrollierbare Datenverbindung?
Nachweise von Beginn an mitentwickeln
Für die BfArM-Listung zählt nicht nur die technische Umsetzung, sondern auch ihre Belegbarkeit. Ein Sicherheitskonzept, Risikoanalysen, Verfahrensanweisungen, Testprotokolle und Nachweise zur Behebung von Schwachstellen sollten deshalb nicht nachträglich aus verstreuten Tickets und Erinnerungen zusammengesucht werden.
Bewährt hat sich eine Anforderung-Evidenz-Matrix. Jede relevante Anforderung wird einer konkreten Umsetzung, einem Verantwortlichen und einem Nachweis zugeordnet. So wird früh sichtbar, ob eine Regel nur beschrieben oder tatsächlich gelebt wird. Gleichzeitig reduziert die Matrix Rückfragen im Projekt, weil Produkt, Entwicklung, Datenschutz und Betrieb auf dieselbe Arbeitsgrundlage schauen.
Inter Medien Networks begleitet DiGA-Vorhaben deshalb nicht nur bis zur funktionsfähigen App, sondern betrachtet Architektur, UX, Betrieb und Nachweisführung als zusammenhängende Aufgabe. Das schafft keine Abkürzung durch regulatorische Anforderungen, aber einen planbaren Weg durch sie.
Die beste Sicherheitsstrategie ist am Ende die, die auch sechs Monate nach der Listung noch funktioniert: mit gepflegten Verantwortlichkeiten, getesteten Abläufen und einem Team, das weiß, was im Ernstfall zu tun ist. Dann wird Sicherheit nicht zum Bremsklotz, sondern zur verlässlichen Grundlage für digitale Versorgung.