By the Onsites AI team · Last updated · 5-minute read
Data residency questions arrive the same day a desk becomes real infrastructure for anything sensitive: a hospital's patient-adjacent inquiries, a defense contractor's RFQ thread, a government supplier's invoices, a university's student records in support chats. The compliance office asks three deceptively simple questions — where does the data physically live, who can access it, and can you prove both — and this guide is the grounded answer set for each delivery shape Onsites AI offers, plus the questions you should be ready to answer back.
"Where is the data stored?" means: in which country, on whose hardware, and which other jurisdictions can compel access to it? For the managed cloud, the honest answer starts "on infrastructure operated by Onsites, encrypted at rest, in regions [our docs list]" — residency by vendor geography plus contract. For self-hosted, it ends with your street address or your cloud tenancy in the region you chose: the database, attachments and backups sit where you put them, full stop. "Who can access it?" means two different lists: on the cloud, Onsites operators exist and are controlled by contract, least-privilege and audit; on self-hosted, that list is empty by architecture — Onsites has no access to customer data, no back channel, no shared admin. "Can you prove it?" asks for audit trails (both shapes keep them), access control evidence (seat-based access on both), encryption attestations (TLS in transit, encryption at rest, either way) — and, on self-hosted, the decisive proof that needs no trust at all: your own network cannot show traffic that never existed.
The managed cloud is a SaaS contract, and its compliance story is contractual: TLS in transit and encryption at rest; seat-based access controls so every human's reach is named and limited; audit trails recording who did what; and region policy per the product documentation, which you verify before the sensitive workload arrives rather than after. The honest residual risks are the ones any SaaS carries: vendor-side staff access exists in principle (bounded and logged, but existing), and jurisdiction follows the vendor's infrastructure. When a compliance office accepts SaaS at all, these controls are the package that makes acceptance routine — and the free tier has one additional wrinkle worth stating out loud in any review: free workspaces have no server-side backups, so data durability depends on your export discipline.
Self-hosted replaces several chapters of a vendor review with one sentence: the processing environment is yours. Your LAN or your tenancy; your jurisdiction; your keys; your firewall logs proving what never left; no subprocessor list to audit because there are no subprocessors on the data path. The compliance office's residual questions become operational rather than contractual: who inside your org can reach the production database, how are self-hosted updates vetted, what does your backup residency look like (an off-site copy still crosses a border if you let it), and who owns the AI endpoint policy — because the model you point at is the last and loudest data processor in the modern stack. Teams in regulated trades usually find self-hosting simplifies the questionnaire, at the price of owning operations the cloud would have carried.
Most real-world findings are not about geography; they are about the joiners-and-leavers spreadsheet nobody maintained. Make seat hygiene a compliance control: every seat belongs to a named person with a role; admins are few and listed in the runbook; offboarding is a same-day seat revoke with the audit trail as its receipt; and shared logins are treated as what they are — a finding, because an audit trail that cannot name a human proves nothing. The desk's seat-based model helps here in an understated way: three free seats keep tiny teams from the "one login for everyone" shortcut, and every added seat is a deliberate, metered act ($15/seat/month beyond the third) rather than an anonymous expansion. When the auditor asks "who could have reached this conversation?", the correct answer should be a list you can produce from settings in one screen — rehearse producing it.
Most vendor-assessment forms collapse to a page you can fill in an hour. Prepare both answers once: hosting — "cloud, operated by Onsites (see docs) / self-hosted, deployed on [our LAN / our tenancy in region X] via Docker" (deployment guide); access — "seat-based access control; named admins; audit trails retained in-product"; encryption — "TLS in transit; encryption at rest"; processing — "cloud: Onsites as processor, see terms / self-hosted: no vendor access, no subprocessors"; AI — "cloud: credits-managed assistant / self-hosted: our model endpoint, our DPA"; backups — "paid cloud: automatic encrypted / self-hosted: ours, schedule and residency per runbook / free: exports we hold"; exit — "full export from settings at any time; migration between deliveries is supported by design." Attach the deployment guide and the security page, and most paperwork ends there; the offices that go deeper are asking the questions the next section equips you for.
1 · "Show me an export of a customer's entire footprint." Both shapes: the CRM record with linked conversations, documents and audit entries, exported on demand — rehearse this before being asked. 2 · "Who deletes, and when?" Name the retention policy for closed conversations and exited employees' seats; audit trails are exactly where deletion shows. 3 · "What happens on breach?" Cloud: the notification pathway in the agreement. Self-hosted: your incident process — and the honest point that a self-hosted breach is your incident, not ours. 4 · "Where does AI data go?" The answer must match the model config you actually run; if you switched endpoints last quarter, say so. 5 · "Can data leave?" Show the exports and the export schedule — the ability to walk away, in a defined format, is the control that outlasts every promise.
The pattern through all of it: cloud compliance is trust expressed as contract, self-hosted compliance is control expressed as architecture, and both are legitimate — the mistake is defending one with the other's arguments. Match the delivery to the sensitivity class of what your customers write, and the questionnaire stops being a cliff and becomes a form.
Where does support data live on the managed cloud versus self-hosted?
On the cloud, on infrastructure operated by Onsites, encrypted at rest and protected by seat-based access and audit trails — residency follows the vendor's documented regions and contract. Self-hosted, the data lives entirely on your LAN or your own cloud tenancy, in the jurisdiction you choose.
Can Onsites staff access a self-hosted workspace's data?
No — in self-hosted mode Onsites has no access to customer data. The deployment runs inside your network, there is no vendor back channel, and your own firewall logs are the proof.
What security controls apply to both delivery models?
TLS in transit, encryption at rest, seat-based access controls and audit trails apply to both cloud and self-hosted. The difference is who operates them: contractually with the vendor, or literally and physically you.
Do we still need a backup policy if we self-host?
Yes, more than ever: self-hosted backups run on your infrastructure via the included scripts, and their residency is your decision too. An off-site copy still crosses a border if you let it — choose deliberately and rehearse restores quarterly.
How do we answer a customer's data-processing questionnaire?
From one prepared page: hosting model, access controls, encryption, AI endpoint policy, backup schedule and exit path. The honest short form is that cloud compliance is contractual trust while self-hosted compliance is architectural control — pick the one your data's sensitivity class demands.