Where a website lives: server location, GDPR and the limits of the EU argument

“Our data is in Frankfurt” — sentences like this crop up ever more often in quotations from web service providers. But what does the location of a data centre really mean: for the speed of a website, for data protection, for legal certainty? And where does the reassuring effect of the words “EU server” end? A classification for companies that want to understand what they are actually buying.

Transparency: this piece appears as an advertisement and comes from the environment of BitBau of Osnabrück (in German), a web agency that runs customer projects on infrastructure at the Frankfurt location. The text is not legal advice — it is meant to explain the technical and legal connections in such a way that one can put the right questions to one's own service provider.

First the technology. Hosting means: somewhere there stands a computer that delivers the website as soon as somebody calls it up. Between that computer and the visitor lie fibre optics, switching nodes — and physics. Data travels fast, but not infinitely fast, and every request shuttles back and forth several times between browser and server. The further away the server is, the more noticeably these journeys add up.

For an audience in Germany, Austria and Switzerland, Frankfurt is therefore no accidental choice: the city houses one of the most important internet exchanges in Europe, this is where the lines converge. A site hosted in Frankfurt simply answers visitors from the German-speaking world faster than the same site from the American east coast. The difference lies in the range of tenths of a second — which sounds harmless, but helps to decide perceived sluggishness, bounce rates and search engine assessment.

Modern hosting platforms partly relativise the distance by distributing copies of the website to servers all over the world. For the pure delivery of pages that works well. But as soon as individual requests are processed — a form, a login, a booking — the request has to go to where the actual processing takes place. And with that we are at the second, weightier subject: where is data processed, and under which law?

Before this question can be answered, it is worth looking at what “the website” encompasses in the technical sense. Because a presence involves more than the web server: a database in which content and form submissions sit; backup copies, which may be stored somewhere other than the original; log files, which record who called up what and when; the service that delivers form submissions as email; possibly a tool for error monitoring. Every one of these components can run with a different provider in a different world region — and about every one the location question can be asked separately. It is therefore not a single question but a small inventory of one's own presence.

For there is practically no such thing as a website without personal data. The mere page call already transmits the visitor's IP address, which under European understanding counts as personal; added to that are server logs, form submissions, cookies, embedded services. The General Data Protection Regulation places the responsibility for this on the website operator — not on the host. Legally, the service provider processes the data on the operator's behalf, set down in a data processing agreement.

This contract is not a formality but the central document of the relationship between operator and service provider. It usually regulates which data is processed for which purpose, that the service provider acts only on instructions, which sub-processors it may deploy, how data is deleted after the end of the contract and how it supports the operator when data subjects request information or erasure. Large platforms provide such contracts in standardised form — but clicking is not the end of it: the operator should actually retrieve the document, file it and know what it says. Because in case of doubt they themselves must be able to prove that the processing has been properly agreed.

It becomes complicated as soon as data leaves the EU. The GDPR permits transfers to third countries only under particular conditions, and no third country is fought over as intensively as the USA. Twice already the European Court of Justice has struck down agreements meant to secure data traffic across the Atlantic — most recently in 2020, in the decision that became known as “Schrems II”. Since 2023 the third attempt has been in force with the EU-US Data Privacy Framework: US companies that certify under it count as permissible recipients.

In fairness, this belongs with it: this third attempt too is under legal attack, and nobody can guarantee that it will endure. For companies that means not panic but precaution. Contracts with service providers should provide for the classic standard contractual clauses alongside the framework, so that if it is struck down again the legal basis does not disappear overnight. Anyone buying infrastructure today buys with it the question of how crisis-proof its legal basis is.

At this point many companies face the fundamental question: European provider or American platform with a European location? Both are defensible, and both have their price. A host based in Germany or the EU noticeably simplifies the legal position — but more operational work then lies with the service provider or with the company itself: updates, scaling and publication processes want organising, and the technical integration of modern frameworks is not always as close as with the specialised platforms. The large US providers take precisely this work off your hands, but bring the transfer questions described along with them. What matters is less which answer a company chooses than that it makes the choice consciously, records the weighing-up — and can justify it on request.

Against this background it becomes clear what an EU server location achieves — and what it does not. It ensures that the ongoing processing takes place geographically in Europe, shortens the journeys and considerably simplifies the data protection argument. But it does not turn a US provider into a European company: if an American parent company operates the platform, questions remain — for instance the much-discussed one of whether US authorities can under certain circumstances demand the release of data that is physically located in Europe. This legal debate is not closed. The reputable course is to name it rather than to smile it away.

How does one deal with this in practice? That can be shown using the example of the agency behind this piece. BitBau runs customer projects on Vercel infrastructure at the Frankfurt location. The weighing-up behind this is typical of many digital projects: the platform is technically closely tailored to the framework in use and takes a great deal of operational work off the operator; the Frankfurt location keeps latency and ongoing data processing within the European area. At the same time Vercel is a US company — which is why a data processing agreement, certification under the Data Privacy Framework and standard contractual clauses belong to the compulsory programme, not to the freestyle. An EU location does not replace this homework; it supplements it.

This honesty distinguishes solid advice from mislabelling. “Server location Germany” is an argument, not a free pass: a website can be hosted in Frankfurt and still have data protection problems — for instance if it loads typefaces, videos or analytics tools from third-party servers that transmit visitor data all over the world. German courts have already objected that merely embedding typefaces loaded from US servers transmits visitors' IP addresses without their being asked. The chain is as strong as its weakest link.

It is therefore worth looking at the entire website, not only at the host. Which third-party services are embedded — map services, typefaces, videos, statistics? Can typefaces be delivered locally from one's own server instead of from external ones? Is the external analytics tool really needed, or will a data-frugal alternative do? In practice, such questions decide the data protection quality of a website more often than the choice of data centre.

Finally, part of due care is that the paperwork keeps pace with reality. If the host changes, an analytics tool is added or a service falls away, the privacy policy has to reflect that — a policy that lists services long since switched off, or conceals new ones, is more than a blemish. The same applies to the internal documentation of processing activities, which should be as up to date as the website itself. This is not a one-off project task for the launch but ongoing upkeep — and at the same time a good occasion to question the stock of third-party services fundamentally once a year: what of it is actually still needed, and what is only running along because nobody ever removed it?

For the conversation with one's own service provider a short catalogue is then enough. Is there a data processing agreement, and does the company actually have it to hand? In which region are website, database and backup copies processed — and is that contractually laid down or merely a default setting? Which subcontractors are involved, and where are they based? On which legal basis do transfers to third countries rest? And finally: who reports within what deadline if something goes wrong?

Anyone who receives clear answers to these questions is working with a service provider who takes their craft seriously. Evasive answers — “the host takes care of that”, “that is all certified” — are by contrast a warning signal, because responsibility ultimately remains with the website operator. Data protection can be delegated like bookkeeping: one can engage specialists, but one cannot hand over the responsibility.

That applies, incidentally, regardless of the size of the project. Anyone running their website with a website builder also has a hosting provider — they have merely not chosen it consciously, because it is included in the package. The questions stay the same: where does the provider process the data, is there a data processing agreement, which sub-processors are involved? The only difference is that the answers are in the website builder provider's contract documents instead of in an individually negotiated contract. In both cases they should be read — the operator's responsibility does not shrink with the monthly price.

That leaves the initial question: does the location count? Yes — three times over. Technically, because proximity means speed and speed decides use. Legally, because processing within the European legal area simplifies the argument and reduces dependence on fragile transatlantic agreements. And as a signal, because a service provider who speaks openly about locations, contracts and borderline cases probably works cleanly in other respects too. Only one thing the location never is: a substitute for one's own homework — frugal use of third-party services, clean contracts and a privacy policy that describes what actually happens.