BfArM-Datenschutzprüfkriterien – der Praxis-Deep-Dive

Von Thomas Wolters · CTO, DUX Healthcare · Stand 17. April 2026

Die BfArM-Datenschutzprüfkriterien sind das Instrument, mit dem das Bundesinstitut für Arzneimittel und Medizinprodukte die DSGVO für Digitale Gesundheitsanwendungen operationalisiert. Seit dem 1. August 2024 sind DiGA-Hersteller nach DiGAV § 4 Abs. 8↗ verpflichtet, den vom BfArM nach § 139e Abs. 11 SGB V↗ festgelegten Katalog umzusetzen. Die aktuelle Version 1.0 ist am 24. April 2024 publiziert worden und enthält rund 150 testbare Einzelanforderungen in zwölf Prüfbereichen. Anders als die DSGVO-Generalklauseln und anders als die rein cybersecurity-orientierte BSI TR-03161 sind die BfArM-Kriterien explizit auf die DiGA-spezifische Situation zugeschnitten: pseudonyme Nutzung, zweckgebundene Verarbeitung nach § 4 Abs. 2 DiGAV, enge Drittland-Regeln, getrennte Einwilligungen, elektronische Widerrufswege, Grace-Periode nach Verordnungsende. Dieser Artikel läuft den Katalog im Detail durch – mit verbatim zitierten Requirement-IDs, aus Engineering-Sicht, für Teams, die nicht die Checkbox suchen, sondern die architektonische Entscheidung.

Was die BfArM-Datenschutzprüfkriterien sind – und wie sie sich von DSGVO, Anlage 1 DiGAV und BSI TR-03161 abgrenzen

Die wichtigste Voraussetzung für die Arbeit mit den Prüfkriterien ist, die drei Instrumente nicht zu verwechseln, die parallel nebeneinander stehen.

Die DSGVO (Verordnung (EU) 2016/679) ist die europäische Grundlage. Sie definiert die Schutzziele – Rechtmäßigkeit, Treu und Glauben, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität, Vertraulichkeit, Rechenschaftspflicht – und sie ist auf jede Verarbeitung personenbezogener Daten anwendbar, auch auf die in einer DiGA. Die DSGVO ist aber in vielen ihrer Vorgaben abstrakt formuliert; sie sagt dass ein angemessenes Schutzniveau einzuhalten ist, selten wie im konkreten DiGA-Kontext.

Die BfArM-Datenschutzprüfkriterien füllen genau diese Lücke. Sie operationalisieren die DSGVO – plus die einschlägigen DiGAV-Vorgaben, plus das BDSG, plus Stellungnahmen der Datenschutzkonferenz (DSK) – in rund 150 testbare Einzelanforderungen. Rechtsgrundlage ist § 139e Abs. 11 SGB V↗ in Verbindung mit DiGAV § 4 Abs. 8. Das Instrument ist ein Kriterien-Katalog zur Zertifizierung: Die Anforderungen sind in RFC-2119-Grammatik formuliert (MUSS / DARF NICHT / SOLL / KANN), und eine unabhängige Zertifizierungsstelle prüft die Umsetzung gegen sie. Anders als die DSGVO-Generalklauseln sind sie konkret genug, um im Audit testbar zu sein.

Anlage 1 der DiGAV ist die formale Brücke zwischen den Prüfkriterien und dem BfArM-Antrag. Der Hersteller reicht die Erklärung nach DiGAV Anlage 1↗ mit seinem Antrag ein – ein Fragebogen, der auf die Prüfkriterien referenziert und den Herstellenden zwingt, jede Anforderung mit einem Nachweis zu unterlegen. Der Fragebogen ersetzt den Katalog nicht; er zeigt nur, dass und wie er umgesetzt ist.

BSI TR-03161 ist ein völlig anderes Instrument. Die Technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik zertifiziert die Cybersicherheit einer DiGA – Architektur, Kryptografie, Authentifizierung, Netzwerkschutz, Third-Party-Komponenten, Backend-Sicherheit. Rechtsgrundlage ist § 139e Abs. 10 SGB V↗, pflichtig seit 01.01.2025 / antragsrelevant seit 01.07.2025. Die beiden Instrumente überschneiden sich an einigen Stellen – Verschlüsselung, Authentifizierung, Datenspeicherung – aber das Subjekt der Prüfung ist jeweils ein anderes: Die BfArM-Kriterien prüfen Datenschutz, die BSI TR-03161 prüft Datensicherheit. Beide Zertifikate sind Voraussetzung für einen vollständigen Antrag; ein separater Deep-Dive zur BSI TR-03161 behandelt deren eigene Systematik.

Die zwölf Prüfbereiche im Überblick

Der Katalog gliedert sich in drei Teile und zwölf Kapitel. Die Kapitel 2 bis 13 enthalten die Kriterien; Kapitel 1 ist das Glossar (GLSR_1 und GLSR_2), Kapitel 14 die Anlagen. Die zwölf Prüfbereiche und ihre Requirement-ID-Präfixe:

Innerhalb jedes Kapitels gliedert sich die Struktur identisch: regulatorische Grundlagen, Gegenstandsbereich, Kriterien, allgemeine und spezifische Erläuterungen. Die Kriterien selbst sind nummerisch mit Präfix-ID (z. B. DMN_4.2), haben oft mehrere Buchstaben-Sub-Anforderungen (a, b, c, …) und verweisen quer durch den Katalog aufeinander – DMN_4 verweist auf TOM_2.1, ACC_2 verweist auf DMN_2, DSFA_1.8 verweist auf TOM_1.3 und DMN_1.2. Wer den Katalog linear abarbeitet, findet die Verknüpfungen nicht; wer ihn als Graph liest, erkennt die Architektur.

Grundlegende Sprachregeln – RFC-2119 und der Unterschied zwischen “dokumentiert” und “etabliert”

Vor dem inhaltlichen Einstieg lohnen sich zwei Definitionen aus dem Glossar, weil sie den Rest des Katalogs tragen.

GLSR_1 legt die Schlüsselwörter fest. GLSR_1.1: “Das Schlüsselwort ‘MUSS’ entspricht dem Schlüsselwort ‘MUST’ gemäß [RFC 2119] und zeichnet eine Anforderung als verpflichtend umzusetzen aus. Die Verpflichtung ist normativ, d. h. eine Nicht-Erfüllung kommt einer Nicht-Erfüllung des Kriteriums gleich.” GLSR_1.2 belegt “DARF NICHT / DARF KEIN” analog mit MUST NOT, GLSR_1.3 deckt “SOLL / SHOULD” (Abweichung nur mit nachvollziehbarer Begründung), GLSR_1.4 “KANN / MAY”. Das Resultat: Eine einzige MUSS-Anforderung, die nicht erfüllt ist, lässt das Kriterium scheitern. Die Zertifizierung kennt keine Teilnote.

GLSR_2.4 ist der Satz, der Teams am häufigsten unterschätzen: “Die Etablierung einer technisch-organisatorischen Maßnahme oder eines Prozesses umfasst alle Schritte der Verankerung in der gelebten Praxis. Hierzu zählen z. B. Konzeption, Dokumentation, Einführung, Anwendung und kontinuierlichen Verbesserung.” Viele Kriterien enden mit der Formulierung “MUSS … etabliert haben” – nicht “dokumentiert haben”. Der Zertifizierer prüft entsprechend nicht nur, ob ein Dokument existiert, sondern ob der Prozess gelebt wird. Für ACC_3.4 (Protokoll-Qualitätsprüfung), CTRL_2.2 (Release-Prozess mit Datenschutz-Gate) oder DSFA_1.8 (mindestens jährliche Neubewertung) bedeutet das: Nachweise aus dem Betrieb – Ticket-Historie, Freigabeprotokolle, Review-Kalendar – sind zu erbringen.

Die dritte tragende Definition ist GLSR_2.3 (Hersteller im medizinprodukterechtlichen Sinn) gegen GLSR_2.10 (Verantwortlicher nach Art. 4 Nr. 7 DSGVO↗). Der Katalog verwendet beide Begriffe strikt getrennt: “Hersteller” dort, wo die Anforderung aus DiGAV/DiPAV abgeleitet ist (GLSR_2.3), “Verantwortlicher” dort, wo sie aus der DSGVO stammt. Im Regelfall ist beides dieselbe Rechtsperson – aber die Sub-Anforderungen adressieren unterschiedliche Rollenbilder und müssen sauber zugeordnet werden.

Organisatorische Kriterien – was Teams häufig unterschätzen

Der Katalog ist zu etwa einem Drittel organisatorisch. Die schärfsten Stolperstellen hier sind nicht die offensichtlich technischen Anforderungen, sondern die prozessualen.

CTRL_1 – Interne Organisation

CTRL_1.1 – Verschwiegenheitsverpflichtung. Der Verantwortliche MUSS alle Personen, die aus ihrer Tätigkeit heraus Zugang zu personenbezogenen Daten haben, auf die Verschwiegenheit verpflichten. Das betrifft Entwickler, Ops, Support, QA, Management – jeden mit Zugang zu Produktionsdaten. Eine einmal unterschriebene Vertraulichkeitserklärung beim Onboarding reicht; aber sie muss dokumentiert und personenbezogen nachweisbar sein. Für DiGA leitet sich diese Anforderung laut spezifischer Erläuterung unmittelbar aus § 4 Abs. 5 DiGAV ab.

CTRL_1.2 – Datenschutzbeauftragter. Der Verantwortliche MUSS einen Datenschutzbeauftragten ernennen. Mit vier Sub-Anforderungen:

• CTRL_1.2 a: fachliche Eignung belegen, Fortbildungsmöglichkeiten geben, deren Wahrnehmung kontrollieren;
• CTRL_1.2 b: der DSB darf keine Entwicklungs- oder Betriebsaufgaben wahrnehmen, die zu einem Interessenkonflikt führen. Ein Lead-Entwickler als DSB ist regelmäßig unzulässig;
• CTRL_1.2 c: Zugang zu allen Verarbeitungsvorgängen und Dokumentationen; proaktives Vorschlags- und Mahnrecht; jede Ablehnung muss begründet und dokumentiert werden;
• CTRL_1.2 d: angemessene Ressourcen – bei internen DSB eine entsprechende Arbeitszeit-Freistellung.

CTRL_1.4 ist der Punkt, an dem internationale Teams stolpern: “Soweit es sich um einen nicht in der Europäischen Union niedergelassenen Verantwortlichen handelt, MÜSSEN die Vorgaben des Art. 27 DSGVO↗ eingehalten werden. Der schriftlich durch den Verantwortlichen benannte Vertreter MUSS in Deutschland niedergelassen sein.” Der EU-Repräsentant in Deutschland – nicht irgendwo in der EU – ist eine DiGA-spezifische Verschärfung gegenüber Art. 27 Abs. 3 DSGVO (der EU-weite Niederlassung erlaubt), die außerhalb Deutschlands fast nie mitgedacht wird.

CTRL_2 – Privacy by Design im Release-Prozess

CTRL_2.1 verlangt einen etablierten Risiko-Erfassungs- und Überwachungsprozess, in den Rest-Risiken der DSFA übergehen. CTRL_2.2 definiert den Datenschutz-Gate im Release-Prozess:

• CTRL_2.2 a: Leistungsmerkmale werden einem Release erst nach Risikoabschätzung zugeordnet.
• CTRL_2.2 b: Alle für ein neues Leistungsmerkmal erforderlichen TOMs müssen vor oder mit dem Release aktiv werden.
• CTRL_2.2 c: Kein Release darf produktiv gehen, wenn nach DSFA und Risiko-Minderung ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen verbleibt.

Das ist die Anforderung, an der viele DiGA-Releases prozessual kippen. In der agilen Realität werden Features geschnürt, und die Datenschutz-Prüfung läuft parallel zum Release – aber CTRL_2.2 verlangt, dass die Prüfung vor der Zuordnung zum Release steht. Die spezifische Erläuterung zu CTRL_2.2 und CTRL_2.3 geht sogar noch weiter: “Jedes Release der digitalen Anwendung muss im Rahmen der Überwachung an die Zertifizierungsstelle gemeldet werden.” Bei agiler Entwicklung wird die Zertifizierungsstelle in die Product-Backlog- und Sprint-Planung-Prozesse einbezogen. Wer mit einer Zertifizierungsstelle arbeitet, die agile Kadenz kennt, hat hier einen massiven Vorteil; wer ein klassisches Waterfall-Audit erwartet, baut den Prozess dreimal um.

CTRL_2.3 dehnt die Anforderung auf Hotfixes aus: Auch kurzfristige Änderungen dürfen bestehende TOMs nicht schwächen.

CTRL_3 – Datenschutzverletzungen unter Pseudonymität

Der Katalog kennt den speziellen Fall einer DiGA, die ihre Nutzerinnen und Nutzer pseudonym führt – und daher im Fall einer Datenschutzverletzung keinen Kommunikationskanal außerhalb der App hat. CTRL_3.1 verlangt den üblichen 72-Stunden-Meldeprozess nach Art. 33 DSGVO↗, aber CTRL_3.2 adressiert die DiGA-Besonderheit:

• Der Verantwortliche MUSS auch bei ausschließlicher Verarbeitung pseudonymer Daten die gegebenen Möglichkeiten der digitalen Anwendung ausschöpfen, um die betroffene Person zu informieren.
• CTRL_3.2 c: technisch-organisatorische Maßnahmen, mit denen eine Änderung von Anmeldedaten erzwungen werden kann.

In der Praxis bedeutet das: Die DiGA braucht ein In-App-Notification-System plus einen Forced-Re-Auth-Flow. Das ist eine Architektur-Entscheidung, die am Start eines Projekts fällt – sie lässt sich nicht drei Wochen vor Einreichung nachziehen.

Technische Kriterien – Zero-Trust-Default statt Checkbox

Der Block TOM (Kapitel 13) und die verwandten Technik-Kriterien sind die Stellen, an denen die Datenschutzkriterien in Infrastruktur umschlagen.

TOM_2 – Integrität und Vertraulichkeit

TOM_2.1 codifiziert die Pseudonymität als Architektur-Default:

• “Im Rahmen der Verordnung oder Bewilligung einer digitalen Anwendung erhalten der Hersteller und der Verantwortliche keine identifizierenden Daten der betroffenen Person. Diese initial gegebene pseudonyme Nutzung DARF grundsätzlich NICHT durchbrochen werden.”
• TOM_2.1 a: Wenn die Verarbeitung identifizierender Daten für den bestimmungsgemäßen Gebrauch erforderlich ist, müssen TOMs eine nicht legitimierte Identifizierung ausschließen.
• TOM_2.1 b: Keine Speicherung von über Plattform/Vertrieb eingebrachten identifizierenden Daten für andere als Sicherheitszwecke.
• TOM_2.1 c: Datenexport zur Portabilität/Interoperabilität grundsätzlich pseudonym – außer wo regulatorisch zwingend (z. B. ePA-Einspielung mit KVNR).

TOM_2.2 verlangt das Kryptografiekonzept. Sämtliche Kommunikation zwischen Komponenten (a), Speicherung auf dem Endgerät (b), Speicherung auf Hintergrundsystemen (c) MUSS verschlüsselt erfolgen. Authentifizierungs-Tokens MÜSSEN digital signiert sein, deren Integrität und Authentizität prüft die Anwendung (d). Backend-Dienste authentisieren sich gegeneinander (e). Zertifikate und Schlüssel MÜSSEN dem Stand der Technik entsprechen (f) – konkret referenziert die spezifische Erläuterung BSI TR-02102-1.

TOM_2.3 verlangt ein dokumentiertes Berechtigungskonzept plus eine Anti-Brute-Force-Strategie für Authentifizierungsversuche.

TOM_3 – Interaktion und Integration

Der TOM_3-Block ist aus Engineering-Perspektive der interessanteste, weil er mehrere produktseitige Gewohnheiten bricht.

TOM_3.1 – Push-Mitteilungen:

• TOM_3.1 a: “Push-Mitteilungen DÜRFEN KEINE Gesundheitsdaten enthalten.”
• TOM_3.1 b: Grundsätzlich keine Push für nicht-bestimmungsgemäße Zwecke.
• TOM_3.1 c: Aufklärung über die damit verbundene Datenverarbeitung.
• TOM_3.1 d: “Push-Mitteilungen MÜSSEN initial deaktiviert sein. Sie MÜSSEN ausschließlich über eine informierte Einwilligung … aktiviert werden können, die durch eine explizite, aktive Handlung bestätigt werden MUSS.”

Das iOS-/Android-typische “Wir würden gern Benachrichtigungen schicken” beim ersten App-Start ist nicht ausreichend; die Aufklärung muss inhaltlich darauf eingehen, was zu welchen Zwecken übertragen wird. Der Cloud-Push-Dienst (APNs/FCM) wird dabei meist zum Auftragsverarbeitungs-Thema – siehe AV_1.4.

TOM_3.3 – Kamera, Mikrofon, Ortungsdienste: Die digitale Anwendung DARF Kamera, Mikrofon und/oder Ortungsdienste NICHT nutzen, sofern dies nicht zu Zwecken des bestimmungsgemäßen Gebrauchs erforderlich ist. TOM_3.3 a verlangt Erforderlichkeits-Nachweis, TOM_3.3 b “initial deaktiviert, aktive Einwilligung” analog zu Push.

TOM_3.4 – Vertrauensdomäne: Nutzerinnen sollen sich nach der Authentifizierung ausschließlich innerhalb der Vertrauensdomäne der DiGA bewegen. Weiterleitungen zu Drittinhalten müssen vorab regelmäßig überprüft werden (TOM_3.4 a), das Verlassen der Domäne muss erkennbar sein (TOM_3.4 b), und vor der Weiterleitung MUSS informiert werden (TOM_3.4 c). Für Teams, die Drittangebote einbinden (Wissensdatenbanken, Video-Provider, Chatbot-Plattformen), ist das ein ausdrücklicher Audit-Prozess – nicht eine einmalige Freigabe.

TOM_5 – Privacy by Default

TOM_5.1 ist die zentrale Default-Vorgabe: “Sofern von der betroffenen Person beeinflussbare Systemeinstellungen der digitalen Anwendung Einfluss auf die Umsetzung der Grundprinzipien des Datenschutzes, den Umfang der verarbeiteten personenbezogenen Daten oder die Wahrnehmung von Betroffenenrechten haben, MUSS in der digitalen Anwendung die datenschutzfreundlichste Systemeinstellung voreingestellt sein.” Und sehr explizit: TOM_5.1 c: keine “Dark Patterns”, die suggerieren, eine datenschutzfreundlichere Einstellung sei nicht der Default.

TOM_5.2: “Die digitale Anwendung MUSS durchgängig das Prinzip von ‘Fail-Safe Defaults’ verfolgen, d. h. jeder nicht explizit autorisierte Zugriffsversuch MUSS abgewiesen werden.” Das ist die Zero-Trust-Prämisse in einem Satz.

TOM_6 – Ausnahmesituationen

TOM_6.1 verlangt ein Backup-Konzept, das explizit das Szenario Ransomware-Befall adressiert (TOM_6.1 a). Die spezifische Erläuterung verweist auf das BSI-Arbeitspapier “Maßnahmenkatalog Ransomware”. TOM_6.2 verlangt einen Selbst-Bediener-Sperrmechanismus: Bei Verlust/Diebstahl des Endgeräts oder vermuteter Kompromittierung der Zugangsdaten muss die betroffene Person die Sperrung ihrer Daten gegenüber externen Zugriffen selbst auslösen können.

Daten-Minimierung in der Praxis – DMN_1, DMN_3 und was sie technisch bedeuten

Der DMN-Block ist der Bereich, an dem Produktentscheidungen am häufigsten in Konflikt mit der Regulatorik treten.

DMN_1 – Erfordernis und Angemessenheit

DMN_1.1 ist der Leitsatz: “Die über die digitale Anwendung verarbeiteten personenbezogenen Daten MÜSSEN dem Zweck angemessen, für die Zweckerreichung erheblich und auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt sein.” Der Hersteller MUSS den Beitrag jeder verarbeiteten Datenkategorie begründen können und darlegen, dass diese Zwecke ohne diese Daten nicht umsetzbar wären.

Drei Sub-Anforderungen mit technischer Schärfe:

• DMN_1.1 a: Datenminimierung über den Lebenszyklus – nicht mehr erhebliche Daten werden anonymisiert oder gelöscht. Einmal-Imports, die zehn Datenkategorien bringen, wo drei genutzt werden, brauchen einen automatischen Reinigungs-Schritt.
• DMN_1.1 b: “Der Verantwortliche der digitalen Anwendung DARF über die Anwendung grundsätzlich KEINE Daten erheben, die für sich oder in ihrem Zusammenspiel die Identifizierung einer natürlichen Person erlauben.” KVNR, realer Name, Adresse, E-Mail-Adressen mit Realnamenbestandteil – alles verboten, sofern nicht zwingend für den bestimmungsgemäßen Gebrauch. Die spezifische Erläuterung macht klar: Auch “natürliche” Identifier wie die KVNR sollen unterbleiben, da sie üblicherweise nicht gesondert geschützt sind.
• DMN_1.1 c: Abfragen nach Namen müssen so gestaltet sein, dass die Eingabe nur Vorname oder Pseudonym einfordert.

DMN_1.4 – Zugriffsberechtigungen auf Plattform-Ressourcen (Kamera, GPS, Adressbuch, Terminkalender) sind nur zulässig, wenn für rechtmäßige Zwecke erforderlich, mit besonderer Absicherung für Ressourcen, die Dritte offenbaren könnten (DMN_1.4 a).

DMN_3 – Datensparsamkeit im Speicherformat

DMN_3.1 – Daten im datensparsamsten Format verarbeiten: “Altersgruppe anstelle des genauen Geburtsdatums”. DMN_3.1 a: IP-Adressen und Gerätenummern sollen nicht gespeichert werden; wenn doch, verkürzt oder maskiert.

DMN_3.2: “Der Verantwortliche der digitalen Anwendung MUSS Kriterien für die Bestimmung der Nicht-Identifizierbarkeit der betroffenen Personen definieren und die Einhaltung dieser Kriterien sicherstellen.” Das ist der Anker, an dem Anonymisierungs- vs. Pseudonymisierungs-Entscheidungen getroffen und dokumentiert werden – oft unterschätzt, weil “pseudonymisiert” und “anonymisiert” umgangssprachlich verwechselt werden, rechtlich aber fundamental verschieden sind.

DMN_4 – Benutzer-Account und Grace-Periode

DMN_4 ist einer der DiGA-spezifischsten Blöcke. DMN_4.1 definiert den pseudonym nutzbaren Nutzer-Account:

• DMN_4.1 a: “Nutzer-Accounts MÜSSEN pseudonym nutzbar sein; Angaben zur Identität der betroffenen Person (Krankenversichertennummer, realer Name, Adresse, unmittelbar identifizierende E-Mail-Adresse etc.) DÜRFEN KEINE Voraussetzung für die Nutzung sein.”
• DMN_4.1 b: Zugriff über sichere Authentisierung gegen die bei Anlage erfassten Faktoren.
• DMN_4.1 c: Der Freischaltcode MUSS separat vom Nutzer-Account gespeichert werden und MUSS nach Freischaltung gelöscht werden. Ein Hashwert des Freischaltcodes KANN Bestandteil des Nutzer-Accounts sein. Die Berechnung des Hashwerts MUSS gemäß BSI TR-02102-1↗ erfolgen.

DMN_4.2 – die Grace-Periode:

• “Diese Grace-Periode DARF NICHT länger als ein Drittel der Verordnungsdauer bzw. Bewilligungsdauer – maximal aber drei Monate – dauern.”
• DMN_4.2 a: Vor Ablauf Information an die betroffene Person plus separate Einwilligung für die weitere Vorhaltung der Daten; keine Einwilligung → Account und Daten gemäß Löschkonzept gelöscht/gesperrt.
• DMN_4.2 b: Während der Grace-Periode sind die Daten gesperrt; zulässig sind nur: Authentisierung gegen den Account zum Widerruf von Einwilligungen, zum Datenexport, zum Kontakt mit dem Verantwortlichen, zur Entsperrung bei neuer Freischaltung.
• DMN_4.2 c: Bei Folgeverordnung entscheidet die Person zwischen Weiternutzung des alten Accounts und Neuanlage; bei Neuanlage wird der alte Account unmittelbar gelöscht.

Teams, die Nutzer-Accounts unabhängig von der Verordnungslogik verwalten, bauen die Account-Lifecycle-Logik hier von Grund auf neu. In einer Plattform-Architektur ist das ein Modul, das einmal gebaut wird und dann pro DiGA konfiguriert wird; in einer Custom-DiGA ist es oft wochenlange Arbeit im letzten Quartal vor Einreichung.

Audit Trail und Protokollierung – ACC_1, ACC_2, ACC_3 in der Praxis

Der ACC-Block operationalisiert Art. 5 Abs. 2 DSGVO↗ (Rechenschaftspflicht) in zwei getrennten Protokollen – analog zur Unterscheidung, die die ePA-Spezifikation zwischen Datenschutzkontrolle durch die betroffene Person und Datenschutzzwecken des Verantwortlichen zieht.

ACC_1 – Verwaltungsprotokoll für die betroffene Person

ACC_1.1 verlangt ein Protokoll, dessen Zweck die Datenschutzkontrolle durch die betroffene Person ist:

• a) Wann welche Einwilligung in welcher Version abgegeben/widerrufen wurde – jede Ausprägung einer Einwilligungserklärung muss versioniert und historisiert werden;
• b) Alle Berechtigungsvergaben, -änderungen und -rücknahmen;
• c) Alle Änderungen an Authentisierungsdaten;
• d) Kontext (genutzte Geräte) SOLL erfasst werden;
• e) Einträge MÜSSEN authentisch, zeitnah, gegen Manipulation geschützt sein;
• f) Die betroffene Person MUSS das Protokoll einsehen können.

ACC_1.2: Vor Beendigung der Anwendungsnutzung MUSS der Download aus der Anwendung heraus möglich sein – und auch während der Grace-Periode. Mit Beendigung wird das Verwaltungsprotokoll gelöscht.

ACC_2 – Audit Trail für den Verantwortlichen

ACC_2.1 ist der interne Audit Trail, mit acht Sub-Anforderungen. Die praktisch relevantesten:

• a) Dokumentation von Zugriffen, Datenweitergaben, Datenänderungen, Quellen-Nachweis, Sperrungen und Löschungen.
• b) “Der Audit Trail MUSS alle Zugriffe von Administrations-, Betriebs- und Support-Personal auf personenbezogene Daten einschließlich des Audit Trails erfassen, um interne Datenschutzverletzungen aufdecken zu können.” – der Audit Trail selbst ist Gegenstand seiner eigenen Überwachung.
• d) Übermittlung und Speicherung der Protokolldaten verschlüsselt, Schutz gegen Verfälschung und Verlust.
• e) Einsicht auf wenige Personen beschränkt, durch TOMs abgesichert, im Rollen- und Rechtekonzept verankert.
• g) “Der Audit Trail MUSS so geschrieben werden, dass er keine Verhaltens- und Leistungskontrolle von Mitarbeitern des Herstellers oder des Verantwortlichen der digitalen Anwendung erlaubt.” – ein BetrVG-getriebenes Kriterium, das Logging-Formate pro Operation beeinflusst.
• h) Bei mehrschrittigen Verarbeitungen umfasst der Audit Trail nur Start oder Abschluss. Datensparsamkeit gilt auch im Log.
• i) Protokolldaten MÜSSEN nach drei Monaten sicher gelöscht werden, sofern nicht für laufende Untersuchungen erforderlich.

ACC_2.3: Der Verantwortliche MUSS anhand der Protokolle die ordnungsgemäße Umsetzung seines Löschkonzepts verifizieren können und Aufsichtsbehörden auf Verlangen Protokollauszüge vorlegen.

ACC_3 – Wirksamkeit der Protokollierung

Der Block, der oft durchfällt.

ACC_3.3: “Der Verantwortliche der digitalen Anwendung MUSS … technische Maßnahmen in der digitalen Anwendung und in den internen IT-Systemen implementieren, die sicherstellen, dass einer Protokollierung unterliegende Verarbeitungsvorgänge nur ausgeführt werden, wenn sichergestellt ist, dass die geforderten Protokolleinträge geschrieben werden können. Erfolgte Schreibzugriffe, die nicht protokolliert werden können, MÜSSEN zurückgerollt werden. Erfolgte Lesezugriffe, die nicht protokolliert werden können, MÜSSEN abgebrochen werden, bevor das gelesene Datum an das anfordernde System bzw. den anfordernden Nutzer übergeben wird.”

Das ist eine transaktionale Rollback-Anforderung an die Protokollschicht – wenn das Logging-Backend nicht erreichbar ist, darf die Geschäftslogik nicht weiterlaufen. Cloud-native Architekturen mit asynchronen Logging-Pipelines müssen das entweder durch Circuit-Breaker + Transaktions-Rollback abbilden oder durch eine synchrone Log-Bestätigung vor Commit. Die spezifische Erläuterung lockert es nur geringfügig: Die Prüfung der Protokollierbarkeit muss nicht vor jedem Schritt erfolgen, solange das System regelmäßig prüft – aber die Rollback-Möglichkeit im Fehlerfall ist Pflicht.

ACC_3.4: “Der Verantwortliche … MUSS Prozesse zu einer regelmäßigen Überprüfung der Qualität der automatisierten Auswertung von Protokollen … etablieren.” – samt “manueller Prüfung in Stichproben” (SOLL). Automatisiertes Security-Monitoring allein genügt nicht; der Hersteller muss zeigen, dass die automatische Auswertung durch manuelle Stichproben gegengeprüft wird.

Pseudonymisierung, Transparenz, Drittland – NVK, TPZ und AV im Zusammenspiel

Drei Bereiche, die in der Praxis oft miteinander verknüpft sind und deren Kriterien sich gegenseitig bedingen.

NVK – Nichtverkettbarkeit und Zweckbindung

NVK_1.1: “Eine Durchbrechung oder Ausweitung der rechtmäßigen Verarbeitungszwecke DARF NICHT stattfinden.” – der Hart-Stopp gegen Zweck-Erweiterung ohne neue Rechtsgrundlage.

NVK_2.1 bis NVK_2.3 sind die Regel, die Teams mit einer einzigen Datenbank am härtesten trifft: Speicherung und Verarbeitung von Daten zu unterschiedlichen Zwecken MUSS technisch getrennt erfolgen.

• NVK_2.1 [nur DiGA]: Daten zum Nachweis positiver Versorgungseffekte getrennt von anderen Zwecken; SOLL anonymisiert; bei Auftragsverarbeiter strikte Trennung; nach endgültiger Aufnahme (oder ablehnendem Bescheid) Löschpflicht.
• NVK_2.2 [nur DiGA]: Daten zur Ermittlung erfolgsabhängiger Preisbestandteile (AbEM-Kontext) getrennt; SOLL anonymisiert; keine Übermittlung personenbeziehbarer Daten an GKV-SV oder Schiedsstelle.
• NVK_2.3: Daten zu Funktionsfähigkeit/Nutzerfreundlichkeit/Weiterentwicklung getrennt; SOLL anonymisiert.

“Technisch getrennt” heißt in der Audit-Praxis: getrennte Datenbank-Schemata oder getrennte Instanzen, getrennte Zugriffsrechte, separate Löschfristen. Eine einzige Tabelle mit einem purpose-Flag reicht typischerweise nicht.

TPZ – Transparenz und Informationspflichten

TPZ_1 gliedert die Datenschutzerklärung in neun Teilanforderungen. Die häufig übersehenen Details:

• TPZ_1.4: Kontakt für Datenschutz-Anfragen in deutscher und englischer Sprache; Sub-Anforderung a fordert eine verbindliche Zusicherung zu einer Antwortfrist (die spezifische Erläuterung nennt 2 Werktage als angemessen); Sub-Anforderung b verlangt auch telefonische Erreichbarkeit (8 Stunden an Werktagen als Richtschnur).
• TPZ_1.7: Ein etablierter Prozess zur Fortschreibung der Datenschutzerklärung – inklusive klarer Zuständigkeiten und Versionierung – ist Teil der Produktentwicklung, nicht nachgelagert.
• TPZ_1.8 und TPZ_1.9: AGB und Datenschutzerklärung können vom Hersteller einseitig geändert werden, aber nicht wirksam werden ohne informierte, explizit bestätigte Kenntnisnahme der Änderung – 14 Tage vor Inkrafttreten informieren; bis zur Bestätigung gilt die alte Version.

TPZ_4.2: Die DiGA MUSS 14 Tage vor Ablauf der Verordnungs-/Bewilligungsdauer auf mögliche Datenverluste und das Recht auf Datenübertragung nach Art. 20 DSGVO↗ hinweisen – ein automatischer In-App-Hinweis, der in der Produktlogik angelegt sein muss.

AV – Auftragsverarbeitung und Drittland

AV_1.1 ist die scharfe DiGA-Drittland-Regel: “Jegliche Verarbeitung personenbeziehbarer Daten … MUSS ausschließlich im Inland, in einem anderen Mitgliedstaat der Europäischen Union, in einem diesem nach § 35 Absatz 7 des SGB I gleichgestellten Staat, oder auf Grundlage eines Angemessenheitsbeschlusses gemäß Artikel 45 DSGVO↗ erfolgen. Dieses schließt personenbeziehbare Bestands-, Nutzungs- und Verkehrsdaten ein.”

AV_1.3 adressiert Tochtergesellschaften US-amerikanischer Konzerne explizit (auch nach EU-US-DPF):

• a) Verschlüsselte Speicherung und Übermittlung, Schlüssel-Verwaltung durch den Hersteller in der EU (oder einen EU-Treuhänder).
• b) Der Dienstleister muss bestätigen, bei behördlichen Herausgabeverlangen zunächst keine Daten zu übermitteln – auch nicht an den Mutterkonzern.
• c) Rechtsweg beschreiten und ausschöpfen im Fall eines Herausgabeverlangens.

Die spezifische Erläuterung begründet: “Töchter US-amerikanischer Unternehmen sind faktisch nicht ohne Weiteres in der Lage, die gegebenen Zusagen zum Ausschluss einer Verarbeitung von Daten in einem nicht zulässigen Drittland einzuhalten (siehe Begründung zu Schrems-II-Urteil).” Das BfArM zieht also eine Linie, die den EU-US-DPF nicht per se als hinreichend ansieht.

AV_1.4 verlangt, dass für alle in der digitalen Anwendung genutzten Komponenten von Drittanbietern – SDKs, Analytics-Bibliotheken, Chat-Widgets, Push-Provider – aktuelle Dokumentation vorliegen, aus der sämtliche Anlässe einer Datenübermittlung und die Orte der Datenverarbeitung ersichtlich sind. Third-Party-SDK-Scans gehören damit ins Release-Gate, nicht in die jährliche Audit-Vorbereitung.

DSFA und Verzeichnis von Verarbeitungstätigkeiten – DSFA_1, DSFA_2

Der Katalog strukturiert die DSFA in fünf Schritten: Schwellwertanalyse, Risikobewertung, TOM-Definition, Rest-Risiken-Bewertung, ggf. Abstimmung mit BfDI/LDA nach Art. 36 DSGVO↗.

DSFA_1.5 a legt die Verfahrensanforderungen an die Risikobewertung fest: Der Hersteller SOLL ein dokumentiertes, von Datenschutzbehörden anerkanntes Verfahren nutzen. Bei einem eigenen Verfahren müssen (a) deutsche Dokumentation, (b) mindestens dreistufige Skalen für Eintrittswahrscheinlichkeit und Schwere, (c) mindestens dreistufige Risikoklassifizierung vorliegen. Die spezifische Erläuterung verweist auf das Standard-Datenschutzmodell (SDM) der DSK als Beispiel.

DSFA_1.5 e SOLL eine vierstufige Skala (geringfügig, überschaubar, substanziell, groß) verwenden. DSFA_1.5 f verlangt die Risikomatrix-Dokumentation mit expliziter Begründung für Ereignisse im Grenzbereich.

DSFA_1.8 ist der Prozess-Teil: “Der Verantwortliche … MUSS einen Prozess zur Nachverfolgung aller erhobenen Risiken bzw. zur regelhaften Neubewertung des Erfordernisses einer Datenschutz-Folgenabschätzung etabliert haben.” Mindestens jährliche Neubewertung – der Prozess, der im zweiten Jahr in die Zertifizierungsstelle reingeprüft wird und nicht mehr bloß ins Zertifikat.

DSFA_2 ist das Verzeichnis von Verarbeitungstätigkeiten (VVT). DSFA_2.1 a: Bei Verarbeitungen zu bestimmungsgemäßem Gebrauch MUSS dargelegt werden, welche Features welcher Verarbeitungstätigkeit zugeordnet sind. Bei benachbarten Verarbeitungstätigkeiten MUSS eine klare Abgrenzung im Sinne der Zwecktrennung vorgenommen werden. DSFA_2.2 zieht die Angaben aus Art. 30 Abs. 1 DSGVO↗ durch – mit Nachweis-Schärfe: Zu jeder Verarbeitungstätigkeit (a) Verantwortlicher/Vertreter/DSB benannt, (b) Zweck, (c) Kategorien betroffener Personen und Daten (Gesundheitsdaten als solche gekennzeichnet), (d) Kategorien von Empfängern, (e) Drittland-Übermittlung (ja/nein, Empfänger, Datenkategorien), (f) Löschfristen, (g) TOMs plus Wirksamkeitsprüfung.

Typische Nachforderungen des BfArM – aus der Beobachtung

Dies sind die Muster, die wir aus Feedback-Schleifen mit der Zertifizierung und BfArM-Kommunikation sehen. Es ist keine offizielle BfArM-Statistik, aber die Wiederholungen sind signifikant genug, dass sie als Warnkatalog taugen.

1. “Dokumentiert statt etabliert” (GLSR_2.4). Eine Checkliste, die erst in den Wochen vor Einreichung gebaut wurde, zeigt sich im Audit-Gespräch. Der DSB kann keine Review-Historie belegen, das Release-Gate nach CTRL_2.2 existiert als Policy, aber nicht als Audit-Trail im Ticket-System.

2. AV_1.4 unvollständig. Ein SDK oder eine Bibliothek mit Telemetrie taucht im Verzeichnis der Drittanbieter nicht auf – oder die vorgelegte Dokumentation stammt aus der Version von vor zwei Jahren. Die Nachforderung ist selten “Komponente entfernen”, sondern “belegen oder ersetzen”.

3. TOM_3.1 a – Gesundheitsdaten im Push. Der Wortlaut der Push-Mitteilung (“Sie haben drei neue Übungen für Ihre Migräne-Therapie”) enthält eine Gesundheitsinformation. Die Korrektur ist konzeptuell, nicht kosmetisch: Push-Content-Design muss die Anforderung strukturell abbilden.

4. NVK_2 – fehlende technische Trennung. Eine einzige Datenbank mit purpose-Flag, aber keine separaten Zugriffs- oder Löschpfade. Die Nachforderung zielt auf Architektur, nicht auf Dokumentation.

5. DMN_4.2 – Grace-Periode nicht abgesichert. Die App erlaubt in der Grace-Periode weiter Eingaben, obwohl DMN_4.2 b die Sperrung fordert. Die Architektur verwechselt “Account exists” mit “Account active”.

6. CTRL_1.4 – EU-Vertreter nicht in Deutschland. Bei internationalen Teams ein Klassiker: Der Art. 27 DSGVO↗-Vertreter sitzt in Irland oder den Niederlanden, nicht in Deutschland.

7. ACC_3.3 – Log-Backend ohne Rollback. Asynchrone Logging-Pipelines ohne Transaktions-Absicherung fallen hier; die Nachforderung ist eine echte Infrastruktur-Änderung, kein Policy-Update.

Zusammenspiel mit BSI TR-03161 – kurze Abgrenzung

Weil die beiden Instrumente oft verwechselt werden: Die BfArM-Datenschutzprüfkriterien prüfen, ob die DiGA die DSGVO und DiGAV-Datenschutzvorgaben operationalisiert. Die BSI TR-03161 prüft die technische Cybersicherheit der DiGA (Architektur, Kryptografie, Authentifizierung, Backend, Penetrationstests). Beide sind Pflicht, beide werden pro DiGA erbracht, keines ersetzt das andere.

Manche Anforderungen überschneiden sich – beide Kataloge verlangen Verschlüsselung in Transit und at Rest, beide verlangen ein Schlüsselmanagement nach BSI TR-02102-1, beide verlangen Berechtigungskonzepte. Aber die Perspektive ist unterschiedlich: TOM_2.2 fragt “sind personenbezogene Daten geschützt?”, die BSI-TR-03161-Kriterien O.Cryp_* fragen “entspricht die kryptografische Implementierung dem Stand der Technik, gibt es hartcodierte Schlüssel, ist der Schlüsselaustausch gegen MITM abgesichert?”. In einer Plattform-Architektur decken sich die Antworten oft – aber die Prüfschritte sind getrennt, und die Nachweisartefakte zeigen in unterschiedliche Richtungen.

Im DUX-Portfolio arbeiten wir beide Kataloge parallel auf einer gemeinsamen Plattform-Architektur: die mHealth Suite liefert die Infrastruktur (Schlüsselmanagement, Identitäten, Logging, Verschlüsselung, Vault-Integration), die je DiGA gegen TOM_2, AV_1 und die BSI-O.Cryp_*-Familie gespiegelt wird. Die Plattform-Arbeit passiert einmal, die Zertifizierung je DiGA. Für die BSI-Seite haben wir das in BSI TR-03161-Zertifizierung ausführlich aufgearbeitet.

Wie DUX den Katalog aus Praxis-Sicht handhabt

DUX Healthcare baut DiGAs auf der mHealth Suite. Unsere DiGAs sind je DiGA durch den BfArM-Datenschutzprüfkriterien-Prozess gegangen – je DiGA, weil der Katalog per Produkt geprüft wird, nicht organisationsweit. Die Plattform-Logik ist: Die Einzel-Requirement-IDs – DMN_4, ACC_2, AV_1.3, TOM_2.2, TOM_3.1 – werden einmal auf der Plattform-Ebene architekturgerecht gelöst, und jedes neue DiGA-Projekt erbt diese Lösung. Was per DiGA spezifisch bleibt, sind die produktspezifischen Antworten: Welche Zwecke nach § 4 Abs. 2 DiGAV werden verfolgt? Welche Daten sind dem Zweck angemessen (DMN_1.1)? Welche Drittanbieter-Komponenten kommen zum Einsatz (AV_1.4)? Welche Features gehören zu welcher Verarbeitungstätigkeit im VVT (DSFA_2.1 a)?

Das ist die gleiche Logik, die wir für BSI TR-03161 und die MDR-Konformitätsbewertung anwenden: Plattform-Arbeit davor, DiGA-Arbeit drauf. Der Unterschied zu einer Custom-Entwicklung ist nicht die Qualität des Audits, sondern der Zeit- und Kostenanteil, der pro Projekt zu tragen ist. Wer die Plattform-Mechanik sehen möchte, findet sie unter /build/; wer hier weiterlesen will, findet im Wissens-Bereich DiGA die angrenzenden Themen – die praktische Antrags-Logik als direktester Nachbarartikel.

Antworten auf häufige Fragen

Weiterführend

Wer die zuvor gelegten Schienen weiterverfolgen will, findet im Wissens-Bereich DiGA die angrenzenden Vertiefungen: den Praxis-Leitfaden zur BfArM-Antragstellung mit Fokus auf die 26 Angabenblöcke nach § 2 DiGAV, die BSI-TR-03161-Zertifizierung als separates Cybersecurity-Instrument, und – sobald publiziert – DiGA und US-Cloud-Dienste für die AV_1.3-Frage im Detail, Pseudonyme Nutzung und Account-Management zur DMN_4-Logik, und Audit Trail und Protokollierung für die ACC-Kriterien auf Infrastruktur-Ebene.

Wer den Katalog direkt lesen will: BfArM Datenschutzprüfkriterien v1.0 (24.04.2024)↗ – 79 Seiten, kostenfrei, und verpflichtende Antragsgrundlage. Wer dann noch operationalisieren will, wie diese Kriterien in einer konkreten Architektur tragen, findet die DUX-Plattform-Mechanik unter /build/.