Does legitimate interest need to be justified in response to a GDPR DSAR? In the response to a GDPR Data Subject Access Request, in describing the lawful basis under which the data controller is processing my data, I got this: We process your personal data for our legitimate interests including: to enforce compliance with our Terms of Use and applicable law. to protect the rights and safety of our Members and third parties. to meet legal requirements. to provide information to representatives and advisors to help us comply with legal, accounting or security requirements. to prosecute and defend legal proceedings. to respond to lawful requests by public authorities. to provide, support and improve our Services. for our data analytics projects. Is this a complete answer to the question, or can I require them to detail exactly what justifies them gaining this legitimate interest? There is nothing in anything else they have sent that would indicate a justification to my non-lawyer eyes.
When responding to a DSAR (Art 15), the controller must list the purposes for which the personal data is being processed. When obtaining personal data (Art 13 &amp; 14), the controller must inform the data subject about the intended purposes of processing, the legal basis, and if the legal basis is a legitimate interest, those legitimate interests pursued by the controller or a third party. Usually, this information is combined into a single document and then published as a privacy policy, to which the data subject is referred when responding to a DSAR. I cannot find a reason to provide further justification on the legitimate interests. However, in the Guidelines on Transparency, the WP29 (adopted by the EDPB) write: The specific interest in question must be identified for the benefit of the data subject. As a matter of best practice, the controller can also provide the data subject with the information form the balancing test, which must be carried out to allow reliance on Article 6.1(f) as a lawful basis for processing, in advance of any collection of data subjects' personal data. To avoid information fatigue, this can be included within a layered privacy statement/ notice (see paragraph 35). In any case, the WP29 position is that information to the data subject should make it clear that they can obtain information on the balancing test on request. This is essential for effective transparency where data subjects have doubts as to whether the balancing test has been carried out fairly or they wish to file a complaint with a supervisory authority. – WP29 (2018): Guidelines on Transparency under Regulation 2016/679. WP260 rev.01. URL https://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=622227 So the WP29/EDBP is of the opinion that data subjects are entitled to get the controller's balancing test (sometimes also called a legitimate interest assessment). I can see no explicit legal basis for this interpretation, and it can just be inferred indirectly from the more general transparency principle or accountability principle. I am not necessarily convinced this interpretation would be upheld by a court. The ICO instead sees a more limited scope: You must tell individuals: what your purpose for processing personal data is; that you are relying on legitimate interests as your lawful basis; and summarise what the relevant legitimate interests are. – ICO: Legitimate interests: What else do we need to consider? In: Guide to the General Data Protection Regulation (GDPR). URL: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/legitimate-interests/what-else-do-we-need-to-consider/ A summary of the legitimate interests points to a fairly terse list similar to that which you have shown. Note that in the given list of alleged legitimate interests, there are some odd entries such as “to meet legal requirements”. This indicates Art 6(1)(f) legitimate interest is incorrect, and Art 6(1)(c) legal obligation should be used instead as the legal basis, unless the legal requirement does not stem from EU or member state law. Also, any “advisors” should instead be bound as data processors, which would make it unnecessary to find a legal basis to share personal data with them. “Data analytics projects” is incredibly vague, and not a legitimate interest unless the data analysis is performed for achieving another purpose such as to “improve our Services”.
Per Art 12(6), they are allowed to ask for additional identify verification: where the controller has reasonable doubts concerning the identity of the natural person making the request referred to in Articles 15 to 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject. Additionally, Recital 64: The controller should use all reasonable measures to verify the identity of a data subject who requests access, in particular in the context of online services and online identifiers. A controller should not retain personal data for the sole purpose of being able to react to potential requests. There is no consensus regarding what this means in practice: Must the controller use all measures that they can be reasonably be required to use? Or only those measures to verify the identity to a reasonable level of certainty? I agree with you that asking for a passport is excessive, and that email verification would be sufficient. However, that is just my personal opinion. The GDPR can also be interpreted in a way that asking for a copy of your passport is OK. Where they process a copy of your passport, that is personal data as well. You also have data subject rights with regards to this processing, for example the right to be informed of the purpose of this processing and of when the data will be deleted. If it is only used for the purpose of verifying your identity, the copy of your passport should be deleted immediately afterwards. The data controller may have additional obligations because a passport or ID card is a very sensitive document. E.g. Art 87 allows member states to impose additional rules. Most sensible controllers will therefore want to avoid processing passports, unless they only operate in specific EU member states.
Personal data is any information relating to an identifiable person, whether that information is public or not. The student website is definitely processing personal data of faculty. Any website is also necessarily processing personal data of visitors due to technical reasons, even though hosting has been outsourced to a third party. There's always a server, you just might not be managing it yourself. Thus, GDPR applies. Just because it processes personal data doesn't mean that the student website would be illegal. It just means the students are responsible for GDPR compliance of that website. Since the website is controlled by students and not by the university, the university DPO has no say here and the university can't demand the website to be hosted in a particular manner. Nevertheless, the DPO's suggestions might be quite sensible. Typical GDPR compliance steps include: having a clear purpose for which the personal data is being processed having a legal basis for that processing (here, probably a “legitimate interest” which will require a balancing test), see Art 6 providing transparent information to the data subjects providing a privacy notice to website visitors, see Art 13 notifying faculty per the requirements in Art 14 GDPR preparing to fulfill data subject rights such as access, rectification, and erasure when using a legitimate interest, there's also a right to “object” (opt-out) implementing appropriate technical and organizational measures to ensure security and compliance of your processing activities, see Art 24+32 making sure that third parties to which you outsource processing activities are contractually bound as “data processors” to only use the data as instructed by you, see Art 28 if you transfer data to non-European countries, having appropriate safeguards in place Does this sound complicated? It can be complicated. The point is that the internet is no longer the lawless Wild West. Just because you can easily publish a site with personal data, doesn't mean that you should. The GDPR is about requiring data controllers to find an appropriate balance with the rights and interests of the affected persons. Of course there are countries with less regulation, but there are also countries with fewer taxes and that isn't necessarily good for society. The easiest way to avoid these responsibilities will be to stop publishing the site as students – and instead taking up the university DPO's offer to have the university run the site. Which is less fun, of course, but the adult thing to do. If this motivates you further: note that the data controller (the people responsible for the site) must publish their contact information in the privacy notice, typically name + email + street address. The GDPR contains no exceptions that would help here. There is an exception for purely personal or household activities. But if the website would be available to the general public, it would be difficult to argue that this is purely personal. There's also case law such as the Lindqvist case requiring a narrow interpretation of that exception. In Art 9, the GDPR does mention that some restrictions are lifted if the data subject made the information public themselves. But that isn't relevant here, because Art 9 is only about extra-protected sensitive data, e.g. health information, union membership, or sexual orientation.
The data controller is correct: they can take up to three months (approx. 90 days) to process a request, though this is only allowed in exceptional cases. From Art 12(3) GDPR (emphasis mine): The controller shall provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request. That period may be extended by two further months where necessary, taking into account the complexity and number of the requests. The controller shall inform the data subject of any such extension within one month of receipt of the request, together with the reasons for the delay. You have not received a response in that timeframe, so the data controller has failed to meet its obligations. The polite thing to do would be to remind them that the time has run out, and that you would like a response ASAP. You can lodge a complaint with your supervisory authority. A letter from the data protection authority tends to speed things up a lot :) In principle, you could sue them to get a response. In practice, this is likely to be too expensive to be worth it.
It depends. Can the data controller or another person, with &quot;means reasonably likely to be used,&quot; (see clause 26 of the preamble of the GDPR) use that data alone or in combination with other data to identify a natural person? If yes, it is personal data within the meaning of the GDPR. If no, it is not personal data within the meaning of the GDPR. Anonymous data is not subject to the GDPR. &quot;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.&quot; Assigning an unique alphanumeric code to a thing does not necessarily make the code and/or the thing &quot;personal data&quot;. But if you have a set of data that is or can be linked by the unique alphanumeric code (e.g. as a primary key in a set of tables) and you can use it to identify a person, then it is personal data. Either way, to be GDPR-compliant / to mitigate risk you should make some kind of record to reflect that process of thinking and what you decided. And if the answer is Yes, it is personal data, then you should record your &quot;lawful basis&quot; for processing the data and how you decided that.
GDPR recital 64 says: The controller should use all reasonable measures to verify the identity of a data subject who requests access, in particular in the context of online services and online identifiers. A controller should not retain personal data for the sole purpose of being able to react to potential requests. The GDPR does not specify exactly what methods of verification are &quot;reasonable&quot;. GDPR Article 11 paragraph 2 provides: 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. This is amplified by Recital 57 which says: If the personal data processed by a controller do not permit the controller to identify a natural person, the data controller should not be obliged to acquire additional information in order to identify the data subject for the sole purpose of complying with any provision of this Regulation. However, the controller should not refuse to take additional information provided by the data subject in order to support the exercise of his or her rights. Identification should include the digital identification of a data subject, for example through authentication mechanism such as the same credentials, used by the data subject to log-in to the on-line service offered by the data controller. GDPR Article 12 paragraph 6 provides: Without prejudice to Article 11, where the controller has reasonable doubts concerning the identity of the natural person making the request referred to in Articles 15 to 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject. All of the above seems to indicate that the Data Controller must follow reasonable practices, but is not required to guarantee a positive response to a Data Subject who cannot supply reasonable evidence of identity. Moreover the Controller is required to reliably ascertain the identity of the Subject before providing information or acting on a request. Incidentally, good security practice is that the site does not retain the actual password. instead it hashes the password with a good cryptographically secure hash function, and stores the hash. This means that the site cannot reliably determine if a password is unique among all passwords saved by the site, and searches among passwords are not normally done, and would not be reasonable. A site using an email address as the User Identifier would normally enforce at the time an account is created that the email is unique among all emails registered on the site. A user who cannot provide the email would typically be rejected as not able to be identified, unless the site retains additional ID info not listed in the question. I think such a practice would be considered to be reasonable in the current state of technology.
An Art 15 Subject Access Request (SAR) “shall not adversely affect the rights and freedoms of others.” It would be a grave violation of privacy for an email provider to search its users' account contents. It is therefore likely that the email provider would refuse to fulfil that subject request, unless required to perform a search via a court order. Instead, the SAR could be directed to the account holder (Alice or Dave), if they are subject to the GDPR. Depending on the exact legal framework, emails might be protected under confidentiality of communications rules, making such searches similarly illegal to wiretapping. At least in germany, I am fairly certain that an email provider would be criminally liable if they were to disclose emails from their users' email accounts to a third party.
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).