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.

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
• Groq — Data Processing Addendum
• Groq — Subprozessoren
• 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.