---
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 wird in bd-Issues gepflegt und enthält mehrere DSGVO‑relevante Workstreams:

- 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.