What are the limits of ID requirements for a subject access request? When one makes a subject access request it is required that the data controller is required to ensure the identity of the requestor, to prevent unauthorised individuals accessing personal data of others. This is implemented by many organisations (eg. cifas) by requiring the subject to provide documents such as photo id (driving license or passport) and one from a list of documents of which I only have a bank statement. These documents contain a lot of personal information that I THINK the organisation does not have and I do not want to provide without good reason. This includes: Special category data Place and date of birth Facial photograph Nationality Data useful to fraudsters Which bank I use Bank account number Reoccurring payments (that are the usual security questions asked when I call my bank) Personally sensitive data Spending habits Driving restrictions/convictions It would seem appropriate to request from the data controller what data they hold about me, and redact any other information. However, as this is likely to be only name and address the redacted documents are likely to be mostly a black square with little boxes of text that would do a rather poor job of verifying my identity in that anyone who knows my name and address could probably generate them. What are the legal limits of what a data processor can require before providing the response to a SAR? What can a data subject do to prevent further distribution of PII when trying to access data from a potentially untrustworthy data controller? Is there actually a solution that both provides for data security for the subject and verification of identify to the data controller?
Overview The GDPR requires data controllers (DCs) to exercise reasonable care when responding to an access, modification, or deletion request, to ensure that it comes from the actual Data Subject (person whose data is involved, here a DS). The GDPR does not specify just what methods must or may be used to ensure that an access (or other) request comes from the DS. It does say, in Article 12, that &quot;additional information&quot; may be requested from the DS by the DC for this purpose that is &quot;necessary to confirm the identity&quot; of the DS. If a DC receives data for identification purposes, it must be used only for those purposes, and retained no longer than needed. Personal Data (PD) in general must be limited according to article 5, so that data is used only for the purposes it was collected for, retained for no longer than needed, adn appropriately secured against unauthorized use or access. The DC is responsible for adhering to these limitations. Recitals 57, 59, and 77 (quoted below) confirm this, and discuss identification. If a DC violates these restrictions, it is subject to the same enforcement as it would be for violating any other GDPR provision. If a DS thinks the data requested to support identification of the DS is excessive, the DS may first complain to the DC, and then to the relevant supervisory authority if the response from the DC is not acceptable (allow at least 1 month for a response). But perhaps knowing that the GDPR forbids the DC from distributing or using this data except for the purpose it was collected, that is, to identify the DS, and from retaining it longer than need be, might offer some reassurance. A DS could also ask the DC what is the minimum data needed for identification, and redact data beyond this. The DC might need more than name and address, but not all that is on a bank statement or other ID document. GDPR Sources Article 12 (section 6) of the GDPR reads: 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. That includes access requests. Paragraph 1 of Article 11 reads: If the purposes for which a controller processes personal data do not or do no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with this Regulation. Paragraph 1(b) of article 5 specifies that personal data shall be : collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; Paragraph 1(c) of art 5 specifies that such data shall be: limited to what is necessary in relation to the purposes for which they are processed ... Paragraph 1(e) of art 5 specifies that such data shall be; kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; [emphasis added] Paragraph 1(f) of art 5 further specifies that such data shall be: processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing Recital 59 reads: Modalities should be provided for facilitating the exercise of the data subject’s rights under this Regulation, including mechanisms to request and, if applicable, obtain, free of charge, in particular, access to and rectification or erasure of personal data and the exercise of the right to object. The controller should also provide means for requests to be made electronically, especially where personal data are processed by electronic means. The controller should be obliged to respond to requests from the data subject without undue delay and at the latest within one month and to give reasons where the controller does not intend to comply with any such requests. Recital 57 reads: 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. 3Identification 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. Recital 77 reads: Guidance on the implementation of appropriate measures and on the demonstration of compliance by the controller or the processor, especially as regards the identification of the risk related to the processing, their assessment in terms of origin, nature, likelihood and severity, and the identification of best practices to mitigate the risk, could be provided in particular by means of approved codes of conduct, approved certifications, guidelines provided by the Board or indications provided by a data protection officer. The Board may also issue guidelines on processing operations that are considered to be unlikely to result in a high risk to the rights and freedoms of natural persons and indicate what measures may be sufficient in such cases to address such risk.
The site would combine the data in novel ways, which is processing the data. Processing personal data which is publicly available is still processing personal data. You would have to take GDPR into account. That does not mean the processing is forbidden, but you need a legal basis for doing it. In many ways, having the informed consent is the easiest legal basis, but there are others. The data subject would have the right to demand information about the data you hold, and to demand the correction of wrong data. There is not necessarily a right to demand deletion, but if consent is withdrawn and you have no other basis for data processing, you have to delete. Note also that the consent basis would mean you have to actively contact the people whose consent you seek before the processing starts, and document how you do it. That makes pay-per-request models difficult. But consider that the news media can process some data about some people without the consent of the subjects of their activities. They just need to balance privacy and other legitimate interests all the time.
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.
The obligation to notify the supervisory authority (CNIL in your case) no longer exists. It was part of the previous regulatory framework, but it is not part of GDPR (which takes affect tomorrow). If you use CCTV that may monitor employees (i.e. they sometimes enter the HQ to consult with the owner), your obligations under the GDPR is basically to inform the employees that the CCTV cameras are there. I.e. Data subjects are entitled to understand when their personal data is being processed, covering the transparency aspect of processing. The use of CCTV must be communicated via signage which indicates the areas covered and instructions for further information.
I'm pretty sure that under GDPR, you can indeed request them to send all data they have on you. If it's a complex request, they may charge you something like £10. If they have a lot of data on you, they may list the categories of data they have and ask you to pick one, rather than them having to collect and send everything. They should respond within one month, but iirc in the UK implementation, they can inform you (within that month) that they will respond within three months instead. For the rest, I only know current Dutch law. GDPR is not that different from what we already had (in general terms) and in many cases it even extends it. Under our law (WBP), you can also request a correction of the data in case it is incorrect, or deletion if they no longer need it for the purpose for which it was collected and stored. I don't really know how that works out in practice though, as Facebook can of course claim that "being able to connect you to your friends when you sign up for WhatsApp or Facebook with that number" is a legitimate purpose (in their eyes). They might also not have your full name and therefore not be able to connect your data to your request. Or, perhaps, they have only your full name (and there are probably more people with your name), so they'll have a hard time verifying that it's really your data which they would be handing over or deleting. The company is required to verify your identity before acting on your request. How they implement that is up to them. Under Dutch law, if I remember correctly, any data that can be connected to your person by any party is personally identifiable information (PII). While Facebook might not be able to find who's behind a phone number, your carrier most certainly can. Therefore, the data falls under PII protection laws and they will have to implement a way to verify you and get you your data. Finally, whether your local laws apply to Facebook, I don't know exactly. There's lots of information on this though, so you should be able to find it. Generally, countries say that if something happened within their territory (e.g. you signed up for WhatsApp while in the UK), their law applies. Companies, I've read, will instead try to claim that their main office is in SomeCountry and therefore SomeCountry's laws apply. But I'm pretty sure you'll be able to find a Facebook office somewhere where GDPR applies, so that's probably fine. While not an exact answer and while I am not sure about everything, I hope this gave you some pointers to go on!
The standard for stopping someone and requesting their ID under the limitations in the U.S. Constitution is &quot;reasonable suspicion.&quot; For example, if the officer has a reasonable suspicion that you are taking pictures for the purpose of a secure location for purposes of espionage, or to case the location for a future crime, reasonable suspicion is probably present and you can probably legitimately be asked for you ID. A creative and intelligent officer can almost always conjure up some reasonable suspicion in the situation that you identify to question you and demand ID. For example, she could state that no one else has taken a picture of that location in weeks and that is is very unusual behavior, that your demeanor or the time of day you were present doesn't seem to be that of someone taking a picture for artistic or journalistic purposes, that you seemed nervous, that a previous criminal engaged in similar behavior before committing a crime fourteen years ago, that a confidential informant (e.g. a nosy neighbor) advised him that there was someone engaged in suspicious behavior at that location, that she read in a police anti-terrorism bulletin that terrorist favor that model of camera, etc. The nature of the suspicion doesn't have to be shared with you until you challenge it in court. A dumb cop won't come up with any colorable reason, demands ID for a stated reason (&quot;before you have to do whatever I say&quot;) that is inaccurate, admits he has no reason to stop you in a conversation captured by a body camera, and doesn't come up with pretext after the fact before going to the court. In that case, the stop is a de minimis violation of your civil rights justifying a nominal damages award of $1 to you and your attorneys' fees and costs and maybe a consent decree ordering the agency not to do that in the future.
There are no direct penalties per GDPR. The data controller must make sure that the person making the request is the data subject, or at least authorized by the data subject. If the controller has reasonable doubts about the identity, they should request additional information for identification purposes. The controller must find a middle ground between violating the GDPR by rejecting a potentially valid request and violating the GDPR by disclosing data to potentially unauthorized recipients. Having reasonable technical and organization measures that prevent unauthorized disclosure is part of the controller's responsibilities per Art 24. What the data controller can do is to block future requests from the alleged stalker. When a request is “manifestly unfounded or excessive, in particular because of their repetitive character”, then the controller can charge a reasonable fee or refuse to act on the request (Art 12(5) GDPR). But it's up to the controller to prove that the requests are unfounded or excessive, it is not possible to reject potentially valid requests on sight. Depending on what the alleged stalker does with the obtained data, they would fall within the scope of the GDPR themselves and would probably be violating it because there is no sufficient legal basis. Also, the alleged stalker, as a data controller, would be required to inform the data subject about subsequent processing of the data per Art 14 GDPR. Attempting to obtain another person's personal data through an access request would have to be punishable by other laws. For starters, such attempts would likely involve identity theft, and successfully obtaining the data would probably be a kind of fraud.
Maybe not. The ICO says that The right of access enables individuals to obtain their personal data rather than giving them a right to see copies of documents containing their personal data. It might be valid to interpret the DPA / UKGDPR in a way that the relevant personal data undergoing processing in their system is the existence of the letters, but that you are not entitled to a copy of the letters. This is in line with the purpose of the right to access, that you can check what data they are processing about you and whether it is correct. If that argument holds and the data subject insists on receiving a copy of the letters, it might be legitimate to charge them a fee for these copies. But in practice: The data controller might not make this argument and just hand over the copies. It is worth a try. A right to access founded in data protection might not be the only way to receive a copy of these materials. If the letters are relevant for legal proceedings, they could perhaps be requested during the disclosure process.