How to store refusal of cookie consent If a user refuses cookies on a website, then how can that website store that refusal? As far as I can tell, the GDPR requires you to store both consent to and refusal of personal data storage. But it seems to me that there is a catch 22 here: they specifically refused the storage of their data, and now the website is supposed to store that somehow. How can you store that information in a compliant way? My initial thought is to use a cookie, but would that be non-compliant? They did just refuse the storage of cookies on their device... And if I store it in a database somewhere, how am I supposed to associate that refusal with that user if I can't store personal information? According to the accepted answer to this question, you can use a userId or some such. But first of all that is in the context of consenting, not refusing, to cookies; secondly, if that identifier is associated with a user, then by definition it is personal data (right?) and therefore storing that information would be non-compliant. Regarding the storage of consent, is it enough to store that in a cookie on the user's device or do you really need to store it in a database somewhere? That really seems superfluous to me.
The so-called 'cookie law' obliges you to inform the user about the site's cookies (or use of Storage or such on the user's computer) and ask for consent for those that are not "strictly necessary for the provision of an information society service requested by the subscriber or user". It does not require you to seek consent for the use of any cookie no matter what function it has. "Strictly necessary" cookies include those necessary for the website to comply with the law. Per guidance from the Information Commissioner's Office (ICO) in the UK (see the example box), a cookie set in relation to such consent or refusal is fine - it's for compliance with the cookie law. I would expect similar guides throughout the EU. You must consider its duration or lifespan: "For example, whilst it may be technically possible to set the duration of a cookie to “31/12/9999” this would not be regarded as proportionate in any circumstances." And consider including information about it in your cookie policy or such that users can find out more if they want.
No, they can't do that. GDPR Recital 42 states: 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. Here's some more context on consent requirements.
The GDPR has a fairly broad concept of personal data: any information that relates to an identifiable person. This is far more than directly identifiable information! The concept of identifiability is further explained in Recital 26: To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. So indirectly linkable information can still be personal data. In your example, that ID can be easily re-identified with a particular person if you know who the secretary was between 2012 and 2014. It is quite likely that there are members in the club with this knowledge, or that this information can be gained from public sources like newspaper reports. Thus, you should assume that your member IDs are at most pseudonyms, but not anonymous. They are likely still personal data. However, it doesn't necessarily follow that you would have to erase everything. Art 17 comes with lots of caveats and exceptions. For example, if you are processing this personal data under a legitimate interest, and someone requests erasure, you might have overriding grounds to continue processing anyway. E.g. such a legitimate interest could involve security or auditability purposes. There might also be such a legitimate interest for keeping some history for the club, but there would have to be a decision based on the individual circumstances. Furthermore, you can of course retain data e.g. due to a legal obligation, or when this information is necessary for the establishment of or defence against legal claims. I understand your desire to keep some data around. Instead of asking “do I have to delete this?” it might be more productive to consider “under which legal basis can I keep this?”. I think you might have a legitimate interest, but you'd have to carry out a balancing test between the various interests and rights. A really problematic approach would be to hold on to de-identified data in the belief that it no longer were personal data. Such a belief is usually mistaken. True anonymization that meets the GDPR's definition is really hard, in particular because you would also have to prevent indirect identification, also by other actors than yourself. There are theoretical models that can help with anonymization, e.g. with k-anonymization methods you'd ensure that there are no unique records in the DB. But this can be tricky to apply correctly, so I'd recommend to only treat aggregate statistics as truly anonymous. In 2012, the ICO has published an anonymization code of practice (PDF). It is no longer up to date with the current legal environment (in particular since the GDPR has expanded the concept of identifiability), but it provides a good overview of both the difficulties of preventing re-identification and an overview of potential solutions.
How does GDPR work with insurers in relation to refusing information about pre-existing medical conditions? Due to it being special category data. As in, which of the "conditions for processing special category data" would apply? As far as I see, Article 9 (a) ("explicit consent") would apply. So the insurer would have to ask the customer for consent. My first thought was it would be consent-based (condition a), but under consent, it is noted that you should avoid making consent a precondition of service. Yes, that is often noted, but that is only partially true. The GDPR actually says (Article 7, emphasis mine): 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. So making consent a precondition of service can be ok, provided that the data is "necessary for the performance of that contract". Whether knowing about preexisting conditions is "necessary" for an insurance provider is something a court would have to decide, but on the face it does not seem unreasonable. Source: General Data Protection Regulation
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
Does GDPR apply if my web app stores personal data on the user's phone only? No. If you are not processing Personally Identifiable Information (PII) then the GDPR does not apply to you. This is what a web browser does when it asks to remember your username and password for this web site. You are providing a tool, the user is using that tool to process their own data. I do offer to back up the user's personal data At this point you are processing the users PII, and the GDPR does apply to you. Even though you do not have enough information to identify an individual, as it can be used with other information to identify an individual it is PII. From the ICO: Can we identify an individual indirectly from the information we have (together with other available information)? Even if you may need additional information to be able to identify someone, they may still be identifiable. That additional information may be information you already hold, or it may be information that you need to obtain from another source. When considering whether individuals can be identified, you may have to assess the means that could be used by an interested and sufficiently determined person.
The same page at the ICO website also lists what an organisation should do if they refuse to comply with a request: What should we do if we refuse to comply with a request? You must inform the individual without undue delay and within one month of receipt of the request. You should inform the individual about: the reasons you are not taking action; their right to make a complaint to the ICO or another supervisory authority; and their ability to seek to enforce this right through a judicial remedy. You should also provide this information if you request a reasonable fee or need additional information to identify the individual. Even if they did not inform you about this, the last two bullet points basically list your options. You can make a complaint (Art. 77 GDPR), or go to court (Art. 79 GDPR) requesting the online retailer to comply with your request. (Or do both). You can request a compensation for damages, but it is often difficult to prove if you have suffered (non-material) damages.
If the data controller has “reasonable doubts concerning the identity of the natural person making the request”, then “the controller may request the provision of additional information necessary to confirm the identity of the data subject” (Art 12(6) GDPR). Until the data subject provides this information, the request is paused. But what are reasonable doubts, and what additional information can the controller request? The GDPR itself provides no clear guidelines, though general principles apply – the additional information must be necessary, adequate, and proportionate for the identity conformation purpose. The controller's obligation to comply with access requests must be balanced with the controller's obligation to ensure the security of data by rejecting invalid requests. Just accepting any request without any verification would also be a breach of the GDPR. For example: If the company identifies data subjects by email address, then demonstrating control over the email address would be an appropriate verification step. But just mentioning the email address would not be enough since it could be someone else's email address. If the company provides a website where data subjects have created user accounts, then being able to log in to the account would be an appropriate verification step. In these examples, asking e.g. for government photo ID would not be appropriate because that doesn't help strengthen the link between the person making the request and the personal data being processed. Such data collection would be disproportionate and unnecessary. In contrast, if you walk into a bank and ask for a copy of your data, it would be entirely appropriate for them to ask for government ID because (a) the higher general risks warrant stronger checks, and (b) such ID will help confirm that the person making the request is indeed the proper account holder. The bank will also have been legally required to request ID when the account was originally opened, so that asking for ID as an identity verification measure during this later request won't involve collection of more data than they already have. (These examples were made up by me and are not official, but read on.) The EDPB has issued draft guidelines on the right of access 01/2022, which also discuss the issue of additional information for identity verification in sections 3.2 and 3.3. In particular, paragraphs 73-78 talk about IDs: 73. It should be emphasised that using a copy of an identity document as a part of the authentication process creates a risk for the security of personal data and may lead to unauthorised or unlawful processing, and as such it should be considered inappropriate, unless it is strictly necessary, suitable, and in line with national law. […] it is also important to note that identification by means of an identity card does not necessarily help in the online context (e.g. with the use of pseudonyms) […]. 75. In any case, information on the ID that is not necessary for confirming the identity of the data subject, […] may be blackened or hidden by the data subject before submitting it to the controller, except where national legislation requires a full unredacted copy of the identity card (see para. 77 below). […] 76. […] Example: The user Ms. Y has created an account in the online store, providing her e-mail and username. Subsequently, the account owner asks the controller for information whether it processes their personal data, and if so, asks for access to them within the scope indicated in Art. 15. The controller requests the ID of the person making request to confirm her identity. The controller's action in this case is disproportionate and leads to unnecessary data collection. […] Example: A bank customer, Mr. Y,, plans to get a consumer credit. For this purpose, Mr. Y goes to a bank branch to obtain information, including his personal data, necessary for the assessment of his creditworthiness. To verify the data subject’s identity, the consultant asks for notarised certification of his identity to be able to provide him with the required information. The controller should not require notarised confirmation of identity, unless it is strictly necessary, suitable and in line with the national law […]. Such practice exposes the requesting persons to additional costs and imposes an excessive burden on the data subjects, hampering the exercise of their right of access. 77. Without prejudice to the above general principles, under certain circumstances, verification on the basis of an ID may be a justified and proportionate measure, for example for entities processing special categories of personal data or undertaking data processing which may pose a risk for data subject (e.g. medical or health information). However, at the same time, it should be borne in mind that certain national provisions provide for restrictions on the processing of data contained in public documents, including documents confirming the identity of a person (also on the basis of Art. 87 GDPR). Restrictions on the processing of data from these documents may relate in particular to the scanning or photocopying of ID cards or processing of official personal identification numbers. To summarize: controllers can request IDs only in comparatively niche scenarios, and must then take additional safeguards to protect the sensitive document (e.g. instructing the data subject to redact parts of the ID, not making copies, and immediately deleting the ID after successful verification). A lot here comes down to national laws, which may explicitly require or forbid use of the ID in this context. The EDPB guidelines are not binding or normative, especially since this guidance is still in the public consultation phase. However, the guidelines present an overall consensus of the national data protection authorities in the EU, and the guidelines are regularly cited by courts. In practice, many controllers do ask for disproportionate amounts of data. Sometimes this seems to be an attempt to discourage data subject requests, which would clearly be non-compliant. In some cases, this is due to a narrow interpretation of “reasonable doubts” in which they try to eliminate any doubt about the identity. If the data subject and data controller cannot agree on a suitable identity verification process, then the data subject can: Art 77: lodge a complaint with a data protection authority, and/or Art 79: sue the data controller in court, both for compliance (fulfilling the request) and for compensation (if damages were suffered). It is worth noting that the data controller is responsible for being able to demonstrate compliance (Art 5(2) accountability principle), such as demonstrating the apparent reasonable doubts to a supervisory authority or to a court. When the controller requests ID, the controller has the burden of proof to show that this is compliant.