> ## 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. # The DSAR intake model > The mental model behind data subject requests: who the controller and processor are, what each request type asks for, which statutory clock applies, and how intake flows from a public portal or an operator into the four fulfilment surfaces. # The DSAR intake model A **Data Subject Access Request** (DSAR) is the formal mechanism a person uses to exercise their rights over the personal data stored about them — access, deletion, correction, portability, or opting out of sale. The [DSAR reference page](/compliance/dsar) documents every endpoint, the [operator walkthrough](/guides/compliance-dsar-breach-register) covers the day-to-day queue work, and the [portal setup guide](/guides/self-service-dsar-portal) covers the public intake flow. This page is the model behind all three — read it once and the controller/processor split, the verb set, the SLA clocks, and the fulfilment surfaces fit together. This page describes the model and your tenant-owned controls. It is **not legal advice** — which laws apply to you and how a request must be answered stay with you and your counsel. *** ## 1. Controller, processor, and where the obligations split Privacy law assigns roles, and a DSAR only makes sense against them: * The **data subject** is the person the data is about — your end customer, lead, or contact. * The **controller** is **you, the tenant**. You decide why and how personal data is processed, you owe the response to the subject, and you own the deadline. * The **processor** is **Orbit**. The platform stores and processes the data on your instructions and gives you the tooling to answer the request — intake, identity verification, fulfilment, and evidence — but the obligation to respond is never transferred to the platform. The split shows up concretely in the product: * **Intake is tenant-owned.** You choose whether requests arrive through the authenticated operator path, the public self-service portal, or both, and you publish the portal link under your own privacy policy. * **Fulfilment is platform-executed, tenant-directed.** Orbit exports or erases the subject's data across the tenant schema, but the request row, its jurisdiction, and its outcome belong to your tenant — nothing crosses a tenant boundary. * **The judgement calls stay with you.** Verifying a marginal identity claim, accepting or rejecting an Art 18 restriction, and deciding whether an exemption applies are operator decisions the platform records but never makes. Because Orbit is the processor, a subject's request addressed to Orbit directly is not a valid substitute: the answer has to come from you, the controller, using the tooling below. *** ## 2. Request types and jurisdiction mapping `request_type` describes what the subject is asking for; the operator verb set is a superset of the friendlier public-portal verbs. Which jurisdiction you file under determines which verbs are available and which statutory clock starts. | Operator `request_type` | What it asks for | Public portal verb | Jurisdictions with the right | | - | - | - | - | | `know` | Access — disclose the data held | `access` | GDPR, CCPA, CPRA, LGPD, PDPA, PIPEDA, DPDP | | `delete` | Erasure | `delete` | GDPR, CCPA, CPRA, LGPD, DPDP | | `correct` | Rectification | — (operator only) | GDPR, CPRA, LGPD | | `portability` | Machine-readable export | `portability` | GDPR, LGPD | | `opt_out_sale` | Opt out of sale/share | `opt_out` | CCPA, CPRA | | `limit_sensitive_pi` | Limit use of sensitive PI | — (operator only) | CPRA | | `non_discrimination` | Non-discrimination right | — (operator only) | CCPA, CPRA | The mapping is enforced: `opt_out_sale` and `limit_sensitive_pi` exist only under CCPA/CPRA, so filing them with the `gdpr` default rejects with `422`. Conversely, every right that exists under GDPR can be filed under any jurisdiction the subject plausibly falls under — the `applicable_jurisdiction` field is yours to set, and operators can reclassify after intake when counsel rules differently. GDPR Article 18 (restriction of processing) has no dedicated verb — file it under the nearest existing right with the legal basis recorded in `requester_statement`. The [reference page](/compliance/dsar) walks through that workaround with a worked example. *** ## 3. SLA clocks and the two intake paths Every request carries one statutory clock, set by its jurisdiction: | Jurisdiction | Statutory deadline | | - | - | | GDPR / PDPA / PIPEDA / DPDP | 30 days | | CCPA / CPRA | 45 days | | LGPD | 15 days | The SLA tracker (`GET /compliance/dsar/sla`) scales its green/amber/red severity tiers proportionally to the window, so a 15-day LGPD request turns red at the same fraction of its deadline as a 45-day CCPA request. `escalation_due` flips five days before the deadline regardless. The clock behaves the same on both intake paths; what differs is how the request arrives and how identity is proven: * **Operator-filed intake.** A support or compliance agent creates the request through the authenticated API or dashboard on the subject's behalf. Identity assurance is an operator decision: higher-risk verbs (delete, opt-out, limit-sensitive) pause in `verification_status: pending` until you mark them verified or rejected. The subject's own paper trail — an email they sent, a form they filled — is yours to weigh. * **Public portal intake.** The subject files through the unauthenticated flow and proves identity with a two-factor email + SMS OTP before anything is queued. Requests that survive OTP arrive pre-marked `verification_status: verified`, so they enter your operator queue ready to fulfil. The portal's abuse defenses (Turnstile, per-IP and per-identifier rate limits, privacy-preserving response shapes) exist so the unauthenticated door can't be used to probe your contact list. Pick intake paths per the audience you serve; both land in the same queue, the same SLA tracker, and the same fulfilment pipeline below. *** ## 4. The four fulfilment-stage surfaces Every request, whichever path it arrived by, moves through four surfaces that together close the loop from "received" to "provably done": 1. **Verify.** The request sits in `verification_status: pending` (or `verified`, if it came through the portal OTP). An operator resolves it before any high-risk fulfilment proceeds — verified and the worker continues, rejected and it halts. 2. **Fulfil.** Access and portability requests produce a signed export URL with per-table row counts; delete requests spawn a tracked erasure resource you can list, cancel while pending, and watch to `executed`. Corrections ride the normal contact-update surfaces. 3. **Audit log.** Every status transition, verification decision, and erasure outcome lands in the tamper-evident audit chain — the sequence an auditor or supervisory authority can replay. 4. **Evidence binder.** For completed erasures, the proof-of-deletion certificate derives a signed, re-verifiable receipt on demand, with downstream propagation outcomes folded in. Hand it to the subject or counsel as the closing artifact. The four surfaces are what turn a queue of requests into a defensible posture: intake without all four is a backlog, intake with all four is evidence. *** ## 5. Cross-links * [DSAR reference](/compliance/dsar) — every endpoint, field, and the Art 18 workaround. * [Operator walkthrough](/guides/compliance-dsar-breach-register) — running the queue day-to-day. * [Self-service portal setup](/guides/self-service-dsar-portal) — publishing and hardening the public intake flow. * [CDP erasure propagation](/guides/cdp-erasure-propagation) — the downstream destination fan-out folded into the deletion certificate. * [Consent and suppression model](/concepts/consent-and-suppression-model) — where delete and opt-out outcomes flow. * [Assembling a GDPR posture](/compliance/gdpr-posture-guide) — where DSAR intake sits in the full sequence. * [Tenant compliance posture map](/compliance/posture-overview) — the controls index for every tenant-owned compliance surface.