Skip to main content

​
Auskunftsanträge betroffener Personen (DSAR)

Ein Auskunftsantrag betroffener Personen (auch Datenschutzanfrage oder Antrag auf Verbraucherrechte genannt) ist der formelle Mechanismus, mit dem eine Person ihre Rechte an den personenbezogenen Daten ausübt, die Sie über sie halten – das Recht auf Auskunft, Löschung, Berichtigung, Datenübertragbarkeit oder Widerspruch gegen den Verkauf dieser Daten. Die meisten Datenschutzgesetze setzen Ihnen eine feste Antwortfrist (30 Tage nach DSGVO, 45 nach CCPA/CPRA). Orbit bietet Ihnen zwei Eingangswege und eine Erfüllungs-Pipeline:
  • Operator-gestellter DSAR – Ihr Support- oder Compliance-Team stellt eine Anfrage im Namen eines Kunden über die authentifizierte API oder das Dashboard.
  • Öffentliches Self-Service-Portal – die betroffene Person stellt ihre eigene Anfrage über einen öffentlichen, nicht authentifizierten Flow, der ihre Identität mit einem Zwei-Faktor-E-Mail- + SMS-OTP nachweist, bevor irgendetwas eingereiht wird.
Diese Seite beschreibt die Plattformsteuerungen von Orbit. Sie ist keine Rechtsberatung. Ihre Pflichten – welche Gesetze anwendbar sind, was Sie offenlegen müssen und wie lange Sie Zeit haben – hängen davon ab, wo Ihre betroffenen Personen leben und welche Daten Sie verarbeiten. Ziehen Sie qualifizierten Rechtsbeistand hinzu.
Alle Endpunkte unten sind unter https://api.orbit.devotel.io/api/v1/compliance verwurzelt.

​
Unterstützte Rechtsordnungen und Fristen

Das Feld applicable_jurisdiction einer Anfrage steuert, welche gesetzliche Frist Orbits SLA-Tracker anwendet. Operatoren können eine Anfrage nach dem Eingang neu klassifizieren.

​
Anfragetypen

request_type beschreibt, was die betroffene Person verlangt. Der vollständige CCPA/CPRA-Verbensatz steht Operatoren zur Verfügung; das öffentliche Portal exponiert eine freundlichere Teilmenge, die darauf abbildet. Bei CCPA-Auskunftsanfragen können Sie zusätzlich consumer_categories anhängen – die Kategorien nach CCPA §1798.100(b), zu denen die betroffene Person fragt: identifiers, customer_records, protected_classifications, commercial, biometric, internet_activity, geolocation, sensory, professional, education, inferences, sensitive_pi.

​
Operator-gestellte Anfragen

​
Eine Anfrage erstellen

POST /compliance/dsar – erfordert einen Admin- oder Owner-API-Schlüssel. Geben Sie mindestens eine Betroffenen-Kennung (contact_id, subject_email oder subject_phone) sowie die requester_email an, die die Korrespondenz erhalten soll.
Gibt 202 Accepted zurück:
Hinweis – applicable_jurisdiction hat nur für Rechte den Standard gdpr, die unter der DSGVO existieren. Die Anfragetypen opt_out_sale und limit_sensitive_pi sind nur unter CCPA/CPRA verfügbar und haben kein DSGVO-Äquivalent, daher müssen Sie applicable_jurisdiction für sie explizit auf ccpa oder cpra setzen. Das Weglassen (oder Beibehalten des gdpr-Standards) wird mit 422 VALIDATION_ERROR abgelehnt.

​
Status-Lebenszyklus

Eine Anfrage durchläuft: received → processing → completed mit den End-Zweigen failed, expired und cancelled. Der Verifikations-Unterstatus wird unabhängig verfolgt: pending → verified (der Worker fährt fort) oder rejected (der Worker hält an). DSGVO-/Operator-eingereichte Zeilen haben standardmäßig not_required.

​
Identität verifizieren oder ablehnen

Anfragen mit höherem Schutzbedarf (Löschung, Opt-out, sensitive Beschränkung) erfordern eine Operator-Entscheidung, bevor die Erfüllung fortgesetzt wird:
decision ist verified oder rejected; notes ist optional (≤ 2048 Zeichen). Gibt den neuen verification_status und verified_at zurück.

​
Eine Anfrage widerrufen

POST /compliance/dsar/{id}/cancel zieht eine laufende Anfrage zurück (DSGVO Art. 7(3)). Funktioniert nur, solange die Anfrage received oder processing ist; eine abgeschlossene Anfrage gibt 409 Conflict zurück.

​
Anfragen auflisten und lesen

  • GET /compliance/dsar – paginierte Liste. Query: page (≥ 1), page_size (≤ 100, Standard 25) und ein optionaler status-Filter.
  • GET /compliance/dsar/{id} – eine Anfrage abrufen. Die Antwort enthält die signierte export_url (und ihr export_expires_at), sobald ein Auskunfts-/Portabilitäts-Export erzeugt wurde, sowie tables_exported mit den Zeilenzahlen je Tabelle.

​
Löschanfragen

Löschungen nach DSGVO Art. 17 werden als eigene Ressource verfolgt, damit Sie prüfen und eingreifen können, bevor Daten vernichtet werden:
  • GET /compliance/dsar/erasure-requests – Liste. Query: status (pending, cancelled, executing, executed, failed) und limit (≤ 500).
  • POST /compliance/dsar/erasure-requests/{id}/cancel – eine ausstehende Löschung vor ihrer Ausführung abbrechen. Optionaler reason (≤ 500 Zeichen). Gibt 409 zurück, wenn sie bereits ausgeführt wird oder fertig ist.

​
SLA-Dashboard

GET /compliance/dsar/sla liefert eine kombinierte Export- + Löschungs-SLA-Momentaufnahme, damit Sie nie eine gesetzliche Frist verpassen:
Die Schweregrade skalieren proportional zum SLA-Fenster jeder Rechtsordnung – die Tagesschwellen sind am DSGVO-30-Tage-Fall verankert und mit dem Verhältnis slaDays / 30 multipliziert, sodass eine Anfrage immer beim selben Anteil ihrer eigenen Frist amber und rot wird. escalation_due wird 5 Tage vor der gesetzlichen Frist aktiv (slaDays − 5). Für DSGVO (sla_days: 30): grün (< 20 Tage verstrichen), amber (20–25), rot (26–30), rot + Verletzung (> 30); escalation_due an Tag 25. Für CCPA/CPRA (sla_days: 45) ergeben dieselben Verhältnisse grün (< 30), amber (30–38), rot (39–45), rot + Verletzung (> 45); escalation_due an Tag 40. Lesen Sie die Stufengrenzen immer gegen die für diese Anfrage zurückgegebenen sla_days, nicht gegen die festen Zahlen 20/25/30.

​
Öffentliches Self-Service-Portal

Der öffentliche Flow lässt eine betroffene Person eine Anfrage ohne Konto einreichen. Die Identität wird mit einem Zwei-Faktor-OTP nachgewiesen – einem E-Mail-Code und einem SMS-Code – bevor irgendeine Anfrage eingereiht wird. Die Endpunkte liegen unter /compliance/public/dsar und sind nicht authentifiziert, aber durch Cloudflare Turnstile, Rate-Limits pro IP und pro Kennung sowie eine datenschutzwahrende Antwortform abgesichert, die nie verrät, ob ein E-Mail-/Telefon-Paar zu einem echten Kontakt passt.
SMS-Verifikationscodes werden über den Devotel-Softswitch zugestellt (der einzige ausgehende SMS-Pfad der Plattform). Es sind Plattform- OTPs, kein dem Mandanten zu berechnender Verkehr, und sie tragen keine Persistenz von Zustellquittungen.

​
Flow-Übersicht

1

Start

POST /compliance/public/dsar/begin mit email, phone (E.164), request_type (access | delete | portability | opt_out) und einem Cloudflare-turnstile_token (in Produktion erforderlich). Gibt eine intransparente claim_id, email_sent: true und expires_in: 600 zurück. Ein E-Mail-OTP wird sofort versendet.
2

E-Mail verifizieren

POST /compliance/public/dsar/verify-email mit claim_id und dem 6-stelligen code. Gibt den Zustand email_verified und den nächsten Schritt phone_send zurück. Codes laufen nach 10 Minuten ab; maximal 3 Versuche. POST …/resend-email (mit claim_id + email) stellt einen neuen Code aus, vorbehaltlich einer 60-Sekunden-Sperre.
3

Telefon-Code senden

POST /compliance/public/dsar/send-phone mit claim_id und der phone, die der beim Start angegebenen entspricht. Sendet ein SMS-OTP (expires_in: 600). Zwischen Sendungen gilt eine 60-Sekunden-Sperre; ein zu früher erneuter Versuch gibt 429 mit Retry-After zurück.
4

Telefon verifizieren

POST /compliance/public/dsar/verify-phone mit claim_id und dem 6-stelligen code. Gibt den Zustand phone_verified und den nächsten Schritt submit zurück.
5

Einreichen

POST /compliance/public/dsar/submit mit claim_id. Persistiert eine Audit-Zeile und – nur wenn die verifizierte E-Mail + Telefon zu einem Kontakt in Ihrem Mandanten passen – reiht einen echten DSAR ein (vorab mit verification_status: verified markiert, da das OTP die Identität bereits nachgewiesen hat). Gibt eine reference_id (z. B. dsar_pub_…) und ein queued-Boolean zurück.

​
Die Identitätsnachweis-Absender konfigurieren

Die beiden OTPs werden von Plattform-Absendern verschickt, die Sie einmal in Ihrer API-Umgebung konfigurieren. Setzen Sie sie, bevor Sie das Portal veröffentlichen – ein nicht gesetzter SMS-Absender ohne Fallback lässt den Telefonschritt fail-closed scheitern. Wenn DEVOTEL_DSAR_PROOF_SMS_FROM und DEVOTEL_PLATFORM_DEFAULT_FROM beide nicht gesetzt sind, scheitert der send-phone-Schritt fail-closed mit einem 503 – das Portal meldet „vorübergehend nicht verfügbar” und der Fehler wird unter der Metrik dsar.proof.sms_send_failed emittiert, sodass er in Ihren Dashboards auftaucht statt den zweiten Faktor still zu überspringen. Ebenso gibt der E-Mail-Schritt 503 zurück, wenn DEVOTEL_RESEND_API_KEY nicht gesetzt ist. Konfigurieren Sie beide Absender, bevor Sie das Portal öffentlich verlinken.

​
Missbrauchsabwehr

Die Antwortform ist identisch, ob die Kennungen zu einem echten Kontakt passen oder nicht – das Portal bestätigt oder bestreitet nie, ob jemand in Ihrer Datenbank ist. Wenn Redis nicht verfügbar ist, öffnen die Rate-Limit-Gates (fail-open), um die Verfügbarkeit zu erhalten.

​
Turnstile-Schutz aktivieren

Das Turnstile-Gate wird mit zwei Umgebungsvariablen konfiguriert.
Das Gate ist fail-open, wenn DEVOTEL_TURNSTILE_SECRET_KEY nicht gesetzt ist: begin akzeptiert Anfragen ohne Token und protokolliert eine einzelne Warnung. Setzen Sie das Secret in Produktion, sonst ist das Portal durch Turnstile ungeschützt, obwohl jede andere Missbrauchsabwehr oben weiterhin gilt. Erzeugen Sie beide Schlüssel im Cloudflare-Dashboard (Turnstile → Add site) und setzen Sie sie auf der API- bzw. Web-Bereitstellung.
Veröffentlichen Sie das öffentliche Portal unter Ihrer Datenschutzerklärung als Link „Datenschutzanfrage einreichen”. Da sich der Flow per OTP selbst verifiziert, sind Anfragen, die darüber eingehen, bereits identitätsgeprüft – sie landen fertig zur Erfüllung in Ihrer Operator-Warteschlange und erscheinen in GET /compliance/dsar gemeinsam mit Operator-gestellten Anfragen.

​
Weiterführende Referenzen