I've reviewed a lot of security questionnaires that open with the same checkbox: "Is customer data hosted in the EU? Yes / No." The vendor ticks Yes. The DPO signs the review. Six months later, the same DPO notices that every click event routes through a US-hosted Meta Pixel and a California-domiciled HubSpot instance, both of which are firing inside the user's browser before Elido's EU edge ever sees the request.
The checkbox was honest. The answer was also incomplete. "EU-hosted" on a vendor's homepage describes where the platform's own servers sit. It says nothing about what the marketing layer attached to that platform does with the data, or where it goes, or which legal basis covers the transfer. Those are the questions a DPO who has read GDPR Article 3 and Schrems II actually asks.
This post is the marketer-meets-DPO version of that conversation. Where does EU data residency start and stop when you're running link tracking and conversion forwarding? What changes legally when you move from client-side pixels to server-side conversion APIs? And what should the procurement checklist actually say?
The companion post — GDPR for URL shorteners — covers the article-level obligations in full. I'll cross-reference it where relevant rather than repeat.
TL;DR#
- "EU-hosted" covers your vendor's data plane. It does not cover the client-side marketing scripts firing in your users' browsers before the redirect happens.
- Schrems II and GDPR Articles 44–49 impose real requirements on data flowing to US-hosted ad and analytics platforms. Server-side conversion forwarding moves the transfer to the server-to-server layer but does not eliminate the transfer obligation.
- Article 28(2) requires a written sub-processor list. Five sub-processors with named regions is auditable; forty with vague entries is a liability.
- The procurement checklist that follows closes most of the DPO's questions in a single discovery call.
The legal stack in plain language#
Four pieces of law do most of the work here. You can cite them without a law degree; the article numbers are short.
GDPR Article 3 — territorial scope. Article 3(2) applies the GDPR to any processing of EU subjects' data by a controller or processor established outside the EU, when the processing relates to offering goods or services to EU subjects or monitoring their behaviour. "Monitoring their behaviour" is click tracking. A US-hosted analytics vendor with no EU entity processes personal data of EU subjects every time your link fires their pixel. Article 3 says GDPR applies to that vendor regardless of where they sit. The residency question is about where the data goes after the processing obligation has already attached.
GDPR Article 28 — processor obligations. Article 28 governs the contract between the controller and each processor in the chain. Your link-shortening platform, your analytics tool, your email provider — each must sign a DPA that covers the eight obligations (a) through (h). A vendor that won't supply a pre-signed DPA is asking you to absorb their compliance risk. Sub-paragraph (2) specifically requires the processor to obtain the controller's authorisation before engaging sub-processors, and to impose equivalent obligations on those sub-processors by contract.
GDPR Articles 44–49 — third-country transfers. Chapter V of the GDPR prohibits transferring personal data to a third country unless one of the listed mechanisms applies: an adequacy decision, Standard Contractual Clauses, Binding Corporate Rules, or the derogations in Article 49. For transfers to US-hosted platforms, the default mechanism since the EU-US DPF was adopted in 2023 is SCCs supplemented by DPF certification — or the EU-US Data Privacy Framework itself where the US recipient is certified. Neither mechanism eliminates the transfer requirement; they describe how to satisfy it.
Schrems II — CJEU C-311/18. The Schrems II judgment invalidated Privacy Shield in July 2020 and established that SCC-based transfers require a Transfer Impact Assessment evaluating whether the destination country's surveillance law would deny EU subjects effective remedies. The TIA burden is real and ongoing. The EU-US Data Privacy Framework, adopted via Commission adequacy decision in 2023, provides a current mechanism for DPF-certified US recipients, but it is the subject of pending litigation — NOYB has signalled an intent to challenge, and the EDPB's supplementary measures recommendations (01/2020) remain relevant guidance for teams that want a transfer regime robust to the next Schrems judgment. Buyers in regulated sectors are increasingly contracting for EU-only processing as a structural hedge against legal regime change.
Where marketing analytics typically leak EU residency#
The gap between "our shortener is EU-hosted" and "our data stays in the EU" opens at the client-side marketing layer. Six common leak points.
Meta Pixel (client-side). The standard pixel implementation fires a GET request from the user's browser to connect.facebook.net, a CDN point served by Meta's US-based infrastructure. That request contains the full URL — including your UTM parameters — plus the user's IP, cookie identifiers, and browser fingerprint. It leaves EU territory in the user's browser before your server ever processes the click. Meta is incorporated in Ireland for EU purposes and claims a legal basis for the transfer under SCCs. That claim is the subject of two substantial DPA decisions (the Irish DPA's 2022 Facebook Ireland ruling, and the 2023 SCCs enforcement order). The pixel itself is still sending data to US servers; the legal basis is contested.
Google Tag / GA4 (client-side). The gtag.js snippet fires from the user's browser to google-analytics.com and analytics.google.com, both of which resolve to US-based Google servers unless you have configured the Google Analytics 4 EU routing with data_collection_endpoint pointed to region1.google-analytics.com. Even with the EU endpoint, Google documents that some processing occurs in US infrastructure. The default implementation is unambiguous: browser-side, US-hosted.
Salesforce CRM. Salesforce Marketing Cloud's data residency depends on which pod your tenant is on. EU customers on EU pods process click-event attribution data in the EU — if you have configured this explicitly. The default US pod is US-hosted. Most teams I see in SMB-to-mid-market have not made this configuration; they have a Salesforce instance that was provisioned by a US-based admin on a US pod and has been routing EU-subject CRM data across the Atlantic ever since.
HubSpot. HubSpot's email tracking pixels are served from HubSpot infrastructure in the US. EU data residency is available as an add-on for Enterprise customers; it is not the default. The tracking pixel that fires when a contact opens a marketing email is, in the default configuration, sending an EU subject's identifier (the email address, encoded in the pixel URL) to a US endpoint.
Third-party email open tracking. Beyond HubSpot — Mailchimp, Brevo, Customer.io, ActiveCampaign — the same pattern applies. Tracking pixel URLs are hosted on the provider's CDN; most CDNs default to US PoPs for origin traffic; the pixel firing from an EU user's email client routes to US infrastructure. EU-region options exist on some plans; they are not defaults.
The shortener itself as transit. Where a shortener is not EU-hosted, the redirect request passes through non-EU infrastructure. The click event is logged outside the EEA. This is the residency layer the "EU-hosted shortener" checkbox is actually meant to address — and it is the smallest of the six leaks, because the redirect is typically a 2-5ms event and the click log is the only persistent data the shortener creates.
The typical exposure for a mid-market marketing team running standard tools: three to five of the above scenarios active simultaneously, with no Transfer Impact Assessment in place for any of them, and an Article 30 Records of Processing Activities entry that names "Google Analytics, Meta Pixel" without documenting which mechanism covers the transfer.
The server-side fix: what changes legally, what doesn't#
Server-side conversion forwarding — where the shortener's EU edge forwards click and conversion events to the ad platform's server-side API rather than letting the user's browser fire the pixel — is the partial fix. Here is what it changes and what it leaves unchanged.
What changes: The user's browser no longer sends data to the US endpoint directly. The request path is:
- User clicks the short link
- Elido's EU edge (Frankfurt) receives the request, logs the click event locally
- Elido's EU edge forwards the conversion signal server-to-server to Meta CAPI / GA4 Measurement Protocol
- The ad platform receives the event on their US server
The Meta Conversions API is the canonical implementation of this pattern for Meta. GA4 Measurement Protocol is the Google equivalent. The user's browser touches only the Elido EU edge; it never directly contacts a US analytics endpoint.
What doesn't change: The data is still being transferred to a US-hosted processor. Elido's EU edge originates that transfer. The transfer obligation under Articles 44–49 still applies — you still need SCCs or DPF coverage for the Meta or Google leg of the chain. What changes is the controller's practical control over that transfer: it happens on a server you operate, using credentials you manage, with the identifier hashing you apply (SHA-256 on email addresses, as Meta CAPI requires), rather than in a browser script you have limited ability to audit or control.
This is a material improvement from a data-minimisation and security standpoint. It is not a complete exemption from the transfer regime. Your DPO needs to be clear on this distinction before signing the procurement review.
The legal consequence of server-side forwarding: your Article 30 RoPA entry for "Meta CAPI" now documents a server-to-server transfer under your control, with identifiers hashed before leaving EU infrastructure. That is a substantially cleaner entry than "Meta Pixel — client-side, browser-originated, transfer basis TBD." It's not zero-transfer; it's a documented, controlled transfer.
Article 28(2): why sub-processor count matters#
Article 28(2) requires the processor to obtain the controller's prior authorisation before engaging sub-processors, either specific (per-vendor) or general (notification-based with a right to object). Every serious SaaS contract uses general prior authorisation with a 30-day notice window. The controller signs the DPA; the DPA includes a sub-processor list; additions to the list trigger a notification and a 30-day objection window.
The sub-processor list is the artefact your DPO will actually read. What a usable list includes:
- Sub-processor name
- Location of data processing (hyperscaler region, not just country)
- Role in the processing chain
- Categories of personal data shared
- Legal basis for any third-country transfer
- Date added
- Notification channel for future additions
The list is also a signal about how the vendor thinks about residency. A vendor with five sub-processors whose regions you can name in a sentence has designed for it. A vendor with forty sub-processors whose entries read "various global regions" has not.
Elido's sub-processor list covers five vendors — Hetzner, OVH, Postmark, LiqPay, Cloudflare — published at /legal/subprocessors. That number is small by intention. Every sub-processor adds to the surface area of the controller's privacy programme; every sub-processor addition triggers a notification cycle and a potential objection window. A vendor that can run a production-grade shortener on five sub-processors has made explicit choices about what third-party dependencies are justified.
Compare this to a marketing analytics platform with 35-40 sub-processors. The list is auditable in principle; in practice, the controller's privacy officer is reviewing forty DPAs and forty Transfer Impact Assessments, some of which will be missing. The five-vendor number is not a marketing claim. It is an operational choice with real consequences for your compliance workload.
The marketer's procurement checklist#
Eight questions. Written answers. If a vendor can supply these on the first discovery call, the procurement cycle shortens by weeks. If they can't, that tells you something.
- What is the specific hosting region for new customer data, named to the hyperscaler region level? (Expected answer: a named EU region — "Hetzner FRA" or "AWS eu-central-1", not "Frankfurt" as an unsupported claim.)
- Is the EU hosting region contractually committed in the standard customer contract, or is it an operational practice the vendor can change without notice? (Expected answer: contractually binding, specific to the standard contract, no custom addendum required.)
- Does the standard contract include a pre-signed DPA covering Article 28 obligations (a) through (h)? (Expected answer: yes, pre-signed, available before the sales call ends.)
- How many sub-processors are in the standard processing chain? Can the vendor name all of them with their data-processing regions? (Expected answer: the full list, named, with regions, available publicly at a URL you can link to in your RoPA.)
- Does the vendor use server-side conversion forwarding to ad platforms, or is conversion tracking client-side in the user's browser? (Expected answer for a privacy-forward vendor: server-side, with identifier hashing before the data leaves EU infrastructure.)
- What is the IP truncation default for click event logging? (Expected answer: /24 truncation for IPv4, /48 for IPv6, before persistence — i.e., the full IP is not stored.)
- What is the data subject erasure SLA, and is it operationally achievable on the click-event store? (Expected answer: 30 days or less, propagated to the analytics datastore, confirmed by webhook or certificate.)
- What independent compliance attestations does the vendor hold, and when was the most recent audit closed? (Expected answer: ISO 27001 current; SOC 2 Type II completed or in progress with a target date; for healthcare-adjacent workloads, BAA availability on the relevant plan.)
These eight questions cover the DPO's primary concerns without requiring a legal review at the discovery stage. The vendor that answers all eight in writing on the same day is ready for procurement. The vendor that escalates to legal before answering question three is not.
Tooling at Elido#
The specifics, for reference.
Workspace-level region pin. New workspaces default to Frankfurt (FRA). Business and Enterprise workspaces can pin to Ashburn (ASH) or Singapore (SGP) per workspace. The pin is enforced at the routing layer — it is not a dashboard preference that can be overridden by a configuration change without a workspace-level contract amendment. The trust page documents the infrastructure.
Pre-signed DPA. The Article 28 DPA is included in the standard customer contract. No custom negotiation is required for EU buyers who need standard Article 28 coverage. Enterprise contracts with additional audit rights, sub-processor approval windows, or custom retention terms are negotiated separately. The standard DPA is available at /legal/dpa.
Sub-processor list. Published at /legal/subprocessors. Five vendors. Additions trigger a 30-day advance notification email plus an RSS feed for tooling-based monitoring. The right to object within 30 days is contractual, not administrative.
Server-side conversion forwarding. Credentials for Meta CAPI, GA4 Measurement Protocol, and Mixpanel are registered once at the workspace level. Elido handles SHA-256 hashing of identifiers before the outbound POST, deduplication via the event_id field, and retry logic on transient upstream errors. The transfer is server-to-server from EU infrastructure; the user's browser does not contact the ad platform directly.
ISO 27001. Certified. SOC 2 Type II in progress, target H2 2026. BAAs available on Business plan for healthcare-adjacent deployments.
For the full compliance posture, /solutions/compliance is the buying-team-facing summary.
What we don't claim to do#
This section exists because "EU data residency" is a phrase vendors use loosely, and we should not.
Elido is the link layer. A click routed through Elido's Frankfurt edge stays within EU infrastructure at the Elido layer. The click event is logged in ClickHouse on Hetzner FRA. The conversion signal forwarded server-side to Meta CAPI leaves EU infrastructure — that transfer happens on your behalf, under your controller responsibility, and you need to document it in your RoPA and cover it with the appropriate transfer mechanism.
If your organisation requires that absolutely no personal data on EU subjects leaves the EEA under any circumstances — including the ad-platform attribution leg — the answer is not a different shortener. The answer is not sending conversion events to US-hosted ad platforms at all. That is a business and marketing decision, not a technology one.
What Elido gives you: a link layer that processes EU-subject click data in EU infrastructure by default, with documented sub-processors, a pre-signed DPA, IP truncation, server-side conversion forwarding with identifier hashing, and a sub-processor count small enough to audit in an afternoon. That covers the link-layer residency obligation cleanly.
Your email marketing platform, your CRM, your ad platforms, and your analytics warehouse each have their own residency posture. Elido is not the answer for those; we are the answer for the redirect and click-attribution layer, and we are not going to overstate the scope.
The GDPR for URL shorteners cornerstone covers the full processor-obligation picture at the article level, if you want the compliance rationale behind any of the above decisions.
Read the compliance cluster#
This post is the cornerstone of the compliance cluster's residency track. Sibling posts: GDPR for URL shorteners (article-by-article processor obligations), and the forthcoming Schrems II and tracking pixels post (the practical browser-layer attribution consequences). For the trust-page and contract artefacts: /trust, /legal/dpa, /legal/subprocessors. For the solutions-facing summary: /solutions/compliance.