ac05e255da
DiGA-Dossier weiter aufgebaut (docs/specs/diga/): - 03 Requirements (57 REQ-IDs aus dem Code, Traceability-Anker) - 04 Risiko-Akte (ISO 14971 Erstliste; R-LYRA-01 = verpasste Krise als Top-Risiko) - 05b Test-Verifikation (Maestro/Vitest-Inventar, IEC-62304-Luecken) - 05c Lyra-Eval (Suite-Doku) - 08 Datenschutz-Audit (hans-mueller; Groq/Art.9, DSFA-Pflicht, Mail-Agent, Anonymitaet) - 00 Dossier-Plan Status aktualisiert Lyra-Eval-Suite: backend/tests/eval/ (30 Prompts, 5 Kategorien, Vitest-Runner, Mock-Modus ohne Key; Live-Run misst Crisis-Recall). Konvergenter Befund aller 3 Agents: Lyras Krisen-Pfad haengt zu sehr am LLM (R-LYRA-01 + fehlender SOS-Handler-Fallback) -> deterministisches Sicherheitsnetz noetig. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
370 lines
21 KiB
Markdown
370 lines
21 KiB
Markdown
# Datenschutz-Audit & Maßnahmenplan — Rebreak · v0 (Entwurf)
|
||
|
||
> **Dok 08 der DiGA-Technischen-Akte.** Erstellt von Hans Müller (externer DSB).
|
||
> Koordination mit `diga-regulatory` (Dr. Marlene Brandt) — siehe `00-dossier-plan.md`.
|
||
> **Status:** wird von hans-mueller befüllt.
|
||
|
||
## 0. Vorbemerkung & Geltungsgrenzen
|
||
|
||
Sehr geehrte Damen und Herren,
|
||
|
||
der vorliegende Bericht ist der **Datenschutz-Audit v0** zur DiGA-Technischen-Akte
|
||
(Dok 08). Er bewertet den Ist-Zustand der personenbezogenen Datenverarbeitung von
|
||
Rebreak, identifiziert Lücken und priorisiert konkrete Maßnahmen mit Blick auf die
|
||
DiGA-Zulassung.
|
||
|
||
> **Ehrliche Grenze (DSB ≠ Anwalt).** Ich bin externer Datenschutzbeauftragter,
|
||
> kein Rechtsanwalt. Vertragstexte (AVV, SCCs, AGB, Datenschutzerklärung-Finalfassung)
|
||
> und rechtsverbindliche Aussagen (Haftung, Klassifizierung als Verantwortlicher/
|
||
> Auftragsverarbeiter) bedürfen **anwaltlicher Prüfung**. Punkte, die ich aus dem
|
||
> Code/Stack nicht abschließend verifizieren konnte, sind durchgängig als
|
||
> **„zu verifizieren"** markiert — diese sind nicht als Tatsachenbehauptung zu lesen.
|
||
|
||
**Methodik dieses v0:** Auswertung des bekannten Stacks (Hetzner DE, Groq USA,
|
||
Stripe, Cloudflare, Supabase self-hosted), Sichtung von `backend/imap-idle/index.mjs`
|
||
und der bekannten Architektur (Lyra/Groq, Anonymität-by-Design, Demographie-Daten).
|
||
**Kein** zeilengenaues Code-Audit — das ist Gegenstand eines späteren Pentests
|
||
(siehe §3).
|
||
|
||
---
|
||
|
||
## 1. Einordnung — höchste Schutzstufe
|
||
|
||
Rebreak verarbeitet **besondere Kategorien personenbezogener Daten nach Art. 9 Abs. 1
|
||
DSGVO**: Suchterkrankung (Glücksspiel), Therapie-/Recovery-Status, mentale Gesundheit,
|
||
Krisen-/SOS-Daten. Das ist die **schärfste Datenschutz-Stufe**, die die DSGVO kennt.
|
||
|
||
Konsequenzen, die den gesamten Audit prägen:
|
||
|
||
- **Verarbeitung grundsätzlich verboten** (Art. 9 Abs. 1), nur über einen
|
||
**Ausnahmetatbestand** des Art. 9 Abs. 2 zulässig — und zusätzlich braucht es eine
|
||
Rechtsgrundlage nach Art. 6.
|
||
- **DSFA ist Pflicht**, nicht optional (Art. 35 Abs. 3 lit. b: umfangreiche
|
||
Verarbeitung besonderer Kategorien — verstärkt durch den KI-Coach Lyra; vgl. die
|
||
Muss-/Blacklist-Kriterien der DSK).
|
||
- **Jede Lücke ist entsprechend kritisch zu bewerten.** Ein Datenleck bei
|
||
Suchterkrankungs-Daten ist nicht nur DSGVO-Verstoß, sondern führt bei einem
|
||
stigmatisierten Krankheitsbild zu erheblichem realem Schaden für die Betroffenen
|
||
(Erw.gr. 75) — Stichworte Arbeitsplatz, Versicherung, soziales Umfeld.
|
||
- **DiGA verschärft zusätzlich**: BfArM verlangt ein eigenständiges Datenschutz- und
|
||
IT-Sicherheitskonzept als Antrags-Anhang (§4 DiGAV i.V.m. Anlage; siehe §3).
|
||
|
||
> **Andockpunkt zu Marlene (`diga-regulatory`):** Die Art.-9-Einstufung ist die
|
||
> datenschutzrechtliche Entsprechung zur **Zweckbestimmung (Dok 01)** und zur
|
||
> **Risiko-Akte (Dok 04)**. Sobald die Zweckbestimmung medizinisch präzise steht
|
||
> („Behandlung/Linderung einer Suchterkrankung"), trägt sie die bevorzugte
|
||
> Art.-9-Rechtsgrundlage (lit. h, siehe §2.7).
|
||
|
||
---
|
||
|
||
## 2. Ist-Zustand, Lücken & Mängel je Bereich
|
||
|
||
Bewertungs-Skala: **Niedrig / Mittel / Hoch / Kritisch**.
|
||
|
||
### 2.1 Mail-Agent (IMAP-IDLE-Daemon) — größte Datenschutz-Oberfläche
|
||
|
||
**Was passiert:** Ein persistenter Daemon (`backend/imap-idle/`) hält pro aktivem
|
||
Nutzer eine IMAP-IDLE-Session zum **privaten E-Mail-Postfach** und triggert bei neuer
|
||
Mail einen Scan (`backend/server/api/mail/scan-internal`), der eingehende Mails gegen
|
||
Glücksspiel-/Casino-Absender matcht (Brand-Token-Matching, VIP-Layer-2). Zweck:
|
||
Schutz vor Trigger-Mails (Casino-Newsletter, Bonus-Angebote).
|
||
|
||
**Ist-Zustand (positiv, aus Code verifiziert):**
|
||
|
||
| Aspekt | Befund |
|
||
|---|---|
|
||
| Credential-Speicherung | App-Passwörter **und** OAuth-Tokens **AES-256-GCM-verschlüsselt** at rest (`password_encrypted`, `oauth_access_token`, `oauth_refresh_token`). Gut. |
|
||
| OAuth bevorzugt | Gmail (Google OAuth) und Outlook (MS XOAUTH2) nutzen OAuth2 statt App-Passwort — datensparsamer, widerrufbar. Gut. |
|
||
| Consent-Gate | Connections ohne `consent_at` werden gehalten, aber **nicht gescannt**. Sauberer Einwilligungs-Riegel. Gut. |
|
||
| Logging-Hygiene | Code-Kommentar + Praxis: **niemals** Passwörter/Tokens loggen; nur E-Mail-Adresse. Gut. |
|
||
|
||
**Lücken / Mängel:**
|
||
|
||
1. **Verarbeitungsumfang & Zweckbindung unklar dokumentiert — `Hoch`.**
|
||
Der Daemon hat technisch Lesezugriff auf das **gesamte Postfach** (inkl. INBOX +
|
||
Junk-Sweep). Datenschutzrechtlich zulässig ist nur die Verarbeitung, die für den
|
||
Schutzzweck **erforderlich** ist (Datenminimierung, Art. 5 Abs. 1 lit. c).
|
||
**Zu verifizieren + zu dokumentieren:** Werden Mail-**Inhalte** (Body) gespeichert
|
||
oder nur **flüchtig** Absender/Betreff gematcht und sofort verworfen? Werden
|
||
gematchte Treffer (= „Person erhält Casino-Mails" → Rückschluss auf Spielverhalten,
|
||
**Art. 9!**) persistiert? Wenn ja: wo, wie lange, verschlüsselt? Das gehört
|
||
lückenlos ins Verarbeitungsverzeichnis.
|
||
|
||
2. **Rechtsgrundlage des Postfach-Zugriffs — `Hoch`.**
|
||
Vollzugriff auf ein privates Postfach ist hochgradig eingriffsintensiv. Tragfähig
|
||
nur über **ausdrückliche, granulare Einwilligung (Art. 9 Abs. 2 lit. a + Art. 6
|
||
Abs. 1 lit. a)**, die den Umfang („Rebreak liest eingehende Mails, um Casino-
|
||
Absender zu blocken") transparent macht. Das `consent_at`-Feld ist die technische
|
||
Basis — **zu verifizieren:** Ist der zugehörige Consent-Text spezifisch,
|
||
informiert und **separat** (nicht mit anderen Einwilligungen gebündelt)?
|
||
|
||
3. **Drittbetroffene (Absender) — `Mittel`.**
|
||
Der Daemon verarbeitet auch personenbezogene Daten **Dritter** (Absender der Mails),
|
||
die nicht eingewilligt haben. Das ist über berechtigtes Interesse / die
|
||
Haushaltsausnahme-Logik bewertbar, **muss aber in der DSFA als eigener Datenfluss
|
||
abgewogen** werden (Interessenabwägung Art. 6 Abs. 1 lit. f dokumentieren).
|
||
|
||
4. **Löschkonzept — `Hoch`.**
|
||
**Zu verifizieren:** Werden Credentials + abgeleitete Daten bei Account-Löschung
|
||
und bei Deaktivierung einer Connection vollständig gelöscht? Cascade-Delete auf
|
||
`mail_connections`? Der OAuth-Refresh-Token muss zusätzlich **provider-seitig
|
||
revoziert** werden (Google/MS revoke-Endpoint), nicht nur in der DB gelöscht.
|
||
|
||
**Risiko gesamt Mail-Agent: `Hoch`** — größte Angriffs-/Eingriffsoberfläche, technisch
|
||
solide abgesichert (Encryption, Consent-Gate), aber Zweckbindung/Löschung/Doku
|
||
unvollständig.
|
||
|
||
### 2.2 Lyra (Groq, USA) — Art.-9-Daten im Drittland
|
||
|
||
> **Achtung: kritisches Datenschutz-Risiko.** Krisen- und Chatinhalte mit dem
|
||
> KI-Coach Lyra enthalten Gesundheitsdaten (Art. 9) und werden zur Inferenz an
|
||
> **Groq Inc. (USA)** übermittelt. Das ist ein **Drittland-Transfer besonderer
|
||
> Kategorien** — der sensibelste Datenfluss im gesamten System.
|
||
|
||
**Befund:**
|
||
|
||
- **Drittland-Transfer (Kapitel V DSGVO).** USA = Drittland. Erforderlich:
|
||
**EU-Standardvertragsklauseln 2021 (SCCs, Modul 2 C2P)** + **Transfer-Impact-
|
||
Assessment (TIA)** wegen FISA 702 / EO 12333 (US-Überwachungsbefugnisse). Groq
|
||
stellt eine **DPA mit eingebundenen SCCs** sowie eine Subprozessoren-Liste bereit
|
||
(`trust.groq.com/subprocessors`) — **zu verifizieren + abzuschließen**, ob diese
|
||
DPA tatsächlich gezeichnet ist.
|
||
- **Data-Retention-Default ist die Stolperfalle — `Kritisch`.** Laut Groq-Doku werden
|
||
Kundendaten **standardmäßig nicht aufbewahrt**, ABER bei vermuteter Reliability-/
|
||
Abuse-Problematik **können Inputs/Outputs geloggt** werden. Für Art.-9-Daten ist
|
||
dieses Abuse-Logging inakzeptabel, solange nicht **Zero Data Retention (ZDR)**
|
||
explizit auf der Data-Controls-Seite aktiviert ist. **Maßnahme zwingend:**
|
||
**ZDR aktivieren und schriftlich bestätigen lassen.**
|
||
- **EU-Data-Boundary?** Groq bietet derzeit keine garantierte EU-only-Inferenz-Region
|
||
— **zu verifizieren**. Solange Inferenz in den USA stattfindet, bleibt der Transfer
|
||
bestehen.
|
||
|
||
**Zusätzliche technische Maßnahmen (Art. 32 + EDSA-Empfehlungen 01/2020):**
|
||
|
||
Da SCCs allein das FISA-702-Problem nicht heilen (vgl. Schrems II), sind ergänzende
|
||
Maßnahmen Pflicht. Priorisiert umsetzbar:
|
||
|
||
1. **Pseudonymisierung vor Übertragung — `Kritisch`/Pflicht.** An Groq dürfen
|
||
**keine** direkten Identifikatoren (Klarname, E-Mail, User-ID, Account-ID) gehen.
|
||
Übertragen wird ausschließlich der **Konversationsinhalt** plus ggf. ein
|
||
**rotierender Pseudonym-Token**, dessen Auflösung **nur bei Rebreak/Hetzner DE**
|
||
liegt. **Zu verifizieren im Code:** Was genau geht im Groq-Request-Payload raus?
|
||
Werden System-Prompt/Kontext mit Klarnamen oder demografischen Klartext-Feldern
|
||
angereichert? Das ist der wichtigste Einzel-Check dieses Audits.
|
||
2. **ZDR + Abuse-Logging-Opt-out** (s.o.).
|
||
3. **Datenminimierung im Kontextfenster** — nur das nötige Gesprächsfenster, keine
|
||
Historie mit Demografie/Realnamen.
|
||
4. **TIA dokumentieren** — Risikobewertung FISA 702 / EO 12333, Eintrittswahrschein-
|
||
lichkeit, Wirksamkeit der Pseudonymisierung als Gegenmaßnahme.
|
||
|
||
**Hinweis zur Memory-Trennung:** Gemäß interner Vorgabe darf Lyra Demografie-Daten
|
||
**nicht** heimlich aus Gesprächen extrahieren; strukturierte DiGA-Daten und narrative
|
||
Lyra-Memories sind getrennt. Das ist datenschutzrechtlich **vorbildlich** (Zweckbindung)
|
||
und sollte in der DSFA explizit als Schutzmaßnahme dokumentiert werden.
|
||
|
||
**Risiko gesamt Lyra/Groq: `Kritisch`** bis Pseudonymisierung + ZDR + SCC/TIA
|
||
nachweislich stehen.
|
||
|
||
> **Andockpunkt zu Marlene:** Dieser Datenfluss ist auch ein **Risiko-Akte-Eintrag
|
||
> (Dok 04)** — „Übermittlung sensibler Daten an US-Subprozessor". Datenschutz-
|
||
> Maßnahme (Pseudonymisierung) und ISO-14971-Risikomaßnahme sind hier deckungsgleich.
|
||
|
||
### 2.3 Auftragsverarbeiter — AV-Verträge (Art. 28) & Drittland
|
||
|
||
| Anbieter | Funktion | Sitz | AVV (Art. 28) | Drittland / SCC | Status |
|
||
|---|---|---|---|---|---|
|
||
| **Hetzner** | Hosting/DB | DE | Standard-AVV verfügbar | EU — kein Transfer | AVV zeichnen — **gut** |
|
||
| **Groq** | Lyra-LLM | USA | DPA verfügbar | **SCC + TIA + ZDR Pflicht** | **kritisch — s. §2.2** |
|
||
| **Stripe** | Payment | IE/USA | DPA verfügbar | SCC für US-Anteil | AVV+SCC zeichnen |
|
||
| **Cloudflare** | DNS/CDN | USA | DPA verfügbar | SCC + TIA (sieht IP/Metadaten) | AVV+SCC zeichnen |
|
||
| **Supabase** | Auth/DB | self-hosted @ Hetzner DE | — (kein externer AV) | irrelevant — Daten bleiben DE | **gut** |
|
||
|
||
**Lücken:**
|
||
|
||
- **`Hoch`: Vollständigkeit unklar.** Es ist **zu verifizieren**, ob für **alle** o.g.
|
||
Verarbeiter unterzeichnete AVV vorliegen. Fehlende AVV = Verstoß gegen Art. 28
|
||
Abs. 3, unabhängig von technischer Sicherheit.
|
||
- **`Mittel`: Cloudflare** verarbeitet IP-Adressen/Verbindungsmetadaten von
|
||
Gesundheits-App-Nutzern (Rückschluss „nutzt Sucht-App"). TIA daher auch hier nötig,
|
||
nicht nur bei Groq.
|
||
- **Stripe**: Zahlungsdaten sind nicht Art. 9, aber die **Tatsache eines Rebreak-Abos**
|
||
ist mittelbar gesundheitsbezogen. AVV + SCC zeichnen; Vertragsabwicklung als
|
||
Rechtsgrundlage (Art. 6 Abs. 1 lit. b).
|
||
|
||
> Alle Vertragstexte (AVV/SCC) → **anwaltliche Endprüfung empfohlen.** Ich liefere die
|
||
> Checkliste, nicht die rechtsverbindliche Zeichnung.
|
||
|
||
### 2.4 Anonymität by Design — verifizieren, dass nichts leakt
|
||
|
||
**Ist-Zustand:** Vorgabe lautet — Nutzer sind überall **nur mit Nickname** sichtbar,
|
||
nie Klarname/E-Mail/Username (DSGVO + Stigma-Schutz). Das ist **vorbildliche
|
||
Datensparsamkeit** (Art. 25 Datenschutz durch Technikgestaltung).
|
||
|
||
**Zu verifizierende Leak-Pfade (`Hoch`, weil ein einziges Leck den ganzen Schutz
|
||
bricht):**
|
||
|
||
- **Community/Posts:** Wird wirklich nur `nickname` ausgespielt — auch in
|
||
API-Responses (kein `email`/`firstName` im JSON, das das Frontend nur „nicht
|
||
rendert")? **API-Payload prüfen, nicht nur UI.**
|
||
- **Realtime/Supabase-Publication:** Leaken Realtime-Events Klarfelder?
|
||
- **Lyra-Payload an Groq** (s. §2.2) — kein Klarname.
|
||
- **Avatar / URL-Slugs / Push-Notifications:** Enthält ein Profil-Slug oder ein
|
||
Notification-Title je den Klarnamen?
|
||
- **Logs/Error-Tracking:** Tauchen E-Mail/Klarname in Server-Logs oder einem
|
||
Error-Tracker auf?
|
||
|
||
### 2.5 Auth (Supabase self-hosted) & Demographie-Daten
|
||
|
||
- **Auth/Supabase self-hosted @ Hetzner DE — `Niedrig`.** Daten bleiben in DE, kein
|
||
Drittland. Gut. **Zu verifizieren:** Passwort-Hashing (Argon2/bcrypt via GoTrue —
|
||
Standard ok), JWT-Secret-Handling (via Infisical — gut, keine `.env`).
|
||
- **Demographie-Daten (DiGA: `birth_year`, Beruf etc.) — `Mittel`.** Strikt
|
||
**user-initiated** über das Profil-Formular (vorbildlich). Diese Daten sind
|
||
**DiGA-Evidenz-relevant** und teils Art.-9-nah (Gesundheitskontext). Erforderlich:
|
||
klare Zweckangabe (DiGA-Wirksamkeitsnachweis), Freiwilligkeit, getrennte
|
||
Rechtsgrundlage. **Keine** Kopplung von App-Nutzung an Demografie-Preisgabe.
|
||
|
||
### 2.6 Community
|
||
|
||
- **`Mittel`.** Nutzergenerierte Inhalte (Posts, Streaks, Trigger-Logs) können
|
||
Gesundheitsdaten enthalten (Selbstoffenbarung der Sucht). Pseudonymität schützt,
|
||
aber: **Moderationskonzept, Meldewege, Löschung einzelner Posts** und Behandlung von
|
||
Drittnennungen müssen geregelt sein. Recht auf Löschung (§2.7) greift hier besonders.
|
||
|
||
### 2.7 Fehlende / zu prüfende Pflicht-Dokumente & Prozesse
|
||
|
||
| Pflicht | Norm | Status | Bewertung |
|
||
|---|---|---|---|
|
||
| **DSFA** | Art. 35 | **fehlt / Pflicht** | **Kritisch** — Art.-9 + KI-Coach lösen DSFA-Pflicht aus |
|
||
| **Verarbeitungsverzeichnis** | Art. 30 | **zu verifizieren** | **Hoch** — muss alle Flüsse aus §2 vollständig listen |
|
||
| **Datenschutzerklärung** | Art. 13/14 | **zu verifizieren/aktualisieren** | **Hoch** — muss Groq-Transfer, Mail-Agent, Lyra benennen |
|
||
| **Betroffenenrechte** | Art. 15–22 | **teils** | **Hoch** — Auskunft/Export/Löschung als Endpoints (s.u.) |
|
||
| **Datenpannen-Prozess** | Art. 33/34 | **zu verifizieren** | **Hoch** — 72h-Meldekette an LfDI definieren |
|
||
| **Einwilligungs-Management** | Art. 7, 9 II a | teils (`consent_at`) | **Mittel** — granular, getrennt, widerrufbar, protokolliert |
|
||
| **Cookie-/Tracking-Consent** | TTDSG | **zu verifizieren** | **Mittel** — Opt-In für nicht-essenzielle Cookies (App: vermutl. wenig relevant) |
|
||
|
||
**Rechtsgrundlagen-Architektur (Soll):**
|
||
|
||
- **Bis DiGA-Listung:** Gesundheitsdaten über **Art. 9 Abs. 2 lit. a** (ausdrückliche
|
||
Einwilligung) + Art. 6 Abs. 1 lit. a/b.
|
||
- **Ab DiGA-Listung:** bevorzugt **Art. 9 Abs. 2 lit. h** (Gesundheitsversorgung /
|
||
Behandlung) — trägt robuster als Einwilligung, weil nicht jederzeit grundlos
|
||
widerrufbar in laufender Versorgung. **Hängt direkt an der Zweckbestimmung (Dok 01).**
|
||
- Account-Daten: **Art. 6 Abs. 1 lit. b** (Vertrag).
|
||
- Berechtigtes Interesse (lit. f) **nur** mit dokumentierter Interessenabwägung.
|
||
|
||
**Betroffenenrechte — konkrete Technik-Specs (Eskalation an `rebreak-backend`):**
|
||
|
||
- **Auskunft/Export (Art. 15/20):** Endpoint, der **alle** Datenkategorien eines
|
||
Nutzers maschinenlesbar exportiert (Profil, Demografie, Posts, Streaks, Trigger-Logs,
|
||
Lyra-Memories, Mail-Connection-Metadaten — **ohne** Klartext-Credentials).
|
||
- **Löschung (Art. 17) — kritisch bei Suchterkrankung:** echtes Cascade-Delete über
|
||
alle Tabellen **+ OAuth-Token-Revoke beim Provider + Groq-seitige Löschung
|
||
bestätigen (ZDR macht das trivial)**. „Soft-Delete-Flag" genügt **nicht**.
|
||
- **Berichtigung (Art. 16), Widerspruch (Art. 21):** über Profil/Settings abbildbar.
|
||
|
||
---
|
||
|
||
## 3. DiGA-spezifische Datenschutz-Anforderungen (BfArM)
|
||
|
||
DiGA verschärft die DSGVO-Basis. Für das BfArM-Fast-Track-Verfahren (§139e SGB V,
|
||
DiGAV) sind datenschutz-/sicherheitsseitig insbesondere relevant:
|
||
|
||
| Anforderung | Inhalt | Status Rebreak |
|
||
|---|---|---|
|
||
| **Datenschutz-Konzept als Antrags-Anhang** | Eigenständiges Dokument, das alle Verarbeitungen, Rechtsgrundlagen, Drittland-Transfers, TOMs beschreibt | **Dieser Bericht + DSFA + VVT bilden die Basis** |
|
||
| **DSFA** | Pflichtdokument | **fehlt — Stufe 3, s. §4** |
|
||
| **IT-Sicherheit: BSI-Grundschutz / ISO 27001** | Nachweis eines anerkannten Sicherheits-Frameworks | **offen — Stufe 4** |
|
||
| **Jährlicher Penetrationstest** | Externer Pentest-Bericht, jährlich | **fehlt — einplanen** |
|
||
| **Datenminimierung & Zweckbindung** | BfArM prüft scharf bei Gesundheits-Apps | Mail-Agent + Lyra sind die Prüf-Hotspots |
|
||
| **Keine Werbung / kein Tracking-Verkauf** | DiGAV untersagt Datennutzung zu Werbezwecken | **zu bestätigen** (kein Ad-/Analytics-SDK mit Datenabfluss) |
|
||
|
||
> Die **BfArM-Anforderungen** (insb. Prüfkriterien Datenschutz/Datensicherheit nach
|
||
> DiGAV Anlage 1) werden ab 2026 enger an BSI-Vorgaben (BSI TR / „Sicherheit für
|
||
> Gesundheits-Apps") gekoppelt — **zu verifizieren** für den aktuellen Antragsstand.
|
||
> Diese inhaltliche Validierung gehört zu **Marlene + einem QM/Regulatory-Profi**.
|
||
|
||
---
|
||
|
||
## 4. Priorisierter Maßnahmenplan (Eskalations-Treppe)
|
||
|
||
Aufwand grob: **S** ≤ 1 Tag · **M** = Tage · **L** = 1–2 Wochen · **XL** > 2 Wochen.
|
||
|
||
### Kritisch — sofort (Stufe 1–2)
|
||
|
||
| # | Maßnahme | Aufwand | Owner |
|
||
|---|---|---|---|
|
||
| K1 | **Groq-Request-Payload prüfen** — sicherstellen, dass **kein** Klarname/E-Mail/User-ID rausgeht; Pseudonymisierung erzwingen | M | `rebreak-backend` (Spec von mir) |
|
||
| K2 | **Groq ZDR aktivieren** (Zero Data Retention) + schriftlich bestätigen; Abuse-Logging-Risiko schließen | S | User/DSB |
|
||
| K3 | **Groq-DPA/SCC zeichnen + TIA** (FISA 702 / EO 12333) erstellen | M | User + Anwalt |
|
||
| K4 | **AVV-Inventur**: alle Verarbeiter (Hetzner, Stripe, Cloudflare) — fehlende AVV/SCC zeichnen | M | User + Anwalt |
|
||
| K5 | **Anonymitäts-Leak-Audit** — API-Payloads/Realtime/Logs auf Klarname/E-Mail prüfen | M | `rebreak-backend` |
|
||
|
||
### Hoch (Stufe 1–3)
|
||
|
||
| # | Maßnahme | Aufwand | Owner |
|
||
|---|---|---|---|
|
||
| H1 | **Verarbeitungsverzeichnis (Art. 30)** vollständig erstellen/aktualisieren (LfDI/GDD-Template) | M | DSB + User |
|
||
| H2 | **DSFA (Art. 35)** für Art.-9 + Lyra-KI + Mail-Agent | L | DSB-Struktur + User |
|
||
| H3 | **Datenschutzerklärung (Art. 13/14)** aktualisieren — Groq-Transfer, Mail-Agent, Lyra benennen | M | DSB-Entwurf → **Anwalt final** |
|
||
| H4 | **Betroffenenrechte-Endpoints**: Export (Art. 15/20) + echtes Cascade-Delete (Art. 17) inkl. OAuth-Revoke | L | `rebreak-backend` (Spec von mir) |
|
||
| H5 | **Mail-Agent Zweckbindung + Löschkonzept** dokumentieren/verifizieren | M | DSB + `rebreak-backend` |
|
||
| H6 | **Datenpannen-Prozess (Art. 33/34)** — 72h-Meldekette an LfDI als Runbook | S | DSB |
|
||
|
||
### Mittel (Stufe 3–4)
|
||
|
||
| # | Maßnahme | Aufwand | Owner |
|
||
|---|---|---|---|
|
||
| M1 | **Einwilligungs-Management** schärfen — granular, getrennt, widerrufbar, protokolliert | M | `rebreak-backend` |
|
||
| M2 | **BSI-Grundschutz / ISO-27001-Gap-Analyse** beginnen (DiGA-Pflicht) | XL | externer Profi |
|
||
| M3 | **Jährlicher Pentest** beauftragen/terminieren | M | externer Dienstleister |
|
||
| M4 | **TTDSG/Cookie-Consent** im Web-Auftritt prüfen | S | User |
|
||
|
||
**Realistische Timeline für die Stufen 1–3** (VVT + DSFA + Datenschutzerklärung +
|
||
AVV/SCC + Endpoints): **4–8 Wochen**, nicht ein Wochenende. BSI/ISO + Pentest laufen
|
||
parallel und länger.
|
||
|
||
---
|
||
|
||
## 5. Koordination mit `diga-regulatory` (Dr. Marlene Brandt)
|
||
|
||
Dieser Bericht **ist Dok 08** der Technischen Akte (`00-dossier-plan.md`, Zeile 34).
|
||
Andockpunkte:
|
||
|
||
| Dieser Audit (Datenschutz) | Andockpunkt bei Marlene |
|
||
|---|---|
|
||
| Art.-9-Einstufung, Rechtsgrundlage lit. h | **Dok 01 Zweckbestimmung** — die medizinische Zweckangabe trägt die Rechtsgrundlage |
|
||
| Groq-Transfer, Mail-Agent-Vollzugriff | **Dok 04 Risikomanagement-Akte** — als ISO-14971-Risiken spiegeln; Pseudonymisierung = gemeinsame Maßnahme |
|
||
| Datenkategorien-Inventar (§2) | **Dok 05 Architektur/SOUP** — Datenflüsse + Subprozessoren-Liste deckungsgleich halten |
|
||
| BSI/ISO, Pentest, DSFA als Antrags-Anhang | **Klassifizierung (Dok 02)** + BfArM-Datenschutz-Prüfkriterien |
|
||
| Betroffenenrechte, Löschung | **Dok 07 Gebrauchsanweisung/Labeling** — Nutzer über Rechte informieren |
|
||
|
||
> **Empfehlung an die Projektleitung:** Die DSFA (H2) ist sowohl DSGVO-Pflicht als
|
||
> auch BfArM-Antrags-Anhang — **ein Dokument, doppelter Nutzen**. Sie sollte als
|
||
> Nächstes nach der AVV-/SCC-Inventur und dem Groq-Payload-Fix priorisiert werden, da
|
||
> sie auf deren Ergebnissen aufbaut.
|
||
|
||
---
|
||
|
||
## 6. Quellen
|
||
|
||
- DSGVO (VO (EU) 2016/679): Art. 5, 6, 7, 9, 13/14, 15–22, 25, 28, 30, 32, 33/34, 35;
|
||
Kapitel V; Erw.gr. 75, 91.
|
||
- BDSG-neu (DE); TTDSG (DE); TMG/DDG.
|
||
- SGB V §139e; DiGAV (Verfahren/Anforderungen Erstattungsfähigkeit DiGA).
|
||
- EuGH C-311/18 („Schrems II") — Drittland-Transfer/SCC-Grenzen.
|
||
- EDSA, Empfehlungen 01/2020 zu ergänzenden Maßnahmen bei Drittland-Transfers.
|
||
- DSK, Liste der Verarbeitungstätigkeiten mit DSFA-Pflicht (Muss-Liste).
|
||
- EU-Standardvertragsklauseln 2021 (Durchführungsbeschluss (EU) 2021/914).
|
||
- [Groq — Your Data in GroqCloud](https://console.groq.com/docs/your-data)
|
||
- [Groq — Data Processing Addendum](https://console.groq.com/docs/legal/customer-data-processing-addendum)
|
||
- [Groq — Subprozessoren](https://trust.groq.com/subprocessors)
|
||
- BSI — IT-Grundschutz; ISO/IEC 27001.
|
||
|
||
---
|
||
|
||
*Erstellt von Hans Müller, externer Datenschutzbeauftragter — v0-Entwurf, Stand 2026.
|
||
Rechtsverbindliche Texte (AVV, SCC, Datenschutzerklärung-Final) bedürfen anwaltlicher
|
||
Prüfung. Als „zu verifizieren" markierte Punkte sind vor Antragstellung am Code/an
|
||
den Verträgen zu belegen.*
|