Betroffenenrechte — operative Prozesse

Fassung vom 12.09.2026.

Dieses Dokument beschreibt, wie WARP heute (Beta-Stand, Code-Stand f1cf3bc7) eingehende Anfragen nach Art. 15–21 DSGVO operativ bearbeitet, auch dort, wo das noch manuell über Datenbankzugriff, Ticket und Dokumentation geschieht. Es ist eine Arbeitsanleitung, keine Rechtsberatung. Sämtliche Werte (Fristen, Dienstleister, Rollen) stammen aus dem Register 12.09.2026 (docs/recht/rechtstexte-fassung-2026-09-12.md). Eingangskanal ist datenschutz@wawihub.de, Serverstandort Helsinki; Löschfristen nach Vertragsende nach F-23.

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. Die Nachweisanforderung mit Datum im Anfragen-Register vermerken und die Antwort so planen, dass die Monatsfrist ab Eingang eingehalten wird.

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.
• Das Anfragen-Register wird als Tabelle geführt (Spalten wie oben: Eingang, Kanal, Person, Typ, Recht, Identitätsprüfung, Entscheidung, Antwortdatum, Fristverlängerung). Ein Self-Service-Export für Auskunft und Übertragbarkeit ist Betriebsaufgabe; bis dahin erfolgt der Export manuell nach Abschnitt 3 (F-36).

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-12 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, erinnert WARP nochmals und dokumentiert den Vorgang. Die Rollen bleiben dabei unverändert (F-40): Der Händler ist Verantwortlicher für alle Daten aus seiner Warenwirtschaft, seinen Google-Konten, seinem Shop und von seinen Lieferanten; WARP ist Auftragsverarbeiter und beantwortet diese Anfragen nicht selbst. WARP teilt dem Endkunden auf Nachfrage mit, dass die Anfrage an den Verantwortlichen weitergeleitet wurde. Materiell beantwortet WARP nur Anfragen zur eigenen Kundenbeziehung (Konto, Rechnung), also Typ A.

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 (Hetzner Online GmbH (Hosting, Helsinki, Finnland), IONOS SE (System-E-Mails, Deutschland), Stripe Payments Europe, Ltd. / Stripe, Inc. (Zahlungsabwicklung, EU und USA; Konto und Data Processing Agreement seit 25.07.2026), lexoffice / Haufe-Lexware GmbH & Co. KG (Rechnungsschreibung, Deutschland)), geplante Speicherdauer (laufend nach den Fristen in Abschnitt 5.0, F-21; nach Vertragsende Export auf Anforderung binnen 30 Tagen, Löschung 60 Tage, spätestens 90 Tage nach Vertragsende, F-23), Herkunft der Daten, Bestehen von Betroffenenrechten sowie den nach Art. 15 (2) DSGVO gebotenen Hinweis, dass Zahlungsdaten an Stripe, Inc. in die USA übermittelt werden und dafür als Garantien (Art. 44 ff.) das EU-US Data Privacy Framework (Stripe, Inc. zertifiziert) und die Standardvertragsklauseln bestehen (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 den Inhaber über bestehende Verwaltungsfunktionen bzw. direkten, dokumentierten DB-Update; ein Vier-Augen-Prinzip entfällt beim Einzelunternehmen, an seine Stelle tritt die Protokollierung jedes Schritts. 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

Der Löschlauf der Plattform (Modul retention) ist gebaut und noch nicht aktiviert (Betriebsaufgabe B-1, Register 12.09.2026). Die im Löschlauf hinterlegten Fristen sind mit der Fassung vom 12.09.2026 verbindlich; bis zur Aktivierung gilt jede Frist als Höchstfrist, die manuell nach dem Lösch-Runbook durchgesetzt wird (F-21). Jede anlassbezogene Löschung (Art. 17) ist derzeit ein manueller, protokollierter Vorgang durch den Inhaber mit direktem, privilegiertem Datenbankzugriff (F-37). 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: Export auf Anforderung binnen 30 Tagen, Löschung 60 Tage, spätestens 90 Tage nach Vertragsende einschließlich Auslauf der Sicherungen (F-23).

Fristen des Löschkonzepts (Register 12.09.2026, Abschnitt 4):

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. Vorgehen: Personenbezug anonymisieren (z. B. sub/Namen entfernen, technische ID durch einen neutralen Wert ersetzen), Vorgang selbst nicht löschen. Aufbewahrungsfrist des Admin-Audits: 365 Tage, danach Löschung durch den Löschlauf; ein gesetzlicher Aufbewahrungsvorbehalt bleibt (F-21).
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: 10 Jahre nach § 147 AO, 6 Jahre für Handelsbriefe nach § 257 HGB, F-41) beachten; Rechnungsdaten sind bis zum Fristende nicht löschbar, sondern nur zu sperren/eingeschränkt zu verarbeiten (Art. 18).
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; Suchbegriffe werden aggregiert verarbeitet und nicht auf Personen ausgewertet, ein Namensfilter ist nicht vorhanden, das Restrisiko trägt der Händler als Verantwortlicher (F-32); praktisch kaum gezielt filterbar, da aggregiert.

Wichtige Einschränkung (heute): Für warp_attribution_events gibt es kein Werkzeug zur Löschung einzelner Personen über UI oder API. Bis ein Werkzeug existiert, erfolgt die Löschung manuell nach dem Lösch-Runbook als direkter, protokollierter DB-Eingriff (F-35). Unabhängig davon löscht der Löschlauf Attributionsereignisse nach 24 Monaten. Ein Selbstbedienungs-Opt-out für Endkunden existiert nicht (siehe Abschnitt 7).

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 den Inhaber als einzige Person mit direktem DB-Zugang, mit Protokollierung jedes Schritts (ein Vier-Augen-Prinzip entfällt beim Einzelunternehmen). Unabhängig davon löscht der Löschlauf Mail-Ausgangs-Metadaten 30 Tage nach Zustellung oder endgültigem Fehlschlag. 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. Die Rechnungsschreibung des Betreibers erfolgt über lexoffice (Haufe-Lexware GmbH & Co. KG, Deutschland; AV-Vertrag über das Kundenkonto); Rechnungsdaten dort und in warp_invoice werden 10 Jahre (§ 147 AO) bzw. für Handelsbriefe 6 Jahre (§ 257 HGB) aufbewahrt und erst nach Fristende gelöscht (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. Der Löschlauf entfernt Webhook-Rohdaten nach 30 Tagen; danach verbleiben nur die strukturierten Abo- und Rechnungsdaten (F-33).
• Stripe-Konto und Stripe Data Processing Agreement bestehen seit 25.07.2026 (im Dashboard angenommen). Übermittlungen an Stripe, Inc. in die USA stützen sich auf das EU-US Data Privacy Framework (Stripe, Inc. zertifiziert) und die Standardvertragsklauseln. Derzeit läuft Stripe im Testbetrieb (Testschlüssel), es gibt keinen Live-Zahlungsbetrieb (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 Aufbewahrungsfrist beträgt 365 Tage, danach löscht der Löschlauf; ein gesetzlicher Aufbewahrungsvorbehalt bleibt (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". Der hier beschriebene Ansatz ist deckungsgleich mit dem Auslauf der Sicherungen in AGB/AVV (F-23/F-38) und beruht auf dem Register 12.09.2026, Abschnitt 3 und 4:

1. Löschung im Livesystem sofort: Die eigentliche Löschung (Abschnitte 5.1–5.4) erfolgt unverzüglich im Produktivsystem, unabhängig vom Sicherungszyklus.
2. Sicherungen rotieren mit dokumentierter Frist: Anwendungsinterne Sicherungen sind Fernet-verschlüsselt und werden nach 90 Tagen gelöscht. Datenbanksicherungen auf dem Host laufen täglich um 03:30 Uhr (warp-saas-backup.timer); vorgehalten werden 14 tägliche und 8 wöchentliche Stände auf dem Server, Zugriff nur über den administrativen Zugang des Inhabers. Ein gelöschter Datensatz verschwindet spätestens nach Ablauf dieser Fristen auch aus allen Sicherungsgenerationen, ohne dass er aktiv aus der Sicherung entfernt werden muss.
3. Nachlöschung nach Restore (F-38): Wird eine Sicherung (z. B. im Rahmen einer Störung) zurückgespielt, ist die Nachlöschung ein manueller Pflichtschritt nach jeder Wiederherstellung: Das Löschprotokoll (welche Person/welcher Datensatz wurde wann gelöscht) wird gegen die wiederhergestellten Daten abgeglichen, und alle seit dem Sicherungsstand protokollierten Löschungen werden erneut ausgeführt (Lösch-Runbook Phase 3), bevor der Betrieb freigegeben wird. Ohne diesen Schritt ist ein Restore aus Datenschutzsicht nicht abschließbar.
4. Ein automatischer Nachlösch-Mechanismus existiert im Code nicht; der manuelle Schritt nach Nr. 3 ist deshalb verbindlich und wird im Lösch-Runbook und in der Restore-Anleitung geführt (Register 12.09.2026, B-2).
5. Offsite-Sicherung (F-19): Eine Offsite-Sicherung auf einer Hetzner Storage Box (Deutschland, EU) ist vorgesehen (bestellt, Anbindung offen); die Stände werden vor der Übertragung verschlüsselt, der Schlüssel liegt nie auf dem Server. Auch diese Sicherungen unterliegen derselben Rotations- und Nachlöschlogik.

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; der Self-Service-Export ist Betriebsaufgabe, bis dahin manueller Export wie bei Art. 15 (Abschnitt 3.1) (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; Layer 1 serverseitig ohne Zugriff auf das Endgerät auf Grundlage von Art. 6 (1) f, Layer 2 nur mit Einwilligung über die Consent-Lösung des Händlers) — hierzu existiert kein technischer Opt-out-Mechanismus für den einzelnen Endkunden (siehe Abschnitt 7, F-35). Ein Widerspruch wird heute über den manuellen Löschpfad in Abschnitt 5.1 (Typ B) nach dem Lösch-Runbook auf Weisung des Händlers umgesetzt, 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 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 dem Code-Stand f1cf3bc7 und dem Register 12.09.2026 (F-28).