rebreak-monorepo/docs/specs/diga/08-datenschutz-audit-v0.md

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 — 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 — 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 — 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.