> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

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

> Kombiniert die Eingabe durch Operatoren mit dem öffentlichen Portal, veröffentlicht den Portal-Link mit geeigneten Absendern, durchläuft die E-Mail- + SMS-OTP-Verifikation und nimmt die verifizierte Anfrage in der Operator-Warteschlange aufgesetzten gesetzlichen Frist im Blick.

# 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)](/compliance/dsar) dokumentiert die Endpunktfläche
und den öffentlichen E-Mail-/Telefon-Claim-Automaten; diese Seite ist
das Runbook, aus dem Sie arbeiten.

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

***

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

### Link veröffentlichen

Hosten Sie das Portal als "Datenschutzantrag einreichen"-Link in Ihrer
Datenschutzerklärung, im Website-Footer oder im produktinternen
Privacy Center:

```
https://orbit.devotel.io/<locale>/dsar
```

`<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:

| Variable                        | Verwendung                      | Fallback                                                  |
| ------------------------------- | ------------------------------- | --------------------------------------------------------- |
| `DEVOTEL_DSAR_PROOF_FROM_EMAIL` | Absenderadresse des E-Mail-OTP. | keine — Zustellung braucht zudem `DEVOTEL_RESEND_API_KEY` |
| `DEVOTEL_DSAR_PROOF_SMS_FROM`   | E.164-Absender des SMS-OTP.     | `DEVOTEL_PLATFORM_DEFAULT_FROM`                           |

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:

| Person wählt  | Operator `request_type` |
| ------------- | ----------------------- |
| `access`      | `know`                  |
| `delete`      | `delete`                |
| `portability` | `portability`           |
| `opt_out`     | `opt_out_sale`          |

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:

| Jurisdiktion           | Code     | Antwort-SLA |
| ---------------------- | -------- | ----------- |
| EU/EWR GDPR            | `gdpr`   | 30 Tage     |
| Kalifornien CCPA       | `ccpa`   | 45 Tage     |
| Kalifornien CPRA       | `cpra`   | 45 Tage     |
| Brasilien LGPD         | `lgpd`   | 15 Tage     |
| Singapur/Thailand PDPA | `pdpa`   | 30 Tage     |
| Kanada PIPEDA          | `pipeda` | 30 Tage     |
| Indien DPDP            | `dpdp`   | 30 Tage     |

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)](/guides/compliance-evidence-binder) 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

* [DSAR-Referenz (EN)](/compliance/dsar) — die vollständige Operator-
  und öffentliche Endpunktfläche, Abuse-Defense-Grenzen und
  SLA-Schweregrade.
* [DPO & EU/UK-Representanten-Designation (EN)](/compliance/dpo-representative) —
  die Art.37/Art.27-Designationen, die eine Datenschutzerklärung nennen muss.
* [GDPR-Verarbeitungsregister (ROPA + DPIA) (EN)](/compliance/privacy-register) —
  das Art.30-Inventar, das fertig ist, bevor irgendein Antrag einreicht.
* [Compliance-Evidence-Binder (EN)](/guides/compliance-evidence-binder) —
  die Audit-Zeilen, die ein Portal-Antrag zurücklässt.
* [DSAR erfüllen und das Breach-Register betreiben (EN)](/guides/compliance-dsar-breach-register) —
  der Operator-Durchlauf der Warteschlange, die Ihr Portal speist.
* [GDPR-Haltung von Anfang bis Ende aufbauen (EN)](/compliance/gdpr-posture-guide) —
  wo der Portal-Eingang in der Gesamtsequenz sitzt.
