Does the German GDPR require storing the data in a German datacenter for a tele-health company? I co-founded a tele-health startup, we are expanding to Germany, we have gone through the GDPR, and implemented most of it, however, we didn't quite understand the data residency part and found conflicting information online. Should the data be stored in a German data center? is it a requirement? Would it be ok to have it stored outside Germany? How about outside the EU? Thanks
The goal of the GDPR is to ensure a single market for personal data processing throughout the EU. Since all EU/EEA member states now have equivalent levels of data protection, it doesn't matter in which member state data is stored or processed. Member states cannot generally limit this single market via national laws. Furthermore, secure processing may be possible outside of the EU/EEA as discussed in Chapter 5 of the GDPR. Some countries such as Japan have been asserted an adequate level of data protection so that no special safety measures are necessary. For other countries, a transfer of personal data may be possible under so-called Standard Contractual Clauses which detail the responsibilities of the data exporter/importer. However, the recent Schrems II ruling has invalidated the (partial) adequacy decision for the United States, and has strongly hinted that SCCs only work if the parties are actually able to honor their responsibilities under the SCC (which is not the case with some surveillance laws). Data protection is likely not ensured for processing in the US or by US-controlled companies (even if the processing usually takes place within the EU). Given the sensitivity of health data, this means you should likely avoid using the typical public cloud providers (regardless of availability region). Depending on where your company is based, you might also be disqualified as a data processor by EU data controllers. So the GDPR has no data residency requirements that limit the processing/storage to Germany, but some data residency requirements to keep the data in the EU. However, there may be non-GDPR obligations that mandate how the data can be processed, but I'm not familiar with those (the German regulatory landscape for tele-health is very uneven, differs between German states, but is also improving a lot recently). Since you're processing health data, you should pay special attention to Art 9(3) GDPR which is expanded in German law by §22 BDSG to list a catalogue of possible safety measures you should consider, but none of them are related to data residency. §78 BDSG has further details on transfers into non-EU countries, such as emphasizing that human rights must be guaranteed in the target country.
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.
In German Law you need to give your agreement ("Willenserklärung") to a contract or in this case terms of service. This is done by telling the other part. In some cases this can also be implied by an action (example: putting your bottle of beer onto the cashiers table is an offer to buy this bottle). As a second criteria a "Willenserklärung" needs to be the exact will of the part that declares its will (the website user in this case) §§ 133, 157 BGB or that the other side (you) could only see so (not the case here as this mainly speaks of content). If you visit a website and there are terms of services, the "Willenserklärung" is only given when the user read and agreed to the terms. If he did not, the terms of service are not applied until the user agrees to them. So I would recommend to block the website until the user agreed (overlay) as you need to proof he did when in court. Additionally there are so called AGB's in Germany. Those are contracts that are used or planed for many (more than 3) uses and set by one side (you). This may apply here, so you need to follow a lot of other rules like making sure the user had access and agreed, then there are many content restrictions and so on... I recommend consulting a German Lawyer specialized on this topic as this is very complex and includes other German laws for Media too, depending on the content of your site and terms. Also note that everything said is only based on my own knowledge and can not be used as safe legal source.
If GDPR applies, then no one can opt out. If it doesn't apply, then an IP block is superfluous. Whether GDPR applies is determined by Art 3 GDPR. For this, we must distinguish where the data controller is operating from. It is irrelevant where the site is hosted, but primarily relevant where the data controller (your colleague) has an “establishment”, e.g. where he resides or typically works from. Per Art 3(1), GDPR applies to all processing activities in the context of an European establishment, regardless of where the users are. So if your colleague were running this site from Europe, they wouldn't be able to circumvent GDPR by blocking European users. However, if your colleague is running this site from outside of Europe, then Art 3(1) doesn't trigger. Per Art 3(2), GDPR can apply to processing activities where there is no European establishment. There is the Art 3(2)(a) “targeting criterion”: if your colleague “offers” goods or services to people who are in Europe, regardless whether paid or gratis, then GDPR applies to all processing activities related to this offer. I'll discuss this more below. There is also the Art 3(2)(b) criterion: if your colleague monitors the behaviour of people that occurs in Europe, then GDPR applies. For example, an app collecting geolocation information or a website creating interest profiles for ad targeting might trigger this criterion. An IP block can help to establish that no offering/monitoring related to people who are in Europe is happening, but it might not be necessary. It may be worth talking a bit more about the targeting criterion. The GDPR explicitly says that mere availability of a website in Europe doesn't imply that GDPR would apply. Instead, it is necessary to establish the data controller's intention – are they soliciting users from Europe, or otherwise expecting that people from Europe might use those services? Recital 23 gives a couple of non-exhaustive factors that can be considered here, for example: the site uses a language or currency used in the EU but not used in the controller's own country the site mentions users or customers from Europe, e.g. in testimonials This means that a lot of US websites, written in English or Spanish, only mentioning payment in USD (if any), not mentioning any European countries, will not be subject to GDPR. Then, occasional European visitors are irrelevant. It wouldn't be necessary to IP-block potential European users. However, such an IP-based block would help establish that the data controller really doesn't intend for those services to be offered to people who are in Europe. My personal opinion is that it's wasted effort to block users from foreign countries in case their foreign laws claim to apply, but if such a block brings peace of mind that might be worth it. While geoblocking might not be necessary, is it sufficient? There is no clear guidance on this subject, but it seems to be generally accepted that IP-based geoblocking is fine, even though it is trivially circumvented using VPN services. Of course, if a website were to block European IP addresses but were to also advertise that people in Europe can use their services via VPNs, that would probably still be an “offer” and might defeat the point of doing any geoblocking. The Art 3(1)(a) targeting criterion is most easily applied to things like ecommerce where physical goods are shipped to the customer in return for payment – so essentially whenever the data controller participates in the EU Single Market. This is roughly similar to the concept of a Nexus in US tax law. But in principle the targeting criterion can also apply to other kinds of websites or apps such as blogs, even if they are gratis. GDPR does not just apply to for-profit commercial activity, and doesn't distinguish between controllers that are entities/LLCs and controllers who are natural persons. Things are slightly more complicated due to the Art 3(2)(b) monitoring criterion and the pervasive use of online trackers on websites, but this aspect of the GDPR is difficult to enforce and frequently ignored. In this answer, “Europe” means the European Union (EU), the European Economic Area (EEA), and the United Kingdom (UK). Note that countries like Norway are covered by GDPR, whereas Switzerland is not. Of course, the GDPR is not the only privacy law relevant internationally.
Among other things, GDPR regulates what you may do with the data within your systems. You can use it for the contracted purpose, or in accordance to law, or with informed and revokable consent, or for some other enumerated purposes. Even with consent, you have to take security measures to avoid the misuse of the data. Remember the software shrink-wrap licenses? &quot;By opening the package, you agree to the terms inside.&quot; GDPR makes the equivalent in the cloud world impossible. You have to document exactly what you do with the data, and for any use that is not necessary to perform the service the customer can opt out. In the scenario you describe, it is possible that you are not the data controller under GDPR but the data processor, and that you have a duty to keep the data from separate controllers apart. And delete any batch at the end of contract. If you want to do this professionally, you need to consult a lawyer for your specific plans.
GDPR rights and obligations cover different things: A duty of the data processor towards the government of the country where they operate to present certain documentation, and to implement technical and organizational measures to protect data. These would be audited by government agencies, not the individual customer. A single data subject cannot waive them. A duty of the data processor to process and store personal data only with a legal justification. User consent is one possible justification, if it is informed, revokable, etc. So a single data subject can waive a &quot;ban&quot; on storing his or her data in a database along with all the other users who waived that &quot;ban,&quot; but the duties towards the government regarding that data would still apply. A duty of the data processor to respond to an Article 15 request by the data subject in a certain way and timeframe. If a data subject writes a letter to the data processor and explicitly states that the letter is not an Article 15 request, then Article 15 does not apply. The data subject would of course have the right to make an Article 15 request at a later time.
Possibly, but probably not. Personal data is any information relating to an identifiable person. The statement “Alice is sick” is information, and relates to Alice who is identifiable. Processing personal data is not inherently illegal, but does require a legal basis per Art 6 GDPR, such as a legitimate interest. Here, the information is data concerning health, processing of which is prohibited unless one of the explicit exceptions applies (such as explicit consent, or legal obligations). So it is legitimate to have concerns on whether disclosure of this information would be legal. If these rules were breached, that would be on the data controller. Here, the company would be the data controller, not Bob (unless Bob acted against training and instructions and processed the personal data for his own purposes). However, GDPR probably doesn't apply to this specific interaction. In Art 2(1), the GDPR says that This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. A conversation itself would not be subject to GDPR rules – there is no filing system or similar structured data involved. What GDPR would prevent is to keep records on Alice's health status, but doesn't necessarily prevent talking about it informally. For example, the EUR 35.3M fine against H&amp;M in Germany was imposed not because managers talked with employees about personal matters, but because they then maintained detailed files about those personal matters. Data controllers are responsible though for ensuring security and compliance through appropriate technical and organizational measures (TOMs). TOMs can include things such as non-disclosure agreements and training for staff. If Bob acts against such training, there could be repercussions along the Bob–Company employment relationship. But that would mostly be an employment law thing, not so much a GDPR thing.
You wrote: As far as I believe, it is permitted under GDPR to record and store non-anonymized web server access logs, as these can be useful for security reasons. True, Recital 49 GDPR: The processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted personal data, and the security of the related services offered by, or accessible via, those networks and systems, by public authorities, by computer emergency response teams (CERTs), computer security incident response teams (CSIRTs), by providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the data controller concerned. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems. You asked: My question is whether this anonymization process counts as processing personally identifiable data under GDPR? IP addresses are personal data in some cases, so yes, you're processing personal data. Then, these anonymized logs will be fed into an analytics tool to provide stats on unique visitors, page hits, etc. These are purposes considered compatible with initial purposes according to Article 5.1.(b): Personal data shall be (...) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for (...) statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’); As a matter of fact, you might be required to anonymize the data for those purposes, see Article 89.1: Processing for (...) statistical purposes, shall be subject to appropriate safeguards, in accordance with this Regulation, for the rights and freedoms of the data subject. Those safeguards shall ensure that technical and organisational measures are in place in particular in order to ensure respect for the principle of data minimisation. Those measures may include pseudonymisation provided that those purposes can be fulfilled in that manner. Where those purposes can be fulfilled by further processing which does not permit or no longer permits the identification of data subjects, those purposes shall be fulfilled in that manner. If I were to anonymize the logs and continue to use them exclusively for security reasons, would that change anything? No, you would be processing data in a manner compatible with initial purposes (ensuring network and information security). Or does it not matter what I do with them once they are anonymized? Yes, it does. If you're not using them for &quot;archiving purposes in the public interest, scientific or historical research purposes or statistical purposes&quot; then you're using them for purposes incompatible with initial purposes. You would need to find new legal basis for processing. does this extra anonymization process on top then take it over the line meaning that consent and a privacy notice would be required? It depends on what you want to do with anonymized data. In your case, for security purposes or security and statistical purposes, you don't need the consent and there is no requirement for the privacy notice (but sure, it would be nice to publish one). For other purposes it might be different.