Skip to main content

​
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 documents every endpoint, the operator walkthrough covers the day-to-day queue work, and the portal setup guide 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. 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 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: 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.