Guide 4 min read

Four regions, no silent transfers: how data residency works in ZAAN

A tenant is pinned to Switzerland, the EU, the US or Singapore at creation and stays there. What that means for content, keys, models, support and the handful of things that do cross a border.

2026 · 05 · 12·admin

Four. Switzerland, the European Union, the United States and Singapore. A tenant is pinned to one of them when it is created, and from that moment its contracts, drafts, intake transcripts, simulation records, indexes, playbooks and keys live there and nowhere else.

That is the sentence firms want to hear. This note is about what sits behind it: what a region is, what never crosses, what does, how the boundary is enforced rather than promised, and the questions a firm should answer before choosing.

What a region is

A region is a complete, self-sufficient deployment. Each one contains the compute that runs Review, Draft, Recall, AI Interview and Simulation; the storage that holds tenant data; a key-management service holding per-tenant keys; and the models. ZAAN-7B Counsel runs in every region. So does the larger model Draft uses for first-pass composition, and so does the 38-language translation stack. Nothing is delegated to a central inference service, because a central inference service would be a transfer.

A tenant’s region is chosen at creation and cannot be changed by us. If a firm wants to move, it exports its tenant and imports into a new one, and the firm performs both steps. We have done this three times. It is deliberately not a button.

What never crosses, and what does

Content never crosses. That includes contract text in any state, flags, redlines, drafts, deal-point answers, intake transcripts and briefs, conflict-check results, simulation transcripts and scorecards, the Recall index, playbooks, and the keys that encrypt all of the above. Translation runs in-region even where a translation model in another region might perform marginally better on a given language pair. There are no exceptions to this and no configuration that creates one.

Some things do cross, and it is better to list them than to pretend otherwise. Tenant metadata: a tenant identifier, its region, which features are enabled and how many seats are licensed. Aggregated, non-content telemetry, if a firm opts in: counts of flags by severity and outcome, latency percentiles, error rates. Software releases, which move from our build systems into each region; code goes in, nothing comes out. Service status. That is the list.

Support access is in-region and just-in-time. An engineer helping with a problem is granted time-limited access to a specific tenant from infrastructure in that tenant’s region, the grant is approved by someone the firm has named, and every action is logged to the tenant’s own audit trail. An engineer in Shenzhen helping a Swiss tenant does so through the Swiss region, and the tenant can see that they did.

Enforced, not promised

A residency commitment is only as good as what happens when someone makes a mistake. Three layers make the mistake hard.

Network. The content planes of the four regions have no routes between them. A service in the EU region cannot open a connection to storage in Singapore, not because policy forbids it but because there is no path.

Keys. Each tenant’s data is encrypted with keys held in that region’s key-management service. A request arriving in the wrong region, were one somehow to arrive, could not decrypt anything. Per-tenant encryption also means that within a region, one tenant’s keys cannot open another tenant’s data.

Control plane. The systems that create tenants, enable features and deploy software can act on a region without being able to read from it. This separation is tested as part of our SOC 2 Type II and ISO 27001 scopes, which cover all four regions.

Zero retention operates inside each region: contract text is processed in memory and not written to durable storage, and what the firm chooses to keep is kept under the firm’s own tenant key.

Edge cases

A firm with offices in two regions has two choices: one tenant in one region, with users elsewhere connecting across the distance, or one tenant per region, with no shared matter history between them. Most choose the former. A user in Singapore working against a Swiss tenant adds around 180 milliseconds of network latency per request; the Word add-in tolerates this and per-clause review still lands inside the 500-millisecond budget most of the time.

Open Bar tenants are served from the EU region, including the Lagos cohort. We say this plainly because clinics ask.

Air-gap bundles are built in the tenant’s region and carry the tenant’s residency with them onto the laptop.

Subprocessors differ by region, since the underlying cloud provider does. The list is in the data processing agreement and is specific to the region a firm selects.

Choosing a region

  • Where are the regulators your clients answer to? Residency is usually about them, not about you.
  • Where are your users? Latency is tolerable across regions, but it is not nothing.
  • Do any client engagement terms specify a jurisdiction for data? Read them before, not after.
  • One tenant or several? A shared matter history is worth a great deal; separate tenants cannot search each other.
  • Who in the firm will approve support access? Name a person and a deputy before you need one.

Residency is not a feature we switch on. It is the shape of the system, and the shape does not change when nobody is watching.

See it on a contract you have already reviewed.

Send us a draft your team has already redlined and we will show you what ZAAN catches, and what it misses.