# 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.
> **Letztes Update 2026-06-07:** Groq-Befund (§2.2) von „kritisch/offen" auf
> „teilweise gemindert (ZDR aktiv)" gesetzt — siehe §2.2, §2.3, §4 (K2/K3),
> Risiko-Akte R-DATA-05.

## 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

> **Statusänderung (Stand 2026-06-07): teilweise gemindert.** Zero Data Retention
> (ZDR) bei Groq ist laut Bestätigung des Gründers **aktiviert**. Damit ist der
> **Speicher-/Retention-Teil** des Risikos adressiert: Groq bewahrt die übermittelten
> Lyra-Chat-Inhalte (Art.-9-Gesundheitsdaten) **nicht mehr auf**. Der **Übertragungs-
> teil in die USA** (Drittland-Transfer an einen US-Auftragsverarbeiter) **bleibt
> bestehen** und ist weiterhin formal abzusichern — ZDR ≠ vollständige Konformität.

**Was ZDR mindert (Speicher-/Retention-Teil):**

- Groq dokumentiert: „All customers may enable Zero Data Retention (ZDR) in Data
  Controls settings." Bei aktivem ZDR werden Customer-Data für Inferenz-Requests
  **nicht aufbewahrt**, und das andernfalls mögliche **Abuse-/Reliability-Logging**
  (Inputs/Outputs, sonst bis zu 30 Tage) entfällt. Für Art.-9-Daten war genau dieses
  Logging der kritische Punkt — er ist mit aktivem ZDR geschlossen.
  *(Beleg: Groq „Your Data in GroqCloud". **Schriftliche Account-spezifische
  Bestätigung des aktiven ZDR-Status für den Rebreak-Account ist als Nachweis zur
  Akte zu nehmen** — Gründer-Aussage allein genügt für das BfArM-Dossier nicht.)*

**Was ZDR NICHT mindert — verbleibender Rest (Übertragungsteil) — `Hoch`:**

Die Daten werden **weiterhin in die USA an einen US-Auftragsverarbeiter (Groq Inc.)
übermittelt**. Groq speichert Customer-Data laut DPA in **US-basierten GCP-Buckets**;
eine **garantierte EU-only-Inferenz-Region bietet Groq nicht** (belegt: Groq-Doku
nennt nur US-Location, keine EU-Residency). Damit bleibt offen:

1. **AVV / DPA (Art. 28) — `Hoch`.** Groq stellt eine **Data Processing Addendum**
   bereit, die mit Abschluss der Services-Agreement als **abgeschlossen gilt**
   („deemed to have signed", DPA §8.2) — also **kein** separater Unterschriftsakt
   nötig. *Zu verifizieren mit Groq:* dass die Rebreak-Account-Konfiguration die
   Services-Agreement (und damit die DPA) tatsächlich akzeptiert hat, und dass die
   **Subprozessoren-Liste** (`trust.groq.com/subprocessors`, 15-Tage-Vorlauf bei
   Änderungen) reviewt ist.
2. **SCCs (Standardvertragsklauseln) — `Hoch`.** Die DPA bindet die **EU-SCCs 2021**
   ein, **Modul 2 (Controller→Processor)** und **Modul 3 (Processor→Sub-Processor)**,
   deemed-signed mit der Agreement (DPA §8.2.a; belegt aus Groq-DPA-Text). Das ist
   die formale Transfer-Grundlage nach Kapitel V — **vorhanden, aber zu
   verifizieren mit Groq**, dass sie für den Rebreak-Account greift und die richtigen
   Module/Optionen (General Authorization, EU-Member-State-Recht) gezogen sind.
3. **TIA (Transfer-Impact-Assessment, Schrems II) — `Hoch`/Pflicht.** SCCs allein
   heilen das **FISA-702- / EO-12333**-Problem nicht (EuGH C-311/18). Eine
   dokumentierte TIA bleibt **zwingend**: Risikobewertung der US-Überwachungs-
   befugnisse, Eintrittswahrscheinlichkeit, und Wirksamkeit der ergänzenden Maßnahmen
   — wobei **ZDR (kein Datenbestand bei Groq) und Pseudonymisierung (kein Personen-
   bezug im Payload) jetzt als die zwei tragenden ergänzenden Maßnahmen** im Sinne der
   EDSA-Empfehlungen 01/2020 in die TIA eingehen. ZDR **verbessert** die TIA-Argu-
   mentation deutlich, ersetzt sie aber nicht.
4. **Pseudonymisierung des Payloads — `Kritisch`/Pflicht — TECHNISCH UMGESETZT
   (Stand 2026-06-07, `rebreak-backend`).**

   **Payload-Audit-Ergebnis (technischer Beitrag `rebreak-backend`; rechtliche Wertung
   bleibt hans-mueller):**

   | Feld | Vorher | Nachher (implementiert) |
   |---|---|---|
   | **Nickname** | `NUTZER-NAME: Der Nutzer heißt "«nickname»"` im System-Prompt | **bleibt** — selbstgewählt, gilt als Pseudonym. Hinweis: technisch könnte ein Nickname ein Realname sein; rechtliche Einordnung obliegt hans-mueller. |
   | **Geburtsjahr / exaktes Alter** | `- Alter: ca. 34 Jahre (Geburtsjahr 1991)` — volles Jahr + exaktes Alter | **Dekaden-Bucket:** `- Altersgruppe: 30–40 Jahre` — kein exaktes Jahr, kein exaktes Alter mehr. |
   | **Stadt** | `- Stadt: Berlin` — Klartextstadt | **entfernt** — wird nicht mehr an LLM-Provider übermittelt. |
   | **Bundesland** | enthalten | **bleibt** — ausreichend grober Regionalbezug. |
   | **Geschlecht, Familienstand, Beruf** | enthalten | **bleibt** — user-initiated, keine direkte Identifikation. |
   | **User-ID / Account-ID / E-Mail** | nicht im System-Prompt enthalten | nicht enthalten — kein Handlungsbedarf. |
   | **Memory-Kanal (OpenRouter, `lyraMemoryExtract.ts`)** | Gesprächstext (letzte 20 Turns, max 4000 Zeichen) ohne Instruktion gegen Klarnamen Dritter | **Prompt-Instruktion ergänzt:** Klarnamen Dritter (z.B. „seine Frau Maria" → „seine Frau") sowie Orte und Arbeitgeber-Namen werden vom Modell explizit reduziert. |

   **Scope:** Endpoint `POST /api/coach/message` (Casual-Coach-Mode). SOS-Mode
   (`sos-stream.post.ts`) war bereits sauber (keine Demografie, kein Nickname
   im Payload — verifiziert). Memory-Extraktion (`lyraMemoryExtract.ts`) via
   OpenRouter trifft alle Providers gleichermassen.

   **Verbleibende Einschränkung:** Nickname bleibt bewusst im Payload. Falls
   hans-mueller diesen nicht als ausreichendes Pseudonym wertet, wäre ein
   rotierender Session-Token als Ersatz technisch umsetzbar — das ist eine
   rechtliche, keine technische Entscheidung.

**Datenminimierung im Kontextfenster** — flankierend: nur das nötige Gesprächsfenster
an Groq, keine Historie mit Demografie/Realnamen.

**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: `Hoch` (zuvor `Kritisch`) — teilweise gemindert durch
aktives ZDR + Payload-Pseudonymisierung.** Der Speicher-/Retention-Teil ist durch ZDR
adressiert; die Payload-Pseudonymisierung (Geburtsjahr→Bucket, Stadt entfernt,
Memory-Drittname-Instruktion) ist technisch umgesetzt (Stand 2026-06-07). Der
Übertragungsteil (US-Transfer) bleibt offen, bis (b) AVV/DPA + SCC-Geltung mit Groq
verifiziert und (c) die TIA dokumentiert ist. **Einzelpunkt Pseudonymisierung:
technisch erledigt — rechtliche Bewertung (Nickname als Pseudonym) offen für
hans-mueller.**

> **Andockpunkt zu Marlene (Risiko-Akte `R-DATA-05`):** Dieser Datenfluss ist der
> Risiko-Akte-Eintrag **R-DATA-05** (Dok 04) — „Übermittlung sensibler Daten an
> US-Subprozessor". **Update an Marlene:** Das **Retention-Teilrisiko ist durch
> aktives ZDR gemindert.** Die **Payload-Pseudonymisierung ist technisch umgesetzt**
> (Geburtsjahr→Dekaden-Bucket, Stadt entfernt, Memory-Drittname-Reduktion, Stand
> 2026-06-07 `rebreak-backend`) — damit greift jetzt auch die zweite ergänzende
> Maßnahme im Sinne der EDSA-Empfehlungen 01/2020. Das **Übertragungs-Teilrisiko
> bleibt offen** (US-Transfer); offen sind noch (b) AVV/DPA-Geltung mit Groq und
> (c) TIA-Dokumentation. Bitte R-DATA-05 entsprechend auf **Restrisiko nach
> Maßnahme** herabstufen, sobald TIA steht und hans-mueller die Nickname-Frage
> rechtlich bewertet hat.

### 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 (deemed-signed) | SCC M2+M3 eingebunden · **TIA offen** · **ZDR aktiv** | **Hoch — teilw. gemindert, 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**~~ — **TECHNISCH ERLEDIGT (Stand 2026-06-07, `rebreak-backend`).** Geburtsjahr→Dekaden-Bucket, Stadt entfernt, Memory-Drittname-Instruktion. Offen (rechtlich): Nickname als Pseudonym durch hans-mueller zu bewerten. | M | `rebreak-backend` DONE; hans-mueller Folge-Bewertung |
| ~~K2~~ | ~~**Groq ZDR aktivieren**~~ — **ERLEDIGT (Stand 2026-06-07, Gründer-Bestätigung).** Folge-Aufgabe: **schriftliche Account-spezifische ZDR-Bestätigung von Groq** als Nachweis zur Akte nehmen | S | User/DSB |
| K3 | **Groq-DPA/SCC-Geltung verifizieren + TIA** (FISA 702 / EO 12333) erstellen. DPA + SCCs (M2/M3) sind deemed-signed vorhanden → Schwerpunkt liegt auf **TIA-Dokumentation** (mit ZDR + Pseudonymisierung als ergänzende Maßnahmen) | 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 (**R-DATA-05**), Mail-Agent-Vollzugriff | **Dok 04 Risikomanagement-Akte** — R-DATA-05: Retention-Teil durch **ZDR gemindert**, Übertragungs-Teil offen; Pseudonymisierung = gemeinsame Restrisiko-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) —
  belegt (abgerufen 2026-06-07): ZDR für **alle** Kunden in Data-Controls aktivierbar;
  Default = keine Retention für Inferenz, aber Abuse-/Reliability-Logging (bis 30 Tage)
  ohne ZDR möglich; Customer-Data in **US-GCP-Buckets**, **keine EU-Residency**.
- [Groq — Data Processing Addendum](https://console.groq.com/docs/legal/customer-data-processing-addendum) —
  belegt (abgerufen 2026-06-07): **EU-SCCs 2021 eingebunden, Modul 2 + Modul 3**,
  **deemed-signed** mit der Services-Agreement (DPA §8.2); Subprozessoren-Liste mit
  15-Tage-Vorlauf; „sensitive data" in Annex I anerkannt; Transfers „to/in the U.S.".
- [Groq — Subprozessoren](https://trust.groq.com/subprocessors) — **mit Groq zu
  verifizieren**, dass DPA/SCC-Geltung für den Rebreak-Account aktiv ist.
- **Zu verifizieren mit Groq (keine harte Quelle):** Account-spezifischer aktiver
  ZDR-Status (schriftliche Bestätigung), Greifen der deemed-signed DPA/SCCs für den
  konkreten Rebreak-Account.
- 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.*