Data residency

Pin your organization's encrypted vault data to a specific region — and control it at the org, group, or user level.

How it works #

Every vault's ciphertext is stored in exactly one region's storage. Routing is fail-closed — if a region isn't available, writes are refused rather than stored in the wrong place. Data is never silently moved across borders. Everything stored is zero-knowledge ciphertext; Veridenti never sees vault contents.

Finding your way around #

The Data Residency screen is organized into three tabs:

• Overview — your residency posture at a glance: the organization default region and the per-group and per-user defaults that layer on top of it.
• Migrations — relocate existing data with Move a Vault Between Regions, and see the Residency Compliance table recording every migration.
• Continuity & DR — live per-region status, in-jurisdiction DR replicas, your RPO/RTO targets, and Break-Glass controls for a region emergency.

Where new data lands: org, group, or user defaults #

A vault's region is resolved in this order — user default → group default → organization default → global:

• Organization default — the fallback for everyone. Set it under Data Residency → Organization Default Region. Changing it first pins existing vaults to their current zone, so no data silently shifts; only new vaults use the new default.
• Per-group default — set a directory or manual group's region under Data Residency → Default Region by Group. Every member's new vaults pin there.
• Per-user default — set an individual's region in the Region column of Members. This works without SSO or SCIM — the self-serve path for smaller teams.

Business plans include Global, EU, and US zones; per-country zones require Enterprise.

Available regions #

Global, EU, and US today; per-country residency (Canada, UK, Germany, France, Australia, Singapore, India, Japan, and more) on an Enterprise contract. EU-member countries are covered at the EU level by the EU zone.

Moving data that already exists #

Setting a default only affects new vaults. To relocate data that already exists, use Move a Vault Between Regions on the Migrations tab: Veridenti copies the ciphertext to the target region zero-knowledge (never decrypted), flips the region pointer only after every item has copied, then purges the source. It is fail-safe — a mid-copy failure leaves the vault intact on the source — and every move is audited.

Compliance reporting #

The Residency Compliance table (on the Migrations tab) records every migration — source, destination, item count, and whether the source purge completed or left anything to remediate — read from the tamper-evident audit log. You can re-run a purge from the same table if a former source needs re-cleaning.

Residency vs. sovereignty #

Storing data in a country (residency) is different from being immune to foreign law (sovereignty). For strict sovereign regimes (e.g., France SecNumCloud, some German public-sector requirements), Veridenti can target a sovereign provider — and because Veridenti is zero-knowledge, even a legal request in another jurisdiction yields only ciphertext no one can decrypt. That last property is often the strongest control of all.

Availability & disaster recovery #

Region-pinning affects durability and availability. See the Continuity & disaster recovery guide for how pinned data rides out an outage — offline-first access, platform redundancy, and in-jurisdiction DR replicas — and use the Continuity & DR tab for live per-region status, replica health, RPO/RTO targets, and Break-Glass.

What if… #

• You need a region that isn't listed — contact your account team; new regions are provisioned per contract.
• You change a default later — new data follows it; existing data moves only via Move a Vault.
• A member should store data in their own country — set their Region in Members (no SSO required), or put them in a group with that region.