GDPR and personal data that gets crawled and ends up on other websites Data controllers must delete the users' personal data if they are asked to do so, according to the GDPR, except in some cases that don't really apply here. But what if that personal data has ended up somewhere else on the internet, maybe on a search engine like Google, or maybe in multiple places that might even be difficult to spot completely, often because some crawling bots have copied the data? I'm not talking about a data breach, where somebody gets unexpected and unauthorized access to data that is supposed to be private. I'm talking about data that is publicly displayed on a website, so anybody (crawling bots included) can access it. It could be a username, an email address, a little picture of you as an avatar, etc. So here are the questions: Who is responsible for the deletion of personal information that ended up on other websites? Should the user try to get the data deleted, or should the original website do it? For example, if a user asks me to delete some data from my website, should I also try to have it removed from Google or could I just tell the user it's none of my business and that they should go ask Google on their own? Should a user expect all this to happen as "the way internet works", or should anything be made clear in the privacy policy? For example saying "The part of your personal data that can be publicly accessed on the internet is likely to end up on other websites that we cannot control and that might not comply with the GDPR at all"?
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.
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.
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.
The intention of the GDPR is to minimize the amount of personally identifiable information (PII) you store. So the GDPR never tells you that you have to log certain events. The simplest way to make sure you comply with the GDPR is to simply not store any PII at all. But that might of course conflict with legitimate business interests and with other legal obligations you might have. So when you do store PII, then the GDPR regulates under which conditions you are allowed to store PII, for how long and what you are allowed to do with that PII. So when you receive a GDPR request from a customer to see their data, then you can say that you only have that one timestamp of their registration, because you didn't log their subsequent logins (assuming this is the truth). I hope your privacy policy says that you store all that PII on registration and that you have some good arguments why storing that information is a &quot;legitimate interest&quot; of your organization.
There is no requirement about "data" in the GDPR, so provided this is just "data", no. An empty form with fields for personal data contains no personal data. On the other hand, if the form is filled in by the user with personal data (as defined in GDPR article 4), and you receive a copy of the filled in form and process these personal data (as defined in GDPR article 4) - then the answer is: Yes. However, if you do not process the personal data (i.e. the form is just printed out on paper and filled in with a pen, and nobody except the data subject has access to the piece of paper with the filled in form - then the answer again is "no").
The GDPR has a fairly broad concept of personal data: any information that relates to an identifiable person. This is far more than directly identifiable information! The concept of identifiability is further explained in Recital 26: To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. So indirectly linkable information can still be personal data. In your example, that ID can be easily re-identified with a particular person if you know who the secretary was between 2012 and 2014. It is quite likely that there are members in the club with this knowledge, or that this information can be gained from public sources like newspaper reports. Thus, you should assume that your member IDs are at most pseudonyms, but not anonymous. They are likely still personal data. However, it doesn't necessarily follow that you would have to erase everything. Art 17 comes with lots of caveats and exceptions. For example, if you are processing this personal data under a legitimate interest, and someone requests erasure, you might have overriding grounds to continue processing anyway. E.g. such a legitimate interest could involve security or auditability purposes. There might also be such a legitimate interest for keeping some history for the club, but there would have to be a decision based on the individual circumstances. Furthermore, you can of course retain data e.g. due to a legal obligation, or when this information is necessary for the establishment of or defence against legal claims. I understand your desire to keep some data around. Instead of asking “do I have to delete this?” it might be more productive to consider “under which legal basis can I keep this?”. I think you might have a legitimate interest, but you'd have to carry out a balancing test between the various interests and rights. A really problematic approach would be to hold on to de-identified data in the belief that it no longer were personal data. Such a belief is usually mistaken. True anonymization that meets the GDPR's definition is really hard, in particular because you would also have to prevent indirect identification, also by other actors than yourself. There are theoretical models that can help with anonymization, e.g. with k-anonymization methods you'd ensure that there are no unique records in the DB. But this can be tricky to apply correctly, so I'd recommend to only treat aggregate statistics as truly anonymous. In 2012, the ICO has published an anonymization code of practice (PDF). It is no longer up to date with the current legal environment (in particular since the GDPR has expanded the concept of identifiability), but it provides a good overview of both the difficulties of preventing re-identification and an overview of potential solutions.
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.
Yes, GDPR applies: you are a data controller established/living in the UK or are offering services to people in the UK you fall under the material scope of the GDPR. The Art 2(2)(c) exemption for “purely personal or household activity” does not apply since you're offering the service to the public. You must consider GDPR compliance here. This is especially important as you are showing personal data to the public. Don't do that unless you have a very good reason, appropriate safeguards, and are clear to users how their information will be shown. On a high level, GDPR compliance involves working on the following questions: For what purpose are you processing personal data? Context: purpose limitation principle per GDPR Art 5(1)(b) What is the legal basis for processing? GDPR Art 6(1) lists the available legal bases. Here, consent, necessity for performance of a contract, or a legitimate interest could be a legal basis. They may have further obligations attached. A legitimate interest requires a balancing test that considers the data subject's rights and freedoms. Consent must fulfil the conditions per Art 7 in order to be valid. What is the minimal data necessary to achieve the purpose? Per the Art 5(1)(c) data minimisation principle, it is illegal to process personal data beyond what is necessary and adequate. You must provide data protection by design and by default per Art 25. Special categories of data per Art 9 such as health data are illegal to process outside of narrow exemptions. You must delete data once it is no longer necessary. What appropriate safeguards and security measures should you apply? Per Art 24 and 25, you are responsible for determining and implementing appropriate measures. This depends a lot on your specific context, so there's no checklist you can apply. Per Art 25(1) you must pseudonymize the processed information if that is compatible with the processing purpose. What further compliance measures do you have to consider? There are additional GDPR and non-GDPR compliance measures. From the GDPR side: Use the answers to these questions to write a privacy policy, including the information that you must provide to data subjects per Art 13. Consider whether you have to maintain a Records of Processing document per Art 30, or if you have to make a Data Protection Impact Assessment per Art 35. If you use third party services, figure out whether they are a joint controller or data processor and apply appropriate safeguards. If you have data processors, ensure that you have a contract in place that covers the items from Art 28(3). If you share data with other controllers (not processors) you need a legal basis for doing so. If you transfer data into a non-EU/EEA country (after 2020: non-UK country) you need a legal basis per Art 44 and have to cover additional items in your privacy policy. Ideally, the target country is covered by an EC adequacy decision per Art 45. For US-based companies, this is the case only when they have self-certified under the Privacy Shield framework. Non-GDPR compliance steps could include cookie consent banners, or showing a VAT ID. How can you prepare for data subject requests? Data subjects have various rights per Arts 15–23, subject to the modalities in Art 12. For example, a data subject could request that their information is erased from your website. The exact rights also depend on the legal basis you selected. You should figure out in advance how to deal with such requests.