What EU jurisdiction means for your technology decisions

Jurisdiction is not an administrative label. It is a set of live obligations that attach to an entity, travel with its data, and do not pause because the parent company is headquartered somewhere else.

Most technology decisions made by international firms with EU operations are made without a clear understanding of this. The results are not always immediately visible. They accumulate quietly until an audit, a data breach, or a regulatory enquiry makes them suddenly very visible indeed.

The subsidiary assumption

The most common failure is the assumption that a US-headquartered firm’s data practices govern its EU subsidiary.

They do not.

The EU entity is subject to EU law. GDPR applies to the processing of personal data by that entity, regardless of where the parent operates, where the data is stored, or what the group’s global privacy policy says. The fact that the parent has a compliant US framework does not extend compliance to the EU entity. These are separate legal obligations in separate jurisdictions.

In practice this means the EU subsidiary may be processing employee data, customer records, and transaction data under a legal basis that has never been documented. Data flows to the US parent may be occurring without a lawful transfer mechanism. A Data Protection Officer may be required and absent. The privacy policy may reflect US law rather than EU law, or neither in any current form.

None of this is malicious. It is the result of a technology architecture built at group level, for a group that is primarily US-operated, extended to an EU entity without a corresponding review of what changes at the border.

The infrastructure gap

EU data residency is not a single answer.

The best-performing datacentres in Europe are in the north — Frankfurt, Amsterdam, Stockholm. The latency difference between Northern and Southern EU infrastructure is real and measurable. An organisation that assumes “EU region” means a datacentre in Cyprus or Greece will find that the compliance answer and the performance answer point in different directions.

This matters for architecture decisions made at group level. A US parent provisioning cloud infrastructure selects an EU region for GDPR compliance. The legal team confirms EU is EU. The engineering team discovers that workloads running from a Southern EU region perform differently from those running from Frankfurt. The decision was made once, without sufficient granularity, and the architecture reflects that.

Data residency requires a specific decision, not a regional checkbox.

SaaS procured by the wrong entity

SaaS procurement is where the gap between policy and practice is most consistently found.

The US parent holds the enterprise licence. The EU subsidiary uses the product. The data — customer records, contracts, communications — sits in a US-region instance because that is where the licence was provisioned. Nobody asked which region the EU entity’s data should sit in. Nobody checked whether the vendor offers an EU datacentre option. The procurement decision was made at group level without reference to the regulatory obligations of the entities using the product.

The reverse is equally common: firms trading in the US, procured under EU terms, unaware that US privacy regulation is not federal but state-by-state. California, Virginia, Colorado, and others each operate their own frameworks. One US is not one standard. The assumption of uniformity works in neither direction.

Middle East: standards have teeth at the border

Firms operating in parts of the Middle East observe that local regulatory enforcement is inconsistent and data standards appear to be someone else’s concern. This observation is sometimes accurate locally. It expires at the border.

The moment a Middle East-based firm processes data belonging to EU residents, serves EU customers, or trades with EU-regulated counterparties, GDPR and related frameworks apply to those interactions. The standards that appeared absent at home have teeth when the firm crosses into regulated territory — and that crossing is often invisible. An API call. A marketing email. A SaaS platform used by customers in multiple jurisdictions.

Assuming standards do not apply is not a legal position. It is an assumption that has not yet been tested.

AI tools and data flows nobody mapped

The most current version of this problem is the AI connector.

A developer installs an integration that passes data to an external AI service. Customer queries, internal documents, support tickets, contract text — the data flows out to a model hosted by a third party, processed under that third party’s terms, potentially retained for model training, potentially stored in a jurisdiction that is not the EU.

Nobody asked whether this processing is lawful under GDPR. Nobody identified the legal basis. Nobody reviewed the vendor’s data processing agreement or checked where inference runs. The integration was installed because it was useful. The data protection implications were not part of the conversation.

This is the guest WiFi problem applied to data. The exposure is not immediately visible. The connection was made for convenience. The question of what it connects to, and what travels across it, was not asked.

The privacy policy that was written once

Privacy policies are treated in most organisations as a compliance artefact — drafted once, filed, linked from the footer, never revisited.

The regulatory landscape has changed significantly since most of these documents were written. GDPR replaced the Data Protection Directive. National implementing legislation has developed. AI regulation is emerging. Cookie consent requirements have been clarified and tightened. The document written fifteen years ago does not reflect the obligations of today.

A privacy policy that does not accurately describe how an organisation processes data is not a compliance document. It is a liability.

A few rules

GDPR attaches to the EU entity, not the group. Document the legal basis for every category of processing in the EU entity. Do not assume the group’s US framework covers it.

Data residency is a specific decision. Name the region, confirm the datacentre, verify the latency implications. EU is not a single answer.

Audit SaaS procurement against data location. For every SaaS product used by the EU entity, confirm which region the data sits in and whether an EU option exists. If the US parent holds the licence, ask where the data goes.

The US is not one standard. State privacy laws vary. If you process data belonging to US residents, identify which states apply and what each requires.

Map your AI data flows before deploying. Before any AI integration goes live, identify what data it processes, where that processing occurs, under what terms, and whether the processing is lawful under the regulations that apply to your entity.

Review the privacy policy. If it has not been updated in the last two years, it needs review. If it was written before GDPR, it needs replacement.

Standards have teeth at the border. The regulatory environment you operate in locally does not define your obligations when you trade internationally. Know the frameworks that apply to your customers and counterparties, not just your own jurisdiction.