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 <noreply@anthropic.com>

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;
+    // Pseudonymisierung: kein exaktes Geburtsjahr / Alter an LLM-Provider (US).
-    demoLines.push(
+    // Stattdessen Dekaden-Bucket (z.B. "30–40") — Empathie-Kontext ohne Identifikator.
-      `- Alter: ca. ${age} Jahre (Geburtsjahr ${profile.birthYear})`,
+    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<string, string> = {
@@ -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}`;

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,

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
+> **Statusänderung (Stand 2026-06-07): teilweise gemindert.** Zero Data Retention
-> KI-Coach Lyra enthalten Gesundheitsdaten (Art. 9) und werden zur Inferenz an
+> (ZDR) bei Groq ist laut Bestätigung des Gründers **aktiviert**. Damit ist der
-> **Groq Inc. (USA)** übermittelt. Das ist ein **Drittland-Transfer besonderer
+> **Speicher-/Retention-Teil** des Risikos adressiert: Groq bewahrt die übermittelten
-> Kategorien** — der sensibelste Datenfluss im gesamten System.
+> 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:
+- Groq dokumentiert: „All customers may enable Zero Data Retention (ZDR) in Data
-  **EU-Standardvertragsklauseln 2021 (SCCs, Modul 2 C2P)** + **Transfer-Impact-
+  Controls settings." Bei aktivem ZDR werden Customer-Data für Inferenz-Requests
-  Assessment (TIA)** wegen FISA 702 / EO 12333 (US-Überwachungsbefugnisse). Groq
+  **nicht aufbewahrt**, und das andernfalls mögliche **Abuse-/Reliability-Logging**
-  stellt eine **DPA mit eingebundenen SCCs** sowie eine Subprozessoren-Liste bereit
+  (Inputs/Outputs, sonst bis zu 30 Tage) entfällt. Für Art.-9-Daten war genau dieses
-  (`trust.groq.com/subprocessors`) — **zu verifizieren + abzuschließen**, ob diese
+  Logging der kritische Punkt — er ist mit aktivem ZDR geschlossen.
-  DPA tatsächlich gezeichnet ist.
+  *(Beleg: Groq „Your Data in GroqCloud". **Schriftliche Account-spezifische
-- **Data-Retention-Default ist die Stolperfalle — `Kritisch`.** Laut Groq-Doku werden
+  Bestätigung des aktiven ZDR-Status für den Rebreak-Account ist als Nachweis zur
-  Kundendaten **standardmäßig nicht aufbewahrt**, ABER bei vermuteter Reliability-/
+  Akte zu nehmen** — Gründer-Aussage allein genügt für das BfArM-Dossier nicht.)*
-  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):**
+**Was ZDR NICHT mindert — verbleibender Rest (Übertragungsteil) — `Hoch`:**
 
-Da SCCs allein das FISA-702-Problem nicht heilen (vgl. Schrems II), sind ergänzende
+Die Daten werden **weiterhin in die USA an einen US-Auftragsverarbeiter (Groq Inc.)
-Maßnahmen Pflicht. Priorisiert umsetzbar:
+ü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
+1. **AVV / DPA (Art. 28) — `Hoch`.** Groq stellt eine **Data Processing Addendum**
-   **keine** direkten Identifikatoren (Klarname, E-Mail, User-ID, Account-ID) gehen.
+   bereit, die mit Abschluss der Services-Agreement als **abgeschlossen gilt**
-   Übertragen wird ausschließlich der **Konversationsinhalt** plus ggf. ein
+   („deemed to have signed", DPA §8.2) — also **kein** separater Unterschriftsakt
-   **rotierender Pseudonym-Token**, dessen Auflösung **nur bei Rebreak/Hetzner DE**
+   nötig. *Zu verifizieren mit Groq:* dass die Rebreak-Account-Konfiguration die
-   liegt. **Zu verifizieren im Code:** Was genau geht im Groq-Request-Payload raus?
+   Services-Agreement (und damit die DPA) tatsächlich akzeptiert hat, und dass die
-   Werden System-Prompt/Kontext mit Klarnamen oder demografischen Klartext-Feldern
+   **Subprozessoren-Liste** (`trust.groq.com/subprocessors`, 15-Tage-Vorlauf bei
-   angereichert? Das ist der wichtigste Einzel-Check dieses Audits.
+   Änderungen) reviewt ist.
-2. **ZDR + Abuse-Logging-Opt-out** (s.o.).
+2. **SCCs (Standardvertragsklauseln) — `Hoch`.** Die DPA bindet die **EU-SCCs 2021**
-3. **Datenminimierung im Kontextfenster** — nur das nötige Gesprächsfenster, keine
+   ein, **Modul 2 (Controller→Processor)** und **Modul 3 (Processor→Sub-Processor)**,
-   Historie mit Demografie/Realnamen.
+   deemed-signed mit der Agreement (DPA §8.2.a; belegt aus Groq-DPA-Text). Das ist
-4. **TIA dokumentieren** — Risikobewertung FISA 702 / EO 12333, Eintrittswahrschein-
+   die formale Transfer-Grundlage nach Kapitel V — **vorhanden, aber zu
-   lichkeit, Wirksamkeit der Pseudonymisierung als Gegenmaßnahme.
+   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
+**Risiko gesamt Lyra/Groq: `Hoch` (zuvor `Kritisch`) — teilweise gemindert durch
-nachweislich stehen.
+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
+> **Andockpunkt zu Marlene (Risiko-Akte `R-DATA-05`):** Dieser Datenfluss ist der
-> (Dok 04)** — „Übermittlung sensibler Daten an US-Subprozessor". Datenschutz-
+> Risiko-Akte-Eintrag **R-DATA-05** (Dok 04) — „Übermittlung sensibler Daten an
-> Maßnahme (Pseudonymisierung) und ISO-14971-Risikomaßnahme sind hier deckungsgleich.
+> 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) |
+| ~~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** (Zero Data Retention) + schriftlich bestätigen; Abuse-Logging-Risiko schließen | S | User/DSB |
+| ~~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 zeichnen + TIA** (FISA 702 / EO 12333) erstellen | M | User + Anwalt |
+| 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 — 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)
+  belegt (abgerufen 2026-06-07): ZDR für **alle** Kunden in Data-Controls aktivierbar;
-- [Groq — Subprozessoren](https://trust.groq.com/subprocessors)
+  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.
 
 ---