GDPR and DSAR on a CPaaS — privacy requests across six jurisdictions, two intake paths

What GDPR and DSAR mean on a CPaaS

GDPR — the EU's General Data Protection Regulation — is the privacy law that gives every person the right to access, correct, port, and erase the personal data a business holds on them, and a DSAR (data subject access request) is the formal mechanism they use to exercise those rights. On a CPaaS, a DSAR is an operational object with an intake channel, an identity-verification step, a fulfilment pipeline, and a statutory deadline clock — not a support ticket.

A communications platform sits on exactly the data privacy requests target: contact records, message bodies, call recordings, consent ledgers, and interaction history. When a customer of yours files a GDPR Article 15 access request or a CCPA deletion request, the fulfilment question is "can the platform produce — or erase — this person's data across every one of those stores, inside the deadline?" The GDPR and DSAR glossary entries define the terms; this guide covers how the request lifecycle actually runs, and why the intake and verification steps matter as much as the export itself.

Most privacy laws give the controller a hard response window — 30 days under GDPR, 45 under CCPA/CPRA, 15 under Brazil's LGPD. A request that arrives through your support inbox and sits in triage for two weeks has already burned half the clock before fulfilment starts, so the design of the intake path is a compliance decision, not a UX preference.

The six jurisdictions and their deadline clocks

One input on the request — applicable_jurisdiction — decides which statutory clock the SLA tracker runs against. The supported set:

The default is gdpr with its 30-day clock: a request filed with no jurisdiction lands on the GDPR track. Operators can reclassify a request after intake, so a subject who picked the wrong jurisdiction at the door does not force a re-filing. The deadline itself is the part no platform can soften — GDPR's one-month window (extendable by two further months for complex requests) and CCPA's 45 days are statutory, and a missed clock is a regulator finding regardless of how good the eventual export was. Track the clocks, not just the queue.

Two intake paths: operator-filed and the public portal

A privacy request can enter through either of two doors, and one fulfilment pipeline serves both:

Operator-filed DSAR. Your support or compliance team files the request on a subject's behalf through the authenticated API or dashboard — an admin- or owner-scoped call that carries the subject identifier, the request type (access, delete, correct, portability, opt out of sale, limit sensitive PI), the jurisdiction, and a requester_email for correspondence. This path fits low-volume business-to-business surfaces where requests arrive by email to a privacy alias and a human files them.

Public self-service portal. Devotel Orbit also hosts a public, unauthenticated intake page — the address you publish under your privacy policy as the "submit a privacy request" link — where the data subject files their own request. Nothing from the portal enters the operator queue until identity is proven (next section), which is what makes an unauthenticated front door safe to publish. High-volume consumer businesses run most of their intake this way: no operator round-trip per request, and a lawful channel for people who have no session with your product.

Either way, the legal duty to respond within the deadline stays with you, the controller. Both doors and the fulfilment pipeline behind them are documented in the DSAR reference; the portal deployment walkthrough is the self-service DSAR portal guide.

Identity verification: two factors before anything is queued

The failure mode a self-service channel has to defeat is a stranger filing an access request for someone else's data — so portal intake proves both an email address and a phone number before a request exists:

1. The subject submits email + phone + request type behind a bot check.
2. An email one-time code goes out (10-minute TTL, 3 attempts, 60-second resend cooldown).
3. After the email proof, an SMS one-time code goes to the same phone.
4. Only with both proofs on file does the request enter the operator queue; the whole claim carries a 30-minute end-to-end TTL.

Operator-filed requests run a different assurance model: they default to not_required on the verification sub-state, and higher-assurance request types (delete, opt-out, limit sensitive PI) hold in pending until an operator marks the identity verified or rejected through the verification endpoint. Either way, fulfilment does not proceed on an unverified request.

The jurisdiction-and-request-type pairing rule

One validation rule catches the most common filing mistake: the CCPA/CPRA-only request types (opt_out_sale, limit_sensitive_pi) have no GDPR equivalent. A California consumer's opt-out-of-sale request filed with the default jurisdiction would otherwise land on a GDPR 30-day clock for a right GDPR does not contain — so intake rejects it. File those two types with applicable_jurisdiction set expressly to ccpa or cpra; omitting it, or leaving the gdpr default, fails at the door with a validation error, and the operator can correct the pairing without the subject re-filing. The full pairing table — including which operator request types the public portal exposes as its friendlier access / delete / portability / opt_out subset — is in the DSAR reference.

Tenant-owned controls, not a platform gate

Nothing on this page is a platform deciding what a tenant may do with personal data — the controls are tenant-owned, and that posture is deliberate. Orbit supplies the intake surfaces, the jurisdiction clocks, the verification states, the export and erasure pipeline, and the SLA snapshot that shows every open request against its deadline; the decisions — which laws apply to your subjects, which jurisdictions you accept, how you verify identity, whether to fulfil or refuse a request — stay with the tenant's operator and counsel. The DSAR controls are documented consoles and API surfaces you operate, not a platform gate that legislates on your behalf. The operational guide is the DSAR operator guide, and the broader regulatory background sits in CPaaS compliance topics.

Frequently asked questions

Which jurisdictions does the DSAR pipeline support?

Six: GDPR (EU/EEA, 30 days), CCPA and CPRA (California, 45 days), LGPD (Brazil, 15 days), PDPA (Singapore/Thailand, 30 days), and DPDP (India, 30 days). The applicable_jurisdiction field on the request picks the clock; it defaults to GDPR when omitted, and operators can reclassify after intake.

Should we take requests through the public portal or file them as operators?

Both feed the same fulfilment pipeline. Operator-filed intake (authenticated API or dashboard) suits low-volume business surfaces where requests arrive by email. The public portal suits consumer volume: the subject files themselves, and two-factor email + SMS OTP verification means no operator round-trip per request. A privacy policy that promises a self-serve channel should point at the portal.

How is a data subject's identity verified before fulfilment?

On the public portal, the subject proves control of both an email address and a phone number with one-time codes before anything is queued — two factors, not one. On operator-filed requests, higher-assurance types (delete, opt-out, limit sensitive PI) wait in a pending verification state until an operator explicitly marks the identity verified or rejected.

What deadline applies, and what happens if intake misclassifies the jurisdiction?

The statutory clock follows applicable_jurisdiction: 30 days for GDPR/PDPA/DPDP, 45 for CCPA/CPRA, 15 for LGPD. Because operators can reclassify after intake, a subject who picked the wrong jurisdiction does not restart the clock — but the CCPA/CPRA-only request types (opt out of sale, limit sensitive PI) are rejected at intake unless filed under ccpa or cpra expressly, so that pairing error never reaches the queue.

Sources and further reading

• GDPR (EUR-Lex, Regulation 2016/679): the EU statute behind Articles 15–20 (access, rectification, erasure, portability) and the one-month response window.
• California CCPA/CPRA (oag.ca.gov): the Attorney General's CCPA resource, including the consumer-rights request provisions.
• Orbit DSAR reference: endpoints, request types, jurisdiction table, SLA snapshot.
• Orbit self-service DSAR portal guide: deployment and operation of the public intake page.