further rework to the documentation

docs/ops/compliance-dsgvo-ops.md

@@ -0,0 +1,90 @@
+---
+title: DSGVO & Compliance-Operationen
+sidebar_label: DSGVO-Operationen
+---
+
+Dieses Runbook beschreibt praktische Abläufe für Datenschutz‑Anfragen, Datenlöschung und Aufbewahrungsfristen.
+
+## 1. Grundprinzipien
+
+- Gäste benötigen kein Konto; die meisten Daten sind Event‑ und Foto‑bezogen.
+- Tenant Admins sind in der Regel Verantwortliche im Sinne der DSGVO, Fotospiel fungiert als Auftragsverarbeiter (je nach Vertragsmodell).
+- Rechtsgrundlagen, Impressum und Datenschutzerklärungen werden über die Legal‑Pages im Admin verwaltet – dieses Dokument fokussiert sich auf **Betriebsprozesse**.
+
+## 2. Typische Anfragen & Aktionen
+
+- **Auskunftsanfragen**
+  - Gast möchte wissen, ob Fotos von ihm/ihr gespeichert sind.
+  - Typischer Ablauf:
+    - Gast an Tenant verweisen (wenn Veranstalter Ansprechpartner ist).
+    - Falls Fotospiel direkt handeln muss: Event/Foto‑IDs anhand bereitgestellter Infos identifizieren (z.B. Link, Screenshot, Zeitfenster).
+    - Relevante Datensätze in DB (Fotos, Likes, Meldungen) lokalisieren und dokumentieren.
+- **Löschanfragen**
+  - Ein Gast/Tenant bittet um Löschung spezifischer Fotos oder eines ganzen Events.
+  - Vorgehen:
+    1. Identität und Berechtigung prüfen (z.B. Tenant Admin, verifizierte Anfrage).
+    2. Fotos/Ereignisse über Admin UI oder interne Tools löschen/archivieren.
+       - Sicherstellen, dass `event_media_assets` und Archiv‑Speicher ebenfalls bereinigt werden.
+    3. Prüfen, ob Logs/Audits pseudonymisiert bleiben können, ohne personenbezogene Inhalte.
+    4. Anfrage und Zeitpunkt dokumentieren (Ticket, internes Log).
+- **Datenexport**
+  - Tenant will einen Export seiner Daten (Events, Medien, Statistiken).
+  - Nutzung der vorhandenen Export‑Funktionen (z.B. CSV/ZIP im Admin) bevorzugen.
+  - Falls diese nicht ausreichen, manuelle Exporte via Skript/DB mit Datenschutz im Blick (keine unnötigen Felder).
+    - Beispiel: nur die Felder exportieren, die für den Zweck der Anfrage wirklich notwendig sind (kein Debug‑Log, keine internen IDs, sofern nicht sinnvoll).
+
+### 2.1 Konkrete Tools & Endpoints
+
+- **Profil-Datenexport (User-Ebene)**
+  - Controller: `App\Http\Controllers\ProfileDataExportController`.
+  - UI: Profilbereich der Tenant Admin PWA; Nutzer kann dort einen Export anstoßen.
+  - Ablauf:
+    1. Nutzer triggert Export → `ProfileDataExportController::store()` legt einen `DataExport`‑Eintrag an (`status = pending`) und dispatcht `GenerateDataExport`.
+    2. Der Job `GenerateDataExport` erstellt ein ZIP mit relevanten Daten und setzt `status = ready`, `path`, ggf. `expires_at`.
+    3. Nutzer kann die Datei über `ProfileDataExportController::download()` abrufen, solange `isReady()` und nicht `hasExpired()`.
+  - Ops-Sicht:
+    - Wenn Exporte „hängen bleiben“ (lange `pending`/`processing`), Queue/Horizon und Logs prüfen, ggf. Job neu anstoßen.
+    - Für DSGVO‑Exports bevorzugt diesen Pfad nutzen, statt ad‑hoc DB‑Abfragen.
+
+- **Account-Anonymisierung (User/Tenant-Ebene)**
+  - Service: `App\Services\Compliance\AccountAnonymizer`.
+  - Job: `App\Jobs\AnonymizeAccount` nutzt diesen Service typischerweise im Hintergrund.
+  - Verhalten:
+    - Löscht/entfernt Medien (`EventMediaAsset`, `Photo`) für einen Tenant.
+    - Anonymisiert Tenant‑ und User‑Daten (setzt neutrale Namen, entfernt Kontaktinfos, sperrt Accounts).
+  - Ops-Sicht:
+    - Nur nach klarer Freigabe einsetzen, da Anonymisierung irreversibel ist.
+    - Vor Einsatz prüfen, ob für den betreffenden Tenant alle vertraglichen Zusagen (z.B. Datenexport) erfüllt sind.
+
+## 3. Retention & automatisierte Löschung
+
+- **Event-bezogene Aufbewahrung**
+  - Standard‑Retentionsfristen für Events/Fotos (z.B. X Tage nach Eventende/Archivierung) laut Produkt‑Spezifikation.
+  - Jobs/Kommandos, die nach Ablauf Medien archivieren oder löschen (siehe `docs/ops/media-storage-spec.md`).
+- **Logs**
+  - Aufbewahrungsdauer von Applikations‑Logs (z.B. 30–90 Tage), Rotation/Anonymisierung.
+- **Konfiguration pro Tenant**
+  - Wenn Tenants eigene Retention wünschen, prüfen ob das UI/Config‑Model dies unterstützt (nicht ad‑hoc in SQL ändern).
+
+## 4. Operative Checkliste bei DSGVO-Fällen
+
+1. Anfrage klassifizieren (Auskunft, Löschung, Export, Sonstiges).
+2. Verantwortlichkeit klären (Tenant vs. Fotospiel).
+3. Technische Schritte definieren (welche Events/Fotos/Accounts betroffen).
+4. Durchführung:
+   - In Admin UI oder via internen Tools.
+   - Medien/Metadaten konsistent behandeln (keine „hängenden“ Records).
+5. Dokumentation:
+   - Ticket/E-Mail‑Thread mit Datum, Betreff, Maßnahmen.
+6. Follow‑Up:
+   - Prüfen, ob Runbooks/Automatisierungen angepasst werden sollten (z.B. besserer Self‑Service für Tenants).
+
+## 5. Verbindung zu Security-Hardening
+
+Das Security‑Hardening‑Epic (`docs/process/todo/security-hardening-epic.md`) enthält mehrere Workstreams, die DSGVO‑relevant sind:
+
+- Signierte Asset‑URLs statt direkter Storage‑Links.
+- Verbesserte Token‑/Auth‑Flows.
+- Storage‑Health und Checksummen‑Verifizierung.
+
+Wenn dort neue Features produktiv gehen, sollten die Auswirkungen auf DSGVO‑Prozesse in diesem Runbook ergänzt werden.