GDPR storing vs processing / computing data (failover scenarios)

Question

I'm having a hard time understanding what exactly is meant by 'data processing' in GDPR. There's one specific scenario which I'll explain later, but I will first try to simplify my question.

Let's say I have 2 servers: one running a database and one is a HTTP web server. The database is located in the EU and stores privacy sensitive data. The HTTP web server is located outside the EU but doesn't store any data.

Would it violate GDPR if a consumer would enter privacy sensitive data which is sent to the HTTP web server and then stored on the database server when no trace of the data is left on the HTTP web server?

This might sound like an odd question, so let me elaborate.

In a real-world scenario, there would be (at-least) 4 servers:

2 databases 2 HTTP web servers For each server type, one is located in the EU, and the other is not. The database in the EU stores all EU data. The database outside will never contain any EU privacy sensitive data.

Now, we define a single entry point for the 2 HTTP web servers. You could do this using Azure Traffic Manager which utilizes the DNS protocol to balance the load between the 2 servers.

Usually, the entry point will route all EU traffic through the HTTP server in the EU. Unless the server in the EU goes down. The entry point will then direct traffic from the EU to the HTTP server outside the EU. Based on the authentication information provided the non-EU web server still knows the request is GDPR bound, so it will use the EU database to handle the request.

Would this violate GDPR?

Answer 1

You're probably making an “international transfer” here, but that doesn't mean it is illegal.

The GDPR has a very broad concept of “personal data” and of “processing”. Per Art 4(2),

‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction

Which I would summarize as: pretty much anything you do with the personal data counts as “processing”.

So yes, your non-EU servers would be processing the personal data in HTTP requests, even when those servers aren't directly storing the personal data.

Chapter V of the GDPR applies to

Any transfer of personal data which are undergoing processing or are intended for processing after transfer to a third country […]

Per this definition, the question whether an international transfer occurred is inextricably linked with the question whether the data is being processed in the destination country. The generally accepted interpretation here is that mere transfer through a country does not constitute processing. For example, if your requests happen to take a network route through other countries, that wasn't an international transfer.

But your HTTP server is definitely doing processing, even if it doesn't store the data persistently.

If the HTTP server is in a non-EU country, then you have to consider how this transfer of data is protected. You're supposed to uphold the high GDPR data protection standards regardless of where the processing occurs.

• Some countries have been granted an EU adequacy decision, meaning that their data protection laws are sufficiently similar to EU laws and no extra bureaucracy is needed for that transfer. The transfer still needs to be noted in your privacy notice (compare Art 13(1)(f)).

• In other cases, you may be able to rely on “standard contractual clauses” (SCCs), which are pre-formulated contracts provided by the EU that translate relevant GDPR aspects into a private contract between the data exporter and data importer. However, you as a data controller must make sure that the data importer is legally able to enter into that contract. For example, the terms of these SCCs are incompatible with US national security laws, meaning that US companies might not be able to enter into the SCCs.

• There are a couple of other ways to authorize international transfers, but they are mostly relevant for multinational groups of companies, or in exceptional situations.

In any case, other GPDR requirements like the need to have a suitable contract with your data processors remain unaffected.

Also unaffected is the obligation to implement appropriate technical and organizational measures to ensure the compliance and security of your processing activities (e.g. see Art 24 and Art 32 of the GDPR). For example, this may imply the need to implement suitable encryption.

In the wake of the Schrems II ruling that struck down the EU–US “Privacy Shield” adequacy decision, the EDPB published recommendations on extra compliance measures that could allow SCCs to remain valid for EU–US data transfers. But it's not easy to defend data processing activities when potential adversaries include literally the NSA, and measures such as end-to-end encryption (E2EE) are incompatible with cloud services that are more interesting than backup storage.

Practically speaking, I would reconsider an architecture that would allow failover of EU data processing operations to non-EU locations, unless those target countries are covered by an adequacy decision. If you need a high availability setup for EU activities, it may be more appropriate to maintain multiple deployments within the EU.