# Data residency

Data residency is the question of which country your data physically sits in. It is narrower than it sounds: it constrains storage locations, not who may compel access, and in a communications product the interesting locations are usually your own providers' rather than the application's. The useful move is to ask specific questions rather than to look for a badge.

- **Status:** Reference
- **Audience:** both
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/data-residency/

## Three words that are not synonyms

**Residency** — Where data is stored. A statement about geography, and the easiest of the three to verify
**Sovereignty** — Whose law can compel access to it. A supplier incorporated in one country storing data in another is subject to both
**Localisation** — A legal requirement that certain data must not leave a jurisdiction at all, sometimes with a copy-abroad allowance and sometimes not

Conflating them produces the common disappointment: a supplier truthfully says data is stored in your region, and a regulator's question turns out to have been about sovereignty, which the storage location does not answer.

## What residency actually constrains in a system like this

A product that reads mail and makes calls has more locations than its own database. Enumerate them before asking anybody a question, because the answer differs per row.

| Location | Holds | Decided by |
|---|---|---|
| The application database | Conversations, records, memory, knowledge, files | The operator's deployment |
| Backups and snapshots | The same data, often for longer | The backup configuration, which may differ in region from the primary |
| Your mail provider | The original messages, before Connect ever sees them | You — Gmail, Microsoft Graph or your own IMAP server |
| Your carrier and messaging providers | Call signalling, audio paths, message delivery | You, per workspace |
| Model providers | The context sent for one piece of work, for the duration of that call | The provider's own regions |
| Anything you export | Whatever the export contains, wherever you put it | You, at the moment you press export |

> **Note** A workspace's own mail provider usually holds a longer and more complete history than Connect does. Residency work that examines the application and stops there has examined the smaller store.

## Does Connect use data residency controls?

Connect is one deployed application rather than something installed per workspace, so there is no per-workspace region setting and no screen on which to choose one. Both audiences run on the same deployment, isolated from each other by the workspace allowlist, the workspace kernel and PostgreSQL row-level security — which is an isolation guarantee, not a geographic one, and the two should not be confused.

What is genuinely under a workspace's control is the set of providers it configures. The mail provider, the messaging provider and the carrier are chosen per workspace, and each brings its own regions and its own terms.

Connect claims no certification — not ISO, not SOC 2, not any other — and this corpus will not imply one. Where a specific deployment fact matters to a decision you are making, ask JBRH Digital Solutions directly rather than inferring it from a documentation page.

## Questions that get a usable answer

1. In which country is the primary database, and in which country are its backups? These are two questions, and the answers are allowed to differ.
2. Which third parties receive data in the course of normal operation, and for what? Name them individually rather than accepting a category.
3. How long is each store kept, and what does deletion do — mark or destroy?
4. What can be exported, in what format, by whom, without asking anyone?
5. Which of these are properties of the product and which are properties of providers I chose? Only the second set changes when I change supplier.

The last question is the one that most often reframes the conversation. If the messages themselves live in your own Google or Microsoft tenancy, the residency of that tenancy is a decision you already made, and it governs a bigger store than the application's copy.

## Questions

### Can I choose which region my workspace's data is stored in?

No. Connect runs as a single deployed application and there is no per-workspace region selection. Isolation between workspaces is enforced three times — the customer allowlist, the workspace kernel and row-level security in the database — but that is a separation guarantee rather than a geographic one.

### Does using Connect move my mail out of my mail provider?

No. Connect reads from the mailbox you connect and keeps a canonical copy of the conversations it works on; the originals stay where they were. If you disconnect a mailbox, your provider still holds everything it held before.

### Is a compliance certificate available?

No, and none is claimed anywhere in this documentation. What is documented instead is the mechanism — how isolation is enforced, where credentials live, what an audit entry contains — so that you can evaluate it rather than take a badge on trust.

## Related

- [What is kept and for how long](https://connectbyjbrh.com/docs/security/data-retention/)
- [Privacy inside the product](https://connectbyjbrh.com/docs/product/privacy-in-the-product/)
- [Personal data](https://connectbyjbrh.com/docs/technology/pii/)
- [Encryption at rest](https://connectbyjbrh.com/docs/technology/encryption-at-rest/)
- [The data you give Connect](https://connectbyjbrh.com/docs/product/data-you-give-connect/)

## What this page is based on

- `docs-source/sources/GENERAL.md` §1, §2 and §10 — deployment shape, isolation, security
- `docs-source/sources/CHANNELS.md` §1 — the two mail models and provider ownership
- Connect capability registry (docs-source/facts.py) — FORBIDDEN_CLAIMS