GDPR and Storing Non-EU Citizen Data as an EU-based company I work for an EU company based in the UK and often work with clients in China and Africa (and some other non-EU countries). In the future, it may arise that we will be storing some personal information on citizens from these countries and was wondering what the GDPR laws were with reference to an EU company storing non-EU citizen data? I thought GDPR was to protect the data/information of EU citizens (from Wikipedia): General Data Protection Regulation (EU) 2016/679 ("GDPR") is a regulation in EU law on data protection and privacy for all individuals within the European Union (EU) and the European Economic Area (EEA). but wasn't sure if personal information outside of the EU was also protected. Short version: are there any GDPR considerations that must be in place when an EU company stores personal information from citizens outside of the EU?
are there any GDPR considerations that must be in place when an EU company stores personal information from citizens outside of the EU? Absolutely. The territorial scope of the GDPR is specified at Article 3: Article 3 Territorial scope This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not. This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to: (a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or (b) the monitoring of their behaviour as far as their behaviour takes place within the Union. This Regulation applies to the processing of personal data by a controller not established in the Union, but in a place where Member State law applies by virtue of public international law. As specified in point 1, the regulation applies to controllers and processors located in the EU. There is no exemption of personal data based on the data subject's nationality or location. In fact, GDPR Recitals 2 and 14 explicitly mention that nationality or residence shall not be a factor: The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. […]
Neither the GDPR, nor the CCPA, nor any other data protection law that I am aware of, requires that when information is deleted on request, that similar information not be collected and stored in future. Under the GDPR Article 6 there would have to be a lawful basis for any processing, including storage, assuming that the GDPR applies to the directory in question. There could be a claim that such processing was lawful under article 6(e) &quot;performance of a task carried out in the public interest&quot;. I do not know if any such claim has been adjudicated. Thus there is no need to hold a database of previously erased records to determine if a new record should be blocked as &quot;previously deleted&quot;. The Wikimedia Foundation, which runs Wikipedia, I believe takes the position that the GDPR does not apply to Wikipedia, I am not sure of their detailed arguments. But surely articles on well-known people, such as a former US president, would be covered under the same provisions as would cover news reports and historical books about such a person. Perhaps that would also come under article 6(e)
The ePrivacy Directive Cookies are governed in the EU by the ePrivacy Directive which was first passed in 2002, and revised in 2009. However, if a site places a cookie, and later reads the cookie and stores an indication of the cookie content, this may be personal information and thus also subject to GDPR rules. (Other privacy laws, such as the CCPA, may also impose requirements on cookie use, when they apply.) Note that the so-called &quot;EU cookie law&quot; is a directive and not a regulation. This means that it is up to the various EU countries to implement it in their national legislation, and different countries may implement it in different ways. It would be the actual laws in individual EU countries that would be binding on website operators, and I am not going to try to find and analyze all the various laws on the topic. Paragraph 25 of the directive (linked above) reads: However, such devices, for instance so-called &quot;cookies&quot;, can be a legitimate and useful tool, for example, in analysing the effectiveness of website design and advertising, and in verifying the identity of users engaged in on-line transactions. Where such devices, for instance cookies, are intended for a legitimate purpose, such as to facilitate the provision of information society services, their use should be allowed on condition that users are provided with clear and precise information in accordance with Directive 95/46/EC about the purposes of cookies or similar devices so as to ensure that users are made aware of information being placed on the terminal equipment they are using. Users should have the opportunity to refuse to have a cookie or similar device stored on their terminal equipment. This is particularly important where users other than the original user have access to the terminal equipment and thereby to any data containing privacy-sensitive information stored on such equipment. Information and the right to refuse may be offered once for the use of various devices to be installed on the user's terminal equipment during the same connection and also covering any further use that may be made of those devices during subsequent connections. The methods for giving information, offering a right to refuse or requesting consent should be made as user-friendly as possible. Access to specific website content may still be made conditional on the well-informed acceptance of a cookie or similar device, if it is used for a legitimate purpose. This should mean, if implemented straightforwardly, that cookies, beyond those absolutely essential to the operation of a site, can only be placed if a user is notified of the intention to place them, and freely consents. This can be done once per user, on an initial session. Users are supposed to be provided with provided with &quot;clear and precise information&quot;. I do not think a simple statement that the site uses cookies fulfills this. At the very least the purposes for which cookies will be used should be provided. The directive does not make clear what level of detail about individual cookies such a notice must provide. The notice described in the question neither describes the purpose of cookie placement, nor does it offer any meaningful choice to accept or reject them. As such, I do not think it would be compliant with the directive. If cookies are read back (which is after all pretty much the point of having them) and can be potentially identified with an individual, then under the GDPR (article 6) there must be a lawful basis for processing them, and the interaction above would not be enough to establish consent as a lawful basis. There might be some other basis that does not require consent, however. Interpretations from others This page from cookiebot explains some of the history of the directive, and how it contrasts with the GDPR (which is a regulation, and so is directly applicable without the action of national legislatures). This page from The Verge discusses recent changes in the directive and the guidelines for applying it, and criticizes how it has been complied with, and ignored, by many sites. Cookies and the GDPR This page, &quot;GDPR, and the ePrivacy Directive&quot;, from GDPR.EU says: ... cookies, insofar as they are used to identify users, qualify as personal data and are therefore subject to the GDPR. Companies do have a right to process their users’ data as long as they receive consent or if they have a legitimate interest. Passed in the 2002 and amended in 2009, the ePrivacy Directive (EPD) has become known as the “cookie law” since its most notable effect was the proliferation of cookie consent pop-ups after it was passed. It supplements (and in some cases, overrides) the GDPR, addressing crucial aspects about the confidentiality of electronic communications and the tracking of Internet users more broadly. To comply with the regulations governing cookies under the GDPR and the ePrivacy Directive you must: Receive users’ consent before you use any cookies except strictly necessary cookies. Provide accurate and specific information about the data each cookie tracks and its purpose in plain language before consent is received. Document and store consent received from users. Allow users to access your service even if they refuse to allow the use of certain cookies Make it as easy for users to withdraw their consent as it was for them to give their consent in the first place. That page also describes the proposed ePrivacy Regulation which, if passed, will replace the current directive, and links to drafts of it. Conclusion The site described in the question probably does not comply with legislation implementing the ePrivacy directive. Depending on where it is hosted and targeted, and what it does with cookies that it sets, it may fail to comply with the GDPR as well. There has been very little enforcement of the directive so far. This may change in the future, particularly if it is replaced by a regulation, as has been proposed.
Yes If you are in the EU, or your players are in the EU and your service is targeted at some part of (or all of) the EU, then this pretty clearly falls within the scope of the GDPR. Such a service would be collecting data associated with natural persons. At least some of it would be made public along with an online identifier, and other parts would be processed and stored, even if disclosed only in anonymized form. (By the way it is a non-trivial task to anonymize data well enough that it is no longer persona data under the GDPR. But let's suppose yoru methods are good enough.) Under GDPR Article 6 the DC must have a lawful basis for such processing. If the basis is &quot;consent&quot; then the consent must be freely given, whch means giving consent may not be a condition of using the service. Under GDPR Article 13 a notice must be sent to the Data Subject (DS) when the data is collected from the subject, including some 11 items or categories of information about the collection process, the Data Controller (DC), the purposes of processing, the legal basis of processing (which the DC must define), who will receive the data, the data retention period, and various rights of the DS. Such a service must be prepared to respond to data access and data erasure requests, under articles 15-17, and data restriction requests under article 18. It must provide a method for a DS to easily make such requests. Other GDPR provisions may well apply in addition to these, but that is enough to show that such service is very likely to be within the scope of the GDPR, unless none of the DSs are present in the EU or the related market area.
GDPR killing genealogy websites? I could see GDPR totally killing genealogy websites if they follow the rules strictly, but would they really want to do that. Seems to me genealogy has an important historical role. Treat living persons with anonymization I assume you don't have data to identify a person or contact the living person. How would you contact to get consent to show personal information if you only have a name, impossible right? GDPR tries to stop abuse of personal data, yes, and your family tree certainly is personal data. However those who come to your website would mostly want to search and edit the non-living, search back in the history, thus the current generation follows the family tree and are not the point of entry. You can provide certain anonymization to those alive by not displaying the first names in full, maybe just the first letter. You may want to hide address, spouse, children for current generation. You could make those available for view/edit first by going through a secondary login, "not a robot". Further you may remove living people from search results and hide from search engines so they do not have ability to index the current generation. That would make it harder to abuse if you're going after an individual, but at the same time doesn't lock out the people providing information.
There are two relevant bodies of EU law to consider here. The GDPR covers processing of personal data. Personal data is any data where the data subject can be identified directly or indirectly. The ePrivacy directive is also relevant, and covers how you may access and store information on the user's device. Directives are not directly applicable law. Instead every member state translates the directive into national law. In the UK, ePrivacy is implemented by PECR. Is the data you collect personal data in the sense of the GDPR? Yes: that hashed unique device ID or a system-provided advertising ID likely is personal data, and any linked data would then be personal data as well. This is going to be the case in particular if you store user accounts on your server and can connect these bug reports to a user. Consider also whether the game save could include personal data, and whether the video clip could be analyzed to identify the data subject. Does this mean collecting this information in bug reports is forbidden? No, the GDPR doesn't forbid or allow anything outright. Instead, you should go through the compliance process. In a nutshell: determine the purpose of this processing, e.g. “fixing bugs” find an Art 6 legal basis for this purpose, e.g. “Art 6(1)(f) legitimate interest” or “Art 6(1)(a) consent” if the legal basis is legitimate interest, you must balance that interest against the data subject's interests determine whether your compliance requirements include creating/updating your Records of Processing, or whether you have to write a Data Protection Impact Assessment implement the processing in a manner that respects GDPR principles such as Transparency and Data Minimization if the legal basis is legitimate interest you must implement an opt-out solution if the legal basis is consent, you must request consent first in a manner that satisfies the Art 7 conditions for consent – and allow consent to be revoked easily prepare to satisfy data subject rights: information requirements per Art 13, usually done in the privacy policy right to access, rectification, erasure, and data portability right to object (opt-out) and to restrict processing be aware of your general requirements a data controller to process this data securely, e.g. use HTTPS connections to transmit bug reports, take steps to protect your own accounts (e.g. 2FA), and ensure you have a suitable contract with any data processors that act on your behalf, e.g. cloud providers or contractors I would question whether your bug reports really need to include a device ID. That isn't forbidden, it just complicates compliance a bit. And what about ePrivacy? The ePrivacy directive is known for its cookie consent requirements. But these consent requirements apply when accessing any information on the user's device, or when applying equivalent fingerprinting techniques. Your game save is not an issue because it is necessary for the game. But that device ID and other system information is more difficult. So what to do? Compliance isn't trivial, but certainly possible. You will likely process the bug reports under your legitimate interest, but might still have to collect consent for accessing a system ID due to ePrivacy. Such a screen might look like this: Oh no, the game crashed! Do you want to send a bug report to the developers? Your bug report will be protected as per our privacy policy (link). Your bug report will contain the following information: … Yes, collect system information and send bug report No, do not send bug report You could make an argument that a bug report can be sent in any case, and that you just need ePrivacy consent to collect useful system information. For example: Oh no, the game crashed! When sending a bug report to developers, do you want to include extra system information (link to details) that helps fixing the problem? In any case, your bug report will be protected as per our privacy policy (link). Your bug report will contain the following information: … Yes, send bug report with extra system information No, send anonymous report
Does GDPR prohibit reading unsolicited emails from people who have not explicitly opted in to a mailing list? tl;dr: No. I have never heard of this, and I don't see how this could follow from the GDPR. You should follow up with the Secretary to find out how she came to her conclusion. Detailed reasoning: The GDPR restricts the processing of personal data, so it does in principle cover reading email, since reading counts as "processing", and an email may contain personal data. However, Article 2 (emphasis mine) 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. I would read this to mean that a human reading emails is only covered by GDPR if the emails are part of a "filing system" or intended to be. So reading the emails is ok, it's only problematic if you intend to systematically store them. Even filing them, while covered by GDPR, would presumably be allowed, because to actually act on the email, you would have to keep it, and Article 6 allows processing of personal data to "take steps at the request of the data subject prior to entering into a contract" and when "processing is necessary for the purposes of the legitimate interests pursued by the controller". One caveat: If the email contains data that falls under special categories of personal data (Article 9) you may need explicit consent for storage. That covers things like racial or ethnic origin, political opinions, religious beliefs and health information. So if someone discloses a health problem or their religious belief in their mail, you may need to ask them for permission to keep it. In summary: At most, GDPR would require you to promptly delete the email once you no longer need it (which could be immediately if the email is irrelevant to you). If the email contains data you legitimately need (e.g. a complaint you need to follow up on), you are allowed to keep it as required (based on Article 6 (f)). Note that in both cases no explicit consent is required from the email sender, unless the email contains particularly sensitive data, such as political/religious beliefs or health data.
If I have correctly untangled the law, Schedule 2 of the Data Protection Act part 3 identifies as a condition where you are not prohibited from revealing personal data: The processing is necessary for compliance with any legal obligation to which the data controller is subject, other than an obligation imposed by contract. The Animal Welfare Act 25(1) says An inspector may require the holder of a licence to produce for inspection any records which he is required to keep by a condition of the licence I can't tell if you are required to keep customer names, but if you are, it looks like the pieces fit together and you would have to provide the records. Call a solicitor to be sure, though.