European company ≠ European infrastructure

A whois lookup on a "European" CMP resolved to Google LLC Frankfurt. That result crystallised something I keep running into in analytics procurement conversations: "European company" is becoming a lazy proxy for "sovereign, independent stack." The two are not the same thing.

I was testing a European consent management platform that just released a Server Side tracking feature and out of habit I ran a whois on the server IP. It resolved to Google LLC. GCP Frankfurt.

To be clear: Frankfurt is an EU data center. GDPR applies. The company never claimed to run sovereign infrastructure, and this is not an attack on them. But the result made me pause, because it crystallized something I keep running into in analytics and martech buying conversations.

“European company” is becoming a lazy proxy for “sovereign, independent stack.” The two are not the same thing.

A company can be EU-incorporated, EU-headquartered, fully GDPR-compliant in its data processing and still run its entire infrastructure on AWS or GCP. Both are US-owned and both fall under the CLOUD Act, which grants US authorities the legal mechanism to compel data disclosure from American companies regardless of where the data physically sits.

The server being in Frankfurt does not change the jurisdictional chain. The incorporation being in Munich does not change it either.

This is the default architecture of most European martech and analytics vendors. And yet in procurement conversations, “we are a European company” is routinely accepted as a sufficient answer to the sovereignty question. It is not.

The pattern reminds me of something adjacent. Over the past decade, big tech (led by Google) systematically conflated “privacy” with “security”, taking a concept with genuine regulatory and philosophical weight and mapping it onto something related but structurally weaker, until the original meaning eroded. “We keep your data secure” became an acceptable substitute for “We respect your autonomy over your data,” and most people stopped noticing the difference.

Something similar is happening with sovereignty. European company is absorbing the meaning of European infrastructure independence.

If you work in analytics, data governance, or martech procurement, there are a few questions that should probably be standard in any vendor evaluation:

  • Who owns the legal entity operating your infrastructure?
  • Under which jurisdictions can your hosting provider be compelled to disclose data?
  • Do you offer deployment on non-US-owned infrastructure, and if so, which?

These are not gotcha questions. Most vendors will not have a pure answer, and that is fine, the European cloud ecosystem is still maturing. But the questions need to be asked, because the absence of them is what allows the conflation to persist.

I do not have a clean conclusion here. I am not a legal scholar or a sovereignty evangelist. But I do think our industry is moving through a period where the difference between compliance and independence will matter increasingly and we are not building the evaluation habits to tell the two apart.


The practical exposure comes from two separate US laws that are often conflated or missed entirely in procurement checklists.

CLOUD Act (2018) — law enforcement compulsion. Grants US authorities the legal mechanism to compel American companies to disclose data stored anywhere in the world, including EU data centers, without requiring a local court order in the country where the data sits.

FISA 702 — intelligence collection. Authorizes surveillance of non-US persons’ electronic communications without individual warrants. Applies when the communication passes through or is stored by a US-owned service. No law enforcement investigation required.

Both apply when your vendor’s infrastructure provider is a US-owned company. They apply in parallel, not as alternatives. The server being in Frankfurt does not change either.


What we built

To make this concrete and actionable, I put together three reference tables covering the European martech categories where this question comes up most in practice.

Each table is community-maintained, open source, and verifiable. The data is backed by a public Codeberg repo — PRs welcome if you find errors or have fresher data.

The methodology — how each entry was verified — is documented in the repo’s methodology.md.