GDPR storing vs processing / computing data (failover scenarios) 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?
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.
The status of any PII (Personally Identifiable Information) is the same in GDPR regardless of location, or who enters it. Its goals are (among others) to stop any actor (company / government or other) from hiding responsibility about their use and practices around people's data. GDPR does even apply to anything offline and on paper. Basically it means you have to validate any entry field is free of PII before processing it. Or make it clear in your privacy statement how you handle this use-case.
I think this shows a misunderstanding of the meaning of the GDPR. A data subject has the right to demand information, correction, deletion etc. about some of their data held by some institutions, depending on the legal basis for the data processing. One John Smith does not have the right to see the data of any other data subject named John Smith, and he cannot even demand to know if there are other John Smiths in the database. The data controller has to make reasonable steps to ensure that an individual who seeks account information is in fact the individual who is the data subject. In the case of an email, that's usually easy -- if John Smith can access the mail account jsmith@sample.org, one can assume that he is the John Smith who opened the account. If not, then not. If the data controller has the birthplace and birthdate in their records, they can possibly match that against some government-issue identity document, too, but why would they have that data?
Please note that Google Analytics do not anonymize the data you collect on its behalf unless you configure it to do IP-anonymization. If you use Google Analytics and do not use this feature, you need to have a DPA (Data Processing Addendum) in place with Google in order to comply with the GDPR. This is a real hassle, so unless you absolutely need fine-grained demographic data, it is strongly recommended that you use IP-anonymization. According to our data protection supervisory authority, this is sufficient to comply with the GDPR vis-a-vis Google Analytics. Does data that is anonymized need to be collect in the event of a GDPR Subject Access Request? No. But as the controller, you need to make sure that is is anonymized.
The GDPR does indeed require that the password be stored "securely". It does not specify the technology which must be used for that purpose. Hashing the PW is a common method, and should be sufficient if properly implemented (strong hash function, use of salt, etc). But other methods of securing the password might be sufficient. Encrypting the PW rather than hashing it, so that an authorized person could decrypt it temporarily might be OK. Or perhaps a security app can separately retrieve only the specified characters of the PW through some sort of encryption. Or perhaps the ISP is not using proper security. In the case of Knuddles in the linked news story, an actual breach occurred which led to the poor security being reported. You could send a report to the appropriate national Data Protection Authority.
Alice's business sells database management software. Organisations buy or licence the software, deploy it on hardware they control and use the software to help store and, process and analyse 'personal data' within the meaning of GDPR. Alice's business has no access whatsoever to the personal data being stored and processed by those organisations. In respect of that personal data, GDPR is not engaged by Alice's business. The business is neither a 'controller' nor 'processor' of that personal data. Who does the data protection law apply to? - European Commission Who does the UK GDPR apply to? - Information Commissioner's Office
Yes, GDPR applies: you are a data controller established/living in the UK or are offering services to people in the UK you fall under the material scope of the GDPR. The Art 2(2)(c) exemption for “purely personal or household activity” does not apply since you're offering the service to the public. You must consider GDPR compliance here. This is especially important as you are showing personal data to the public. Don't do that unless you have a very good reason, appropriate safeguards, and are clear to users how their information will be shown. On a high level, GDPR compliance involves working on the following questions: For what purpose are you processing personal data? Context: purpose limitation principle per GDPR Art 5(1)(b) What is the legal basis for processing? GDPR Art 6(1) lists the available legal bases. Here, consent, necessity for performance of a contract, or a legitimate interest could be a legal basis. They may have further obligations attached. A legitimate interest requires a balancing test that considers the data subject's rights and freedoms. Consent must fulfil the conditions per Art 7 in order to be valid. What is the minimal data necessary to achieve the purpose? Per the Art 5(1)(c) data minimisation principle, it is illegal to process personal data beyond what is necessary and adequate. You must provide data protection by design and by default per Art 25. Special categories of data per Art 9 such as health data are illegal to process outside of narrow exemptions. You must delete data once it is no longer necessary. What appropriate safeguards and security measures should you apply? Per Art 24 and 25, you are responsible for determining and implementing appropriate measures. This depends a lot on your specific context, so there's no checklist you can apply. Per Art 25(1) you must pseudonymize the processed information if that is compatible with the processing purpose. What further compliance measures do you have to consider? There are additional GDPR and non-GDPR compliance measures. From the GDPR side: Use the answers to these questions to write a privacy policy, including the information that you must provide to data subjects per Art 13. Consider whether you have to maintain a Records of Processing document per Art 30, or if you have to make a Data Protection Impact Assessment per Art 35. If you use third party services, figure out whether they are a joint controller or data processor and apply appropriate safeguards. If you have data processors, ensure that you have a contract in place that covers the items from Art 28(3). If you share data with other controllers (not processors) you need a legal basis for doing so. If you transfer data into a non-EU/EEA country (after 2020: non-UK country) you need a legal basis per Art 44 and have to cover additional items in your privacy policy. Ideally, the target country is covered by an EC adequacy decision per Art 45. For US-based companies, this is the case only when they have self-certified under the Privacy Shield framework. Non-GDPR compliance steps could include cookie consent banners, or showing a VAT ID. How can you prepare for data subject requests? Data subjects have various rights per Arts 15–23, subject to the modalities in Art 12. For example, a data subject could request that their information is erased from your website. The exact rights also depend on the legal basis you selected. You should figure out in advance how to deal with such requests.
GDPR gives you a lot of flexibility here to choose either DPA. From Art 77: Without prejudice to any other administrative or judicial remedy, every data subject shall have the right to lodge a complaint with a supervisory authority, in particular in the Member State of his or her habitual residence, place of work or place of the alleged infringement if the data subject considers that the processing of personal data relating to him or her infringes this Regulation. However, the DPA from the company's country would be designated the lead supervisory authority for this investigation. If multiple DPAs are involved, they would coordinate with each other. There is no EU body that you could contact directly. But if the different DPAs have a dispute regarding this investigation, the EDPB would provide a consistency mechanism. This mechanism has been used in the past e.g. to force the Irish DPA to correctly apply the GDPR against companies from the Meta group, like WhatsApp and Instagram. Though it might slow things down, it could be advantageous to have multiple DPAs involved, precisely so that the investigation is double-checked. If the lead supervisory authority declines the case, this would also enable the other DPA to do its own investigation. So, it would be a good idea to lodge a complaint with the DPA of your home country, and let it forward the issue to other DPAs as needed. However, contacting the DPA in the company's country would also be fine, especially if you are fluent in the relevant official language, and/or if you live in Ireland.