GDPR with refusing medical information 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? https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/special-category-data/ 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. The only other one that slightly fits is condition h) in "the provision of health or social care or treatment or the management of health or social care systems" But its a bit of a stretch. Are they likely to make consent a pre-condition of service anyway, or is there a more appropriate way?
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
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.
GDPR defines consent like this in Art 4(11): ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her; Further conditions on consent are given in Art 7 GDPR. For you, the important aspects are: Consent must involve an affirmative action (opt-in). Thus, consent cannot be the default and must not be pre-selected. The Planet49 judgement provides relevant case law on this. Consent must be an unambiguous indication of the data subject's wishes. Consent must be informed. This requires access to the full privacy policy. Abuse is discouraged because the data controller has burden of proof that valid consent was collected (see Art 7(1)). How does the RedHat consent tool measure up? The consent appears to require an affirmative action and seems unambiguous: no option is pre-selected, and you need to click on “Out” or “In”. The selected option is then highlighted. However, I agree that the radio buttons are not entirely clear once a selection has been made. I also agree with you that the terms “Out” and “In” are not self-explanatory. They rely on the user knowing the terms “opt-out” and “opt-in”. This could indicate that the user's action isn't unambiguous. That the privacy policy page also shows a cookie consent popup could mean that consent isn't sufficiently informed. So together, this isn't a particularly good design for a cookie consent tool. There are some potentially fatal problems that could render the consent invalid. However, it isn't obviously non-compliant – I have seen far worse.
I believe in this case, your company (OrgX) is a data processor and your customer's organization (OrgY) is the data controller. OrgY is responsible for establishing a lawful basis for sending you (OrgX) the personal data for their employees. Note that consent is just one of six lawful bases outlined in article 6(1). I'm no expert, but I believe OrgY's admin can claim they have a legitimate interest in sending their employee's personal data for training sake. In either case, the data processor is not responsible for establishing the lawful basis for processing. Of course, data processors aren't completely off the hook. GDPR outlines specific requirements for data processors (see chapter 4, particularly article 28).
Yes, you still need consent (opt-in). Cookies usually require consent, but not always. There are two relevant laws at play here: GDPR makes general rules about the processing of personal data, and ePrivacy has specific rules about cookies and similar technologies, regardless of whether the cookies involve personal data. The ePrivacy directive was implemented in your EU member state (or the UK) in national law. The national laws contain the authoritative rules on this matter. But in general: Accessing or storing any information (such as cookies) on the end user's device requires consent. Consent is defined by the GDPR. You do not need consent if the access/storage is strictly necessary for a service explicitly requested by the user (“functional cookies”). Using cookies to store site preferences such as user language is strictly necessary for a service explicitly requested by the user, so you do not need consent for this. You must still make your use of cookies transparent to the user. Setting cookies for marketing purposes is not strictly necessary to provide the service, so you always require consent for them. Registered users don't automatically give consent. You now raise the interesting question if this is also the case if the user is already registered. Yes, you still need consent (opt-in). This is due to the way how the GDPR defines “consent”. Consent is not general or vague agreement. Agreement with your terms of service or privacy policy is not consent in the sense of the GDPR. Instead, consent is defined in Art 4(11) GDPR to be (emphasis mine): any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her Art 7 GDPR adds further conditions for consent. (1) You are responsible for demonstrating that the user has given valid consent. (2) The request for consent should be clearly distinguishable from other matters (i.e. not buried in a larger document) and should be presented “in an intelligible and easily accessible form, using clear and plain language.” (3) Withdrawing consent must be as easy as giving it. (4) In general, you cannot make access to a service conditional on unrelated consent. I.e. you can't force your users to consent to marketing cookies in order to use the app. The users must have an actual choice, or the consent isn't freely given. Supervisory authorities have produced extensive guidance on the matter of consent. If you're in the UK, consider the ICO Guide to Consent and Guidance on the use of cookies and similar technologies. If you're in the EU/EEA, consider the EDPB Guidelines 05/2020 on Consent (PDF). To summarize why agreement with your terms of service is not consent to marketing cookies: Agreement to such large documents is not sufficiently specific. The consent would not be sufficiently informed. You cannot expect users to actually read all your legal documentation. You must present information in an intelligible manner, possibly with multiple layers (compare WP29 Guidelines on Transparency, endorsed by EDPB). Agreement to your terms of service is not an unambiguous indication that the user wants these cookies. If consent to marketing cookies is a condition of using your service, the consent is likely invalid. The consequence is that cookie consent is usually obtained via separate consent management tools that provide detailed explanations about different categories of cookies, and let the user select which specifically categories of cookies they want to consent to, if any. Outside of cookies, consent is just one legal basis among many. In this context, you might ask “if getting consent is so difficult, but GDPR requires that I have consent, how does that work?” It is a common misconception that the GDPR requires consent for everything – the ePrivacy requirement that most cookies need consent is one of the exceptions. In general, GDPR offers a choice of six categories of legal bases for processing in Art 6 GDPR, and consent is just one of them. In many cases, an online service will process personal data because it is necessary to fulfil a contract with the user, or because there is a legitimate interest for the processing (and the legitimate interest outweighs the user's interests). For example, reasonable security measures such as keeping logfiles can be based on a legitimate interest and do not require consent.
Whether GDPR applies does not depend on the country of residence. Instead, GDPR applies to a non-EU site or service if the data controller offers products or services to people in the EU (see Art 3(2) GDPR). This depends solely on the behaviour and intent of the data controller / the provider of the website – compare also the discussion of the “targeting criterion” in EDPB guidelines 3/2018 on the territorial scope of the GDPR. While your proposed measures might not be entirely ineffective (in that they document an intent to not serve people in the EU), they are both unnecessarily restrictive and overly lax. For example, they would unnecessarily prevent EU tourists in the US from registering but would nevertheless allow US tourists in the EU. For the targeting criterion, it matters whether the data subject is in the EU at the time of the offer, not at all what their residency is. Even if a person who is currently in the EU registers with your service, that doesn't necessarily mean that you are targeting people in the EU. Instead of implementing signup restrictions, a better strategy might be to clarify in the copy on your website that you are only targeting the domestic US market, not the European market with your services. I have discussed this in more detail in an answer to “How can you block GDPR users from US based sites?” If you have a site where GDPR doesn't apply, and you receive a GDPR data subject request, you shouldn't deny it on the basis that the user must have lied – instead you can deny it on the basis that GDPR just doesn't apply to you.
GDPR does not require consent. It requires a legal basis. Consent is only one legal basis among many. Some other legal bases are: legitimate interest (implying an opt out solution) necessity for performance of a contract If your customers pay you to deliver email updates, that contract is the legal basis for sending email updates. The only wrinkle is that as you describe your service, the emails aren't an essential part of the service. Alternatively, you might assert that there's a legitimate interest to deliver updates via email so that updates aren't missed. In that case you must allow the users to object, e.g. via ab unsubscribe link in the email and via their account settings. Because a prior business relationship exists, there's a strong case for legitimate interest – even if this were marketing emails (!). Legitimate interest requires you to balance the legitimate interest with the data subject's rights and freedoms though. Your updates are most likely not marketing, so any advice you might read relating to marketing emailings is irrelevant. GDPR applies because you are established in the EU. The regulation applies in relation to all your users, not just EU users. If and when Brexit happens you will still be covered by the Data Protection Act, which transcribes the GDPR's requirements into UK law. However, processing data from EU users will then count as an international transfer which requires extra compliance work, at least until the EU issues an adequacy decision for the UK.
Where did California get authorization to receive my medical info from Walgreens? From HIPAA. Permitted Uses and Disclosures. A covered entity is permitted, but not required, to use and disclose protected health information, without an individual’s authorization, for the following purposes or situations: (1) To the Individual (unless required for access or accounting of disclosures); (2) Treatment, Payment, and Health Care Operations; (3) Opportunity to Agree or Object; (4) Incident to an otherwise permitted use and disclosure; (5) Public Interest and Benefit Activities; and (6) Limited Data Set for the purposes of research, public health or health care operations.18 Covered entities may rely on professional ethics and best judgments in deciding which of these permissive uses and disclosures to make. ... (5) Public Interest and Benefit Activities. The Privacy Rule permits use and disclosure of protected health information, without an individual’s authorization or permission, for 12 national priority purposes.28 These disclosures are permitted, although not required, by the Rule in recognition of the important uses made of health information outside of the health care context. Specific conditions or limitations apply to each public interest purpose, striking the balance between the individual privacy interest and the public interest need for this information. ... Public Health Activities. Covered entities may disclose protected health information to: (1) public health authorities authorized by law to collect or receive such information for preventing or controlling disease, injury, or disability and to public health or other government authorities authorized to receive reports of child abuse and neglect; (2) entities subject to FDA regulation regarding FDA regulated products or activities for purposes such as adverse event reporting, tracking of products, product recalls, and post-marketing surveillance; (3) individuals who may have contracted or been exposed to a communicable disease when notification is authorized by law; and (4) employers, regarding employees, when requested by employers, for information concerning a work-related illness or injury or workplace related medical surveillance, because such information is needed by the employer to comply with the Occupational Safety and Health Administration (OHSA), the Mine Safety and Health Administration (MHSA), or similar state law. See: HIPAA Privacy Rule In plain English... A covered entity (Walgreens) is allowed to use and disclose your PHI without your authorization to public health authorities for controlling and preventing diseases. Additionally, they are allowed to receive this information for the purposes of adverse event recording (reactions to shots), tracking of products (tracking of shots), and notifying you of issues related to the product you were given. Is this legal, and can the State be indicted for breach of privacy? Yes, this is legal, and no, the State cannot be sued for it.