Skip to main content

​
DSAR-Self-Service-Portal von Anfang bis Ende

Devotel Orbit nimmt Anträge von betroffenen Personen über zwei Eingangswege entgegen: die Eingabe durch Ihre Operatoren im Namen einer betroffenen Person und ein öffentliches Portal, über das die Person selbst einreicht. Eine Warteschlange bedient beide. Diese Anleitung führt den Portalweg von der Link-Veröffentlichung bis zur Erfüllung und zeigt, wie er mit der Operator-Eingabe zusammenwirkt. Die DSAR-Referenz (EN) dokumentiert die Endpunktfläche und den öffentlichen E-Mail-/Telefon-Claim-Automaten; diese Seite ist das Runbook, aus dem Sie arbeiten.
Jede Kontrolle hier gehört dem Tenant: Sie veröffentlichen den Link, Sie führen die Warteschlange, Sie entscheiden und erfüllen. Orbit hostet das Portal, beweist die Identität mit einem Zwei-Faktor-OTP und verfolgt die gesetzlichen Fristen — die rechtliche Antwortpflicht bleibt bei Ihnen als Verantwortlichem. Klären Sie Ihre Pflichten mit Ihrem Rechtsberater.

​
1. Zwei Eingangswege, eine Warteschlange

Operator-Eingabe. Ihr Team reicht einen Antrag über POST /compliance/dsar oder den Dialog Create DSAR unter Settings → Compliance → DSAR ein. Ein so eingereichter Antrag beginnt als verification_status: pending — kein Export- oder Lösch-Worker berührt ihn, bis ein Operator die Identitätsprüfung genehmigt oder ablehnt. Dieser Weg passt derzeit für: Personen, die Sie bereits kennen (ein eingeloggter Kunde, ein Kontakt in Ihrem Workspace), und die Rechte, die das öffentliche Formular nicht übermitteln kann (Correction, limit-sensitive-PI, Non-discrimination). Öffentliches Self-Service-Portal. Die betroffene Person reicht ihren Antrag selbst über die gehostete öffentliche Seite ein — kein Konto, kein API-Schlüssel, keine Session. Die Seite beweist ihre Identität mit einem Zwei-Faktor-E-Mail- + SMS-OTP, bevor irgendetwas in Ihre Warteschlange gelangt, sodass ein Portal-Antrag vorverifiziert einreicht und der Export- oder Lösch-Worker sofort startet. Betreiben Sie beide. Das Portal trägt das Verbrauchervolumen auf null manuelle Berührungen; die Operator-Eingabe deckt die Randfälle ab, die das Portal nicht kann. Jeder Antrag beider Wege landet in derselben Settings → Compliance → DSAR-Liste und derselben GET /compliance/dsar-Antwort — eine Warteschlange, ein SLA-Banner, eine Audit-Kette.

​
2. Portal-Durchlauf

Hosten Sie das Portal als “Datenschutzantrag einreichen”-Link in Ihrer Datenschutzerklärung, im Website-Footer oder im produktinternen Privacy Center:
<locale> ist dasselbe Locale-Präfix, das jede Orbit-Webseite trägt (en, fr, de, …). Die Seite rendert ein zweistufiges Identifikator-Formulare hinter einer Cloudflare-Turnstile-Botprüfung: die Person gibt E-Mail und Telefon (E.164) ein, wählt eine Antragsart, und der Identitätsbeweis beginnt.

​
Voraussetzung Absender-E-Mail

Entscheiden Sie, von welchen Adressen die Verifikationscodes des Portals gesendet werden, bevor der Link live geht — ein nicht gesetzter Absender lässt das Portal im Öffentlichen geschlossen fehlschlagen. Zwei plattformweite Absender werden einmal in Ihrer API-Umgebung konfiguriert: Ohne SMS-Absender und ohne Plattform-Fallback gibt der Telefonschritt 503 zurück und das Portal zeigt eine “vorübergehend nicht verfügbar”-Meldung; ohne E-Mail-Zustellschlüssel fehlschlägt der E-Mail-Schritt ebenso. In Produktion braucht der erste Schritt außerdem ein Turnstile-Token — setzen Sie DEVOTEL_TURNSTILE_SECRET_KEY auf der API und NEXT_PUBLIC_DEVOTEL_TURNSTILE_SITE_KEY auf dem Web-Deployment, aus dem Cloudflare-Dashboard (Turnstile → Add site). SMS-Verifikationscodes fahren über den Devotel-Softswitch als Plattform-OTPs — kein tenant-abrechenbarer Verkehr.

​
Was die betroffene Person sieht

Die Person füllt einen fünfstufigen Claim; nichts wird zur Warteschlange zugelassen, bevor beide Beweise vorliegen:
  1. Begin — E-Mail, Telefon (E.164), Antragsart. Ein E-Mail-OTP wird sofort versendet.
  2. Verify email — ein 6-stelliger E-Mail-Code (10-minütige TTL, 3 Versuche, 60-Sekunden-Wiederversendungs-Abkühlung).
  3. Send phone code — ein SMS-OTP an dasselbe Telefon (60-sekündige Abkühlung zwischen Sendungen).
  4. Verify phone — ein 6-stelliger SMS-Code.
  5. Submit — der Antrag gelangt nur in Ihre Warteschlange, wenn beide Beweise vorliegen. Der gesamte Claim hat eine 30-minütige Gesamttl.
Die freundlichen Antragsarten, die die Person wählt, mappen auf das Operator-Enum: Wenn die Identifikatoren zu keinem Kontakt in Ihrem Workspace passen, antwortet der Submit-Schritt gleich darauf — das Portal verrät nie, ob ein Kontakt existiert — und die Audit-Zeile wird auf Plattformebene geschrieben, damit die forensische Spur den Nicht-Treffen-Fall überlebt.

​
Jurisdiktion mapt auf die SLA-Uhr

Die Person wählt die Jurisdiktion, unter die ihr Antrag fällt, und diese Wahl bestimmt sowohl die gesetzliche Uhr, die die Zeile trägt, als auch welche request_type-Werte die Warteschlange halten darf: Die Zuordnung stimmen zu lassen ist wichtig: opt_out_sale und limit_sensitive_pi haben kein GDPR-Äquivalent, und der Operator-Standard-Jurisdiktion ist gdpr — setzen Sie sie ausdrücklich bei kalifornischen Verbrauchern. Eine Portal-Eingabe von opt_out setzt die Jurisdiktion standardmäßig auf CCPA/CPRA, gerade deshalb, weil der GDPR-Default sonst ungültig wäre. Eine Fehlwahl der Person ist korrigierbar: reklassifizieren Sie die Jurisdiktion aus der Warteschlange, und das SLA-Badge verankert sich neu.

​
3. Was Operatoren nach einer Einreichung sehen

Ein Portal-Antrag, der einem Kontakt entspricht, landet in Settings → Compliance → DSAR neben Operator-eingereichten Anfragen. Weil das OTP die Identität schon bewiesen hatte, kommt es als verification_status: verified an — keine Genehmigen/Ablehnen-Gate blockiert es.
  • Status und Frist. Die Zeile trägt den üblichen Lebenszyklus- Status und ein Tag X von N-SLA-Badge, verankert auf das Jurisdiktionsfenster; jede Verletzung wirkt sich auf den SLA-Banner auf Workspace-Ebene aus. GET /compliance/dsar/sla zeigt das gleiche Bild über die API.
  • Löschungsklassen. Eine Person, die “delete” gewählt hat, erscheint im Tab Erasure requests (Art. 17) im Portal-Abschnitt, SLA-Badge daneben, vor dem Standard-Frist von 7 Tagen Abkühlung.
  • Erfüllung. Ein Access- oder Portabilitäts-Antrag läuft auf Completed mit einer signierten export_url; die Aktion Download decrypted baut den Klartext-Export für einen Operator. Ein einmal ausgeführter Löschvorgang bietet das Proof of deletion-Zertifikat und Propagate an Ihre verbundenen Ziele.
  • Audit-Kette. Begin, beide Verifikationen und Submit schreiben Zeilen mit gehashten (nie rohen) Identifikatoren, Quell-IP und User-Agent — die Aufzeichnung, aus der Ihr Evidence Binder (EN) beim Regulator-Nachfrage abliest.

​
4. Was Orbit nicht tut

Das Portal ist Maschinerie für Eingang und Identitätsbeweis; die rechtlichen Entscheidungen bleiben bei Ihnen:
  • Orbit entscheidet nie über Gültigkeit. Es akzeptiert oder lehnt einen Antrag nie aus rechtlichen Gründen. Auf Verification-pending-Zeilen wartet Ihre Genehmigen/Ablehnen-Entscheidung; verified-Zeilen erfüllen, weil Sie es zulassen, nicht, weil die Plattform den Anspruch beurteilte.
  • Orbit auto-erfüllt nie eine Operator-Entscheidung. Bei einem Operator-eingereichten Antrag wird kein Export erzeugt und nichts gelöscht, solange verification_status: pending steht. Eine Portal-Einreichung umgeht das Gate nur, weil ihr OTP bereits Identität bewiesen hatte.
  • Löschung respektiert Ihre Abkühlhaltung. Der 7-Tage-Default (pro Tenant übersteuerbar) gibt Ihnen das Fenster zum Ablehnen, Halten oder Ausnehmen vor der Vernichtung.
  • Welches Recht gilt, bleibt die Aufgabe Ihres Rechtsberaters. Orbit verankert die SLA-Uhr an der Jurisdiktion, die die Person gewählt und Sie bestätigt haben.
  • Das Portal zeigt die verbrauchsgerechten Rechte-Teilmenge — eine Person, die ein Operator-only-Recht braucht (Correction, limit-sensitive-PI, Non-discrimination), reicht über Ihr Team ein.

​
5. Durchgespieltes Beispiel — ein GDPR-Access-Antrag von Ende zu Ende

Eine Kundin in Berlin öffnet Ihre Datenschutzerklärung, tippt den Portal-Link und bittet um alles, was Sie speichern. Reihenfolge:
  1. Begin. Sie gibt E-Mail, ihr Telefon in E.164 (+4915…), wählt access und besteht die Turnstile-Prüfung. Das Portal liefert eine Claim-ID zurück; das E-Mail-OTP ist schon unterwegs.
  2. Verify email. Sie liest den 6-stelligen Code (10-minütige TTL, bis zu 3 Versuche) und besteht den ersten Faktor.
  3. Send phone code, Verify phone. Der zweite Faktor wiederholt über SMS — mit 60-Sekunden-Abkühlung zwischen Sendungen — und beide Beweise sind nun vorliegen.
  4. Submit. Das Portal reicht den Antrag ein. Weil ihre E-Mail und ihr Telefon zu einem Kontakt in Ihrem Workspace passen, queued die Zeile als know unter gdpr und retourne eine dsar_pub_…-Referenz.
  5. In Ihrer Warteschlange. Die Zeile zeigt Tag 1 von 30 — verification_status: verified — und der Export-Worker hat sie bereits. Keiner in Ihrem Team berührt die Triage.
  6. Erfüllen. Der Worker kompiliert den Export und markiert die Zeile Completed mit export_url und tables_exported. Ein Operator liefert den Download-Link aus (eine Operator-Klartextkopie ist einen Download decrypted-Klick entfernt).
  7. Über die SLA-Linie. Wenn die Zeile beim Ablauf des 30-Tage- GDPR-Fensters noch offen ist, flaggt der Workspace-SLA-Banner sie — und hätte sie bei der Eingabe eine Jurisdiktion falsch gewählt, korrigiert die Queue-Reklassifizierung die Uhr rückwirkend.
Zeit von der ersten Formularabsendung der Person bis zum queued Antrag: die zwei OTP-Rundgänge. Operator-Berührungen: null.

​
Verwandte Referenzen