Is it allowed to Psuedonym or Soft delete the User Records in a highly complex User centric Software under GDPR? I referred this question: Under the GDPR, should transaction data be deleted on account deletion or on user request? which deals specifically with the use-case of e-commerce site. But still, there is a need for a generalized view on the confusion regarding GDPR's "Right to be Forgotten". A complex business user-centric web application might have references of user throughout and a complete hard delete (completely deleting the user from database) might create lots of havoc by breaking the referential integrity in the database and thereby in the entire application. So, is soft deleting or pseudonymizing a user a correct approach meaning the user's record won't be removed from the database completely instead, his all personal information will be updated with a pseudonym (junk phrase) in the database. On UI/UX as well instead of all personally identifiable information, a pseudonym or a generic "Deleted User" or "User #234" (just as SO do) will show up. The general reference of the User's entry in database will not even be processed/used/displayed/transmitted/sold anywhere. Please note that I am aware that GDPR is about how the data is processed and does not hold restrictions on the technicalities and designs one follows but the actual implementation and adaptions of the same are causing several severe technical constraints and the complete refactoring of the database architecture and references which happens to complicate the business application and might even need a complete restart/reset. For instance, a Software Engineer would know that an Email can be used as identity and the entire app revolves around UserManager and the cookies. Moreover, many fields that are marked Required in database models on deletion may break the app completely. So what should be the correct approach, in context of GDPR, when a user revokes his consent in a complex architectured web application?
Can you anonymise people It is valid to anonymise the data of people, instead of deleting all of the records. The principles of data protection should apply to any information concerning an identified or identifiable natural person. Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. 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. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. 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. Source As long as the person is not identifiable, then you do not need to treat the data as personal under the GDPR. You do have to inform a person once they are no longer identifiable, and be able to identify them if they provide the missing information: 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. Where, in cases referred to in paragraph 1 of this Article, the controller is able to demonstrate that it is not in a position to identify the data subject, the controller shall inform the data subject accordingly, if possible. In such cases, Articles 15 to 20 shall not apply except where the data subject, for the purpose of exercising his or her rights under those articles, provides additional information enabling his or her identification. Source The articles covered by this are: 15 - Right of Access 16 - Right to rectification 17 - Right to erasure 18 - Right to restrict processing 19 - Right to be informed 20 - Right to data portability
In principle, the data subject's right to access involves a copy of all personal data the controller holds on them. There are no time limits by default. Of course, the controller can ask a data subject to clarify their request, e.g. to focus on a particular time frame. There is an implied time limit though: personal data may only be processed/stored for as long as the data is necessary to achieve the purposes for which it was collected. Afterwards, it must be deleted. A controller with good data management will be able to limit their effort by having as short retention periods as possible for their different records. Furthermore, a lot of data is not personal data, or falls out of scope of the GDPR because it is not processed with automated means or forms part of a filing system. For example, if thousands of old invoices were archived in paper form in boxes that are only sorted by year, there might be an argument that this isn't a filing system in the sense of the GDPR and that a DSAR would not have to involve looking through all the archived invoices (compare also Art 11). In your scenario, there is a clear retention period of six years. You are asking for records about how that data might have been used further in the past. To the degree that such data is actually available, that could reasonably be personal data and should be included in a response to a DSAR. E.g. they might have information like this: “File #1234 was included in a data set that was sold to EvilCorp in 2007. The entries in File #1234 that are older than 2014 have been purged, so we do not know which entries were included in the data set. The current name on File #1234 is Dave.” This information about the sale would be personal data because it relates to you, and you are identifiable. Of course, the controller might not be set up to perform this search unless specifically asked. However, more unspecific information might not be personal data. For example: “About 70% of our files were included in a data set that was sold to EvilCorp in 2007. We no longer have records indicating whether your file was included.” Since there is no link between the sale and your personal data, I don't think it would have to be included in a DSAR response. The primary reason why you should be told about sales of personal data is that per Art 15(1)(c), you should be informed about “the recipients or categories of recipient to whom the personal data have been or will be disclosed” in a DSAR response. So when making a data subject access request, it could make sense to explicitly referencing this paragraph. So you would be interested in receiving a copy of your personal data as per Art 15 GDPR, and in particular any available information per Art 15(1)(c) GDPR about the recipients or categories of recipients to whom your personal data has been or may have been disclosed in the past. Quite likely the response will be underwhelming, e.g. by just giving a broad category such as “potential creditors who are contractually obligated to use the data only in accordance with our policies”. Whether such responses are compliant (I don't necessarily think so) will not be clear until there's a good precedent, and that would require that someone sorts this out in court.
Overview As described, only the last of these seems to be compliant ways of obtaining consent, and indeed even that is not fully compliant, although features not described might make it so. However, if there is a lawful basis for processing PI other than consent, under GDPR article 6, then there is no need to obtain consent at all, and doing so in an improper way is irrelevant. However storage of or access to local information (such as cookies) requires consent unless such storage or access is &quot;strictly necessary&quot; for providing a service which the user has requested. Relevant GDPR Provisions GDPR article 6 lists six possible lawful bases for processing personal data. These are, in summery: (a) consent; (b) processing is necessary for the performance of a contract or to takwe steps requested by the Data Subject; (c) necessary for compliance with a legal obligation; (d) to protect the vital interests of the data subject or another person (e) or the performance of a task carried out in the public interest (f) legitimate interests of the Controller The other provisions cited here apply only to PI for which the lawful basis is consent. GDPR article 7 reads: (2) If the data subject’s consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language. Any part of such a declaration which constitutes an infringement of this Regulation shall not be binding. (3) The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent. When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. GDPR Recital 32 reads: Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement. This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them. If the data subject’s consent is to be given following a request by electronic means, the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided. GDPR Recital 42 reads: ... in particular in the context of a written declaration on another matter, safeguards should ensure that the data subject is aware of the fact that and the extent to which consent is given. In accordance with Council Directive 93/13/EEC a declaration of consent pre-formulated by the controller should be provided in an intelligible and easily accessible form, using clear and plain language and it should not contain unfair terms. For consent to be informed, the data subject should be aware at least of the identity of the controller and the purposes of the processing for which the personal data are intended. Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment. GDPR Recital 43 reads: ... Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance. Analysis I will review each of the scenarios in the question in turn. Scenario 1: not allowing [a user] to use the site until the user clicks Accept. No options, just an &quot;Accept&quot; button. This does not constitute freely given consent, because: The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). It appears that the provision of a service (use of the site) is conditional on consent not needed for that service (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). the data subject has no genuine or free choice (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 2: A banner stating that &quot;By browsing the site you accept the conditions&quot;. Just an &quot;x&quot; to close the banner. Using the site is allowed while the banner is displayed. This does not constitute freely given consent, because: Consent was not &quot;given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data&quot; (Art 7(2)). The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). the data subject has no genuine or free choice (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 3: A banner with an &quot;Accept&quot; (and possibly &quot;Reject&quot;) button. No other options. Site navigation is allowed while the banner is displaying. This does not constitute freely given consent, because: The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 4: A banner with an &quot;Accept&quot;, &quot;Reject&quot; and also a &quot;Settings&quot; options where the user can fine tune the way his data is being used by the site. This might constitute freely given consent, provided that: a document is displayed or linked to that describes the kinds of PI that will be processed, and the purposes of the processing; There is some easy and obvious manner to withdraw consent, and to change the individual choices on what to consent to, after the banner has closed, or on any subsequent visit to the site; The consent section of the settings dialog must be clearly distinguished from other sections that do not deal with consent; Just where the lines must be drawn between &quot;different personal data processing operations&quot; which each requires the possibility of separate consent is not yet fully clear. And again, if the site or service does not store or otherwise process PI, or has a lawful basis for doing so other than consent, and does not store or access local information, it need not obtain consent at all, and the question of what constitutes freely given consent becomes irrelevant. Of course many sites do depend on consent as the lawful basis for much of their activity.
There are no direct penalties per GDPR. The data controller must make sure that the person making the request is the data subject, or at least authorized by the data subject. If the controller has reasonable doubts about the identity, they should request additional information for identification purposes. The controller must find a middle ground between violating the GDPR by rejecting a potentially valid request and violating the GDPR by disclosing data to potentially unauthorized recipients. Having reasonable technical and organization measures that prevent unauthorized disclosure is part of the controller's responsibilities per Art 24. What the data controller can do is to block future requests from the alleged stalker. When a request is “manifestly unfounded or excessive, in particular because of their repetitive character”, then the controller can charge a reasonable fee or refuse to act on the request (Art 12(5) GDPR). But it's up to the controller to prove that the requests are unfounded or excessive, it is not possible to reject potentially valid requests on sight. Depending on what the alleged stalker does with the obtained data, they would fall within the scope of the GDPR themselves and would probably be violating it because there is no sufficient legal basis. Also, the alleged stalker, as a data controller, would be required to inform the data subject about subsequent processing of the data per Art 14 GDPR. Attempting to obtain another person's personal data through an access request would have to be punishable by other laws. For starters, such attempts would likely involve identity theft, and successfully obtaining the data would probably be a kind of fraud.
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.
This is possibly but not necessarily fine. The data controller (the garage) is responsible for safeguarding your personal data. They must take appropriate safety measures, but this depends a lot on their own risk assessment. For example, to protect the data from being used by employees for their personal purposes, the controller might use organizational measures like a policy “you're not allowed to do that.” Many companies allow employees to use their personal devices for work purposes (BYOD). When the data controller allows this and takes appropriate safety measures, everything is perfectly fine. The company still has to make sure that the data is only processed for legal purses and deleted afterwards. Implementing a BYOD policy in a GDPR compliant manner is difficult but not impossible. A data breach has occurred when the security measures were insufficient and your data was deleted or disclosed without authorization. Your scenario would only be a breach if the company did not have a BYOD policy and the salesman used their personal phone, and arguably then only if that device is also breached. However, do not discount the alternatives: they do have a BYOD policy and the salesman is acting within their instructions the salesman was using a company-controlled device, not their personal phone If you have good reason to believe that your data was mishandled (and these alternatives do not apply), then the GDPR offers you the following remedies: You can of course complain to the data controller, especially if they have a dedicated data protection officer. You can lodge a complaint with a supervision authority, which is the ICO in the UK. They expect you to attempt to resolve your issue with the controller first. The ICO can then decide if they want to investigate the issue. You can sue them for compliance and for actual damages suffered (you have none, though). Note that all of these alternatives are more effort than they are likely worth. In particular, the garage can always correct the problem, e.g. by getting your contact info deleted from the personal device or by creating a retroactive BYOD policy.
You are processing the users IP address in order to carry out the translation to a physical location (see my comment for the technical issues with that) and an IP address is most certainly considered personal information, so yes under the GDPR you are going to need a published policy because you are both data controller and data processor. You need to inform the user of what you are doing, and you need to tell them of the legal basis for the processing (there are several under the GDPR, of which consent is only one - but in your case its going to be the easiest to justify). If you use a third party service for the location translation, you also need to inform the user of that and make available the third party services data processing policy.
The material scope of the GDPR (Article 2) is limited to the processing of personal data (including mere storage) by automated means or as part of a filing system. The question of whether your activity falls within this scope hinges on what you actually do with the data once you take possession of it. You have mentioned saving the contact information of people you have met at conferences, which could refer to simply retaining it for later use, or to the technological process of storing data in a computer. The former, if not done in any structured way (a filing system) would not fall within the scope of the GDPR. The latter, even if poorly executed, such as a photo stored on a business smartphone or a text document thrown onto your workstation's desktop, would always fall within scope as computerised data is processed &quot;by automated means&quot;. When the contact information you receive identifies a specific person, as distinct from just a corporate switchboard number and company name for example, it is personal data. When you get that personal data from the person it identifies (data subject), and you're otherwise in scope, Article 13 is invoked, requiring you to provide a list of information, &quot;at the time when personal data are obtained&quot;, unless &quot;the data subject already has the information.&quot; This is known as the right to be informed. The requirements differ when personal data are not obtained directly from the data subject. I would argue it is unreasonable to be expected to provide the information to the data subject over a cup of coffee or in a quick business card exchange, but if you start entering it into a spreadsheet or your CRM, you need to provide the required information, which may be as simple as a follow-up email thanking them for their time and letting them know you'll keep their contact details on file, along with a link to your organisation's privacy policy, assuming it covers this use, or if not, a specific privacy notice. You will of course be required to comply with other requirements such as the principles of data minimisation and identify a lawful basis, maintain adequate security by implementing technical and organisational measures, hold contracts with any third parties who process personal data on your behalf, and have a process for upholding data subject rights and responding to requests to exercise them - among others - but you should already be doing that for your other processing activities unless exempt. Additional information Edits have been made as clarifications and questions were forthcoming. Email marketing You need to consider the applicable country's implementation of Directive 2002/58/EC as amended (&quot;ePrivacy Directive&quot;). For example, in the UK you could send such messages without consent to contacts at incorporated companies or public sector bodies, but would have required consent for sole traders, private individuals, or partners in an unincorporated partnership. In Ireland, you have an exemption to consent for existing customers who were offered the opportunity to opt out when their email address was collected, but must use the email address for marketing within 12 months. Each EU country will have a different implementation of the Directive. In the Netherlands, Article 17 of the Telecommunications Act implements Directive 2003/58/EC and thus provisions for direct marketing by email. Processing by automated means Processing by automated means refers to processing of personal data in electronic, rather than manual form. All electronic processing is within the material scope of the GDPR, while only manual processing that forms or is intended to form part of a filing system is. Recital 15: The protection of natural persons should apply to the processing of personal data by automated means, as well as to manual processing, if the personal data are contained or are intended to be contained in a filing system. Art. 4(2): ‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means ICO guidance What is personal data?: The GDPR covers the processing of personal data in two ways: personal data processed wholly or partly by automated means (that is, information in electronic form); and personal data processed in a non-automated manner which forms part of, or is intended to form part of, a ‘filing system’ (that is, manual information in a filing system).