Under GDPR can I avoid divulging a customer&#39;s data to the government? Scenario: A business has a legal requirement to obtain a license from a government agency relating to its business activities. The business activities have already being undertaken and there is no way to avoid the need for the license (e.g. by ceasing the activities). The license application form asks for customers' personal data (names plus basic details relating to their contracts e.g. dates). The business feels uncomfortable divulging such data to the government, and is pretty sure their customers would be unhappy if they knew about it. The business, the customers, and the government, are all located in the EU. What is the position in relation to GDPR? Can the business refuse to complete the relevant sections of the license application? My starting point is GDPR Articles 4(2) and 6(1)(c) (emphasis added): 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; 6(1) Processing shall be lawful only if and to the extent that at least one of the following applies: (c) processing is necessary for compliance with a legal obligation to which the controller is subject; This would seem to indicate to me that the business does indeed have to divulge the information. Is this correct?
Your analysis so far seems correct. You must comply with all applicable laws. The GDPR's Art 6(1)(c) legal basis clarifies that having to provide personal data is no excuse: that legal obligation is all the legal basis you need for sharing the personal data in accordance with your obligations. However, that legal basis doesn't generally excuse you from your other data controller obligations. For example, you should still inform the data subjects about the processing as per Art 13(3).
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.
See Art. 17(2) GDPR: Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data. So the controller must tell all other controllers (like google) to delete the data. The privacy policy must include the fact that data is made public.
There is nothing in the GDPR requiring you to collect individual personally identifiable information. If the website has no need, and the website owner no desire, to collect such information, there is no requirement to do so. The GDPR requires that if such information is collected, that there is a lawful basis, and that it be handled appropriately and stored securely, and deleted when there is no longer a need to retain it, or on a proper request. If no such information is collected in the first place, all the rules about how to handle it do not apply. It is possible that some law of an individual country in the EU might mandate collection of some particular information, but I have not heard of any such requirement.
In principle, the data subject's right to access involves a copy of all personal data the controller holds on them. There are no time limits by default. Of course, the controller can ask a data subject to clarify their request, e.g. to focus on a particular time frame. There is an implied time limit though: personal data may only be processed/stored for as long as the data is necessary to achieve the purposes for which it was collected. Afterwards, it must be deleted. A controller with good data management will be able to limit their effort by having as short retention periods as possible for their different records. Furthermore, a lot of data is not personal data, or falls out of scope of the GDPR because it is not processed with automated means or forms part of a filing system. For example, if thousands of old invoices were archived in paper form in boxes that are only sorted by year, there might be an argument that this isn't a filing system in the sense of the GDPR and that a DSAR would not have to involve looking through all the archived invoices (compare also Art 11). In your scenario, there is a clear retention period of six years. You are asking for records about how that data might have been used further in the past. To the degree that such data is actually available, that could reasonably be personal data and should be included in a response to a DSAR. E.g. they might have information like this: “File #1234 was included in a data set that was sold to EvilCorp in 2007. The entries in File #1234 that are older than 2014 have been purged, so we do not know which entries were included in the data set. The current name on File #1234 is Dave.” This information about the sale would be personal data because it relates to you, and you are identifiable. Of course, the controller might not be set up to perform this search unless specifically asked. However, more unspecific information might not be personal data. For example: “About 70% of our files were included in a data set that was sold to EvilCorp in 2007. We no longer have records indicating whether your file was included.” Since there is no link between the sale and your personal data, I don't think it would have to be included in a DSAR response. The primary reason why you should be told about sales of personal data is that per Art 15(1)(c), you should be informed about “the recipients or categories of recipient to whom the personal data have been or will be disclosed” in a DSAR response. So when making a data subject access request, it could make sense to explicitly referencing this paragraph. So you would be interested in receiving a copy of your personal data as per Art 15 GDPR, and in particular any available information per Art 15(1)(c) GDPR about the recipients or categories of recipients to whom your personal data has been or may have been disclosed in the past. Quite likely the response will be underwhelming, e.g. by just giving a broad category such as “potential creditors who are contractually obligated to use the data only in accordance with our policies”. Whether such responses are compliant (I don't necessarily think so) will not be clear until there's a good precedent, and that would require that someone sorts this out in court.
Under GDPR article 6 paragraph 1 item (c) one lawful basis for processing personal information (PI) is: processing is necessary for compliance with a legal obligation to which the controller is subject; The obligation to attribute a reused work under a CC license is such an obligation. Moreover, the licensor has the option under any CC license to specify a pseudonym for attribution of that work, or to waive attribution totally. Not doing that while releasing content under a CC license that requires attribution could reasonably be considered consent to publish that name along with each re-released copy of the work, so there are at least two lawful bases for processing that name and making it public. In some jurisdictions the license has the status of a contract, which imposes an obligation to attribute the author properly under GDPR Article 6 paragraph 3, as described in more detail in the answer by amon. Also, usernames are PI if and only if it is reasonably possible to associate them with a specific natural person. If a person chose a user name for a single site, not used for any other, and did not post any info that allows the person's identity to be determined, it is not PI. Often, of course, the person can be determined.
GDPR Article 4 paragraph 1 says: ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; Recital 26 says Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. ... The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. Recital 30 says: Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them. An IP address hashed through a cryptographically secure one-way hash cannot reasonably be used to establish the original IP address, nor to geolocate, nor to directly identify the data subject. However if such addresses are stored in a database with a link to the subject's individual record, or to other data which identify the data subject, then they would clearly be personal information. The ICO's page on &quot;What is personal data&quot; says: ‘Online identifiers’ includes IP addresses and cookie identifiers which may be personal data. The page from GDPR.EU on &quot;Personal Data&quot; says: Any information that can lead to either the direct or indirect identification of an individual will likely be considered personal data under the GDPR. ... Any data that relate to an identifiable individual is personal data. The page on &quot;Personal Data&quot; from gdpr-info.eu says: Personal data are any information which are related to an identified or identifiable natural person. The data subjects are identifiable if they can be directly or indirectly identified, especially by reference to an identifier such as a name, an identification number, location data, an online identifier or one of several special characteristics, which expresses the physical, physiological, genetic, mental, commercial, cultural or social identity of these natural persons. In practice, these also include all data which are or can be assigned to a person in any kind of way. For example, the telephone, credit card or personnel number of a person, account data, number plate, appearance, customer number or address are all personal data. Since the definition includes “any information,” one must assume that the term “personal data” should be as broadly interpreted as possible. This is also suggested in case law of the European Court of Justice ... See also &quot;Can a dynamic IP address constitute personal data?&quot; If a hashed IP address is stored so that it can be related to a specific individual, it is personal data. as such, it would be subject to the GDPR. To store it one would need to identify a lawful basis under GDPR Article 6 This could be the Data subject's consent, or the Controller's legitimate interest. In either case the information should be included in the list of personal information collected (often in a privacy policy document), disclosed to the subject on request, adn deleted on request if possible. If that is done, such a use of a hashed IP, although personal information, would seem to be compliant. If a hashed IP is stored in such a way that it cannot be related to any particular user, then it would not constitute personal information, and no compliance issue would seem to exist. Limiting the retention time of a hashed IP is a good practice which would reduce any possible impact it might have.
When you make a request based on the GDPR, Art. 12(6) GDPR applies. Without prejudice to Article 11, where the controller has reasonable doubts concerning the identity of the natural person making the request referred to in Articles 15 to 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject. As you can see, this only applies when the data controller (Blizzard) has reasonable doubts about your identity. If I understand it correctly, Blizzard provides services (games) which requires you to login with a username and password. So they have no doubts about your identity when you use their (paid) services with just a username and password. So there should also be no reasonable doubts when you make other requests when you are able to login to their website. A copy of your government ID seems unnecessary. Recital 57 also confirms that identification does not require a government ID: Identification should include the digital identification of a data subject, for example through authentication mechanism such as the same credentials, used by the data subject to log-in to the on-line service offered by the data controller. A copy of your id, includes a photograph. The photograph could show health, religious, racial or ethnic information. That kind of personal data has much stricter rules defined in Art.9 . Most governmental IDs contain a national identification number. EU Member States can limit processing of those identification numbers even further. For example in the Netherlands processing of the identification number is only allowed when a specific law exists. So Blizzard is not allowed to process a Dutch national identification number. There are also ID convers] which hide sensitive information like document numbers and photographs in case you do need a copy of an ID. Also note that identification is only possible by comparing existing personal data with the provided personal data. I assume you did not provide a copy of your ID when registering. So many things which are shown on the ID do not make sense to sent to Blizzard. It does not know your place of birth, so it cannot verify it. Art. 5 requires 'data minimisation' for personal data. So they are not allowed to process more data than required. So you also do not need to send you more data than required. You should get an answer on your request within 30 days. However, since you ask to delete your account, the answer also might be that they will deny your request. They have to explain why they will not delete your account.