Enterprise buyers ask a CPaaS vendor "are you GDPR-compliant" and the answer is a uniformly useless "yes." The question that actually separates vendors is not whether they claim compliance — it is where each class of your customer data lives and which controls you can operate yourself. This checklist is written the way a procurement or security review should run: three data classes to scope, the residency question for each, and a final questionnaire where every item lands on a public docs page.
Everything below is framed as tenant-owned configuration — the controls a platform gives you to set, audit, and export. Orbit (like every vendor) is the conduit; the residency and retention decisions are yours to make, and a vendor that cannot show you the knobs is asking you to trust a claim instead of operate a control.
1) The three data classes to scope
A voice + SMS workload produces three classes of personal data that review teams should enumerate separately, because each has a different residency story and a different retention surface:
- Call recordings — stored audio of every recorded call, plus voicemail. Under GDPR this is personal data in the strictest sense, and it is usually the single largest artifact in the review.
- Voice biometrics — voiceprints enrolled for caller verification, plus the enrollment and verification attempts. Higher-order data class: biometric identifiers sit in GDPR's special-category territory, so "treat them like recordings" is not a safe answer.
- Contact records (CDP) — customer profile, identifiers, conversation history, tags, opt-in/opt-out state. The data your routing, messaging, and retention logic keys off.
A vendor that answers "where does the data live" without splitting these classes has not answered at all. Score each class separately; the questionnaire at the end does exactly that.
2) Voice data residency — announce the scope, then verify the scope
The residency question for voice splits into "stored" and "in-flight," and most vendors answer only the first. Stored recordings are table stakes. The harder question is the media plane: which region's media servers carried the live audio while the call happened, and whether a degradation quietly reroutes it elsewhere.
On Orbit, residency is scoped to the voice media classes — call recordings, voicemail, live in-call media, SIP/call metadata — and the region is a tenant-owned pin (eu, us, or auto) set in the dashboard or the API. There is no automatic cross-region failover that would silently substitute one region for the other. The full details are in the voice data residency announcement, and the tenant-facing reference — including the retention ranges and the boundaries of the pin — is the Voice Data Residency & Retention page.
The buyer's test is simple: ask the vendor to show, in writing, (a) which classes the pin covers, (b) how you set it, and (c) what happens to residency when a region degrades. If the answer to (c) is "we fail over automatically," the guarantee is a preference, not a pin.
3) Recording retention — windows you set, holds you take
Retention is the second residency question: not where the file rests, but how long it persists and who closes the window. The control surface to ask for has four parts:
- Windows — per-channel retention ranges you set yourself (on Orbit, 30 days default, 7–3,650 days configurable, enforced rather than optional under HIPAA mode).
- Search — a way to prove the recording you are deleting (or holding) is the right one. Orbit's recording and transcript library joins recording + finalized transcript + QA score so the hit list is the QA worklist, not a scrub-through-audio exercise.
- Legal hold — the ability to exempt an individual recording from age-based deletion when litigation or eDiscovery requires it.
- Playback hygiene — short-lived playback links so a copied URL does not become a durable leak.
The failure mode to guard against is a vendor whose only retention control is "contact support." If a window change or a legal hold is a ticket, the control is not tenant-owned, whatever the marketing says.
4) Biometric verification retention — enrollment, thresholds, deletion on a lifecycle
Voice biometrics are where buyer reviews go vague fast. The questions to ask are specific: what exactly is stored (the voiceprint, the enrollment attempts, the verify attempts), how long each persists, and whether the tenant can tune the threshold and revoke the enrollment per individual. On Orbit this is the full enrollment → challenge → verify gate, with per-tenant thresholds, documented in Voice biometrics: enrollment, challenge, verify and the voice biometric verification patterns post.
The checklist item here is structural: special-category data needs a lifecycle answer (enroll, verify, revoke/delete), not a "we encrypt it at rest" deflection. If the vendor cannot describe the deletion path per individual, the control does not exist.
5) Opt-outs and suppression — where the "never contact again" record lives
The opt-out record is the one data class a GDPR audit will read first, because it is the clearest binary test: either the suppression blocklist exists and is honored across all channels, or it is not. Ask the vendor four things:
- Where the ledger lives — is the suppression record held per tenant, scoped correctly, and exportable as evidence?
- How opt-outs land — STOP keywords, preference-center unsubscribe, bounced addresses, complaints — and whether all of those write the same ledger.
- Whether it gates — whether a suppressed contact is dropped at send time, before dispatch, regardless of campaign or API path.
- Whether exports survive re-permissioning — the export should preserve the revoke/re-permission history, not just today's blocklist.
On Orbit this is the Opt-Out & Suppression Lists surface: a tenant-owned ledger with bulk CSV import (for migrating an existing list), send-time gating as a hard pre-dispatch check, and an export endpoint whose status=all output preserves revoked rows — the audit-file answer to a GDPR inquiry on the quarterly posture review. That review is where you operationalize this — but the ledger itself, and its export shape, are the thing to test in the questionnaire.
6) The questionnaire — questions that map to a docs page
Run the review as written answers against public documentation, not as a demo. Each question below maps to the Orbit surface a buyer should be handed — a vendor that cannot point at a public docs page per question is asking you to trust a private claim.
| # | Question to put in the vendor questionnaire | Orbit docs page that answers it |
|---|---|---|
| 1 | Which data classes does your residency pin cover — recordings, voicemail, live media, metadata? | Voice Data Residency & Retention |
| 2 | Can we pin an explicit region ourselves, in dashboard and API, without a support ticket? | Voice Data Residency & Retention |
| 3 | What happens to residency when your region degrades — do you fail across regions silently? | Voice Data Residency & Retention |
| 4 | What retention window ranges are configurable, and are they enforced or optional? | Recording Library, Voice Data Residency & Retention |
| 5 | Can we place an individual recording under legal hold, exempt from age-based deletion? | Compliance first-run / surface guide |
| 6 | For voice biometrics — what exactly is stored, for how long, and how is a per-individual deletion executed? | Voice biometrics: enrollment, challenge, verify |
| 7 | Where does the opt-out / suppression ledger live, and is it exportable with revoke history? | Opt-Out & Suppression Lists |
| 8 | Does the suppression list gate every send path, at pre-dispatch, across SMS/voice/email/social? | Opt-Out & Suppression Lists |
| 9 | How are contact (CDP) profile records scoped per tenant, and how do we export or delete them per individual? | CDP feature surface, DSAR pipeline |
| 10 | Does the compliance posture come with evidence exports rather than screenshots? | Compliance posture review, Evidence binder |
A completed row is a vendor answer that cites its own public page. An empty row is a finding. The checklist works on any vendor — the Orbit column exists so a reviewer can test the answer instead of transcribe it.
Frequently asked questions
Is this a GDPR compliance guide or a buyer's checklist?
A buyer's checklist. It tells you which tenant-owned controls to ask about — residency pins, retention windows, legal hold, biometric lifecycle, suppression export — and where to verify each. The legal interpretation (lawful basis, special-category handling, sub-processor chain) stays with you and your counsel.
Does a voice data residency pin cover every record in our workspace?
No. The pin covers voice media — recordings, voicemail, live media, SIP/call metadata. Contact records and opt-out ledgers are separate classes with their own tenant-owned surfaces; if your contractual requirement spans channels, confirm coverage with the vendor in writing before go-live.
What retention window should we set for recordings?
There is no single correct window — the control is that it is tenant-configurable, not vendor-fixed. Orbit defaults to 30 days with a 7–3,650 day range per channel (enforced rather than optional under HIPAA mode), and supports per-recording legal hold to exempt an item from age-based deletion.
Why does the questionnaire demand a docs page per question?
Because a residency claim you cannot test against public documentation is a preference, not a control. The review's job is to move each answer from "trust the vendor's word" to "verify on the vendor's public docs and in our own workspace."
Are these controls mandates the platform enforces on us?
No. The suppression gate is the only send-path block and it is tenant-configured; everything else — the region pin, retention windows, legal hold, biometric thresholds — is your own configuration, defaulted open, that you set to match your own obligations. Orbit does not mandate your posture — it gives you the surfaces to run it.