GDPR: Can I make a subject access request for information that I obviously already know? The GDPR guidance states that subject access requests can only be refused if they are manifestly unfounded or excessive. The detailed guidance on what constitutes manifestly unfounded or excessive can be found here In summary a manifestly unfounded or excessive request is: Malicious or intends to cause disruption Repeats previous subject access requests Overlaps with other subject access requests The guidance makes no mention about whether or not it would be excessive to request information clearly already known to the subject. When I say information already known, I mean for example: Asking a previous employer for information such as: My salary while I worked there My start and leaving date My job title This would be useful in a situation for example, where a person needs to prove their income for the last several months and the previous employer is refusing to provide an employers letter. Of particular interest is the following paragraph: An individual may also want to receive another copy of information they have requested previously. In this situation a controller can charge a reasonable fee for the administrative costs of providing this information again and it is unlikely that this is an excessive request. This seems to imply that I can ask an organization for another copy of information that I already know. They can charge a fee, but not refuse to comply.
A data subject access request can be valid even if it wouldn't disclose new information. The right to access ties in with the GDPR's transparency principle (finding out which data is being processed) and with the right to rectification (are there any mistakes in the data being processed?). For rectification, it's pretty much ideal if you get back exactly the data you expect – but you're allowed to check with an access request. The Art 12(5) limitations on excessive or manifestly unfounded requests do put a limit on the right to access, but this limit helps controllers respond to legitimate requests. For example, if a request is clearly intended to harass the controller with busywork, it can be denied as unfounded. Similarly, requesting access to the same data very frequently would be excessive. However, the controller has burden of proof to show that the request is excessive or unfounded – basically impossible for a one-time request for specific data. A request is not automatically excessive just because it is likely to only return data you already know. But ultimately, detailed guidance on the interpretation of “excessive” is up to the supervisory authorities – the GDPR itself provides no guidance. Aside from the above exception, access can only be denied if it would adversely affect the rights and freedoms of others. For example, you could be denied access to non-anonymous performance reviews. There would be no such adverse effect for basic information about your employment. If a data controller improperly considers your request as excessive or unfounded, you can lodge a complaint with your supervisory authority, e.g. the ICO in the UK. Most controllers are suddenly extremely helpful once contacted about an official complaint.
There is nothing preventing the OP's &quot;subject&quot; from making a Subject Access Request in these circumstances From the British Transport Police's Privacy Notice page, under the heading &quot;How we use personal data&quot;: This privacy notice explains: ... the rights individuals have when we process their personal data. ... Right of Access: You can request access to the personal data we hold about you free of charge. You can request access to the personal data we hold about you using the contact details in this privacy notice. ... We collect personal data from a variety of sources, including: ... sound and visual images (e.g. from body worn cameras, CCTV, or facial recognition software); ... our own CCTV systems and body worn cameras. There's more detail in the link, which I have not replicated here to save space and avoid unnecessary &quot;noise&quot;, but the above should cover the relevant points raised by the OP
First take a look at Article 13(1) of Directive 2002/58/EC Article 13 Unsolicited communications The use of automated calling systems without human intervention (automatic calling machines), facsimile machines (fax) or electronic mail for the purposes of direct marketing may only be allowed in respect of subscribers who have given their prior consent. Notwithstanding paragraph 1, where a natural or legal person obtains from its customers their electronic contact details for electronic mail, in the context of the sale of a product or a service, in accordance with Directive 95/46/EC, the same natural or legal person may use these electronic contact details for direct marketing of its own similar products or services provided that customers clearly and distinctly are given the opportunity to object, free of charge and in an easy manner, to such use of electronic contact details when they are collected and on the occasion of each message in case the customer has not initially refused such use. Note that this is a Directive, so it is not directly binding, but each EU member state has created it's own laws containing this. I also quoted paragraph 2 for completeness, but based on your description, it does not apply. Article 95 GDPR explicitly specifies it does not change any obligations from Directive 2002/58/EC. So it looks very clear to me the situation you describe is not legal. Article 14 GDPR allows you to request all information regarding this, which included information how they have exactly obtained your name and email address.
No, it's not legal. The General Data Protection Regulations (GDPR) apply given that you are in the UK (regardless of where the Data Processor is based). The UK GDPR is slightly modified due to Brexit, but the same principles apply. The only plausible legal basis for this actions would be that you consent to it, and you're entitled to withdraw that consent at any time. Some may claim that Article 6.1(b) applies, i.e. that it's necessary to send marketing email in order to fulfil the contract, but GDPR is clear that bundling such consent into a contract for service simply to permit the data processor additional actions isn't allowed, as I'll demonstrate. UK GDPR requires that consent to use your personal information (in this case, your email address) for the stated purpose be freely given. Consent to use your information for direct marketing is not freely given if it's inseparable from the consent to use it for some other service, as per para 43: 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. And Article 7.4 backs this up with 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. The intent of Article 6.1(b) is that only the processing required for the service you have bought is allowed (e.g. if you supply your address for delivery of stuff you've bought, the data processor can use that address to send you the stuff, but is not allowed to add a contract term that allows them to send you unwanted stuff). Examples of emails that Article 6.1(b) would allow (in my assessment) include things such as notification of upcoming downtime, or a reminder that subscriptions are due, but not unsolicited advertisements for other products. There's a grey area that's open to interpretation, where adverts are piggybacked onto actual service messages.
The GDPR gives controllers a lot of latitude. They must decide on the correct course of action taking into account the possible risks to data subjects. Specifically, no notification of the authority is necessary if “the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” In your scenario 1, you suggest that there is no breach because there is no evidence that the data was improperly accessed. This analysis is faulty: the controller is aware that the data was not properly secured, and cannot rule out that the data was improperly accessed. I would argue this fits the description of a “breach of security leading to the accidental or unlawful … unauthorised disclosure of … personal data” (compare the definition of a data breach in Art 4(12)). Thus, a data breach has happened. The question whether the supervisory authority has to be notified of that breach is more debatable. The controller must assess the likelihood of risks to the data subjects. Here, they can perhaps argue that the risk of disclosure is low. However, the nature of the breached data would also be relevant. If in doubt, the controller should make the notification. The goal of the GDPR is not to punish unlucky companies that suffer a breach, but to protect personal data. Thus, fixing mistakes and cooperating with the supervisory authorities is likely the best approach for most companies. In your second scenario, the data is sensitive – its disclosure has a high risk for data subjects. However, the risk of someone intercepting this data is debatable. Does the risk of interception balance out the sensitivity of the data? That's the data controller's call, but I don't think so. A notification would seem appropriate here. As a technical remark, simply offering HTTPS is not sufficient to prevent MitM attacks – users must be forced to use encrypted connections. If a controller sees MitM as a risk, they are required by Art 24 to take appropriate technical measures. Here HSTS and HSTS preload would prevent the connections from being downgraded to HTTP. Instead of offering insecure connections, the site would become inaccessible. A complementary strategy is to not serve content over HTTP, but have the HTTP server only issue a permanent redirect to the HTTPS URL.
This is a good question, as it raises an issue which places the controller's interest in providing a smoothly functioning customer sign up process against customers' right not to have their data leaked. Note that it is not necessary to consider &quot;enumeration&quot; here. Even just being able to check whether one person has a registered account raises the issue. The relevant provisions of the EU GDPR (or in the UK, the UK GDPR as defined in sections 3(1) and 205(4) of the Data Protection Act 2018) are (emphasis added): Article 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, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction So, disclosure of the fact that a user has a registered account amounts to &quot;processing&quot;. Article 6(1): Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) 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. Of these, only (a) and (f) are likely to be of any relevance: (a) is not too useful since it isn't feasible to design a sign-up system that depends on the user's consent (which they may not give). That leaves us with (f). As noted by the Information Commissioner's Office, &quot;Legitimate interests is the most flexible lawful basis for processing, but you cannot assume it will always be the most appropriate. It is likely to be most appropriate where you use people’s data in ways they would reasonably expect and which have a minimal privacy impact, or where there is a compelling justification for the processing.&quot;. The legitimate interest here would be that you need a sign up system which prevents duplicate registrations. Remember though that the processing has to be &quot;necessary&quot; for the purposes of the legitimate interest. One might argue that it is not since you could design the system to give the appearance of accepting the duplicate registration followed by sending an email to the account holder to inform them. On the other hand this will result in a less user friendly experience which could itself be a legitimate interest. Ultimately this is a balancing exercise and it is hard to say whether you have struck the right balance until someone complains to the ICO or the court and a decision is issued. The fact that the practice is widespread among well-resourced and large companies would tend to indicate that it is lawful albeit this is not conclusive in the absence of a court decision. I'm not aware of any cases involving this particular issue but would be interested to hear from others on this point. If the processing is unlawful then Article 18 is applicable: The data subject shall have the right to obtain from the controller restriction of processing where one of the following applies: [...] (b) the processing is unlawful and the data subject opposes the erasure of the personal data and requests the restriction of their use instead Where processing has been restricted under paragraph 1, such personal data shall, with the exception of storage, only be processed with the data subject’s consent or for the establishment, exercise or defence of legal claims or for the protection of the rights of another natural or legal person or for reasons of important public interest of the Union or of a Member State. In other words, the data subject could ask you not to disclose their registration status via the sign up page, and you would be obliged to comply with the request. Separately from the above points, in order to be lawful you must provide the data subject with certain prescribed information at the time when the data is collected. Of particular relevance here are the following items: Article 13(1): Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: [...] (c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing; (d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party; So even if you conclude that the processing will be lawful you will have to give some consideration to the basis so that you can comply with the above provision.
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.
Either approach can be GDPR-compliant. An issue to consider is that you as a data controller relying on consent “shall be able to demonstrate that the data subject has consented to processing of his or her personal data” (Art 7(1)). This might be simpler if a record of the consent is linked to a user account. On the other hand, the GDPR's data minimization principle would suggest that decentral, offline approaches are preferable. So you do have some flexibility here, as long as you feel comfortable demonstrating that your approach is compliant when investigated by a supervisory authority. In many cases, consent is not an appropriate legal basis to start with. It is one of several options in Art 6(1) GDPR. If a data processing activity is necessary for fulfilling a contract with the data subject, then Art 6(1)(b) is more appropriate. If the processing is necessary for a legitimate interest, then Art 6(1)(f) would work – after conducting a balancing test. Art 6(1)(a) consent is appropriate when the processing activity is not necessary, or when a legitimate interest balancing test doesn't go in your favor, or in some cases when required by law. For example, consent is required when processing special categories of data (such as biometrics), or when accessing or storing information on the end user's device, beyond what is necessary for a service explicitly requested by the user (the “cookie law”, but much more general than cookies). Consent also has heightened compliance requirements compared to other legal bases. The data subject must be able to make a free decision, without any coercion. You must not use dark patterns. You must leave the data subject a real choice. You must not make access to your app conditional on giving unrelated consent (like providing access to a game only when the user gives consent for personalized ads). The data subject must be able to easily withdraw consent later, without suffering detriment for this. The EDPB has issued relevant guidelines that might be helpful here: EDPB guidelines 05/2020 on consent EDPB guidelines 2/2019 on Article 6(1)(b) in the context of online services (also relevant for apps) TL;DR: what is “necessary” for performance of a contract is an objective question, and should generally be considered from the data subject's perspective. It is not possible to circumvent consent requirements by putting unrelated processing purposes like “analytics” into a services' terms of service. The main purpose of this document is to serve as a rebuttal of Facebook's GDPR compliance strategy. But it's perfectly fine to avoid asking for consent for those processing purposes that are actually necessary for the user. I've noticed that you mentioned various Google services like Analytics and Firebase. To the degree that your use of these services implies an international transfer of personal data into the US, it might be impossible to be GDPR-compliant. Be wary of claims that you're only transferring “anonymous” data, as the GDPR has a fairly broad concept of identifiability.