I want to be forgotten according to Art. 17 GDPR. What is the correct procedure? English I want to send someone a letter: Dear Sir or Madam, In accordance with Art.15 GDPR, I ask you to inform me whether you are storing data about me. If you do this, I ask you (and third parties with whom you have shared data about me), in accordance with Art. 17 GDPR, to delete this data about me. In accordance with Art. 19 GDPR I ask you to inform me about the progress of this action. Regardless of whether you had already saved data about me or not, I ask you (and third parties with whom you have shared data about me), after you replied to me, to delete the data I submitted in this letter, that is, my address and my name, in accordance with Art. 17 GDPR. MFG Nils Lindemann I am doing this for the first time, is that correctly worded, or do I have to proceed differently in order to be forgotten? Deutsch Ich möchte jemandem einen Brief schicken: Sehr geehrte Damen und Herren, Entsprechend Art.15 DSGVO ersuche ich Sie, mir Auskunft darüber zu erteilen, ob Sie Daten über mich speichern. Falls Sie dieses tun, ersuche ich Sie (und Dritte mit denen Sie Daten über mich geteilt haben) entsprechend Art. 17 DSGVO, diese Daten über mich zu löschen. Entsprechend Art. 19 DSGVO ersuche ich sie, mich über den Fortgang dieser Aktion zu informieren. Unabhängig davon, ob sie bereits Daten über mich gespeichert hatten oder nicht, ersuche ich sie (und Dritte mit denen Sie Daten über mich geteilt haben), nachdem Sie mir geantwortet haben, die von mir in diesem Brief übermittelten Daten, sprich meine Anschrift und meinen Namen, entsprechend Art. 17 DSGVO ebenfalls zu löschen. MFG Nils Lindemann Ich mache das zum ersten Mal, ist das so korrekt formuliert, oder muss ich anders vorgehen, um vergessen zu werden?
Look at the form letters from the consumer advice center, e.g. Lower Saxony. Keep in mind that the entity may be allowed/required to keep some of your data. Anything that impacts their taxes, for starters. And your information/deletion request might also have to go on file, to mirror their record of a before-due-date deletion.
Since they have allready given you a form to fill that you have sent back with the original receipts, I will assume that the major preconditions have been fulfilled (mainly that they have asked you to come in writing and have not exclude reimbursement). This a case of civil law based on §670 BGB. Since they have not fullfilled their obligation, you must send them a reminder (Mahnung) in the form of a registered letter, requiring them to do so within a reasonable timeframe (like 10 working days after receipt of the letter). look for standard letters on this topic (Mahnungen) The letter should be descriptive in nature (i.e. a Judge, after reading a copy of the letter, will understand the whole situation). Nowadays such a letter should be sent through your local Amsgericht, so that they can certify that your copy of the letter was included in the original letter. If they don't react to this, then you must charge them. This is a basic description of the needed method. Look up the details of the process and/or for someone to assist you. Section 670 Reimbursement of expenses If the mandatary, for the purpose of performing the mandate, incurs expenses that he may consider to be necessary in the circumstances, then the mandator is obliged to make reimbursement. Sources §670 - German Civil Code (BGB) Wer trägt die Reisekosten für das Vorstellungsgespräch? - ingenieur.de
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.
Yes, there would still be an obligation to comply with erasure requests – if the data subject can be identified, and if the GDPR applies. This is a case for Art 11 GDPR: processing which does not require identification. The pastebin site is not required to collect identifying info just in order to facilitate later deletion. If the site is unable to identify the data subjects, then the data subject rights (like access, rectification, erasure, restriction, or data portability) do not apply. Other rights like the right to be informed and the right to object do remain, though. But if the data subject provides sufficient additional information that makes it possible to identify their records, then the data subject rights apply again. In practice, this is likely going to mean that anyone with access to a paste will be able to request deletion, since the site would have no ability to verify the identity of the data subject beyond the information in the paste. None of this absolves the site from implementing appropriate technical and organizational measures to ensure the security of this data. Even though the pastes might not be directly identifying, they are personal data and are far from anonymous. Common practices like numbering pastes with a sequential ID or showing recent pastes on a homepage have to be viewed critically. My go-to recommendation is to assign a cryptographically random UUIDv4 ID to the post, so that it is practically impossible for anyone to find the paste unless they were given a link by the uploader. Your idea to delete pastes after a fairly short retention period is also good. This helps with security, and it is in line with the GDPR's data minimization and storage limitation principles: data may only be kept as long as necessary for its purpose. On the other hand, quick deletion might not be in line with the purpose of these pastes – it all depends on context. You mention that this is an US-based site. If so, there's a question whether GDPR would even apply. GDPR will apply per Art 3(2) if the data controller is offering its services to people who are in Europe. Here, “offering” does not mean mere availability of the website, but that the data controller intends the service to be used by such people, in particular if the service is somehow targeted or marketed to such people.
[I'm not so well-versed on US and Russian law, thus I will limit my answer to EU law.] Your specific use of a user identifier, as I understood from your question, can be classified as personal data, so in your case, the GDPR seems to apply. This means that you need to have a) legitimate purposes to process that personal data (e.g. crash reporting) and b) a legal justification for each purpose of processing: it could be based on consent or another legitimate purpose (inc. your own legitimate interests). Consent might not be the best option for you, but it's up to you to decide. In any case, you need to assess the risks to the data subjects (your users) before you decide. How likely is it that you will get breached, and what potential harm will that cause to your users? These are some guidelines; my recommendation is that you read the law and the guidelines by the Article 29 Working Group and European Data Protection Board, or hire some good experts on this. There is no easy answer, or one size fits all solution. The GDPR isn't so hard to understand or implement, but it does require some change in mindset. With the new law, processing personal data carries a higher risk of penalties, so you should do it only when it's absolutely necessary, and with respect to the rights of your users.
GDPR forces companies and employees to keep personal data confidential and to use it only for its allowed uses. That obligation continues after the work contract ends. If the employee breaches confidentiality, it does not matter if he provides the data as a file in an USB-drive or if he provides it from memory; it is a breach of confidentiality. Access logs will help to determine which employees have had access to your data, in case a leak is suspected. The part of the question about human memory seems to come from a deep misunderstanding of how human memory works1. I can remember tomorrow something that I have totally forgotten now. Even worse, there is no telling of what can make me remember you; your name might not ring a bell but I may remember you by seeing someone walking a dog. And nobody will ever be able to tell if I have complied with any of your requests or if I am just lying. And of course, there is only one proven way to erase memories, and I am pretty sure the GDPR does not allow for the execution of employees (Disclaimer: IANAL and IANYL, check with a lawyer before murdering anyone if you have doubts). 1 The classical example: You can certainly delete a file from a disk. But just try to stop thinking about white bears
The GDPR does not mandate specific features, but that any processing is lawful and transparent etc. So what would be the purpose of storing a revision history? Once that is clear you can work out an appropriate legal basis (e.g. a legitimate interest) and then figure out which data subject rights apply. For example, let's assume that there is a security interest in keeping a revision history, so that (a) mistaken edits can be rolled back, and (b) the user can be notified of possibly unauthorized changes. This would be a legitimate interest primarily of the account holder, secondarily of you as the system operator. Of course, such security requirements have to be proportional, but I'd see that as given when there's a payment method on file. You are required to apply appropriate safety measures and to apply the data minimization principle. E.g. is it necessary to store this revision history for all eternity? No, one or two months will likely be sufficient. Who should have access to this data? If the purpose is to defend against unauthorized access, it could make sense to only give out this data on request, and otherwise only make it available to support and security staff. Now we can discuss how this interfaces with rectification or deletion. That the user is able to rectify their data themselves is very good. However, that doesn't imply a prohibition on keeping a revision history: the revision history indicates what data was stored at what point in time, and is by definition correct. This assumes that you are not using the revision history for any other purposes. When the legal basis is a legitimate interest, a request for erasure has to be preceded by (or implies) an objection (opt-out) to further processing. The objection must weighed against the legitimate interest: the objection can be denied when there are overriding grounds to continue processing. This might be the case for a security purpose: if someone with unauthorized access can just erase their traces, the purpose cannot be achieved. But perhaps the user could opt out when they create their account? Or opt-out later, but with some delay to still achieve the security purpose at the time of opt-out? In any case, erasure is required when the data is no longer necessary for its purpose – this ties back to picking an appropriate retention period, as discussed above. So it's not really possible to provide a general answer, and it really depends on the specific purpose you are trying to achieve.
The way you describe this UUID, it is pseudonymous data (see GDPR Art 4(5) and Recitals 28–29). That is, it is not directly identifying, but you have a mapping between pseudonyms and identifiers that can be used to re-identify this data. Effective pseudonymisation requires not only that the data is logically separate, but that there are effective organisational and technical measures preventing re-combination by unauthorized persons. Alongside with encryption, pseudonymisation is one of the safety measures that the GDPR explicitly requires whenever appropriate (see Art 25, Art 32). Pseudonymous data is still personal data, because you can easily re-identify the data. The PII concept is US-specific and is misleading in a GDPR context, where it is not the inherently identifying characteristics of the information that matters, but the realistic ability of the data controller to single out data subjects to whom this data relates (compare Art 4(1) and Recital 26). However, were you to irrevocably erase the UUID–email mapping, things are more tricky. There is no longer any connection with directly identifying data, so this data might be anonymous. On the other hand, such a persistent UUID still allows you to recognize/distinguish persons, so it might still be personal data. This might be the case especially when the UUID is used in long-lived cookies of website visitors, thus matching the GDPR's concept of an “online identifier”. This conclusion could be avoided by limiting reuse of UUIDs, e.g. creating a new UUID after some context-dependent appropriate duration. The GDPR does not require all data to be stored in the EU, but requires international transfers of personal data to have sufficient protections. If you're processing these data in countries without adequate legal protections (like the United States), additional safeguards have to be used. Pseudonymisation could be part of such safeguards, and has been suggested by some data protection authorities in the wake of the Schrems II ruling. However, pseudonymisation alone does not make the international transfer legal, it is more of a strategy to reduce remaining risks. I think that your systems has a good chance of being OK, but not neccessarily so. If in doubt, perform a DPIA and possibly consult your data protection authority under GDPR Art 36. If feasible, storing/processing data only in the EEA or in countries with an adequacy decision will simplify compliance. Safeguards such as pseudonymisation could be strengthened by rotating UUIDs, and by restricting access to the table with identifiers.