GDPR: cookie for login management I use cookie in my site for login management. I user logs in the cookie dies with the session, if user flags "Keep me logged in" when logging in a long time cookie persists. In the long time cookie I store a hashed informations (user_id,password_hash). It's used to check if user is still logged in in a new session and I use these informations to check if user can access site without relogin. I read in some article about GDPR that technical cookies are allowed without any disclaimer. I can consider my login cookie a technical cookie since I store only these informations? Do I need to show the disclaimer in this case?
From the WP 29 Opinion 04/2012 on Cookie Consent Exemption - 00879/12/EN WP 194: Persistent login cookies which store an authentication token across browser sessions are not exempted under CRITERION B. This is an important distinction because the user may not be immediately aware of the fact that closing the browser will not clear their authentication settings. They may return to the website under the assumption that they are anonymous whilst in fact they are still logged in to the service. The commonly seen method of using a checkbox and a simple information note such as “remember me (uses cookies)” next to the submit form would be an appropriate means of gaining consent therefore negating the need to apply an exemption in this case. So a cookie to keep a user logged in, requires consent. But the checkbox "Keep me logged in" is appropriate to gain consent. So in your case you do not need to display a cookie banner.
No GDPR applies to people (not just citizens) who are in the EU. It has no applicability if both parties are not in the EU.
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.
Art 13 GDPR is about information to be provided when data is collected directly from the data subject. This information can be provided directly during/before collection. It is not generally necessary or useful to send the data subject an email with this information. Usually, a SaaS website will provide the information under Art 13 as part of their privacy policy, and link it in easy to find places. Also consider the EDPB guidelines on transparency, which suggests a layered approach: in addition to a detailed privacy policy, summarize key information directly when the data is collected, e.g. next to an input form.
The line they'll rely on for GDPR compliance is the first part of that sentence - "If you agree to this during the order process", which suggests that there will be a separate request to opt in to marketing communications at some other time in the process. Check any order documents. There's likely to be a tick box or similar on at least one. If that implies opting out rather than opting in there may be grounds to argue with that under GDPR, but there's nothing in the quoted text that suggests a problem.
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.
The conditions for lawfulness of processing are spelled out in Article 6 of the GDPR. As for it being legal for website operators to log the IP-addresses of visitors, this is covered by the following paragraph (also pointed out by phoog in a comment). The paragraph says it is legal to process personal data if 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. (my emphasis) You are not the only web site that logs IP addresses for the purpose of security. Every web site I've ever worked on - from those controlled by large corporations to tiny NGOs - do this. This security practice will not be impacted by the GDPR (if it were, I am sure we would have heard about it by now). there is the EU cookie law too If your website are going to be accessible to European citizens and not only accessible by your friends and familiy, you have to comply with the EU cookie directive of 2002 (a exemption for "personal websites" does not exist).
Your data is not anonymous since from the picture of the face the individual can be identified. It would be anonymous, if the face was blurred and other possible identifiable information was removed. Of course, that would defeat your purpose. Please note that, in any case, Anonymization Techniques are, themselves, a type of personal data processing that requires a legal ground, and achieving real anonymization is not a trivial matter (see Article 29 Working Party's opinion 0829/14/EN WP216 on the subject). 1. The face of a person includes biometric information, which is defined in article 4 (14) among other types of personal information regulated by the GDPR as: "personal data resulting from specific technical processing relating to the physical, physio­logical or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data". A facial recognition software's purpose is exactly to perform a specific technical processing based on the facial features of the persons, to achieve a unique identification of a person based on these biometric features. Article 9 of the GDPR includes biometric data among the types of prohibited processing, unless one of the exceptions in § 2 applies. There are 10 types of exceptions among which: consent of the person, employment context, personal data made public by the person, scientific or historical research,... (each exception having its own conditions). You should check that you comply with one of these exceptions stated in article 9 § 2, if your application is about using facial images for unique identification of a person based on these biometric features. 2. In turn, if your processing is not about unique identification of a person based on these biometric features, but only about emotions recognition (which you briefly mentioned at the beginning of your post), it could be considered as not falling under the requirements of Article 9. That would still be a processing of personal information, but it would fall under the normal article 6 requirements.