> ## 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. # Data Residency Overview > How data residency works across Orbit — which controls resident-location is available per channel, and which commitments live on the Devotel platform side # Data Residency Overview "Where does my data live?" has a different answer per channel on Orbit. Voice is the one channel where you pin a resident region directly; everything else — email, SMS, WhatsApp, RCS, and the audit trail — is covered by the platform geography Devotel publishes in its legal materials, plus the location guarantees that apply when a data-subject request is exported. This page is the map: which surface answers which channel's residency question, and what belongs in a residency-aware tenant checklist. This page describes Orbit's platform controls. It is **not legal advice.** Your residency obligations depend on where your recipients and data subjects are located, your industry, and your contracts. Confirm the specifics with qualified counsel. *** ## Which control answers which channel Pick the right surface before you write residency into a register or a contract answer. Using the voice-region pin as the answer for every channel is the common mistake — it covers voice data and nothing else. | Data class | Residency surface | What it controls | | ----------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | Call recordings, voicemail, live voice media | [Voice data residency](/compliance/voice-data-residency) | The resident region — you pin `eu`, `us`, or leave it on `auto` per workspace | | Email, SMS, WhatsApp, RCS messages and metadata | The subprocessor registry in the [Trust Center](https://orbit.devotel.io/en/trust) | Where the platform and its named subprocessors store and process this data — a Devotel-side commitment, not a tenant setting | | Audit logs and security events | The subprocessor registry plus [SOC 2 control mappings](/compliance/soc2-controls) | Platform processing geography; retention is the tenant-owned switch | | Data exported under a DSAR | The export artifact's storage and link expiry (see below) | The residency scope is fixed when the export is produced — it cannot relocate after export | For messaging channels there is no tenant-side region pin. The residency answer lives with the Devotel platform and the subprocessors it engages, and it is published — with data-residency notes per entry — alongside the SOC 2 reports and downloadable agreements in the Trust Center. *** ## How to read the subprocessor registry The registry names every third party that processes platform data and states, per entry, what it processes and where. Read it before you fill in a security questionnaire or your own Art. 30 register. (The [Legal index](/legal/) keeps the map of which document binds which party if you need the contract context around the registry.) * **What the registry gives you** — the vendor name, the data classes it touches, its processing location, and the agreement that covers it. That is the residency answer for email, SMS, WhatsApp, and RCS — there is no per-workspace toggle that changes it, and none is offered as one. * **What it does not give you** — a control you can flip. The note `not a tenant setting` in the table above is deliberate: residency on messaging channels is set by where the platform runs, which is a procurement-side question, not an ops-side switch. * **What to do with it in your own records** — record the registry entry as the residency basis for the channel in your Art. 30 register, next to the channels it covers. If a buyer asks for a channel-level residency answer for messaging, point at the registry entry, not at a dashboard toggle. When a contract requires messaging residency beyond what the registry describes, raise it with Devotel before signing — the registry is the published answer, and anything narrower is a commercial conversation, not a configuration step. *** ## What resident region the controls actually cover The distinction matters most at the audit-evidence and questionnaire boundaries you are answering. The [Voice data residency](/compliance/voice-data-residency) page — and the dashboard region pin it documents — covers exactly three voice data classes: **call recordings**, **voicemail**, and **live media** for calls in progress. Each resident region runs its own media servers, live call-state, and recording storage, and the platform routes nothing from an `eu`-pinned workspace through the `us` region (nor the reverse). Everything else on Orbit — message bodies and metadata for email, SMS, WhatsApp, and RCS, plus your audit logs and security events — is under the subprocessor-registry answer above. When a residency question arrives, don't point it at the voice-region page unless the data being asked about is one of the three voice data classes; pointing at it for messaging or audit data answers a question with the wrong control. *** ## The DSAR export's residency scope When an access or portability request runs, the exported payload — the per-table rows behind `tables_exported` on a completed request — is packaged in storage whose location and link shape are fixed at export time. That scope has two consequences: * **The scope can't be widened after the fact.** If a residency reading of your tenant is part of the export decision, it needs to be settled before the export is produced, not argued about once the link is issued. * **Playback-style links are short-lived.** Like recording playback, the export link is a temporary signed artifact, not a durable copy of the data. Whatever residency interpretation you rely on, treat the link as a one-hour-shaped pointer rather than a new residence for the data. The precedent is the reasoning on the voice page: a stored artifact carries its region with it, and fetching it from a different geography doesn't relocate it. The same shape applies to DSAR exports. For the intake, verification, and fulfilment mechanics of a request, see [DSAR](/compliance/dsar). For how the export fits the wider GDPR sequence, see [Assembling a GDPR Posture End to End](/compliance/gdpr-posture-guide). *** ## Tenant checklist for a residency-aware posture Residency is a set of per-channel answers plus record-keeping decisions. Work this checklist before you certify a workspace's residency posture to a buyer or a supervisory authority. If you record calls or process voicemail, decide whether `auto` routing is acceptable. If your recipients' locations or your industry require a resident region, pin it under **Voice → Regions** before you start recording — region changes apply to new calls only, so pinning after recordings exist leaves them in the region they were written in. Owner or admin permission is required; every change is in your audit log. Details: [Voice data residency](/compliance/voice-data-residency). For each messaging channel you run (email, SMS, WhatsApp, RCS), record the Trust Center registry entry as the residency basis in your Art. 30 register. If a buyer's questionnaire asks for a channel-level switch, point at the published registry entry; if your contract truly requires narrower residency, raise it with Devotel before you commit to an answer. Residency answers the where; the how-long side of the answer is your [per-domain retention policy](/compliance/data-retention-policy) (message-body redaction, conversation hard-delete, and the opt-in audit-log purge). Both halves belong in the register. If an export artifact will be handed to a requester or authority, confirm the residency reading of your tenant is settled before the export is produced — its scope freezes at export time. Region pins, workspace-level retention, and the registry's residency notes change independently. Rerun the checklist when you change a pin, extend a domain's retention, or when the Trust Center registry publishes a revised entry for a channel you use. None of the controls above gates sending. Residency pinning is a record-keeping and location preference, not a platform hard guard — configure it deliberately, and document whichever reading you settle on. *** ## Related The channel where you pin a resident region — recordings, voicemail, and live media. The how-long half of the residency answer for messages, conversations, and audit logs. The exports and erasures whose residency scope freezes when they run. Audit logging, tenant isolation, and the platform control environment behind the registry. Where the platform's binding documents — terms, privacy, and the Trust Center — live.