How does GDPR&#39;s right to erasure apply to deduplicated storage? I am trying to understand GDPR's right to erasure (and principle of storage limitation) in the following case: Company A offers a online data storage service that is intended to be used by the users of other companies (e.g. company A hosts a FTP server for company B and its users). The users of the service that company B subscribes to may be employees of company B or just regular private consumers. The users can upload arbitrary files, they may or may not contain their personal information, it is each user's individual decision what data they upload and/or access. The storage system that company A uses for its service deduplicates all uploaded files. This means that if user A uploads a file, and then user B uploads the same file, the file will exist only once but under two distinct aliases chosen individually by each user. This also means that if user B deletes their file (or more precisely their alias to the file), then the file will still be present in the storage service until user A also deletes it. A common sense counter-argument for this would be that without deduplication, in a system where each file is always distinct, if there are duplicate files then if one user requests erasure then we would not also delete all duplicates of the file which might belong to other users. Is there any reason for this to not extend to deduplicated files with aliases? According to section 65 of the GDPR1, personal data can be kept for as long as it is needed for its intended purpose. Is the purpose that it is needed for other users to be able to access their data valid? I would really appreciate any insight on this and any good resources to further my understanding of GDPR.
I think there are a couple of different ways to look at this. Deduplication is a technical detail that's irrelevant here While the data may be deduplicated on a technical level, the files remain logically distinct. If users 1 and 2 upload identical files, and then one user edits or deletes their file, this will not affect the other user's data. Users cannot tell whether their files are duplicates of someone else. From the user's perspective, it makes no difference whether or not the storage uses deduplication, except perhaps via the cost of the service. Because there is no user-perceptible difference, it would be difficult to interpret some GDPR significance into this scenario. Whose personal data is it anyway? Personal data is any information that relates to an identifiable data subject. The files here are likely to be their uploader's personal data. Thus, the uploaders would also have a right to have their uploaded files erased. In case of deduplicated storage, this would affect their logical copy. The contents of the uploaded files might also be personal data relating to a third party. Then that third party might have a right to get the file contents erased. But this right must be invoked with the data controller for that processing activity, which might be company A, company B, or the uploaders, depending on context. Which leads us to the next aspect: Company A is not responsible for handling erasures From your description, it sounds like company A is a data processor providing services on behalf of company B. In turn, B might be a processor acting on behalf of the uploaders. In any case, it seems that A would not be the data controller for these processing activities. Data subject rights like erasure must be invoked against the controller, as only the controller can understand whether such a request should be granted. The right to erasure is not absolute, and depends a lot on why that data is being processed. In particular: Personal data need not be erased if it is still necessary For example, a person might very well be the data subject of some of these files, and might then ask for erasure. But if the files are being stored because they are going to be needed as evidence in legal proceedings, the data subject can't use this GDPR right to destroy evidence. The data controller would be allowed to refuse a request in such cases. It could now happen that two different users of this deduplicated storage are storing the same file, but for entirely different purposes. Blanket deletion of all copies of a file could be quite problematic. Note that deletion is also a &quot;processing activity&quot; and needs a legal basis under the GDPR. Unexpected data loss could be a data breach. One user's erasure could be another user's reportable data breach incident. Thus, I would strongly expect such requests to be handled on a logical file level, not on the deduplicated storage level. Caveat: public access and cloned files If the (logical) file is made available to the public who can then clone or copy this file, and if the &quot;original&quot; is taken down due to an erasure request (or copyright takedown notice), it might be appropriate to remove logical clones as well. Again, this might not involve deleting the contents on the deduplicated storage level, but it might affect other users' copies. In a GDPR context, the grounds for this would be the Art 17(2) right to be forgotten: 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. But this depends crucially on who those other controllers are. If A is the sole controller, the logical files could probably be deleted directly. If B or the end users are controllers, it could be more appropriate to forward the erasure request to them.
No. Art. 17(1) GDPR lists conditions when erasure can be requested. None of the listed grounds would apply in this case. However, you might have to explain why you process the data (for moderation purposes as you explained above), and why that is lawfully. In particular Art. 5 and Art. 6 need to be taken into account. In your case, processing will be based on Art. 6(1)(f): (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Even if the data subject would be a 9 year old child, the legitimate interests of you and other forum users outweigh the objection of the data subject. Based on Art. 5, there will be a moment when the data has to be deleted. For example 1 year after the last login attempt.
Nicknames, usernames, or gamer tags are definitely personal data under the GDPR. You are operating under a very narrow definition of “identifying”, which is understandable since the definition of personal data in the GDPR isn't overly enlightening at first glance: […] 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; — GDPR Art 4(1) However, this definition does show that “identifiable” should be interpreted rather broadly. For example, indirectly identifying data is still identifying data – there doesn't even have to be a strong identifier like a name, passport number, or street address. It is also not necessary that identification enables you to determine the real world identity – identification is anything that allows you to single out a person, or to combine data into a profile of that person (compare Recitals 26 and 30). In any case, an online username or user ID is clearly an identifier and will fall under one of “a name, an identification number, […] an online identifier”. If in doubt, ask your data protection authority for guidance. You've correctly understood that you will need a legal basis to process this data, and that legitimate interest could be that legal basis. This doesn't have to be your own interest, so a community interest would be OK. You need to balance the user's rights against this interest. You have performed this balancing and have found that the interest outweighs these rights. You've noted that such leaderboards are a cultural norm and are generally expected, which strongly weighs in your favour. However, legitimate interest is not a free pass but just means an opt-out solution (right to object per Art 21). You should also inform users that the leaderboard is accessible publicly when they join your server (transparency principle per Art 5(1)(a) as detailed by the information obligations in Art 13). In particular, you should use a “message of the day” or welcome message functionality to link to your privacy policy. You should also be aware that other rights such as the right to access, erasure, and data portability apply. As an alternative to legitimate interest (opt-out) you could also consider consent (opt-in), though this results in slightly different data subject rights and is more difficult to do correctly. But I'd agree that legitimate interest is more appropriate here.
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.
a few quick notes that come to mind. As the commenters point out: DSGVO is indeed the German equivalent name to the GDPR (English term) "Imprint" isn't a privacy related topic that much, as such it's not really changed by the upcoming GDPR The GDPR changes many things, but the requirement for up front information isn't one of them - so it would've already been a rule to follow Sometimes the question who is responsible for privacy information might not be that easy to decide when you're on platforms. I take this situation as being pretty clear though. You are basically given a blank slate, you can do with that page whatever you want, and the visitor has no clue whatsoever that it might be hosted by Github. In addition to this, Github would be classified as a data processor (providing the tool) and you as the data controller who is in charge of practically everything except for the provision of the page. I hope this helps. Btw. it's not that hard anymore to write a privacy policy these days.
Artice §12(5) GDPR limits the right to access: Information provided under Articles 13 and 14 and any communication and any actions taken under Articles 15 to 22 and 34 shall be provided free of charge. Where requests from a data subject are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either: (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or (b) refuse to act on the request. The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request. A request to request the filing that you acted on their request is already excessive, repeated and frequent requests could be acted upon by taking the not-acting steps or sending an invoice before any action is taken. Also, very frequent requests with overlapping times might be answered jointly. It would be good to inform the customer in the last answer granted for free, how often they requested information and that any further answer might incur such and such fees for compiling the information.
The GDPR does not set fixed retention periods. Instead, it says data may not be kept for longer than necessary. What is necessary depends very much on the specific context of the processing activity, in particular on the purpose of processing. The GDPR allows retention for as long as necessary. For example, businesses (including financial institutions) are required to keep financial records. This requirement stems from EU member state law, which also sets specific retention periods. If a business wants to keep personal data in financial records for longer than this retention period, they can't just point to the law to authorize this processing – they must instead find a different purpose why they need to keep the data, and then find a suitable Art 6 legal basis. In some cases, retention periods might not be coupled to a fixed duration, but to certain events. For example, personal data for online accounts should typically be kept until the account is closed, which is potentially indefinite. This follows directly from the GDPR approach of limiting data storage by necessity, not by duration. All processing needs a clear purpose + a legal basis. In the context of a genealogy site, the site should analyze carefully what data they collect for what purposes. These purposes might enable potentially unlimited retention. But such processing must also be covered by a legal basis, and I doubt that the site would have a legal basis to make such storage irrevocable. If the data is collected based on Art 6(1)(a) consent, then the data can only be used as consented to, and consent can always be withdrawn in the future. If the data is collected based on Art 6(1)(b) necessity for performance of a contract, then the data can be used for compatible purposes in the sense of Art 6(4), but that would require a new legal basis (e.g. legitimate interest). If the data is collected based on Art 6(1)(f) legitimate interest, then the data can be used for Art 6(4) compatible purposes but the data subject has the Art 21 right to object to processing. While a genealogy site may have a legitimate interest in keeping supplied data in order to use it for future research, I think this is a fairly weak legitimate interest that can be easily overridden by an Art 21 objection, which in turn could require Art 17 erasure of the data. The genealogy site should also keep in mind principles like data minimisation and data protection by design and by default, so just keeping data for the off chance that it might be useful in the future is not GDPR-compliant. Data can only be collected and processed for “specified, explicit, and legitimate purposes”. The Art 89 privilege for research purposes also imposes conditions. There is a pretty big carveout in these GDPR requirements for archiving purposes in the public interest, scientific or historical research purposes, and statistical purposes. Specific rules for this exemption are given in Art 89 GDPR. The main value of this exemption is that Art 89 research purposes are always considered compatible with the purpose for which the data was originally collected (cf Art 5(1)(b)), though this might not cover data that was collected under the legal basis of consent (cf Art 6(4)). Other GDPR rules stay intact, and Art 89(1) imposes extra steps to consider: Special attention MUST be given to the data minimisation principle. If the research purpose can be achieved without identifiable data, the data MUST be anonymized. If the research purpose can be achieved with pseudonymized data, pseudonymization MUST be used. Appropriate safeguards MUST be implemented (though this just re-iterates the general requirement in Art 24). In some cases, the research purpose stands in conflict with data subject rights like the right to be informed or the right to object. If so, EU or member state law can provide exemptions from the data subject rights, but can also impose further conditions or safeguards. It is not possible to rely on the Art 89 exception without taking member state law into account. Art 89 does not modify necessity-based retention. Now on to the main question: how long can the personal data be kept for research purposes? While Art 89 research purposes allow us to extend the retention period because we have a new and compatible purpose of processing, it does not affect the general principle that data may only be kept as long as necessary for that purpose. In a scientific context, it would be common to preserve many data sets indefinitely for the purpose of enabling reproducibility of the scientific findings. A privately-run genealogy service might not benefit from Art 89. This “research” angle doesn't seem to be a good fit for a genealogy site. Such a site would typically not be collecting personal data for specific research purposes. At best, it would be operating as an archive of personal data which can be mined by future generations of researchers. But the GDPR specifically only considers archiving purposes in the public interest, which might not cover privately run archives. Archives rely on specific privileges in national laws, and severely restrict access to the information. For example, I'm leafing through the law on public archives in a German state. It forbids access for 10–100 years, depending on the date of death of the data subject and on the age of the documents. This leads me to believe that a privately run genealogy site cannot reasonably rely on the Art 89 exemption, and must instead rely on an ordinary processing purpose + corresponding Art 6 legal basis. This doesn't directly prevent indefinite storage, but means that it will be easy for a data subject to invoke their right to erasure. It is not quite enough to say “we will keep the data indefinitely”, it is also necessary to have a clear purpose for this retention.
It may be legal or it may not For example, if any of the users are in the European Union, then the GDPR applies and the person storing the information is a data controller and has legal obligations. These include, having a legitimate reason for storing them, storing them only for as long as necessary for that reason, notifying the individuals that the data is being stored and why, deleting it upon a users request etc.