fotospiel-app/docs/ops/compliance-dsgvo-ops.md

title, sidebar_label

title	sidebar_label
DSGVO & Compliance-Operationen	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.