Data Residency
Data residency is the question of where data physically lives and gets processed — which country’s data centers, under which jurisdiction’s reach. Related but distinct: data localization (a legal requirement that data stay in-country) and data sovereignty (whose laws govern it regardless of location).
Where it bites SaaS companies
Three places. GDPR transfers: EU personal data reaching US infrastructure needs a lawful mechanism (SCCs or adequacy). Sector and national rules: financial regulators, health systems, and public- sector buyers in many countries carry localization expectations — fintech expansion plans meet these early. Procurement preference: even absent legal requirement, “can you host our data in the EU?” is now a routine enterprise ask, and “no” is a scored answer.
Answering it honestly
Your real residency posture is your infrastructure map plus your sub-processor list: primary regions, backup regions, and every vendor that processes the data (support tooling and LLM APIs included — the classic leak in residency claims). Claiming “EU-hosted” while logs stream to US-based observability is the discrepancy security reviews are built to find.
The architecture note
Regionalization is far cheaper designed than retrofitted. If EU enterprise or regulated-market pipeline is plausible within two years, make region a first-class parameter now — the compliance answer then becomes a configuration screenshot instead of a migration project.
Shared Responsibility Model — The shared responsibility model splits security duties between cloud provider and customer — and misreading the split is a classic audit and breach root cause.
Sub-processor — A sub-processor is any third party your company uses to process customer personal data — your cloud host, email provider, analytics. You must disclose them.
Standard Contractual Clauses (SCCs) — Standard Contractual Clauses are the EU-approved contract terms that make transfers of personal data outside the EU lawful — the workhorse of GDPR transfers.