Multi-Region Data Residency — Enterprise Guide

This feature is not available on all Enterprise accounts. It must be explicitly provisioned for your account by the Velaro account team. If you are unsure whether your account has data residency enabled, contact your account manager or check with support before telling customers it is available to them.

How to check: The EnableDataResidency and EnableMultiRegionInbox flags on your subscription must be set. Your Velaro account team configures this — there is no self-service toggle.

Contact to provision: Your account manager, or compliance@velaro.com

---

What data residency means

Data residency controls where conversation transcripts and personal data are stored — specifically, which Azure region holds the Cosmos DB instance that contains your chat data.

This is a paid add-on. Not every Enterprise account has it. Do not promise or imply it is included until confirmed for a specific account.

---

GDPR, UK GDPR — important clarification

You are not required to store EU or UK data in-region to comply with GDPR. GDPR does not mandate physical storage location. What it requires is that personal data of EU residents is protected with adequate safeguards when transferred outside the EEA — which can be satisfied with Standard Contractual Clauses (SCCs), the EU-US Data Privacy Framework, or other mechanisms.

What you cannot gate behind any plan: The right to erasure (Article 17), the right to access, and the right to a Data Processing Agreement. These are legal obligations for any customer whose users are EU residents, regardless of their Velaro plan tier.

What the EU/UK regional storage add-on provides: Convenience and reduced compliance overhead. If data physically stays in the EU, no SCCs are needed and no transfer analysis is required. For organizations with strict internal policies or regulators who prefer in-country storage, it eliminates the conversation entirely. But it is not a legal mandate — it is a risk reduction option.

Canada (PIPEDA / Quebec Law 25) is different. Quebec Law 25 is stricter and does practically require Canadian storage if you want to avoid the PIA and written agreement burden. Canadian in-region storage has a stronger compliance driver than EU/UK.

---

What's included by default vs. what requires this add-on

Capability	All paid plans	Requires data residency add-on
Right to erasure (GDPR Article 17)	✅ Always	✅
Data Processing Agreement (DPA)	✅ On request	✅
Standard Contractual Clauses (SCCs)	✅ Available	not needed if in-region
Immutable GDPR erasure log	✅ Always	✅
Contact permanent deletion	✅ Always	✅
Physical storage in Canadian Azure	❌ Add-on only	✅ Canada Central
Physical storage in EU Azure	❌ Add-on only	✅ West Europe (Netherlands)
Physical storage in UK Azure	❌ Add-on only	✅ UK South
Per-deployment region config	❌ Add-on only	✅
Per-team region config	❌ Add-on only	✅
Unified cross-region agent inbox	❌ Add-on only	✅
PIPEDA / Quebec Law 25 DPA addendum	❌ Add-on only	✅

---

Supported regions

Code	Azure Region	Regulatory framework
us	East US 2	Default — all accounts. SOC 2, HIPAA, CCPA.
ca	Canada Central	PIPEDA + Quebec Law 25
eu	West Europe (Netherlands)	GDPR Article 44
uk	UK South	UK GDPR (post-Brexit)

---

How it works

Region assigned at conversation creation — permanently

When a visitor starts a conversation, Velaro resolves the data region using a priority chain:

1. Deployment data region — if the widget deployment has a region set, all conversations from that deployment use it

2. Team data region — if the team receiving the conversation has a region set, that region applies

3. Default: us — if neither is configured, conversations go to the US instance

The data_region field is written to the conversation record at creation and never changes. This immutability is the foundation of the compliance evidence trail — an auditor querying conversation records can confirm exactly where every conversation was stored from its start.

What data goes to the regional store

Data type	Regional?	Examples
Message bodies	✅ Yes	Chat transcripts, AI replies
Contact identity	✅ Yes	Name, email, phone, IP address
AI skill inputs	✅ Yes	Prompts, extracted values
Attachments	✅ Yes	Files sent by visitors
Conversation metadata	✅ No (jurisdiction-safe)	Status, timestamps, team_id
Routing config	No	data_region tag itself, deployment_id

During an active conversation, message text passes through transit infrastructure for real-time delivery. Once the conversation is resolved and archived, PII is written exclusively to the regional Cosmos instance.

---

Agent experience — nothing changes

Agents do not need to change anything when data residency is enabled:

• One inbox — the inbox automatically fetches conversations from all regional instances (US, CA, EU, UK) in parallel and merges them. There is no "switch to Canada view."
• Same team, multiple regions — one agent team can handle conversations from a Canadian deployment (stored in CA) and a US deployment (stored in US) simultaneously. The queue shows them together.
• Transfers preserve the region — when a conversation is transferred to another agent or escalated, the data_region does not change. The data stays where it was assigned.
• Reporting — supervisors see aggregate metrics across all regions, filterable by region when needed.

---

Example configurations

Canadian bank — separate retail and back-office deployments

Deployment: widget on velaro-bank.ca  →  data_region = ca
Deployment: internal.bank.com          →  data_region = us (default)

Result: Canadian retail conversations → Canada Central Cosmos
        Internal back-office conversations → US East Cosmos
        Agents work one inbox, see both queues

GDPR ecommerce — EU storefront, US warehouse

Deployment: widget on mystore.eu       →  data_region = eu
Deployment: widget on mystore.com      →  data_region = us (default)

Result: EU visitor conversations → West Europe Cosmos (GDPR Article 44 satisfied, no SCCs needed)
        US conversations → East US Cosmos
        DPA addendum required for EU deployment only

Healthcare — Quebec patients vs. US research team

Team: Provincial Intake (Quebec patients)  →  data_region = ca
Team: US Research Collaboration            →  data_region = us

Result: Quebec patient conversations → Canada Central (Law 25 compliant)
        Research conversations → US East
        Law 25 PIA scope = Provincial Intake team only

Global enterprise — all four regions, one platform

support.ca → ca   |   support.eu → eu   |   support.uk → uk   |   support.com → us

Agents log into one Velaro Workspace
Inbox aggregates from all four regions in parallel
Supervisors see one dashboard, filterable by region

---

Setting data regions

Data regions are configured by the Velaro account team via SuperAdmin. There is no self-service UI today.

To request configuration:

Contact your account manager or compliance@velaro.com with:

• Which deployments or teams need Canadian/EU/UK routing
• Which specific laws apply (PIPEDA, Quebec Law 25, GDPR, UK GDPR)
• Whether you need a DPA addendum for any region

What Velaro will do:

1. Enable EnableDataResidency (and EnableMultiRegionInbox for cross-region inbox)

2. Configure data_region on your specified deployments and/or teams via SuperAdmin API

3. Issue the appropriate DPA addendum for each active region

4. Document the configuration for your compliance team

---

Canadian compliance specifics

PIPEDA (federal)

• Allows cross-border transfer with "comparable protection" — but storing in Canada eliminates the transfer entirely, which is the cleanest compliance position.
• Canadian data in Canada Central satisfies the at-rest storage requirement.

Quebec Law 25 (provincial — stricter)

• Requires a formal Privacy Impact Assessment (PIA) before any cross-border transfer.
• Requires written data processing agreements with specific Law 25 clauses.
• Requires individual notification to affected persons.
• Storing in Canada avoids all of these requirements. The PIA scope is limited to deployments/teams configured with ca — not your entire account.
• Banks, telecoms, insurance companies, and BPOs serving Quebec customers face direct enforcement risk without in-province storage.

Velaro's DPA addendum for Canadian accounts includes Law 25-specific clauses. Request it at compliance@velaro.com.

---

GDPR right to erasure with regional data

When a GDPR deletion request is processed:

1. The contact's data is permanently deleted from the assigned regional Cosmos instance (not just the US SQL record)

2. An immutable GdprErasureLog entry is created documenting: who requested deletion, when, confirmation initials, reason, and a summary of tables erased

3. Deletion is processed within 30 days and includes backup purges

4. The erasure log itself is never deleted — it is your evidence of compliance

---

Historical data before data residency was enabled

Conversations archived before the feature was configured are stored in the US (default). A SuperAdmin backfill tool is available to re-archive historical conversations to the correct regional Cosmos instance by date range. Contact Velaro support if a backfill is needed.

---

Compliance documentation available

Document	How to get it
Data Processing Agreement (DPA)	compliance@velaro.com — include your regions
Quebec Law 25 DPA addendum	compliance@velaro.com
GDPR Standard Contractual Clauses (SCCs)	compliance@velaro.com
Security questionnaire (CAIQ/SIG format)	security@velaro.com — 1 business day response under NDA
Penetration test summary	Enterprise accounts — contact account manager
SOC 2 Type II report	Available under NDA to Enterprise accounts
Architecture summary for auditors	This document, plus features/data-residency.html