Does GDPR affect personal projects with family data? My extended family is rather large, and I would like to make a family tree. Given the nature of the data I'll have a lot of peoples personal data. Preferably their immediate family relations, name, a picture, DOB, phone number, email address, Facebook link. And potentially more. Some of this information I know just because they're my family, I wouldn't have been given GDPR consent when I was a child first meeting them. This would be things like their name and who they're related to. After this I know some DOBs for similar reasons. I can get phone numbers from our family chat. I can get a picture and some additional information from Facebook. Etc. Given that all of this information is almost definitely protected by GDPR could I legally make a family tree? What if: The family tree is strictly for myself. The family tree can only be seen by people in that tree. And they can only see people they're blood/adopted relatives of, and people married into the tree. To be clear my fathers side could see my mother, but not her side of the family. I can see both sides, as I'm blood related to both. What if I want to be able to include more than just the two families? Say one of my cousins are in a similar situation and wants to include both their sides of the family.
The GDPR has an exemption for purely personal or household activity. Creating a family tree seems purely personal as long as you don't publish it. You're also allowed to freely share the tree as long as it stays within that purely personal scope. Your proposed restriction of only showing data of blood relatives seems excessively strict. But assuming that this exemption wouldn't apply, there'd probably still be no problem. The GDPR does not require you to always obtain consent. It requires that the purposes for which you process personal data are covered by some legal basis. Consent is one such legal basis, but legitimate interest is another. You can likely argue that you have a legitimate interest to create a tree of your (extended) family. The legitimate interest must be weighed against the rights and freedoms of the affected persons. For example, contact information could be used for stalking. The balance of the legitimate interest check can be changed if you adopt suitable safeguards. Your idea of only sharing data with close relatives would be such a safeguard, but it might not be necessary. When you rely on legitimate interest, the affected person can object to further processing, furthermore they can request to be erased from your records. A request for erasure can be denied if there are overriding grounds to keep the data. E.g maybe only contact information has to be deleted but names, dates, and relations might be kept. You should notify persons when they are included into your records. It is your obligation as the data controller to make these decisions. If someone disagrees they can sue you or lodge a complaint with a supervision authority. Note that dead persons are not natural persons in the sense of the GDPR, and have no privacy. However, national laws may provide such protections.
Privacy against publication of criminal convictions has been considered in the High Court in NT1 &amp; NT2 v Google LLC [2018] EWHC 799 (QB), if I may run the risk of posting a legal citation myself. But note that the claimaints there are anonymized, as often happens in criminal trials as well. In some cases, the court may give an injunction against disclosing names or details, and can hand down both a public and a private judgement, with the latter being a restricted document that does have the identifying details. So this question could only apply to mentions of criminal process where the accused is actually identified. (And I think just saying &quot;R v Smith&quot; is not enough - the posted or linked text would have to give some identifying detail about which Smith it is, the nature of the crime, etc.) I have no qualms at all about talking about NT1 and NT2. The claimants brought a case against Google for making available information about their long-spent convictions, including on GDPR grounds although it took place just before the implementation of GDPR in UK law. Dealing with that argument under the prior legislation, the judge found that of the various exemptions claimed by Google, the condition The information contained in the personal data has been made public as a result of steps deliberately taken by the data subject. (found in the Data Protection Act 1998, Schedule 3, paragraph 5, implementing the Data Protection Directive that preceded GDPR) applied, because of a longstanding principle for criminal conduct. The idea is that (paragraph 111): A person who deliberately conducts himself in a criminal fashion runs the risk of apprehension, prosecution, trial, conviction, and sentence. Publicity for what happens at a trial is the ordinary consequence of the open justice principle [...] The same must be true of the details of the offending, and other information disclosed in open court, including information about himself which a criminal reveals at a trial or in the course of an application. The core principles are the same as the carve-out from defamation law for the fair and accurate reporting of criminal proceedings (paras 44-49). That &quot;made public&quot; condition can now be found in a slightly different context in the Data Protection Act 2018, Schedule 1, Part 3, paragraph 32, which mirrors Article 9(2)(e) of the GDPR for the purpose of Article 10: This condition is met if the processing relates to personal data which is manifestly made public by the data subject. Since this is virtually the same condition of European provenance, in the same context of surrounding rules, I think the precedent is a good guide. For courts themselves, law reports, and journalism or scholarship, there are other specific grounds to rely on. Individual Stack Exchange posters are surely covered under the general exemption for posting on social media in a private capacity, GDPR 2(2)(c) as interpreted through its Recital 18. For the site itself, as in the case of NT1 and NT2, there could well be a legal claim made about the inclusion of criminal conviction information in a posted answer. (In general, such a post, being free text, could contain all sorts of defamatory statements or other objectionable content.) The court would have to look at the competing interests and the level of harm. NT1 was not successful but NT2 was. The example scenario, where we are talking about a very brief mention of a criminal case, cited because it illustrates a legal point rather than because there's anything relevant about the person mentioned, is quite far from the grounds complained of by NT2. For NT2, there was a newspaper article in which he was &quot;quite inappropriately, portrayed as one of a rogues' gallery of serious criminals&quot; (para 188), eight years after the end of his sentence, and it was this that he wanted removed from search results. In particular, the academic exemption (para 13) seems strong, in the same way that it would be for a publisher of legal academic content. The test of &quot;substantial public interest&quot; does not apply, because this exemption comes through paragraph 36 in the case of criminal convictions; it's enough to show a reasonable belief that publication would be in the public interest. Google was not able to rely on the &quot;journalism&quot; version of this exemption (again, under the prior law) because they are a totally generic search engine for all kinds of data and purposes (para 100 of the 2018 judgement). The public interest test, and the accompanying &quot;legitimate interest&quot; for the data controller, do not seem too difficult in this example.
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.
It's hard to prove a negative, and I'm not sure which specific part of the quoted Terms you object, to, but it specifically states that content access may be done to: Comply with the law Protect its customers; and Protect the security of its business; and Protect its business interests. It's unlikely that access of information to comply with the law is illegal. At least one EU directive, Directive 95/46/EC, sets limits on the collection and use of personal information. We're concerned with the first condition for lawful data processing, and the second principle of data quality. Data processing is only lawful if the data subject has unambiguously given his consent; or processing is necessary for the performance of a contract to which the data subject is party; or processing is necessary for compliance with a legal obligation to which the controller is subject; or processing is necessary to protect the vital interests of the data subject; or processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller or in a third party; or processing is necessary for the purposes of the legitimate interest pursued by the controller or by the third party, except where such interests are overridden by the interests for fundamental rights and freedoms of the data subject which require protection. The principles of data quality, which must be implemented for all lawful data processing activities, are the following: personal data must be processed fairly and lawfully, and collected for specified, explicit and legitimate purposes. They must also be adequate, relevant and not excessive, accurate and, where necessary, kept up to date, must not be stored for longer than necessary and solely for the purposes for which they were collected; special categories of processing: it is forbidden to process personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life. This provision comes with certain qualifications concerning, for example, cases where processing is necessary to protect the vital interests of the data subject or for the purposes of preventive medicine and medical diagnosis. So, let's say that someone has given their consent. It'd be at least a little questionable whether the inspection of private information could mean that they access personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life. I'm a bit less clear on US laws, but you'd probably look for laws around Personal Identifying Information, as that's where a lot of focus has been.
Art. 17 GDPR, Right to erasure (‘right to be forgotten’) requires “erasure of personal data concerning him or her”. That’s all personal data. However, this only applies when this article applies. Section 1 details when this is and sections 2 and 3 detail limitations and exceptions to the right of erasure. For example, you would be allowed to keep financial records that you're legally obligated to keep. So, if they have the right, you have to delete all their personal data that is not exempted. Aggregate statistics and other anonymous data in the sense of Recital 26 are not personal data and don't have to be deleted. Whether the kinds of data you have mentioned would be sufficiently anonymous would require further analysis.
If you process any personal data, you do need to provide notice to the data subjects per Art 13 or Art 14 GDPR. Personal data is any information relating to a (directly or indirectly) identifiable natural person. It seems you are processing personal data including as addresses, PayPal accounts, and IBANs. Thus you're in scope of the GDPR. The GDPR does have an exception when data is processed for “purely personal or household purposes”, but that very likely does not apply to you. The German Datenschutzkonferenz (DSK), a cooperation of the German supervisory authorities, has published a handout on information obligations, listing which information has to be provided in a privacy notice: https://datenschutzkonferenz-online.de/media/kp/dsk_kpnr_10.pdf Such a privacy notice can be fairly short if you're don't doing anything special, in particular if you only use the data as necessary to fulfil the sale contract and then as legally required (e.g. for keeping financial records). There are privacy notice generators that can help with the boilerplate, but be aware that some are significantly outdated, and that in any case you have to fill in the information about your concrete processing activities. You have guessed correctly that you will need to inform your customers about your data retention periods. Your privacy notice will get more complicated if you also want to use this data in other ways, for example for marketing purposes. That would also require you to think about appropriate legal bases (e.g. legitimate interests, or consent).
This depends on the context – GDPR rarely restricts the use of specific kinds of data (see Art 9) but instead regulates the processing of this data, and the purposes for which it is processed. Personal data is any information relating to an identifiable person (Art 4(1)). So to show that some information is not personal data, you must show either that it doesn't relate to the identifiable person, or that it's not possible to identify the person. Whether a person is identifiable depends on the means of identification that are reasonably likely to be used, taking into account the cost and effort of these means (Recital 26). This recital also mentions that singling out a person is a kind of identification. If you have lots of birthdays so that there are no unique birthdays, or if the birthdays are stored without contextual information that would allow identification, this can indicate that it's not personal data. Some examples to illustrate my views: Scenario 1: you are collecting statistical data in a shopping mall and are collecting birthdays from passer-bys, without any additional information. This information is anonymous and not personal data, since you have no reasonable means to identify the persons. Scenario 2: in an office, there's a publicly visible calendar on the wall with the birthdays of all staff members. However, the calendar doesn't say whose birthday it is. This information is likely personal data, since it's reasonably possible to infer the correct person based on contextual information. At least HR would also have the birthday for all staff members on file, so that the company clearly has the means to identify anyone. (This doesn't mean such a public calendar is illegal, just that there must be a legal basis.) It is more difficult to determine whether information also relates to an identifiable person, i.e. whether this information is about that person. This depends not just on what the information is, but how the information is used. AFAIK there has yet to be EU-wide guidance by the EDBP, but the ICO has listed some hints. I think that a birthday of an identifiable person will almost always relate to that person.
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.