Name the legal frameworks that govern each location. Name the mechanism that authorizes the transfer to each jurisdiction. If you cannot answer this question with specificity about your primary customer data categories, the answer is that you do not know — and not knowing is the compliance position that regulators are increasingly finding unacceptable.
Why the Question Is Harder Than It Sounds
Customer data in a modern enterprise environment does not sit still. It is processed by the CRM system, replicated to the analytics warehouse, shared with the email service provider for communications, processed by the customer support platform, backed up to disaster recovery storage, and transmitted to reporting tools. Each of these systems may run in different cloud regions. The cloud regions may be in different countries. The service providers may be in different jurisdictions. The backup may replicate to a jurisdiction that was not considered when the primary storage location was selected.
Cloud architecture decisions are made by engineering and infrastructure teams whose primary objectives are performance, reliability, and cost. Data residency is a governance consideration that may not have been part of the architecture decision. The cloud region selected for latency optimization may be in a jurisdiction that creates compliance obligations that the governance team did not anticipate. The backup replication configured for disaster recovery may create a data presence in a jurisdiction that the privacy team did not know existed.
Data residency is a governance requirement. Cloud architecture decisions are engineering decisions. When these two decision-making processes operate without coordination, the architecture produces data locations that the governance program has not assessed.
The Legal Framework at Each Location
Knowing where customer data is located is the first question. The second question is what legal framework governs each location. This requires more than knowing which data protection regulation applies in the primary storage jurisdiction. It requires understanding the government access frameworks in each jurisdiction — the laws that allow law enforcement and intelligence agencies to compel access to data stored or processed there.
The Schrems II decision made the government access question legally significant for EU-to-US data transfers. The decision invalidated the Privacy Shield mechanism and required that organizations assess whether the legal protections in the recipient country are essentially equivalent to EU protections, taking into account government access laws. This assessment cannot be completed without knowing where the data actually goes, which requires the kind of precise jurisdictional mapping that most organizations had not built before the decision made it necessary.
Since Schrems II, the jurisdictional landscape has continued to evolve. The EU-US Data Privacy Framework has been adopted and is being implemented. UK adequacy decisions post-Brexit have their own assessment requirements. APAC privacy frameworks including China's PIPL and India's DPDPA have introduced new requirements for data transfers involving those jurisdictions. The legal framework at each data location is not static, and the mapping that was accurate last year may not be accurate today.
The Jurisdictions That Surprise Organizations
The CDN Jurisdiction
Content delivery networks cache data at edge nodes distributed globally. Organizations that serve global users through a CDN may have customer data cached in jurisdictions that were never selected as data locations and may not appear in any data mapping exercise. CDN edge nodes in jurisdictions with problematic government access frameworks represent a data residency reality that most privacy programs have not assessed.
The Backup Jurisdiction
Backup and disaster recovery systems are configured for resilience, not for data residency compliance. An organization whose primary customer data is in the EU may have backup replication configured to a region that is outside the EU. The backup exists for legitimate resilience purposes. Its jurisdictional implications may not have been assessed by the privacy team that assessed the primary storage.
The SaaS Subprocessor Jurisdiction
SaaS vendors process customer data using their own infrastructure, which may include subprocessors in jurisdictions not prominently disclosed. The SaaS vendor's privacy notice and DPA may specify the primary processing regions. The subprocessor list may reveal processing in additional jurisdictions. The subprocessor's subprocessors — the fourth-party chain — may include additional jurisdictions that are not in any disclosed list.
The Analytics Platform Jurisdiction
Customer behavioral data sent to analytics platforms is processed in the platform vendor's infrastructure. Analytics platform vendors, particularly those serving global markets, often process data in multiple regions for performance. The organization's customer data may be processed in jurisdictions selected by the analytics vendor for infrastructure efficiency rather than by the organization for compliance.
Building the Map
Answering the question with precision requires a data flow mapping methodology that tracks specific data categories to specific jurisdictions, not just to named service providers. The mapping must include primary storage, backup and disaster recovery, analytics processing, CDN caching, and third-party processing. It must be updated when architecture changes occur, when service providers change their infrastructure, and when the legal framework in any relevant jurisdiction changes.
This is more demanding than the data mapping exercises most organizations have completed. The standard GDPR Article 30 record of processing activities documents what data is processed and by whom. The jurisdictional map documents where each processing activity occurs and under what legal framework. The two documents serve different purposes and require different information sources.
The organizations that have built precise jurisdictional maps have done so as a legal and compliance investment driven by specific regulatory requirements — Schrems II compliance, GDPR Article 44 transfer mechanisms, PIPL requirements for cross-border transfers. The investment was made because the regulatory risk of not knowing was assessed as higher than the cost of knowing.
Know where the data is. Precisely. The regulation that requires you to know does not accept 'primarily' as an answer.
Map the jurisdictions. All of them. The backup, the CDN, the analytics platform, and the subprocessor's subprocessor. The legal obligation applies to where the data actually is, not where you intended it to be.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.