"CPaaS data residency" as a search query returns vendor pages that answer one question badly: they tell you a platform is compliant, when the question you actually need answered is where each class of your data lives and which controls you operate yourself. This page is the concept guide to how Devotel Orbit answers it — the posture that ships today, the record classes it covers, and the configuration burden that stays with you as the tenant. Nothing here is a platform mandate; residency on Orbit is a set of controls you set, default-open, to match obligations that are legally yours.
The shipped posture
Residency on Orbit is per-region self-containment plus tenant-owned configuration. The platform runs its voice plane as independent per-region clusters — eu (Belgium) and us (Iowa) are live today — and each region holds its own media servers, live call-state store, and recording storage. A workspace pinned to eu never has its call media, SIP/call metadata, or recordings carried through us infrastructure, and there is no automatic cross-region failover that could substitute one region for the other during a degradation.
The pin is a tenant-owned setting, not a support ticket. You set it in the dashboard under Voice → Regions or through the same public API route your buyers' checklist maps against — PUT /api/v1/voice/regions/preferred to set the pin, GET /api/v1/voice/regions/preferred to read back what calls will resolve to. The full mechanism, including why failover stays opt-in, is documented in the voice data residency announcement and the Voice Data Residency & Retention docs page.
One boundary stated plainly, because it is where residency claims usually overreach: the region pin covers the voice media classes below. It does not, on its own, relocate every record in your workspace. Messaging records, contact profiles, and opt-out ledgers are separate classes with their own tenant-owned surfaces; if your contractual requirement spans channels, confirm coverage in writing before go-live.
The record classes a voice + SMS workload produces
A buyer scoping residency should enumerate data classes, because each has a different residency story and a different retention surface. On a voice + SMS workload there are five:
| Class | What it contains | Where the control lives |
|---|---|---|
| Call recordings + voicemail | Stored audio of recorded calls and messages left against your numbers | Region-pinned storage; retention windows + legal hold under Settings → Compliance → Retention |
| Live media + SIP/call metadata | In-flight audio of calls in progress; the live call-state the platform holds while a call runs | Region-pinned media plane and per-region call-state store |
| Messaging records | SMS bodies, delivery receipts, and the routing metadata each message accumulates | Workspace-scoped records; channel-level retention under your compliance settings |
| Contact records (CDP) | Customer profiles, identifiers, conversation history, tags | Per-individual export and deletion through the DSAR pipeline |
| Opt-out / suppression ledger | The "never contact again" record across channels | Opt-Out & Suppression Lists, exportable with revoke history |
WhatsApp templates, sender identities, and other channel configuration are definitions your team authors, not the personal-data records a residency review scopes; the classes above are where your customers' data actually accumulates.
Retention and audit configurations to run as the tenant
Residency answers where; the equally important half is for how long, and who closes that window. The controls you should run in your own operations and audit workflows:
- Retention windows — recordings and voicemail auto-delete after a window you set per channel: 30 days by default, configurable from 7–3,650 days. Under HIPAA mode the window is enforced rather than optional, with a 365-day default. Set the window that matches your sector's minimum and your counsel's maximum, and re-visit it on a schedule — the quarterly compliance posture review is the cadence most teams adopt.
- Legal hold — exempt a specific recording from age-based deletion when litigation or an eDiscovery request attaches. The hold is per-recording, so the rest of the library keeps ageing out normally.
- Bring-your-own recording storage — when the residency decision lives at the storage layer, point recordings at your own Google Cloud Storage bucket under Voice → Calls → Recording settings. Orbit writes directly to your bucket; a temporarily unreachable bucket falls back to Orbit-managed storage and flags the call for reconciliation, so the recording is never lost.
- Posture evidence — residency claims survive audits only as exportable evidence. The Evidence Binder surface packages your posture as documents rather than screenshots, and the region pin's read-back endpoint gives you the written answer a reviewer asks for.
The buyer-side mapping of each control to its public docs page is the GDPR and data residency buyer checklist — run your review as written answers against documentation, not as a demo.
GDPR and HIPAA integration notes
For GDPR processing, the residency scope is Article 4 territory-reduction plus Article 32 security-of-processing: the pin reduces the set of processors and jurisdictions a call's personal data touches, and the class-by-class controls above are the "appropriate technical measures" your records-of-processing entries should cite. Voice-recordings-as-personal-data reads as the strictest GDPR sense of the term; treat the recording class as your scoping priority and the opt-out ledger as the clearest binary test an audit performs first.
For HIPAA-adjacent buyers, the enforced-retention asymmetry matters: rather than default-open windows, HIPAA mode makes retention mandatory (365-day default, 30–3,650 day range) and pairs with a signed BAA before voice recording unlocks. The full lifecycle, including the one-year BAA term the platform tracks, is in the BAA lifecycle walkthrough.
Tenant-owned framing, stated plainly
Everything above follows one rule and it is worth stating as a rule: on Orbit, compliance posture is the tenant's responsibility, configured by the tenant. The platform provides the surfaces — region pins, retention windows, legal hold, suppression ledgers, evidence exports — and the one send-path block (the suppression check) is a gate you set yourself. A residency control the vendor overrides unilaterally on degradation is not yours either; that is precisely the failure the no-silent-failover design refuses. Confirm coverage in writing, set the pin before you start recording, and keep the audit trail in the surfaces above.
Frequently asked questions
Does the region pin cover SMS records too?
The pin covers the voice media classes — recordings, voicemail, live media, SIP/call metadata. Messaging records are a separate class; confirm multi-channel coverage in writing before go-live if your contract requires it.
What retention window should we pick?
There is no right answer — the control is that it is tenant-configurable rather than vendor-fixed. Most GDPR reviews land between 30 and 90 days; HIPAA mode enforces a 365-day default. Re-visit the window on your quarterly posture review.
Can we keep recordings in storage we control?
Yes — bring-your-own Google Cloud Storage is a recording setting, and a temporarily unreachable bucket falls back to Orbit-managed storage with the call flagged for reconciliation.
What happens when we change the pin?
The pin applies to new calls. Recordings already written stay where they were stored, so make the pin before recording starts.
Is failover between regions possible during a degradation?
Only as an explicit per-workspace opt-in — never as a silent substitution, because silent failover would be the residency pin being overruled exactly when it matters.