GDPR and EU hosting: what teams should look out for in developer tools

When a company wants to introduce a new analytics tool, the procedure is well rehearsed by now: the data protection officer asks for the data processing agreement, somebody checks the server location, the privacy policy is amended. With the development department's toolbox things often go differently: a team member finds a useful tool, creates an account, and three months later it is a silent part of the working day. This unequal treatment has no objective justification — developer tools process data too, and some of them more than their users realise.

Test services are a good object of study for this. A screenshot service, for instance, photographs web pages — and a photo of a web page contains everything that web page shows. With a public marketing page that is uncritical. It gets interesting at the margins: staging environments that have been filled with copies of real production data. Pages that display user comments, reviews or profile pictures. Addresses whose URL parameters contain session attributes or identifiers. Anyone handing such pages to an external service may be transferring personal data — even if what is going on in their head is only “we're testing the layout”.

The GDPR sorts such a constellation clearly: the company using the service remains the controller of the data; the service acts, as a rule, as a processor. This division of roles is not a formality but has a practical consequence: a data processing agreement under Article 28 is needed — usually as the provider's standard document — and the responsibility for the processing being lawful overall does not travel to the service provider along with the data. It stays with the company.

The second standard question concerns the place of processing. Within the EU the GDPR applies directly; with providers that process data in third countries, by contrast, a chapter of assessment of its own begins: adequacy decisions, standard contractual clauses, transfer impact assessments. For transfers to the United States an adequacy decision does exist, but its predecessors were struck down in court twice already, and the current framework too remains legally contested. None of this makes US services unusable — but every one of these constructions is assessment effort that simply falls away with an EU location. EU hosting is in that sense less a seal of quality than a shortcut: it makes the assessment shorter, not superfluous.

ScanU, a service for visual regression tests and browser screenshots, lends itself here as a concrete example because the provider makes the data location explicit: according to the provider, the data is hosted in Frankfurt, and the service positions itself expressly with the GDPR in mind — as can be read on ScanU's English-language entry page. For a German company that means: the third-country question does not arise for the core service to begin with, and the assessment can concentrate on the usual points — contract, retention periods, deletion, sub-processors.

And this is exactly where an honest sentence belongs, one that applies to every provider, including the one considered here: statements on a product website are the starting point of the assessment, not its result. “Hosted in Frankfurt” and “GDPR-oriented” are the provider's own representations — anyone wanting to use the service commercially reads the data processing agreement, checks the list of sub-processors and clarifies what happens to the data on termination. A provider who hands over such documents willingly does more for trust than any marketing formulation; one where they cannot be found has already answered the most important question.

Anyone reading a data processing agreement for the first time can orient themselves around four points. First, the subject matter: does the contract describe concretely which data is processed for which purpose, or does it stay interchangeably generic? Second, the technical and organisational measures, usually as an annex: are there comprehensible statements there about encryption, access control and location — or platitudes? Third, the provision on sub-processors: is the customer informed about changes, and can they object? Fourth, return and deletion of the data after the contract ends. None of these questions presupposes a law degree — they are questions of comprehension that any technically competent person can answer. And where the contract is silent, a targeted query to the provider is the most honest test of its willingness to provide information.

An often overlooked checkpoint is retention periods — even though in data protection law they are a core topic, under the heading of data minimisation: data should not be kept for longer than the purpose requires. With screenshot services the retention of the check history determines how long images of your own pages sit with the provider. ScanU tiers this history by price level — from three days on the free plan through 15 and 30 days up to 90 days in the largest tier, as ScanU's price tiers set out. What is remarkable about that: from a data protection point of view the smallest tier is the most frugal. Anyone who needs long histories, in order to narrow down regressions over months for instance, chooses the longer period deliberately — but it should be a conscious choice, not a default setting nobody has ever thought about.

At least as important as vetting the provider is your own usage behaviour — because the most effective data protection measure is not putting sensitive data into the service in the first place. For test services that means, concretely: fill test environments with synthetic sample data instead of copies of the production database. Test public pages and layouts instead of logged-in views with real customer data. Make sure that no session tokens or personal identifiers are contained in the URLs being tested. These rules cost little, apply to every URL-based tool — and they defuse the data protection question more effectively than any contractual clause.

What such usage rules can look like fits into three sentences for the team wiki. First: only the addresses of public pages or of staging environments with synthetic data go into the service — never views that show real customer data. Second: before a new check project is created, the URL is deliberately reviewed once for its parameters; session tokens and personal identifiers have no business being in it. Third: shared reports are treated like internal documents — passed on only to those involved, links not posted in public channels. Rules of this kind are formulated in ten minutes and quickly conveyed when new colleagues are onboarded. Their value lies less in the wording than in the fact that the topic has been spoken about once: data protection mishaps in tool use rarely arise from intent — usually from routine in which nobody ever asked the question.

Shared reports deserve a thought too. Shareable check reports are extremely practical for collaboration — which is exactly why it should be clear who can open a shared report and how long it stays available. That is not a peculiarity of test services: the same applies to reports as to shared documents in any cloud tool. A report containing screenshots of an unpublished product page is confidential material and should be treated as such.

How deep should the assessment go? The GDPR itself supplies the answer: risk-based. A screenshot service that photographs public marketing pages is a different calibre from payroll software holding salary data. It would be disproportionate to subject both to the same catalogue of questions — but equally wrong not to look at the smaller case at all. A pragmatic middle way for developer tools: clarify the role (processor?), collect the contract, note the data location and sub-processors, record the retention and deletion periods, formulate usage rules for the team. That is done in a manageable amount of time and covers the essential obligations.

Played through with the example of a screenshot service, this catalogue looks like this. Role: the service processes the transmitted page content on behalf of the company — a processor, then, so collect the Article 28 contract and file it. Data location: read it up at the provider and note it; with ScanU, Frankfurt is stated, which means the third-country assessment falls away for the core service. Sub-processors: take the list from the contract documents or request it — an EU provider can use sub-contractors too, and only this list makes the chain complete. Retention periods: the chosen price tier determines how long the check history, and thus the screenshots, are kept; match the period against the actual need and justify the decision in one sentence. Deletion: clarify what happens to reports and histories on termination. Anyone who documents these five points on one page has done the essentials for a tool of this risk class — and at the same time has a template that can be reused for the next tool. The provider bundles answers to typical questions about the service itself in the frequently asked questions about ScanU.

Part of this is also an entry in the record of processing activities — that mandatory documentation in which a company records which services process which data for which purpose. That sounds more bureaucratic than it is: for a developer tool it comes to a few lines. The real value lies elsewhere: whoever writes the entry has to have answered the questions. The documentation forces the assessment that otherwise seeps away in everyday work.

One objection from practice deserves an honest answer: if the assessment becomes too ponderous, it does not happen more thoroughly, it does not happen at all. If six weeks and three areas of responsibility lie between “tool found” and “tool approved”, developers will at some point set up the account privately — and a service that could have been assessed turns into shadow IT that nobody knows about any more. The consequence is not to do without assessment but to match it to the risk: a quick, documented short check for tools with little data exposure, the full assessment for anything that comes near production data or customer systems. A team that knows the short check takes a few days and usually ends in a yes has no reason to bypass it. The most robust data protection organisation is, in the end, the one whose official route is faster than the detour.

That leaves the overall placement. Choosing data-frugal, transparently hosted tools is not a legal quibble but part of the craftsmanlike care that teams take for granted elsewhere — nobody would run a database without a backup concept. EU hosting, clear retention periods and a sound data processing agreement are three good criteria among several here, not a substitute for your own assessment: a service hosted in Frankfurt can also be badly configured, used wrongly or filled with the wrong data. The responsibility for that lies not with the provider but with the company deploying it.

The good news at the end: the effort is one-off and manageable. An hour of structured assessment per tool, a short entry in the documentation, two usage rules for the team — most developer tools need no more than that. Compared with the effort of having to explain an ill-considered data transfer after the fact, that is a very good trade.