Betroffenenrechte — operative Prozesse

ENTWURF — vor Veröffentlichung anwaltliche Prüfung erforderlich. Kein Rechtsrat. Stand: 25.07.2026 (Finalisierung).

Dieses Dokument beschreibt, wie WARP heute (Beta-Stand, Code-Basis ddbba50) eingehende Anfragen nach Art. 15–21 DSGVO operativ bearbeiten kann — auch dort, wo das noch manuell über Datenbank-Zugriff, Ticket und Dokumentation geschehen muss. Es ist eine Arbeitsanleitung, keine Rechtsberatung; Rechtsgrundlagen-Angaben sind vorläufige Einordnungen zur anwaltlichen Bestätigung. Am 25.07.2026 eingearbeitet: Eingangskanal datenschutz@wawihub.de, Löschfristen nach Vertragsende (F-23), Serverstandort Helsinki. Offene Sachfragen sind als [PLATZHALTER: F-x] markiert und in OFFENE-PUNKTE.md gelistet.

Zentraler Eingangskanal für alle datenschutzrechtlichen Anfragen betroffener Personen (Auskunft, Löschung, Berichtigung, Widerspruch, Widerruf) ist das Postfach datenschutz@wawihub.de. Damit ist der bislang offene Punkt „kein definierter Eingangskanal für Löschersuchen" (O-1) aufgehoben. Eingehende Anfragen über andere Kanäle (allgemeiner Support support@wawihub.de, Postweg) sind unverzüglich in diesen Prozess zu überführen und im Anfragen-Register (Abschnitt 1.3) zu erfassen.

0. Zwei Betroffenen-Typen — Grundunterscheidung

Jede eingehende Anfrage ist zuerst einem der beiden folgenden Typen zuzuordnen. Diese Zuordnung entscheidet, ob WARP die Anfrage selbst bearbeitet oder weiterleiten muss (siehe Abschnitt 2).

Merksatz für alle folgenden Abschnitte: Immer zuerst fragen „Wer stellt die Anfrage — ein Vertragspartner von WARP (Typ A) oder ein Kunde eines WARP-Kunden (Typ B)?", bevor irgendetwas bearbeitet wird.

1. Grundsätze für jede Anfrage

1.1 Fristen (Art. 12 (3) DSGVO)

• Regelfrist: unverzüglich, spätestens innerhalb eines Monats nach Eingang der Anfrage.
• Verlängerung: um weitere zwei Monate möglich bei Komplexität/Vielzahl von Anfragen — die betroffene Person ist innerhalb der ersten Monatsfrist über die Verlängerung und deren Gründe zu informieren.
• Fristbeginn: Tag des nachweisbaren Eingangs der Anfrage (E-Mail an datenschutz@wawihub.de, Support-Ticket, Postweg).
• Ablehnung: Wird eine Anfrage nicht bearbeitet, ist die betroffene Person spätestens binnen eines Monats über die Gründe sowie über das Beschwerderecht bei einer Aufsichtsbehörde und den gerichtlichen Rechtsbehelf zu informieren.

1.2 Identitätsprüfung

Vor jeder inhaltlichen Bearbeitung ist die Identität der anfragenden Person zu verifizieren, um Datenherausgabe an Unberechtigte auszuschließen:

• Typ A (Händler-Nutzer): Anfrage-Absenderadresse gegen users.email des betroffenen Kontos abgleichen; bei Zweifel Rückfrage über einen zweiten, bereits bekannten Kanal (z. B. die E-Mail-Adresse eines weiteren, bereits bekannten Nutzers desselben Mandanten aus users.email, verknüpft über customerId, i. d. R. eines CUSTOMER_ADMIN; ein separates Kontaktfeld auf Ebene customers ist im dokumentierten Datenmodell nicht vorhanden).
• Typ B (Endkunde): WARP selbst führt keine Identitätsprüfung durch — die Anfrage wird ohnehin an den Händler weitergeleitet (Abschnitt 2); die Identitätsprüfung ist dort Sache des Händlers als Verantwortlichem.
• Bei Unsicherheit über die Identität: keine Daten herausgeben, stattdessen weitere Nachweise anfordern; die dadurch verstrichene Zeit hemmt die Monatsfrist nicht automatisch — im Zweifel anwaltlich klären.

1.3 Dokumentationspflicht

Jede Anfrage ist — unabhängig vom Ausgang — zu dokumentieren (Rechenschaftspflicht Art. 5 (2) DSGVO):

• Eingangsdatum, Kanal, anfragende Person, Anfrage-Typ (A/B), betroffenes Recht (Art. 15/16/17/18/20/21).
• Ergebnis der Identitätsprüfung.
• Entscheidung: selbst bearbeitet / weitergeleitet an Händler / abgelehnt (mit Begründung).
• Datum der Antwort, ggf. Fristverlängerung mit Begründung.
• Empfehlung: bis zur Einführung eines dedizierten Tickets/Tools ein einfaches Anfragen-Register (Tabelle/Spreadsheet) führen — [PLATZHALTER: F-36, Zielbild Self-Service-Tooling].

2. Weiterleitungsprozess — wenn sich ein Endkunde (Typ B) direkt an WARP wendet

Das ist der wichtigste Sonderfall, weil hier eine falsche Reaktion (materielle Beantwortung durch WARP) die Rollenaufteilung aus Art. 28 verletzen würde.

Warum: Für VT-8 bis VT-11 ist WARP nur Auftragsverarbeiter. Nach Art. 28 (3) e DSGVO unterstützt der Auftragsverarbeiter den Verantwortlichen bei der Erfüllung von Betroffenenrechten — er erfüllt sie nicht selbst gegenüber der betroffenen Person. Antwortet WARP dem Endkunden direkt inhaltlich (z. B. mit einer Auskunft aus warp_attribution_events oder warp_rfm_snapshots), handelt WARP ohne Weisung des Verantwortlichen und damit potenziell rechtswidrig.

2.1 Klartext-Ablauf

1. Erkennen: Anfrage kommt nicht von einem WARP-Vertragspartner (users.email unbekannt), sondern bezieht sich auf einen Shop/Bestellung/Besuch bei einem Händler → Typ B.
2. Nicht materiell beantworten. Keine Daten aus warp_rfm_snapshots, warp_customer_clv_snapshots, warp_attribution_events oder sonstigen Auftragsverarbeitungs-Tabellen an den Endkunden herausgeben, keine Löschung/Berichtigung dort vornehmen.
3. Höflicher Verweis an den Endkunden: Mitteilen, dass WARP im Auftrag des jeweiligen Händlers verarbeitet und nicht die verantwortliche Stelle ist; den Endkunden an den Händler (dessen Kontaktdaten dem Endkunden i. d. R. aus dem Shop/der Bestellbestätigung bekannt sind) verweisen. Falls der Endkunde den Händler nicht benennen kann/will: anhand der Anfrage (z. B. genannte Bestellnummer, Shop-URL, Absenderdomain) versuchen, den betroffenen Tenant zu identifizieren, und nur dessen Namen (nicht dessen interne Daten) mitteilen, sofern zweifelsfrei zuordenbar; im Zweifel keine Zuordnung kommunizieren.
4. Händler informieren: Den zuständigen Händler — d. h. die bei WARP hinterlegte(n) Nutzer-E-Mail-Adresse(n) des betroffenen Mandanten (users.email mit passendem customerId, i. d. R. CUSTOMER_ADMIN; ein separates Kontaktfeld auf Ebene customers ist im dokumentierten Datenmodell nicht vorhanden) — unverzüglich über die eingegangene Anfrage informieren — mit allen Angaben, die der Endkunde gemacht hat (Anfrage-Text, Kontaktkanal, Datum) — sowie mit dem ausdrücklichen Hinweis auf die laufende Monatsfrist (Abschnitt 1.1), damit der Händler seine eigene Frist wahren kann. Empfehlung für den Hinweistext: „Diese Anfrage ist von Ihnen als Verantwortlichem gemäß Art. 12 (3) DSGVO grundsätzlich innerhalb eines Monats ab dem oben genannten Eingangsdatum bei WARP zu beantworten."
5. Unterstützung anbieten: Dem Händler anbieten, bei der technischen Umsetzung (Auskunft/Löschung in den WARP-Systemen) im Rahmen der Weisung des Händlers zu unterstützen (Art. 28 (3) e) — Bearbeitung dann wie in Abschnitt 3–6, jeweils Typ-B-Pfad, aber ausgelöst durch die Weisung des Händlers, nicht direkt durch den Endkunden.
6. Dokumentieren: Eingang, Weiterleitung, Informationsdatum an Händler, Fristhinweis — vollständig im Anfragen-Register (Abschnitt 1.3) erfassen.

2.2 Wenn der Händler nicht reagiert

Reagiert der Händler nicht innerhalb einer angemessenen Zeit vor Ablauf der Monatsfrist, sollte WARP nochmals erinnern und den Vorgang dokumentieren. Eine eigenständige materielle Beantwortung durch WARP bleibt die Ausnahme und ist vorab anwaltlich zu klären [PLATZHALTER: F-40].

3. Art. 15 — Auskunft

3.1 Typ A (Händler-Nutzer) — WARP bearbeitet selbst

Zu durchsuchende Tabellen/Systeme (gemäß VT-1 bis VT-7):

Vorgehen (manueller Export, Stand heute):

1. Tenant/customerId bzw. userId der betroffenen Person eindeutig bestimmen.
2. Tenant-skopierten Datenbankzugriff verwenden — d. h. die Session-GUC warp.tenant_id korrekt setzen bzw. über die tenant-gebundene Anwendungsrolle (warp_app) abfragen, niemals über eine RLS-umgehende Rolle (warp_control/warp_owner), außer für die dokumentiert notwendigen Admin-/Audit-Tabellen, die ohnehin plattformweit sind.
3. Für jede Tabelle aus der obigen Liste die Zeilen mit userId = <ID> bzw. customerId = <ID> selektieren und in ein lesbares Format (CSV/JSON/PDF) exportieren.
4. Export vor Versand auf enthaltene Daten Dritter prüfen (z. B. warp_admin_audit-Einträge können remote_addr/on_behalf_of anderer Personen enthalten) und ggf. schwärzen.
5. Erläuternde Begleitinformationen nach Art. 15 (1) beifügen: Verarbeitungszwecke, Kategorien, Empfänger (Stripe (USA, noch kein DPA), Hetzner (Helsinki, Finnland), IONOS (DE/EU)), geplante Speicherdauer (laufend derzeit größtenteils [PLATZHALTER: F-21], da kein Löschjob existiert; nach Vertragsende 30/60(max. 90) Tage, F-23), Herkunft der Daten, Bestehen von Betroffenenrechten sowie — soweit personenbezogene Daten an Stripe in die USA übermittelt werden — den nach Art. 15 (2) DSGVO gebotenen Hinweis auf die Datenübermittlung in ein Drittland und die dafür bestehenden Garantien (Art. 44 ff.) [PLATZHALTER: F-12].

3.2 Typ B (Endkunde) — nur im Auftrag, i. d. R. über den Händler

Nach dem Weiterleitungsprozess (Abschnitt 2) erfolgt eine Bearbeitung durch WARP ausschließlich auf Weisung des Händlers. Relevante Tabellen (VT-8 bis VT-11):

Vorgehen: Der Händler benennt die betroffene Person möglichst konkret (Name, E-Mail, Bestellnummer, ungefährer Zeitraum). WARP sucht tenant-skopiert (RLS/tenant_id) in den genannten Tabellen nach zuordenbaren Zeilen (über kKunde, Bestellnummer, oder — mit Unterstützung des Händlers, der den Pepper/die Zuordnungslogik im Shop kennt — über Session-/Visitor-Hash) und liefert den Export an den Händler, der ihn an den Endkunden weiterreicht. WARP übermittelt Auskunftsdaten zu Endkunden nicht direkt an den Endkunden.

4. Art. 16 — Berichtigung

Typ A

Kurzprozess: betroffene Person benennt fehlerhafte Angabe (i. d. R. users.name/users.email, customers.name). Berichtigung durch Admin über bestehende Verwaltungsfunktionen bzw. direkten, dokumentierten DB-Update mit Vier-Augen-Kontrolle. Dokumentation im Anfragen-Register.

Typ B

Kurzprozess: WARP leitet die Berichtigungsanfrage nach Abschnitt 2 an den Händler weiter. Auf Weisung des Händlers korrigiert WARP die betreffenden Zeilen in den tenant-skopierten Tabellen (z. B. falsch zugeordnete kKunde-Verknüpfung), sofern die Korrektur nicht ohnehin durch eine erneute Synchronisation aus dem JTL-System des Händlers erfolgt (da Endkunden-Stammdaten bei WARP größtenteils nur transient nachgeladen und nicht persistiert werden, VT-9).

5. Art. 17 — Löschung (Kernstück)

Löschung ist bei WARP nicht ein einzelner DELETE-Befehl, sondern muss über fünf unterschiedliche Speicherorte koordiniert werden, die je nach Betroffenen-Typ unterschiedlich betroffen sind. Im Folgenden je Typ der konkrete Löschpfad.

5.0 Vorbemerkung — was heute strukturell fehlt

Für keine der unten genannten Tabellen existiert im untersuchten Code ein automatisierter Löschjob (siehe DATENFLUESSE.md, Teil E Punkt 3 sowie OFFENE-FRAGEN.md/OFFENE-PUNKTE.md F-21/F-37/F-38). Jede Löschung ist derzeit ein manueller, dokumentierter Vorgang durch eine Person mit direktem, privilegiertem Datenbankzugriff. Das ist für die Beta-Phase mit geringer Nutzerzahl vertretbar, aber kein Dauerzustand — siehe Abschnitt 7. Für die Löschung/Rückgabe nach Vertragsende gilt zusätzlich der Rahmen aus AGB/AVV: 30 Tage Self-Service-Export, endgültige Löschung spätestens 60 (max. 90) Tage nach Vertragsende (F-23).

5.1 (i) Produktions-Datenbank — RLS-Mandantendaten

Typ A — Löschpfad Händler-Nutzer/Konto:

Reihenfolge wegen Fremdschlüsseln/Kaskaden (von abhängig zu übergeordnet, damit keine verwaisten Fremdschlüssel-Verweise entstehen bzw. in der vom Schema vorgesehenen Kaskaden-Reihenfolge):

1. login_attempts (HMAC-Schlüssel zu dieser Person — self-cleaning, aber vorsorglich prüfen)
2. auth_rate_limits (dito)
3. account_action_tokens (userId-Verweis)
4. mail_outbox (userId-Verweis)
5. warp_admin_audit — Sonderfall: dies ist ein Nachweis-/Sicherheitslog; vollständige Löschung kann der Rechenschaftspflicht bzw. eigenen berechtigten Interessen (Art. 6 (1) f) entgegenstehen. Empfehlung: Personenbezug anonymisieren (z. B. sub/Namen entfernen, technische ID durch Platzhalter ersetzen), Vorgang selbst nicht löschen. [PLATZHALTER: F-21, endgültige Aufbewahrungsfrist]
6. accounts (falls befüllt — aktuell inaktiv)
7. Billing-Seite: warp_billing_customer_map, warp_subscription, warp_invoice, warp_billing_event — vor Löschung Abschnitt 5.3 (Stripe, inkl. Aufbewahrungspflichten für Rechnungsdaten, [PLATZHALTER: F-41]) beachten; Rechnungsdaten ggf. nicht löschbar, sondern nur zu sperren/eingeschränkt zu verarbeiten (Art. 18) bis Ablauf der handelsrechtlichen Frist.
8. customers — nur löschen, wenn kein weiterer Nutzer des Mandanten mehr existiert bzw. der gesamte Mandant beendet wird; sonst nur den betroffenen Datensatz in users behandeln.
9. users — der Konto-Datensatz selbst, zuletzt.

Ausführung: über die tenant-gebundene Anwendungsrolle mit korrekt gesetzter warp.tenant_id-GUC, niemals über eine RLS-umgehende Rolle außerhalb der dafür vorgesehenen Admin-/Audit-Fälle. Jeder Schritt einzeln protokollieren (welche Zeile, wann, durch wen).

Typ B — Löschpfad Endkunde eines Händlers:

Da Verantwortlicher der Händler ist, löst WARP die Löschung nur auf Weisung des Händlers aus (nach dem Weiterleitungsprozess, Abschnitt 2). Betroffene Tabellen (tenant-skopiert über tenant_id):

1. warp_attribution_events — Löschung der zuordenbaren Zeilen (Session-/Visitor-Hash bzw. Bestellnummer, vom Händler benannt).
2. warp_rfm_snapshots, warp_customer_clv_snapshots — Zeilen zum benannten kKunde.
3. Margen-Aggregate (warp_order_margin, warp_db3_channel_margin u. ä.), soweit personenbezogen zuordenbar.
4. warp_ga4_*_snapshots/warp_ads_*_snapshots/warp_sc_*_snapshots — nur relevant, falls im Einzelfall eine konkrete Person aus search_term/query/Geo re-identifizierbar würde [PLATZHALTER: F-32]; praktisch kaum gezielt filterbar, da aggregiert.

Wichtige Einschränkung (heute): Für warp_attribution_events gibt es keinen definierten technischen Löschpfad über eine UI/API — die Löschung ist ein manueller, direkter DB-Eingriff. Ein Selbstbedienungs-Opt-out für Endkunden existiert nicht. → siehe Abschnitt 7, F-35.

5.2 (ii) Mail-Outbox — Sonderfall privilegierter Pfad

Befund aus dem Code: Die Worker-Rolle, die mail_outbox im Normalbetrieb verarbeitet, hat kein DELETE-Recht auf diese Tabelle (Least-Privilege-Design). Eine reguläre Löschung über den normalen Anwendungspfad ist damit nicht möglich.

Operativer Weg heute: Löschung von mail_outbox-Zeilen erfordert einen separaten, privilegierten Datenbankzugriff (z. B. über die Eigentümer-/Migrationsrolle, nicht die Worker-Rolle) — durchzuführen durch eine Person mit direktem DB-Zugang, mit Vier-Augen-Dokumentation. Da mail_outbox keine E-Mail-Adresse/keinen Klartextinhalt speichert (nur userId + Metadaten), ist der Personenbezug hier gering, aber bei einer vollständigen Konto-Löschung (Typ A) trotzdem zu bereinigen, da der userId-Verweis sonst nach Löschung des users-Datensatzes verwaist.

5.3 (iii) Stripe — externer Löschweg

Stripe-Daten (Kunden-, Zahlungs-, Rechnungsobjekte) liegen außerhalb der WARP-Datenbank bei Stripe selbst. Löschung/Anonymisierung dort erfolgt nicht durch einen WARP-Datenbank-Vorgang, sondern über das Stripe-Dashboard bzw. die Stripe-API (z. B. Löschung/Anonymisierung eines Customer-Objekts gemäß Stripes eigenem Datenschutz-Werkzeug).

Zu beachten:

• Aufbewahrungspflichten: Rechnungs-/Zahlungsdaten unterliegen regelmäßig handels-/steuerrechtlichen Aufbewahrungsfristen (§ 147 AO, § 257 HGB) — eine vollständige Löschung bei Stripe und in warp_invoice ist ggf. erst nach Fristablauf zulässig; bis dahin kommt Einschränkung der Verarbeitung (Art. 18) statt Löschung in Betracht. Für die Rechnungsschreibung ist zudem LexOffice vorgesehen (AV-Prüfung offen). [PLATZHALTER: F-41]
• Der bei WARP verbleibende Verweis (warp_billing_customer_map.provider_customer_id) sollte nach erfolgter Stripe-seitiger Löschung/Anonymisierung ebenfalls entfernt bzw. der Verweis entwertet werden.
• Rohes Webhook-Event-JSON (warp_billing_event.payload) kann Name/E-Mail aus Stripe-Objekten enthalten und ist bei der Löschung/Anonymisierung mit einzubeziehen, nicht nur die strukturierten Felder. [PLATZHALTER: F-33]
• Stripe-DPA/SCC-Status (zum Finalisierungsstand noch kein Stripe-Konto/DPA) und Live- vs. Testmodus sind gesondert zu klären. [PLATZHALTER: F-12]

5.4 (iv) Logs / Admin-Audit

warp_admin_audit enthält Nachweis-/Sicherheitsdaten (Actor, remote_addr, on_behalf_of-Tenant). Wie in 5.1 dargestellt: Anonymisierung statt vollständiger Löschung ist regelmäßig der richtige Weg, wenn ein berechtigtes Interesse an der Nachweisführung (Art. 6 (1) f) fortbesteht; die endgültige Aufbewahrungsfrist ist offen. [PLATZHALTER: F-21] Weitere, außerhalb der Repos liegende Logs (z. B. nginx-Zugriffslogs, System-Logs auf den WARP-Servern bei Hetzner, Helsinki, Finnland) sind in diesem Dokument nicht erfasst und gesondert zu prüfen.

5.5 (v) Backups — Vorgabe an das Backup-Konzept

Backups sind der Speicherort mit dem größten strukturellen Risiko für „Löschung wirkt nicht dauerhaft". Marktüblicher, hier als Vorgabe an das parallel entstehende Backup-Konzept formulierter Ansatz (deckungsgleich mit dem Backup-Rotationsauslauf in AGB/AVV, F-23/F-38):

1. Löschung im Livesystem sofort: Die eigentliche Löschung (Abschnitte 5.1–5.4) erfolgt unverzüglich im Produktivsystem, unabhängig vom Backup-Zyklus.
2. Verschlüsselte Backups rotieren mit dokumentierter Frist: Bestehende Backup-Mechanik (Fernet-verschlüsselt, Standard-Retention 90 Tage, siehe DATENFLUESSE.md Teil C) rotiert automatisch — ein gelöschter Datensatz verschwindet spätestens nach Ablauf dieser Frist auch aus allen Backup-Generationen, ohne dass er aktiv aus dem Backup entfernt werden muss.
3. Garantie der Re-Löschung nach Restore: Wird ein Backup (z. B. im Rahmen einer Störung) zurückgespielt, muss dabei sichergestellt sein, dass zwischenzeitlich erfolgte Löschungen erneut angewendet werden — sonst lebt ein bereits gelöschter Datensatz durch den Restore wieder auf. Dafür ist ein Löschprotokoll (welche Person/welcher Datensatz wurde wann gelöscht) zu führen, das nach jedem Restore-Vorgang verpflichtend gegen die wiederhergestellten Daten abgeglichen und die betroffenen Löschungen erneut ausgeführt werden. Ohne dieses Protokoll ist ein Restore aus Datenschutzsicht nicht abschließbar.
4. Diese drei Punkte sind als verbindliche Anforderung an das Backup-Konzept zu verstehen, nicht als bereits umgesetzter Zustand — im Code ist aktuell kein Re-Löschungs-Mechanismus nach Restore vorhanden. [PLATZHALTER: F-19, F-38]
5. Zusätzlich offen: Eine Offsite-Sicherung über eine Hetzner Storage Box (EU) ist freigegeben, aber noch nicht eingerichtet; sofern klassische Backups (pg_dump/Hetzner-Snapshots, offsite) hinzukommen, unterliegen auch sie derselben Rotations-/Re-Löschungs-Logik. [PLATZHALTER: F-19]

6. Art. 18 (Einschränkung), Art. 20 (Übertragbarkeit), Art. 21 (Widerspruch)

6.1 Art. 18 — Einschränkung der Verarbeitung

Typ A: Statt Löschung (z. B. während laufender Rechnungsaufbewahrungsfrist, Abschnitt 5.3, oder bei streitiger Richtigkeit nach Art. 16) den betroffenen Datensatz technisch markieren/sperren (z. B. Konto deaktivieren, aber nicht löschen) und von weiterer Verarbeitung außer der Aufbewahrung ausschließen. Heute nur durch manuellen, dokumentierten Eingriff möglich; kein eigenes „Sperr-Flag" im Schema ersichtlich — Umsetzung z. B. über Status-Feld (customers.status) bzw. organisatorische Sperre.

Typ B: Weiterleitung an den Händler (Abschnitt 2); Umsetzung nur auf dessen Weisung, analog zu Löschung in 5.1.

6.2 Art. 20 — Datenübertragbarkeit

Typ A: Betrifft die vom Nutzer selbst bereitgestellten, automatisiert verarbeiteten Daten mit Rechtsgrundlage Vertrag/Einwilligung — im Wesentlichen die Stammdaten aus users/customers. Export als strukturierte, maschinenlesbare Datei (CSV/JSON) aus denselben Quellen wie beim Auskunftsexport (Abschnitt 3.1), beschränkt auf die übertragbarkeitsfähigen Felder. Heute kein automatisiertes Export-Werkzeug — manueller Export wie bei Art. 15. [PLATZHALTER: F-36]

Typ B: Datenübertragbarkeit betrifft die Beziehung Endkunde–Händler; WARP unterstützt nur auf Weisung des Händlers, analog Abschnitt 3.2.

6.3 Art. 21 — Widerspruch

Typ A: Bei auf Art. 6 (1) f gestützten Verarbeitungen (z. B. Admin-Audit/Sicherheitsmaßnahmen, Impersonation) kann widersprochen werden; WARP prüft im Einzelfall, ob zwingende schutzwürdige Gründe überwiegen (z. B. IT-Sicherheit) — Dokumentation der Abwägung im Anfragen-Register.

Typ B: Betrifft in erster Linie den Pixel/Attribution (VT-11, Rechtsgrundlage laut Code-Kommentar Art. 6 (1) f) — hierzu existiert kein technischer Opt-out-Mechanismus für den einzelnen Endkunden (siehe Abschnitt 7, F-35). Ein Widerspruch würde heute nur über den manuellen Löschpfad in Abschnitt 5.1 (Typ B) auf Weisung des Händlers umgesetzt werden können, nicht über eine Selbstbedienungsfunktion.

7. Was heute technisch nicht (voll) erfüllbar ist — priorisierte Produkt-Anforderungen

Diese Punkte sind nicht zu beschönigen — sie sind reale Lücken im heutigen Beta-Stand und müssen als Produkt-Backlog an den Kopf (Lukas) adressiert werden. Priorisierung P1 (dringend, blockiert belastbare Compliance-Aussage) / P2 (wichtig, aber kurzfristig durch manuellen Prozess überbrückbar).

Diese vier Punkte sind untereinander verzahnt: P1-Punkt 4 setzt voraus, dass P1-Punkt 3 überhaupt ein dokumentiertes „was wurde gelöscht" liefert (Löschprotokoll, siehe Abschnitt 5.5). Die Empfehlung ist, Punkt 3 (automatisierte, protokollierte Kontolöschung inkl. abhängiger Tabellen) und Punkt 4 (Re-Löschungs-Garantie nach Restore) gemeinsam mit dem Backup-Konzept zu planen, statt getrennt. Ein vom Kunden angestoßener Selbstbedienungs-Weg zur Konto-/Datenlöschung (z. B. mit kurzer Aufbewahrung vor endgültiger Löschung) ist als Produktanforderung vorgesehen (F-37).

8. Vorlage/Checkliste für die Bearbeitung einer einzelnen Anfrage

Zur Verwendung als Ablaufzettel je eingehender Anfrage:

`
[ ] 1. EINGANG

• Datum/Uhrzeit: __________
• Kanal (datenschutz@wawihub.de / Support / Post): __________
• Anfragende Person / Absenderadresse: __________
• Anfragetext (Kopie/Anhang ablegen): __________

[ ] 2. IDENTITÄT PRÜFEN

• Typ A: Absender gegen users.email abgeglichen? ja/nein
• Bei Zweifel: Rückfrage über zweiten Kanal gestellt? ja/nein
• Typ B: keine WARP-seitige Identitätsprüfung nötig (Weiterleitung)

[ ] 3. TYP BESTIMMEN

• [ ] Typ A — Händler-Nutzer (WARP = Verantwortlicher)
• [ ] Typ B — Endkunde eines Händlers (WARP = Auftragsverarbeiter)

[ ] 4. ZUSTÄNDIGKEIT KLÄREN

• Typ A → WARP bearbeitet selbst (weiter mit Schritt 5)
• Typ B → Weiterleitungsprozess (Abschnitt 2): Endkunde informiert,

Händler informiert (inkl. Fristhinweis), Datum: __________

[ ] 5. BETROFFENES RECHT BESTIMMEN

• [ ] Art. 15 Auskunft [ ] Art. 16 Berichtigung [ ] Art. 17 Löschung
• [ ] Art. 18 Einschränkung [ ] Art. 20 Übertragbarkeit [ ] Art. 21 Widerspruch

[ ] 6. BEARBEITUNG DURCHFÜHREN

• Verwendeter Abschnitt dieses Dokuments: __________
• Betroffene Tabellen/Systeme: __________
• Ausführende Person: __________
• Datum der Durchführung: __________
• Bei Löschung: Backup-Löschprotokoll aktualisiert? ja/nein (Abschnitt 5.5)

[ ] 7. DOKUMENTATION

• Eintrag im Anfragen-Register angelegt/aktualisiert? ja/nein
• Fristverlängerung nötig? ja/nein — falls ja: Grund + Mitteilung an

betroffene Person innerhalb 1 Monat erfolgt? ja/nein

[ ] 8. ANTWORT

• Antwortdatum: __________
• Innerhalb der 1-Monats-Frist (bzw. verlängerten Frist)? ja/nein
• Antwort enthält bei Ablehnung: Gründe + Hinweis auf Beschwerderecht? ja/nein

`

Angaben beruhen auf Code-Stand ddbba50; Produktivstand ist abzugleichen (F-28).