GDPR: What is the legal situation on documenting cases of &quot;Right to be forgotten&quot; claims? I wasnt able to find an explanation inside the GDPR whether a data privacy officer (or similar responsible) is allowed or required to document cases where individuals claimed the right to be forgotten. Is it against the law to document the individual cases? edit for clarification: Such as "on Feb 26th Mr. John Doe inquired via e-Mail and requested to purge all his data". Now there is another data set about John Doe, documenting his deletion request, whereas he initially inquired to have his data erased. Instead of being forgotten, he is now remembered in one extra data collection. /edit On one hand documenting the process allows a company to prove they obeyed the law and the request, should this be questioned later on by the individual. I can even imagine a former employee first claiming his right to be forgotten, and then - a week after getting the confirmation - claiming his right to receive a resumee (a right in existense in Germany), which a company would not be able to fulfill as it hasnt got any data to base the resumee on. In case they do not have documentation, that the former employee requested to be forgotten, they cannot tell this. On the other hand documenting such cases is 180 degree against the original request to be forgotten, as the individual ends up being stored in yet another data processing process.
The "right to be forgotten" is not absolute. It is subject (Art. 17) to certain conditions, in particular the absence of "overriding legitimate grounds for the processing" (1(c)). 3(b) explicitly exempts data controllers from the erasure where needed "for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject". I can even imagine a former employee first claiming his right to be forgotten, and then - a week after getting the confirmation - claiming his right to receive a resumee (a right in existense in Germany), which a company would not be able to fulfill as it hasnt got any data to base the resumee on. If the "right to receive a resumee" indeed exists in Germany and employers need to comply with it, that would be perfectly legitimate ground to only partially fulfil the request to be forgotten⁠ — forget everything but the resume. Is it against the law to document these cases? If you document "On 27 February 2020 John Smith requested to be forgotten so we deleted or anonymised all his records", you will effectively NOT forget him. If you actually had to forget him, it will therefore be against the law to document your forgetting that way.
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.
Is there any sources of information where extraction of data from a closed source application and provided to a data subject is further defined? No, the GDPR is based on &quot;general principles&quot; and does not concern itself with implementation details for such matters. It's possible there's EU case law on this, but I can't find any. Am I within my rights to insist on this, even if to comply they would have to do some software development? Yes you can demand it, but they don't have to comply with your demand. The information only has to be provided in a &quot;concise, intelligible and easily accessible form, using clear and plain language.&quot; and they only have to provide the information electronically where &quot;reasonably practical&quot; to do so, and they only have to take &quot;reasonable steps&quot; to do all this per Section 52 of the Data Protection Act 2018 which implements GDPR into UK law. You can complain to the Information Commissioner's Office, and they will decide if Section 52 has been complied with or not. 52 Form of provision of information etc (1) The controller must take reasonable steps to ensure that any information that is required by this Chapter to be provided to the data subject is provided in a concise, intelligible and easily accessible form, using clear and plain language. (2) Subject to subsection (3), the information may be provided in any form, including electronic form. (3) Where information is provided in response to a request by the data subject under [the Right of access by the data subject], the controller must provide the information in the same form as the request where it is practicable to do so.
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.
There are a number of misconceptions in this question. Firstly, the regulatory environment did not drastically change when the GDPR came into force in 2018. Previously, each EU member state had its own laws implementing the 95/46/EC Data Protection Directive. The GDPR harmonizes these laws, and replaces them with a single EU-wide law. However, the GDPR is largely identical with the DPD. In particular, both laws have the same definition of a controller. Secondly, the data controller is not a position to be designated, like a Data Protection Officer would be. A controller is whoever – alone or jointly with others – determines the purposes and means of processing of personal data. Whether someone can decide the purposes of processing is a matter of fact, not a matter of formalities. There can be more than one controller. Most likely, the institution hosting the research group is the controller. For individual researchers, the important aspect would be to demonstrate that they've fully complied with their institution's procedures at all times – that they acted as agents of the controller, not as controllers of their own. The institution might have a more difficult time mounting the defense if its technical and organizational measures were inadequate. For example, keeping an unattended server running for five years without security updates borders on gross negligence – so there should have been a procedure so that each system has a clear point of contact who is responsible for administrating the system. The controller should also have inventoried its systems and processing activities at the latest in preparation of GDPR, e.g. for an Art 30 record of processing activities. Your question suggests that no one could be at fault because no one did anything, but inaction and failure to fulfil responsibilities can also be a violation of law. If the institution wasn't convinced that this server was GDPR-compliant, the correct approach would have been to shut the server down, not to continue the processing of personal data. Of course, the controller may be able to demonstrate that this breach of GDPR was very minor, for example because the personal data was pseudonymized and because other technical measures (like firewalls) would have prevented unauthorized access.
It depends. Can the data controller or another person, with &quot;means reasonably likely to be used,&quot; (see clause 26 of the preamble of the GDPR) use that data alone or in combination with other data to identify a natural person? If yes, it is personal data within the meaning of the GDPR. If no, it is not personal data within the meaning of the GDPR. Anonymous data is not subject to the GDPR. &quot;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. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes.&quot; Assigning an unique alphanumeric code to a thing does not necessarily make the code and/or the thing &quot;personal data&quot;. But if you have a set of data that is or can be linked by the unique alphanumeric code (e.g. as a primary key in a set of tables) and you can use it to identify a person, then it is personal data. Either way, to be GDPR-compliant / to mitigate risk you should make some kind of record to reflect that process of thinking and what you decided. And if the answer is Yes, it is personal data, then you should record your &quot;lawful basis&quot; for processing the data and how you decided that.
How can I truly say that I 'consent' to data collection and processing when I am coerced, so to speak, by the threat of failing my courses if I do not use this novel software? There is no need for you to "consent". Consent is just one of the reasons that allows a data processor to collect your data. There are other reasons that allows the data processor to capture your data. In this case, it seems of application the "legitimate interest clause", as it is in your university's legitimate interest to capture your activity in order to evaluate you. Of course, that covers only the data collected that is relevant to that interest. They will certainly capture your identity and your answers, they may log your sessions and may try to gather some data to detect if you are somehow cheating, but they would not be allowed to check which are your favorite pornhub videos because that is not relevant for the university's legitimate interest. Art. 6 of the GDPR states: Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) 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; (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. This page also provides some in-depth analysis
I'm pretty sure that under GDPR, you can indeed request them to send all data they have on you. If it's a complex request, they may charge you something like £10. If they have a lot of data on you, they may list the categories of data they have and ask you to pick one, rather than them having to collect and send everything. They should respond within one month, but iirc in the UK implementation, they can inform you (within that month) that they will respond within three months instead. For the rest, I only know current Dutch law. GDPR is not that different from what we already had (in general terms) and in many cases it even extends it. Under our law (WBP), you can also request a correction of the data in case it is incorrect, or deletion if they no longer need it for the purpose for which it was collected and stored. I don't really know how that works out in practice though, as Facebook can of course claim that "being able to connect you to your friends when you sign up for WhatsApp or Facebook with that number" is a legitimate purpose (in their eyes). They might also not have your full name and therefore not be able to connect your data to your request. Or, perhaps, they have only your full name (and there are probably more people with your name), so they'll have a hard time verifying that it's really your data which they would be handing over or deleting. The company is required to verify your identity before acting on your request. How they implement that is up to them. Under Dutch law, if I remember correctly, any data that can be connected to your person by any party is personally identifiable information (PII). While Facebook might not be able to find who's behind a phone number, your carrier most certainly can. Therefore, the data falls under PII protection laws and they will have to implement a way to verify you and get you your data. Finally, whether your local laws apply to Facebook, I don't know exactly. There's lots of information on this though, so you should be able to find it. Generally, countries say that if something happened within their territory (e.g. you signed up for WhatsApp while in the UK), their law applies. Companies, I've read, will instead try to claim that their main office is in SomeCountry and therefore SomeCountry's laws apply. But I'm pretty sure you'll be able to find a Facebook office somewhere where GDPR applies, so that's probably fine. While not an exact answer and while I am not sure about everything, I hope this gave you some pointers to go on!