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