Skip to content
← All insights
ComplianceBuying guide24 August 2026·7 min read

What "EU-hosted" actually means when a customer asks

By navichain team

A data centre corridor with rows of server racks

A procurement questionnaire arrives with the tender documents. Between the insurance certificates and the environmental policy sit four or five questions about data: where is it stored, who can reach it, can it be deleted, what happens if there is a breach. The efficient move is to open your software vendor’s website, copy the line that says EU hosting, and move on.

That answer is usually true and rarely sufficient, because “hosted in the EU” is a narrower claim than the question is reaching for. What follows maps those questions against the General Data Protection Regulation ((EU) 2016/679), with article numbers so you can check the text yourself. It describes what the regulation says; it is not legal advice.

Two jurisdictions, and they come apart

Two questions hide inside “where is your data”. The first is hosting jurisdiction — which country the servers physically sit in. The second is company jurisdiction — whose law the company operating the software answers to. Most questionnaires ask the first and mean both.

The gap is not hypothetical. The United States CLOUD Act, passed in 2018, amended the Stored Communications Act so that a US-based provider must produce data in its possession, custody or control in response to a lawful order, regardless of whether that data sits inside the United States. A US-owned company running servers in Frankfurt has answered the hosting question and not the control question — which is not grounds to strike such suppliers off a list, but is grounds to answer the two questions separately.

What the regulation says about location

The common misconception in these documents is that GDPR requires personal data to be kept in the EU. It does not. No article says so.

Article 3(1) ties the obligations to you rather than to your hardware: the Regulation applies to processing “in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not”.

Chapter V governs what happens when data leaves. Article 44 permits a transfer to a third country only if that chapter’s conditions are met — including onward transfers from that country to another — and requires it to be applied so the level of protection “is not undermined”. Under Article 45(1), where the Commission has decided a country ensures an adequate level of protection, the transfer “shall not require any specific authorisation”; around sixteen jurisdictions qualify, plus the EU–US Data Privacy Framework, adopted 10 July 2023. Absent adequacy, Article 46 requires appropriate safeguards, most often the Commission’s standard data protection clauses under 46(2)(c).

Adequacy is a decision, and decisions move. In case C-311/18, on 16 July 2020, the Court of Justice invalidated the earlier EU–US Privacy Shield while upholding standard contractual clauses in principle. The current framework was upheld by the General Court in case T-553/23 on 3 September 2025 — a judgment still appealable on points of law.

The practical case for EU hosting is therefore narrower than the slogan: it appeals less because a rule demands it than because it keeps you out of Chapter V altogether. If you do rely on adequacy or on clauses, know which.

You are the controller; the vendor is the processor

Your customer’s obligations flow down to you, and yours flow down to your software supplier. The regulation writes that relationship out:

  • 28(1) — use “only processors providing sufficient guarantees to implement appropriate technical and organisational measures”.
  • 28(2) — the processor “shall not engage another processor without prior specific or general written authorisation”.
  • 28(3)(a) — it acts “only on documented instructions from the controller, including with regard to transfers”.
  • 28(3)(g) — at the end of the service it deletes or returns the personal data, and deletes existing copies.

Article 28(2) quietly decides whether “EU-hosted” holds. The application may run in Stockholm while error monitoring, email delivery, mapping and the support desk run elsewhere — each a sub-processor, each somewhere a driver’s phone number can end up. A supplier who cannot produce a data processing agreement and a current sub-processor list has given you a marketing line, not an answer.

And Article 33: a controller notifies the supervisory authority of a breach within 72 hours of becoming aware where feasible, while a processor notifies the controller “without undue delay”. That clock is yours, and it starts when your vendor tells you.

Isolated database, or a shared table

In a pooled design every customer’s records share the same tables, separated by a tenant column the application must include in every query. In an isolated design each customer has their own database, and separation is a property of storage rather than of code.

Pooled is not a scandal — a great deal of competent software works that way, it costs less to run, and it upgrades everyone in lockstep. The difference is where the boundary lives, and so what one mistake costs: in a pooled system a forgotten filter is a cross-customer disclosure, while in an isolated one the same bug returns an empty result. Isolation also makes three awkward questions ordinary: export, restore or delete one customer.

Neither is mandated. Article 32(1) requires measures “appropriate to the risk”, naming pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, restoring access after an incident, and regular testing. Isolation is evidence you can point at, not a certificate — so the useful question is not “is it isolated?” but “what would have to go wrong for one customer to see another’s data, and what prevents it?”

Export: the right you have, and the one you negotiate

Questionnaires often cite Article 20, portability, as though it guaranteed a carrier its own data back. Read it: it gives the data subject the right to receive personal data “concerning him or her, which he or she has provided”, in a structured, commonly used and machine-readable format, where processing rests on consent or contract and is automated. That is your driver’s right — not your company’s right to extract five years of bookings from a vendor.

Your company’s export right is contractual. Article 28(3)(g) gives you deletion or return at the end of the service; everything before that is whatever the agreement says. So put it in the agreement: which records, in what format, at what cost, and whether you can run it yourself. An export “available on request” is a favour rather than a capability, and favours end when relationships do. More in how to choose a TMS.

What a transport operator is actually being asked

Strip the legal wrapping and the questionnaire wants to know what personal data you hold, and why. For a carrier the list is consistent: drivers (name, phone, licence and CPC expiry, position while working), office users, customer contacts, consignees, and signatures captured on delivery.

Driver position data is the one to settle before you are asked. It is employee monitoring; it needs a lawful basis under Article 6 — commonly legitimate interests under 6(1)(f), which by its own text yields where overridden by the data subject’s interests or fundamental rights — and it must satisfy Article 5: specified, explicit and legitimate purposes, limited to what is necessary, kept no longer than necessary. “How long do you keep GPS traces?” is a number you decided in advance.

Questions worth sending back

  1. Where is it hosted, and whose law does the operating company sit under?
  2. Is there a processing agreement and a current sub-processor list, with locations?
  3. Own database, or shared tables?
  4. How, and how fast, are you told about a breach?
  5. What can you export yourself, in what format, and at what cost?

Where navichain stands

Our answer to the hosting and isolation questions is the same every time: every customer gets an isolated per-tenant database, within the EU, and driver consent, retention periods and deletion eligibility are enforced by the platform rather than described in a policy document. Access inside a tenant runs on roles and claim-based permissions per user and per department, with two-factor authentication for administrators and a field-level audit trail on the records that matter. Billing is monthly with no lock-in, since a supplier you can leave has to keep earning the answer. Our privacy policy is public, the platform page sets out what runs where, and if your questionnaire asks something this article did not cover, send it to us.

Ready to see it on your workflows?

Contact us