From 7f529c3be3fc7f40114bc6afafc3b6d85efa2e0d Mon Sep 17 00:00:00 2001 From: chahinebrini Date: Sun, 7 Jun 2026 08:35:13 +0200 Subject: [PATCH] feat(privacy): Coach-Payload an LLM-Provider pseudonymisieren (Art.9/DSGVO) Schliesst hans-muellers K1-Befund (Datenschutz-Audit): der Coach-Prompt sendete Identifier + Art.9-nahe Daten an US-LLMs (Gemini/OpenAI/Anthropic). - message.post.ts: Geburtsjahr/exaktes Alter -> Altersgruppe (Dekaden-Bucket); Stadt komplett entfernt (Bundesland bleibt). Geschlecht/Familienstand/Beruf/ Nickname unveraendert (gewollte Personalisierung; Nickname = Pseudonym). - lyraMemoryExtract.ts: Extraction-Prompt reduziert Dritt-Klarnamen auf Rolle ("Frau Maria" -> "seine Frau"), keine Orte/Arbeitgeber im Memory-Content. - 08-datenschutz-audit: Payload-Audit-Platzhalter durch Vorher/Nachher-Tabelle ersetzt, K1 erledigt, ZDR-Update (DPA/SCCs deemed-signed, TIA offen). Pseudonymisierung zaehlt jetzt als zweite Schutzmassnahme neben ZDR fuer die TIA. Co-Authored-By: Claude Opus 4.8 --- backend/server/api/coach/message.post.ts | 13 +- backend/server/utils/lyraMemoryExtract.ts | 4 +- docs/specs/diga/08-datenschutz-audit-v0.md | 157 ++++++++++++++------- 3 files changed, 120 insertions(+), 54 deletions(-) diff --git a/backend/server/api/coach/message.post.ts b/backend/server/api/coach/message.post.ts index a3ef02e..eb1fce2 100644 --- a/backend/server/api/coach/message.post.ts +++ b/backend/server/api/coach/message.post.ts @@ -545,10 +545,13 @@ export default defineEventHandler(async (event) => { const demoLines: string[] = []; if (profile?.birthYear) { - const age = new Date().getFullYear() - profile.birthYear; - demoLines.push( - `- Alter: ca. ${age} Jahre (Geburtsjahr ${profile.birthYear})`, - ); + // Pseudonymisierung: kein exaktes Geburtsjahr / Alter an LLM-Provider (US). + // Stattdessen Dekaden-Bucket (z.B. "30–40") — Empathie-Kontext ohne Identifikator. + const currentYear = new Date().getFullYear(); + const age = currentYear - profile.birthYear; + const bucketStart = Math.floor(age / 10) * 10; + const bucketEnd = bucketStart + 10; + demoLines.push(`- Altersgruppe: ${bucketStart}–${bucketEnd} Jahre`); } if (profile?.gender) { const GENDER_LABEL: Record = { @@ -577,7 +580,7 @@ export default defineEventHandler(async (event) => { if (profile?.profession) demoLines.push(`- Beruf: ${profile.profession}`); if (profile?.bundesland) demoLines.push(`- Bundesland: ${profile.bundesland}`); - if (profile?.city) demoLines.push(`- Stadt: ${profile.city}`); + // Stadt wird NICHT an LLM-Provider übermittelt (Pseudonymisierung, K1-Maßnahme). if (demoLines.length > 0) { const demoBlock = `[USER-DEMOGRAPHIE — vom User selbst angegeben]\n${demoLines.join("\n")}\nNutze diese Infos nur für Empathie + Kontext. Frage NIEMALS nach diesen Daten — der User pflegt sie selbst in der Profile-Form.\n\n`; systemPrompt = `${demoBlock}${systemPrompt}`; diff --git a/backend/server/utils/lyraMemoryExtract.ts b/backend/server/utils/lyraMemoryExtract.ts index b7497b1..76aeaa9 100644 --- a/backend/server/utils/lyraMemoryExtract.ts +++ b/backend/server/utils/lyraMemoryExtract.ts @@ -26,7 +26,9 @@ Regeln: - Nur Wesentliches. Wenn nichts Neues drin ist → leeres Array []. - confidence: 0.9+ wenn User explizit gesagt, 0.5-0.7 wenn implizit, <0.5 garnicht extrahieren. - content in der Sprache des Gesprächs (DE). -- Maximal 8 Einträge pro Extraktion.`; +- Maximal 8 Einträge pro Extraktion. +- DATENSCHUTZ — Klarnamen Dritter (echte Vornamen/Nachnamen von Personen im Umfeld des Users, z.B. "seine Frau Maria", "sein Freund Thomas") NIEMALS speichern. Ersetze durch Rolle/Beziehung ("seine Frau", "ein enger Freund"). Nur die Beziehung ist relevant, nicht der Name. +- DATENSCHUTZ — Keine Orte, Adressen, Arbeitgeber-Namen oder andere lokalisierenden Angaben im content.`; export async function extractAndStoreMemories( userId: string, diff --git a/docs/specs/diga/08-datenschutz-audit-v0.md b/docs/specs/diga/08-datenschutz-audit-v0.md index fef306b..3825b58 100644 --- a/docs/specs/diga/08-datenschutz-audit-v0.md +++ b/docs/specs/diga/08-datenschutz-audit-v0.md @@ -3,6 +3,9 @@ > **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 @@ -116,65 +119,113 @@ 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. +> **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. -**Befund:** +**Was ZDR mindert (Speicher-/Retention-Teil):** -- **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. +- 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.)* -**Zusätzliche technische Maßnahmen (Art. 32 + EDSA-Empfehlungen 01/2020):** +**Was ZDR NICHT mindert — verbleibender Rest (Übertragungsteil) — `Hoch`:** -Da SCCs allein das FISA-702-Problem nicht heilen (vgl. Schrems II), sind ergänzende -Maßnahmen Pflicht. Priorisiert umsetzbar: +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. **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. +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: `Kritisch`** bis Pseudonymisierung + ZDR + SCC/TIA -nachweislich stehen. +**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:** 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. +> **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 verfügbar | **SCC + TIA + ZDR Pflicht** | **kritisch — s. §2.2** | +| **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** | @@ -294,9 +345,9 @@ Aufwand grob: **S** ≤ 1 Tag · **M** = Tage · **L** = 1–2 Wochen · **XL** | # | 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 | +| ~~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` | @@ -334,7 +385,7 @@ 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 | +| 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 | @@ -356,9 +407,19 @@ Andockpunkte: - 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) +- [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. ---