Data residency: what it means, the laws, and how to map your analytics data

Enterprise buyers now ask where your analytics data lives before they sign. Data residency is the answer to that question, but the law usually cares more about transfers and identifiers than about the server’s address. This guide explains the terms, the main rules and a worked mapping of an analytics stack.

What is data residency?

Data residency is the physical or geographic location where an organization's data is stored and processed: the country or region of the data centers that hold it, including backups and copies made by service providers. When a company says "our data is resident in the EU," it means the servers that store and process it are in the EU.

Residency is often chosen for legal reasons, but also for customer trust, latency and procurement requirements. Enterprise buyers and public-sector customers increasingly ask where analytics, support and product data live before they sign.

Data residency vs data sovereignty vs data localization

Residency answers "where is it?"; sovereignty answers "whose laws apply?"; localization answers "is it allowed to leave?"

Not legal advice.

Data residency laws and rules

• GDPR (EU and EEA). GDPR does not require data to stay in the EU. Chapter V restricts transfers to countries outside the EEA unless there is an adequacy decision, standard contractual clauses or another safeguard. After the Court of Justice's Schrems II ruling in July 2020 invalidated the EU-US Privacy Shield, transfers to the US needed extra assessment until the EU-US Data Privacy Framework adequacy decision in July 2023, which covers only US companies that certify under it.
• UK GDPR. Similar transfer rules, with the UK's own adequacy regulations and the UK Extension to the Data Privacy Framework.
• China (PIPL). Cross-border transfers require a legal basis such as a security assessment, certification or standard contract, and critical information infrastructure operators and processors above volume thresholds must store personal information collected in China within China.
• Russia. Personal data of Russian citizens must be recorded and stored in databases located in Russia.
• Sector rules. Health, finance and government contracts often add their own location requirements regardless of general privacy law.

This is a summary, not legal advice. Requirements depend on the data, the sector and the contract.

Why analytics is a data residency question

Web and product analytics data looks harmless but usually contains personal data: IP addresses, cookie or device identifiers, user IDs and sometimes URLs with email addresses. Several European regulators ruled in 2022 that specific uses of Google Analytics transferred personal data to the US unlawfully, starting with the Austrian data protection authority in January 2022. The issue was not the product itself but identifiers and full IP addresses being transferred without adequate protection.

An analytics data flow has more stops than most teams realize: the tracking script and its CDN, the collection endpoint, the event database, backups, data exports, email reports, AI features and any subprocessor that sees raw rows.

Worked example: mapping an analytics stack

An EU software company mapped every place its analytics data went before an enterprise customer's security review (sample findings):

Of nine flows, six contained personal data and five of those left the EEA; two had no documented transfer basis at all. After the changes (EU region for storage and backups, IP truncation at collection, input masking, expiring exports), only two flows left the EEA, both documented, and the enterprise review passed. The analytics reports themselves did not change.

How to approach data residency

1. Map data flows, including vendors' subprocessors, backups and support access.
2. Classify the data: what is personal, what is aggregated, what is sensitive.
3. Minimize before you move. Truncating IPs, dropping identifiers and aggregating early can make residency questions disappear for much of the data.
4. Choose a region per data class based on law, contracts and customers.
5. Document transfer mechanisms for anything that leaves the region: adequacy, SCCs, or another basis, plus a transfer impact assessment where needed.
6. Ask vendors the right questions: where data is stored and backed up, which subprocessors see it, whether support staff outside the region can access it, and whether self-hosting is available.
7. Review yearly and when adding vendors or features.

Data residency in TapCub

TapCub's compliance center sets region rules for visitors in the EEA, UK, California, the rest of the US, China and elsewhere: collection tier, whether consent is required, how many bytes of the IP address are truncated, and how precise geography may be (Set region privacy rules, IP truncation and retention). IP addresses are not stored on event rows. China mode adds the init-after-consent gate and China-specific fields (China privacy mode). For organizations that must keep all data in their own data center or a designated cloud, TapCub analytics, behavior analysis and live chat can be deployed privately. See also Privacy by design and Data retention policy.

Sources

• GDPR, Chapter V: Transfers of personal data to third countries.
• European Commission, Adequacy decisions.
• Court of Justice of the EU, Press release on Case C-311/18 (Schrems II) (2020).
• DigiChina, Translation: Personal Information Protection Law of the PRC.