Do you need to remove a customer&#39;s data for GDPR or the like, if that data has been anonymized and used as part of an aggregate? Say I have a SaaS which collects users financial information, or location information, or other random information, and aggregates it in an anonymous way. Say for example I present to my users &quot;there are ~1000 people that live in California that have a website&quot;, or &quot;90% of website owners have visited New York&quot;, or those kinds of things. Then say that an organization leaves the SaaS and wants their data removed. Am I to actually literally update the aggregated data with -1 user, or let's say -100 organization members, so it's calculations are based on 1 or 100 less users? That way, if 100 users left the SaaS and deleted their data, it would now maybe say &quot;89% of website owners have visited New York&quot;, or however the aggregate was recomputed. I ask this because, the way we are generating aggregate data currently is by querying over anonymized &quot;data points&quot;. The location might be kept, or the fact they owned a website, or some financial data point, but the organization or user name (and database ID) is deleted from the anonymized data point. Then we do a SQL query on these points to compute the aggregated statistics. But the question is, if some organization or user asks to &quot;remove their data&quot;, what are we to do with these &quot;data points&quot;, since they are anonymized? We can't really delete them because they are anonymized, and we don't know where they came from (since org/user name is deleted on them, for example). So they ask to delete data, but we don't delete this data because we have no way to map it back to their org? Is that acceptable? Or should we be keeping track of the org/user &quot;under the hood&quot;, (not showing the personal information in the aggregate reports to customers though), and that way when they ask to delete their data, we can actually delete their data points from our analytics system? The problem is, we want to build a data set of some kind, and so are keeping everything anonymized from the get go, but there is no way to actually know how to delete their data if they asked, but we did still technically have gained from their signing up and adding their data points originally. So I am not sure what to do. At a high level, what should you do for stringent &quot;data privacy&quot; laws (like GDPR, or the California data privacy one, or others). I don't need to know the exact specific law requirements, but just at a high level generally how it would work in this situation. Note, when the user signs up, and they &quot;agree to terms&quot;, the terms say we are going to collect their data and use it in these sorts of aggregated reports.
Among other things, GDPR regulates what you may do with the data within your systems. You can use it for the contracted purpose, or in accordance to law, or with informed and revokable consent, or for some other enumerated purposes. Even with consent, you have to take security measures to avoid the misuse of the data. Remember the software shrink-wrap licenses? &quot;By opening the package, you agree to the terms inside.&quot; GDPR makes the equivalent in the cloud world impossible. You have to document exactly what you do with the data, and for any use that is not necessary to perform the service the customer can opt out. In the scenario you describe, it is possible that you are not the data controller under GDPR but the data processor, and that you have a duty to keep the data from separate controllers apart. And delete any batch at the end of contract. If you want to do this professionally, you need to consult a lawyer for your specific plans.
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.
In answer to your questions, always get potential clients to sign a contract which covers the GDPR personal data processing requirements at a minimum, prior to giving them a copy of a consultant resume to retain. If you were sat in a meeting with them it is much simpler to record in your logs that the client had sight of the resume but was not left a copy of it in any format, than it is to keep track of which clients have a copy of which data and chasing up to ensure it is erased/destroyed when appropriate. To ensure clients treat the resumes as confidential, make sure they are labelled in the header and footer as confidential. They could also be kept in an envelope clearly marked confidential. There could also be a footnote in small print that informs anyone with a copy, who the data controller is, and that processing is strictly subject to the terms of the 'client contract' or whatever you call it, and that it should be returned or shredded within X days of receipt for example. If you have a computer system generate these it could even specify the client's name and the specific date it should be shredded by. Your notice could include a reminder that the personal data is protected under the E.U. General Data Protection Regulation (GDPR) 2016 and that (client name) as a data processor could be held liable in the event of unauthorised disclosure or processing, if they act outside or contrary to lawful instructions of the data controller. Whilst this won't enforce responsible processing at least it will ensure that your business has done its best to ensure any recipients are fully aware of their responsibilities to protect the information and it would be very difficult for a client to claim they weren't aware the information was confidential or that they had legally binding responsibilities to protect it. It's also worth noting that simply sending CV's/resumes (or other personal data) out via email (unless suitably encrypted) would not meet the requirement in GDPR recital 39 for personal data to be "processed in a manner that ensures appropriate security and confidentiality of the personal data, including for preventing unauthorised access to or use of personal data and the equipment used for the processing." Email technology whilst convenient does not offer any guarantees regarding privacy and confidentiality, therefore instead of sending resumes as email attachments it might be better to use a web-based extranet system which authenticates users before granting access to view resumes. Emails could just let clients know there is a new resume or X number of resumes waiting for them to review and give them a link/button to login. The records of processing activities are in GDPR Article 30 on page 50, and it does not specify a retention period nor that we can choose the retention period, but simply states that data controllers make the records available to the supervisory authority when requested to do so - this may imply indefinite retention of processing records even beyond the life of the processing system (e.g. discontinued products/services), however we may need to await further clarification on this issue from supervisory authorities to be sure.
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.
Question 1. Are technical identifiers personal data? Yes. If they identify a person. For example an IP Address is considered personal data, because a person or household can be identified by an IP. Yes, I know that technically there are a lot of exceptions. But in general, if you have an IP, you can identify the subscriber given the right databases. So if your identifier, lets say a generated GUID, identifies a customer or something the customer can be linked to, it is personal data. Question 2. Can technical identifiers be stored in measurement devices? Just because something is personal data, does not mean you are forbidden from using it. As long as you need it to do your job, you can store it. The internet would not work, if everybody was forbidden from storing any IP address. So to summarize it: yes, it is personal data since it identifies a subscriber. However, it is needed for the job your subscriber asked you to do. So for as long as the job takes, it is legal to store it. Once your job is done, you would be required to delete it. But consent trumps everything. If your subscriber consents to you keeping all data of such incidents to improve your network and handle future incidents better, then it's legal. Just let them sign it with your other legal paperwork. Done. No problem. You could just periodically delete all records that have no consent for long term storage beyond the current incident. Lets say every 24h or 48h. You should get the details on the wording of the paperwork and the period that it is legal to keep the data as &quot;current incedent related&quot; from your data protection officer or legal department.
Is X considered personal data? Can you use X to directly or indirectly identify a natural person? In the data to which you have access can X be related to an identifiable natural person? If you answer yes to either of those questions then X is personal data. Article 4(1): ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); 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; Scenario 1: you want to count each user agent that comes to your site, that's the only data you have, then the user agent is not personal data (it cannot be used to identify someone - unless it has a name and address etc, which seems highly unlikely - and you cannot relate it to anyone). Scenario 2: you have customer records with names, addresses etc (clearly personal data) and want to record each customer's user agent then the user agent is personal data (it relates to the identifiable natural person). Scenario 3: in one dataset you record that a user agent was associated with order ID 123456 and in another dataset you record that order ID 123456 was for John Smith (plus address etc), then the user agent is personal data (it relates to the identifiable natural person). Is this considered storing personal data? If X is personal data. Do I need user's consent to record X? If you want to record X and X is personal data, then you must have an Article 6 lawful basis for recording X. Consent is one of the six lawful bases. 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. Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks.
The key issue here is the unauthorized collection of video thumbnails, not the use of cloud services. Under GDPR, every personal data processing activity has one or more controllers who are responsible for the activity, and every such activity needs a “legal basis”. With such cameras, the operator will typically be a controller, since they determine the purposes for which this camera is used. In this scenario, the operators – as part of their responsibility to conduct the data processing activity in a GDPR-compliant manner – had disabled any cloud features provided by the camera manufacturer. Despite this configuration, the camera manufacturer collected thumbnails and uploaded them to servers under their control. So, we likely have two distinct issues at hand: the camera manufacturer misled its customers about the privacy settings of the cameras. This is not necessarily a GDPR issue by itself. the manufacturer performed data processing activities in contravention of various aspects of the GDPR. Relevant aspects of the GDPR that might have been violated: the manufacturer did not have an Art 6 GDPR legal basis for this processing activity, such as a “legitimate interest” the manufacturer did not provide information per Art 13 GDPR to the people being monitored this way even if the cloud-based thumbnail processing were intended, this could be a violation against the Art 25 obligation to ensure “data protection by design and by default” depending on how the cloud storage services were configured, there might be violations against the Art 28 responsibility to contractually bind such vendors as data processors, or against the Chapter V rules on international data transfers Different actors might have different remedies against this violations: buyers of the camera might have remedies under consumer protection and product liability laws against the manufacturer data subjects of the illegal processing activity have remedies under the GDPR they can exercise their data subject rights against the data controllers, such as erasure of the thumbnails. However, this will be difficult to exercise in practice since the manufacturer will not have identifying information, and would then be free from having to fulfil certain data subject requests per Art 11 GDPR. they can lodge a complaint with a responsible supervisory authority, which would be the data protection agency in their EU/EEA member state (or the ICO in the UK). The EDPS is irrelevant here, since it is only the internal supervision authority for EU institutions. The competent supervisory authorities can levy fines. they can sue the data controllers, both for compliance (e.g. deleting unauthorized thumbnails) and for damages, if any were suffered. However, immaterial damages awarded for GDPR violations are typically fairly low, if they are recognized by the court at all. the right to judicial remedy (sue the controllers in court) and to lodge a complaint are independent. They largely pursue different remedies. Both can be used to seek compliance, but only supervisory authorities can impose fines, and only direct lawsuits by the data subjects can seek damages.
There are a number of misconceptions here. GDPR does not generally impose blanket bans, but things get dicey if you're using data in a way that is not strictly necessary. Consent (freely given opt-in) is a way to continue nevertheless. A website without ads, tracking, or potentially tracking embedded content can probably work without having to ask for consent. Under the GDPR, every processing of personal data needs a purpose. This purpose must be covered by a legal basis. Some processing might be legally mandated or required by a contract with the data subject. It's also possible to base processing on a legitimate interest, but this requires a balancing test that also considers the data subject's rights and interests. As a last resort, consent can be an appropriate legal basis, but this comes with additional restrictions. Once you have a clear purpose that is covered by a legal basis, you can process the minimum data necessary to achieve the purpose. Sometimes, laws prescribe a particular legal basis. This is the case for cookies. You can use cookies (and similar technologies that access information on the end user's device) as strictly necessary to provide a service explicitly requested by the user. If you go beyond that, the ePrivacy Directive says you must obtain consent first. So for example, session cookies, shopping carts, or cookies that remember a “dark mode” preference are all perfectly fine because they are strictly necessary for something the user is trying to do. Also, you can use cookies to remember if the user gave or declined consent. On the other hand, analytics or tracking cookies are not necessary and require consent. If a website embeds third party content, this discloses personal data such as IP addresses to the third party. This disclosure requires a legal basis, most likely consent. There is case law about this regarding Facebook Like buttons on a page (→ Fashion ID case) but the same principle can be generalized to embedded Tweets or Youtube videos, images, or JavaScript files. A common way to handle this is to replace the embedded content with a placeholder, and to only load the embed once the user gives consent. But not all other domains or services are “third party” in the sense of the GDPR. When you engage a company to act as a data processor on your behalf, they are contractually bound to only use the data as instructed by you, and not for their own purposes. The GDPR allows you to outsource processing activities such as serving web content, as long as you have a suitable contract in place. Such “data processing agreements” are common for hosting providers or CDNs. When consent is to be used as a legal basis, it's important to consider the various conditions that the GDPR imposes (see Art 7 GDPR). The core principle is that consent must be freely given. You cannot make access to a site conditional on consent, so a naïve cookie wall or captive portal will be non-compliant. It's fine to force a choice, but “no” MUST be valid and possible. That consent is freely given also means that you must provide enough context for the user to make an informed decision, that the user must give consent through an unambiguous, affirmative action (consent is never the default), and that consent must be specific for a particular purpose (you can't bundle unrelated purposes). That is why modern consent management tools have multiple layers of information and allow the user to give consent for individual purposes (e.g. yes to analytics but no to ad personalization). In your particular context, you could proceed as follows: Figure out what kind of external content you're currently including. Can you enter into a data processing agreement with the external providers? If so, sign that. Can you host the content locally? This can be an easy solution except for video streams. Careful: copyright concerns might make this impossible. Can you replace the content with placeholders that only load if and when the user gives consent? That way, the rest of your site remains accessible without annoying consent walls. If the third party content is an unavoidable and essential part of your page, use an interstitial to inform the user of the risks before they proceed.