Does the GDPR apply to the data subject&#39;s computers? In this answer to a GDPR question about processing conducted by an app on the user's computer I wrote: The GDPR only applies to data processed by you on your computer. Any processing that happens on the user's device is the user's responsibility, not yours. To which the OP replied: But could you explain why? Does some other part of GDPR specify that? I looked through the ICO website, but to my surprise I failed to find an answer. It looks as if the drafters of the GDPR did not consider the question. So: if I write a program which is run by the user on their own computer, and which is designed to process the user's personal information solely on that computer, does that processing make me a Data Controller for GDPR purposes? Answers must cite judicial rulings or regulations which directly address the question. Note in response to comments: there are other laws and regulations that might apply, but here I am only interested in the narrow question of whether the GDPR can be definitely ruled out as not applicable.
The GDPR applies regardless of where and how data is processed. But it is necessary to look at what the processing activities in question are, and who is the controller for these activities by determining their purposes and means. This argument is supported: by the absence of relevant exemptions in the GDPR by the GDPR's broad definition of the data controller by the ECJ's analysis in the Fashion ID case GDPR Exemptions For certain constellations (e.g. controller = natural person, purposes = purely personal or household activities) that processing is exempt from GDPR compliance (see GDPR Art 2(2)). However per GDPR Recital 18, the GDPR would still apply “to controllers or processors which provide the means for processing data for such personal or household activities.” For example, this means that I am able to use WhatsApp to process my friends' contact information for purely personal purposes because I'm exempt from the GDPR with respect to that processing, but Facebook is still subject to the GDPR regarding how they process personal data collected via WhatsApp. Already on the basis of the GDPR providing no exception for processing on someone else's computer, I disagree strongly with the answer you cited (and have already written a competing answer). It seems entirely counterfactual. How to figure out who the controller is. Per GDPR Art 4(7), controller is whoever “alone or jointly with others, determines the purposes and means of the processing of personal data”, although other laws might provide more specific criteria for individual purposes or means. We will return to that definition in the next section. The ICO has provided a checklist to figure out if you're a data controller or perhaps a joint controller. Some of the questions are aligned with the above definition, like “We decided what the purpose or outcome of the processing was to be”. Other questions are there as a contrast to the data processor role, e.g. “We have complete autonomy as to how the personal data is processed”. Analysis of the Fashion ID case (ECJ C-40/17) This judgement provides a detailed analysis of who the data controller is, and is therefore relevant to the question. Fashion ID had embedded a Facebook “Like” button on their website, thus causing the visitor's browser to transmit personal data to Facebook. Fashion ID asserted that they were not the data controller, since they had no control over what data was collected by the Like button and how it was subsequently used by Facebook. Fashion ID relied in part of the argument that they weren't the controller because processing happened on the visitor's computer. This ruling was made on the basis of the Data Protection Directive 95/46 which was repealed by the GDPR. However, since the DPD and GDPR have effectively identical definitions of “controller” and “processing”, the court's analysis remains highly relevant. In the following I'll “translate” all DPD references to the GDPR, in analogy to GDPR Art 94(2). The court found that Fashion ID was a data controller for the processing by the Like button, and that it was a joint controller with Facebook for this processing. However, Fashion ID was only a controller for those processing activities in which they played a part, not for subsequent processing of the data that was controlled by Facebook alone. Relevant details from the Judgment (ECLI:EU:C:2019:629): Paragraphs 65–66: The GDPR tries to achieve a high level of data protection through a broad definition of “controller”. Thus, an overly narrow interpretation that counteracts this goal is incompatible with the law. Paragraph 68: An entity is a controller when it exerts influence over the processing for its own purposes, thereby participating in determining the purposes and means of processing. Compare the GDPR Art 4(7) definition of “controller”. case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 68: “However, a natural or legal person who exerts influence over the processing of personal data, for his own purposes, and who participates, as a result, in the determination of the purposes and means of that processing, may be regarded as a controller”. Paragraphs 67, 69–70, 82: It is not necessary to have a single controller, there can be multiple joint controllers. The joint controllers can be involved to different degrees. You can be a joint controller without having access to the personal data. case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 69: “Furthermore, the joint responsibility of several actors for the same processing, under that provision, does not require each of them to have access to the personal data concerned”. case law: C-210/16 Wirtschaftsakademie Schleswig-Holstein, ECLI:EU:C:2018:388, paragraph: 38: “In any event, [GDPR] does not, where several operators are jointly responsible for the same processing, require each of them to have access to the personal data concerned.” Paragraphs 71–74: Processing can consist of many different individual activities. A controller might only be involved in some of them, and can only be a controller for those activities for which they (jointly) determine purposes and means of processing. Paragraphs 76–79: Fashion ID was able to determine the purposes and means of processing regarding data collection and transmission by the Like button. The act of embedding the button showed that they had decisive influence over the processing: without the embedding, the data processing would not have occurred. To summarize the relevant conclusions: someone is a data controller when they participate in determining the purposes and means of processing for some processing activity for joint controllers, this holds regardless of whether they have access to the data or participate in the processing itself one cannot be a controller for a processing activity for which they cannot determine purposes and means. Conclusion and application to the question This analysis reaffirms my competing answer to the cited answer that it is important to determine who the data controller is. The Fashion ID case shows that is important to perform this analysis on a fairly granular manner, on the level of individual processing activities. For processing on a data subject's computer by a program written by another provider, this means: some processing activities might be solely under the user's control, then they are the sole data controller (or might be exempt from GDPR) for some processing activities, the software developer might decide alone for which purposes and through which means the processing is carried out for other activities, the user and data controller might be joint controllers. This does not require explicit agreement but can result implicitly. This does not require that the software developer has access to the personal data undergoing processing. For example, a spreadsheet application might be used by an end user to process personal data on their own computer (or via a cloud application, with the same conclusions). We can consider different processing activities performed by the software: sorting, transforming, and other processing of the data in the spreadsheet is solely under the end users control, so they are the data controller (if they aren't exempt) collecting usage analytics (where those analytics signals are personal data for which the end user is the data subject) is solely under the software developers control uploading crash reports (where those reports contain personal data from the end user and contain contents from the currently opened spreadsheet) is more complicated. The software developer is definitely a controller. The end user has a dual role here as a data subject and a joint controller (if they aren't exempt) because the crash report processes personal data for which they are the controller.
Legal framework Per Articles 4(1) and 4(2) of the UK GDPR, your email address is most likely personal data (and certainly is once you notify the data controller that it belongs to you), and the storage and use of that data constitutes processing. In order to process your personal data, the data controller must establish at least one of the six lawful bases set out in Articles 6(1)(a) to 6(1)(f). It's quite clear that none of those lawful bases apply in this situation. Hence, the processing is unlawful. Next steps Start by making a request to the data controller under Articles 14(1) and 15(1) for the following: A copy of all personal data (including the email address) which they hold in relation to you. The purpose of them holding the data. The legal basis on which they hold the data. That they erase all personal data which they hold in relation to you, pursuant to Article 17(1)(d) (unlawful processing of data). Per Article 12(3), the data controller is required to respond &quot;without undue delay&quot;, with an upper time limit of 1 month (or 2 months if they notify you of the time extension within 1 month). Sadly, most data controllers in my experience seem to interpret this to mean that 1 month is the standard time limit, even though technically this is incorrect and the standard limit is &quot;without undue delay&quot;. Pursuant to Article 12(6) the data controller can pause the clock by asking you for additional information if they have &quot;reasonable doubts concerning [your] identity&quot;. If you send your request from the email address in question then they can't really have &quot;reasonable&quot; doubts, but be aware of this possibility in any case and respond promptly to any requests to confirm your identity so that the clock resumes. Most likely they will be unable to (correctly) provide an answer to points 2 and 3 above, since they do not have a genuine purpose or legal basis. If, after the maximum deadline has expired, they have still not responded and/or erased the data, you have two options: Complain to the ICO under Article 77(1). The ICO has the power under Article 83(5) to fine the data controller up to the higher of 4% of their turnover or £17,500,000. Complaining to the ICO is free and easy and is usually recommended over option 2. Issue a claim in the County Court for a compliance order pursuant to Article 79(1) and Section 167 of the Data Protection Act 2018. You also have the right to claim compensation for &quot;material and non-material damage&quot; (including distress) pursuant to Article 82(1) and Section 168, but this may be unrealistic in the case of a few unwanted emails. Option 2 is not free: you will need to pay a court fee and, unless you represent yourself, legal fees. There may also be additional cost risks if you lose the case. Mentioning the above two points in your request could be an effective way to persuade them to comply in the first place.
Apparently, Yes In the ECJ's Breyer decision the final conclusion reads: Article 2(a) of Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data must be interpreted as meaning that a dynamic IP address registered by an online media services provider when a person accesses a website that the provider makes accessible to the public constitutes personal data within the meaning of that provision, in relation to that provider, where the latter has the legal means which enable it to identify the data subject with additional data which the internet service provider has about that person. It is true that in this case the decision was actually under Directive 95/46/EC, not the GDPR, but the GDPR took its definition of personal Data directly from Directive 95/46/EC, so that should make no difference. It is also true that in this case the website in question was operated by the German Federal government, an not by a private individual, or by a private business. A government might have "legal means" to link an IP address with an individual that a private actor does not. However in point 23 of the decision, the Court refered to the IP addresses as: ... stored by the Federal Republic of Germany, acting in its capacity as an online media services provider, ... which seems to indicate that the same ruels were being applied to it as would have been to a private entity. Point 44 of the decision says that: The fact that the additional data necessary to identify the user of a website are held not by the online media services provider, but by that user’s internet service provider does not appear to be such as to exclude that dynamic IP addresses registered by the online media services provider constitute personal data within the meaning of Article 2(a) of Directive 95/46. In point 47, the court says that: ... in the event of cyber attacks legal channels exist so that the online media services provider is able to contact the competent authority, so that the latter can take the steps necessary to obtain that information from the internet service provider and to bring criminal proceedings. This leads the court to point 49, where it says that; Having regard to all the foregoing considerations, ... Article 2(a) of Directive 95/46 must be interpreted as meaning that a dynamic IP address registered by an online media services provider when a person accesses a website that the provider makes accessible to the public constitutes personal data within the meaning of that provision, in relation to that provider, where the latter has the legal means which enable it to identify the data subject with additional data which the internet service provider has about that person. Nothing in the decision indicates that any particular governmental authority was considered to provide the "legal means" to get an ISP to link an IP used at a particular time to an individual. In this page from Intersoft consulting it is said that: Since the definition includes “any information,” one must assume that the term “personal data” should be as broadly interpreted as possible. ... The same also applies to IP addresses. If the controller has the legal option to oblige the provider to hand over additional information which enable him to identify the user behind the IP address, this is also personal data. In this page from eugdprcompliant.com it is said that: A much discussed topic is the IP address. The GDPR states that IP addresses should be considered personal data as it enters the scope of ‘online identifiers’. Of course, in the case of a dynamic IP address – which is changed every time a person connects to a network – there has been some legitimate debate going on as to whether it can truly lead to the identification of a person or not. The conclusion is that the GDPR does consider it as such. The logic behind this decision is relatively simple. The internet service provider (ISP) has a record of the temporary dynamic IP address and knows to whom it has been assigned. A website provider has a record of the web pages accessed by a dynamic IP address (but no other data that would lead to the identification of the person). If the two pieces information would be combined, the website provider could find the identity of the person behind a certain dynamic IP address. However, the chances of this happening are small, as the ISP has to meet certain legal obligations before it can hand the data to a website provider. The conclusion is, all IP addresses should be treated as personal data, in order to be GDPR compliant. Finally the european Commission says, on this official page: Personal data is any information that relates to an identified or identifiable living individual. Different pieces of information, which collected together can lead to the identification of a particular person, also constitute personal data. ... Examples of personal data ... an Internet Protocol (IP) address; While the case law is scanty on the point, it appears that the consensus is that IP addresses, even dynamic IP addresses, will be considered to be Personal Data under the GDPR. >
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 Facebook Pixel analytics solution does not seem to support access or erasure for data subjects. While there are some GDPR compliance features, these focus on collecting consent prior to collecting data. The relationship between the pixel user and Facebook is also murky. For certain kinds of data, Facebook acts as the data processor only, and the user has all the responsibility as the data controller. For other kinds of data, Facebook and the Pixel user are joint controllers, and therefore jointly responsible. This lack of features doesn't necessarily mean that Facebook Pixel is in violation of the GDPR, since the GDPR Right to Erasure only applies under certain circumstances. However, it is really difficult to argue that a website or app that integrates Facebook Pixel would be compliant. It is also rather dubious that Facebook could be compliant themselves, since their pixels will also collect data about persons who are not Facebook members. While these problems are most apparent with the Facebook Pixel since it's explicitly intended for tracking, this problem also applies to any other embeds provided by Facebook, such as like buttons. This was the subject of the Fashion ID case, in which the ECJ determined (in 2019) that the site operator is a joint controller with regards to data collection on the website by the Facebook embed. This effectively means that third party embeds can only be loaded after the website visitor has given consent for sharing data with Facebook. The tracking of non-users by Facebook was seen as especially problematic in Belgium, where Facebook had been banned from collecting such data already in 2015 (which was upheld in 2018). Since this was pre-GDPR, FB is currently litigating whether Belgium can continue enforcing their ban. I expect that Belgium will prevail with their ban. While this has no immediate consequences for Pixel users, this would make it more likely that Pixel users could be sued or fined successfully. From an advertiser perspective, Facebook does have valuable data that make the integration of Facebook Pixel an attractive proposition. However, other analytics solutions are much easier to bring into compliance. This is ultimately a business decision: will the better understanding of your ad spend on Facebook outweigh the risk and effort of integrating the Pixel?
Think of a website that has gives no option for the users to delete what they have posted -but still the users can delete their account completely. That's easy - this is exactly how all StackExchange sites (including this one) work :-). See for example: How does deleting work? on meta.SE. Is it against the right to erasure mentioned here as a part of GDPR? No, it is not (otherwise StackExchange would be in rather big trouble). The "right to be forgotten" is subject to limitations. Most importantly, it only applies to personal data. Personal data is defined as (GDPR, art.4): any information relating to an identified or identifiable natural person (‘data subject’) If what you posted contains no personal information about you, it is not "relating to" you. The details are complicated (as usual, see e.g. The GDPR: What exactly is personal data?), but "personal data" is things about you (your name, your address, your sexual history, maybe even your IP address). On the other hand, if someone asks how to solve a programming problem, and you write an answer explaining what API to call, that answer is not personal data. In addition to that, even personal data may be retained if the data controller has a need to retain that information. This is also covered in article 4. For example, the controller may retain information "for the establishment, exercise or defence of legal claims" - otherwise you could buy something online without paying, and then ask the seller to forget about your purchases so they cannot collect the outstanding payment. So, in summary: A website will need to allow users to delete or hide personal data that they posted - such as their user profile information, or personal information in their posts. That does not mean they are allowed to delete entire posts - it is enough if personal information is redacted or anonymized. The website may be allowed to retain that information (hidden) if they can show legitimate interest - for example billing information, or posts that are the subject of a lawsuit. The StackExchange network, for example, covers this by allowing users to: disassociate posts from their account delete their account entirely (thus effectively disassociating all posts from personal information) asking a moderator for redaction of personal data
Belgium enacted an implementing law, the Act of 30th July 2018 on the protection of natural persons with regard to the processing of personal data. This, along with the GDPR, are the key legislative references that relate to your question. On 5th September 2017 the ECHR judged that it "considers that States should ensure that, when an employer takes measures to monitor employees' communications, these measures are accompanied by adequate and sufficient safeguards against abuse". This case set a precedent relevant to employee monitoring in Belgium. This is most definitely a data protection or privacy law matter and the DPO should be consulted. If they have to do research, that shouldn't be your concern as that is their job. The company must support the DPO in what they need to do that job, as such is literally written into the GDPR. Furthermore, in this case it would, by my evaluation, be necessary to conduct a Data Protection Impact Assessment (DPIA) for the monitoring activity, and if one has been done, it should document the recommendations and requirements or what is already in place. You as an individual may also ask a question of the Data Protection Authority: (NL) https://www.gegevensbeschermingsautoriteit.be/verzoek-klacht-indienen (FR) https://www.autoriteprotectiondonnees.be/introduire-une-requete-une-plainte You might ask them about your position and liability as an employee, but I would be more concerned, if I were you, with verifying that your actions are above board rather than trying to cover your ass just in case they aren't. Do the right thing, even if that means questioning the direction you've been given. AD logons still identify the person logging on, and may include source IP, which is specifically listed in the GDPR as within the scope of 'personal data'. So while there may be a legitimate need to process such data, it needs to be gone about in the right way. Actions taken by an employee are taken by the organisation in terms of processing personal data, so whatever you are asked or ordered to do, will be done by the company. If you are being offered no legal justification for doing so, you might document the direction you are given and question it respectfully, pointing out that if found to be unlawful, it is the company that would be in trouble, all while knowing that should there be for example an unfair dismissal, you have a record of who asked you to do what, how you challenged or questioned it, and what was the outcome.
Overview The GDPR requires data controllers (DCs) to exercise reasonable care when responding to an access, modification, or deletion request, to ensure that it comes from the actual Data Subject (person whose data is involved, here a DS). The GDPR does not specify just what methods must or may be used to ensure that an access (or other) request comes from the DS. It does say, in Article 12, that &quot;additional information&quot; may be requested from the DS by the DC for this purpose that is &quot;necessary to confirm the identity&quot; of the DS. If a DC receives data for identification purposes, it must be used only for those purposes, and retained no longer than needed. Personal Data (PD) in general must be limited according to article 5, so that data is used only for the purposes it was collected for, retained for no longer than needed, adn appropriately secured against unauthorized use or access. The DC is responsible for adhering to these limitations. Recitals 57, 59, and 77 (quoted below) confirm this, and discuss identification. If a DC violates these restrictions, it is subject to the same enforcement as it would be for violating any other GDPR provision. If a DS thinks the data requested to support identification of the DS is excessive, the DS may first complain to the DC, and then to the relevant supervisory authority if the response from the DC is not acceptable (allow at least 1 month for a response). But perhaps knowing that the GDPR forbids the DC from distributing or using this data except for the purpose it was collected, that is, to identify the DS, and from retaining it longer than need be, might offer some reassurance. A DS could also ask the DC what is the minimum data needed for identification, and redact data beyond this. The DC might need more than name and address, but not all that is on a bank statement or other ID document. GDPR Sources Article 12 (section 6) of the GDPR reads: Without prejudice to Article 11, where the controller has reasonable doubts concerning the identity of the natural person making the request referred to in Articles 15 to 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject. That includes access requests. Paragraph 1 of Article 11 reads: If the purposes for which a controller processes personal data do not or do no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with this Regulation. Paragraph 1(b) of article 5 specifies that personal data shall be : collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; Paragraph 1(c) of art 5 specifies that such data shall be: limited to what is necessary in relation to the purposes for which they are processed ... Paragraph 1(e) of art 5 specifies that such data shall be; kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; [emphasis added] Paragraph 1(f) of art 5 further specifies that such data shall be: processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing Recital 59 reads: Modalities should be provided for facilitating the exercise of the data subject’s rights under this Regulation, including mechanisms to request and, if applicable, obtain, free of charge, in particular, access to and rectification or erasure of personal data and the exercise of the right to object. The controller should also provide means for requests to be made electronically, especially where personal data are processed by electronic means. The controller should be obliged to respond to requests from the data subject without undue delay and at the latest within one month and to give reasons where the controller does not intend to comply with any such requests. Recital 57 reads: If the personal data processed by a controller do not permit the controller to identify a natural person, the data controller should not be obliged to acquire additional information in order to identify the data subject for the sole purpose of complying with any provision of this Regulation. However, the controller should not refuse to take additional information provided by the data subject in order to support the exercise of his or her rights. 3Identification should include the digital identification of a data subject, for example through authentication mechanism such as the same credentials, used by the data subject to log-in to the on-line service offered by the data controller. Recital 77 reads: Guidance on the implementation of appropriate measures and on the demonstration of compliance by the controller or the processor, especially as regards the identification of the risk related to the processing, their assessment in terms of origin, nature, likelihood and severity, and the identification of best practices to mitigate the risk, could be provided in particular by means of approved codes of conduct, approved certifications, guidelines provided by the Board or indications provided by a data protection officer. The Board may also issue guidelines on processing operations that are considered to be unlikely to result in a high risk to the rights and freedoms of natural persons and indicate what measures may be sufficient in such cases to address such risk.