Buyer's Guide Practical By Samson Tanimawo, PhD Published Jan 9, 2025 4 min read

Data Residency in Buying

Region requirements.

Why it matters

GDPR (EU), DPA (UK), CCPA (California), LGPD (Brazil), and sector rules (HIPAA, PCI) impose constraints on where customer data can live.

Vendor data residency claims vary widely. "Hosted in the EU" sometimes means "primary in EU, replica in US". Read the fine print.

Default rule: customer data stays in the customer's jurisdiction unless the customer signs off otherwise.

List every region where data is stored, processed, and replicated. Demand specifics, not "globally distributed".

Ask for the architecture diagram showing data paths. Vendor shouldn't need to draft this; it should already exist.

Confirm subprocessor list and their regions. Backup providers, search providers, analytics: all touch data.

Data residency clause: explicit list of regions, with notice required to add new ones (30 days minimum).

Right to terminate if vendor changes regions without notice. This is the only enforcement mechanism that works.

DPA addendum: GDPR-compliant data processing agreement signed at contract time, not promised later.

Single-region deployments are simpler but risk total outage if the region fails.

Multi-region within one jurisdiction (eu-west-1 + eu-west-2) is the right balance for most EU customers.

Multi-jurisdiction (US + EU) breaks GDPR unless you can prove data does not cross. Hard to prove with most SaaS.

List your customer base by jurisdiction. Map each to a residency requirement.

Audit current vendors against the map. Any mismatch is a renewal-time conversation.

Build residency questions into your vendor evaluation template. Catch issues during procurement, not during a renewal crisis.