Do companies have the right to demand proof of being present in the EU before executing a GDPR request? Under the GDPR, any company doing business in the EU must remove EU users' personal data upon request from that user. Since the statute only applies to persons present in the EU, are companies legally permitted to demand that a user requesting personal data removal supply proof that they are present in the EU, so that they can deny the request to those outside?
the statute only applies to EU residents Wrong. GDPR applies to everyone in the EU (Art. 3). This means tourists are also covered. Residence status is completely irrelevant (Recital 14(1)): The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence There is no provision for data processors/controllers to demand proof from data subjects of them being located in the EU. You can challenge them, but if they refuse to provide proof you will still be liable to fulfill their GDPR request should they indeed be present in the EU.
… would face and voice count as personal information under GDPR? Absolutely. Does person B have the right to erasure … No. The right to erasure only applies in certain circumstances. While the initial reason for collecting personal data was consent, once it has been incorporated into a film, the processor now has a legitimate interest in the data. The right to erasure does not apply when there is a legitimate interest.
Yes, phone numbers would generally qualify as Personal Data under GDPR. It would be so irrespective of whether you have also stored other information along with the phone numbers or not, since also information that indirectly could identify a natural person is Personal Data (provided that there are, somewhere else, public or not public, a register of who holds the specific phone number). See Article 4(1) GDPR. (One could possibly argue that the phone numbers would not be considered personal data if there is no actual register of who owns a specific phone number with any other party. Or if such register is in practice not available for anyone. It might be so in some cases, although I would not rely on it.) Whether you have the right to process the phone numbers must be assessed based on its lawfulness (see Article 6 GDPR). It could be based on consent, performance of contract, legitimate interest or any other ground set out therein.
Is it actually necessary for businesses (such as a Small Town News USA Inc) that do not reside in EU to care about GDPR? Only if they offer goods/services to or monitor behavior of people in the EU (Art. 3(2)). Note that: having a commerce-oriented website that is accessible to EU residents does not by itself constitute offering goods or services in the EU. Rather, a business must show intent to draw EU customers, for example, by using a local language or currency. If it is then how (and by whom) would compliance be audited and/or enforced? Supervisory Authorities will care of it.
Your analysis so far seems correct. You must comply with all applicable laws. The GDPR's Art 6(1)(c) legal basis clarifies that having to provide personal data is no excuse: that legal obligation is all the legal basis you need for sharing the personal data in accordance with your obligations. However, that legal basis doesn't generally excuse you from your other data controller obligations. For example, you should still inform the data subjects about the processing as per Art 13(3).
However, if a website is based in the US and the terms of service say that the law governing the terms is US law, how can GDPR have any affect? It is unlikely that the EU will be able to enforce financial penalties against a company with no presence in the EU. But they could for example block your website in the EU, depriving you of your EU user base. The actual measures that they could or would take against such a company are still unclear, since the GDPR is quite new, and there has been no action under the GDPR against foreign companies. I'm not a lawyer, but I've signed many contracts in my life and nearly all of them have some form of "governing law" clause. The governing law clause in a contract identifies the law that will be used to interpret the contract and to resolve any disputes arising from the contract. The law identified in the clause does not become the sole law governing every aspect of the relationship between the parties, however. For example, a business in New Jersey could have a contract with a client in New York with a clause specifying New Jersey law as the governing law of the contract. But that does not mean that New York's consumer protection law doesn't apply to the transaction.
The data processor is not responsible for complying with the GDPR. You are ultimately responsible, since you are the data controller. The data processor is merely required to assist you, but it's unclear what that means in the presented scenario. Per Art 28(3)(e) GDPR, the DPA must require the data processor to provide reasonable assistance: That contract or other legal act shall stipulate, in particular, that the processor: […] taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller’s obligation to respond to requests for exercising the data subject’s rights laid down in Chapter III; However, per Art 28(1) you can only engage processors that you deem sufficient to protect the data subject's rights: the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject. Here, it seems that your company failed to ensure that the processor provides the features you need for compliance. Many companies claim to be GDPR-compliant, but that doesn't mean that your use of their services will be GDPR-compliant as well. Depending on how the Art 28(3)(e) requirement was implemented in the DPA you may have a right to assistance even if the processor doesn't implement necessary features in their software, but enforcing this contract could require a lawsuit in a foreign jurisdiction (but that's par for the course for international B2B contracts). It is worth noting that the GDPR right to erasure doesn't always apply. In a processing activity where no erasure right is likely to arise, it would be perfectly fine to use a data processor that doesn't offer any possibility for erasure. Similarly, it can sometimes be legal to use technologies like Blockchain or Git that make erasure difficult or impossible. However, it is the responsibility of the data controller to analyze the impact of such a choice up front, before commencing the processing activities. In some cases, this could require a Data Protection Impact Assessment (DPIA). Note that transfers of personal data into the US are illegal or at least questionable in the wake of the 2020 Schrems II ruling. The Privacy Shield is no longer a legal basis for such transfers. Standard Contractual Clauses (SCCs) are technically allowed, but only “on condition that enforceable data subject rights and effective legal remedies for data subjects are available” (cf Art 46). The ECJ's judgement calls this into question. This could be a further incentive to migrate to a more GDPR-compliant service.
If the data controller has “reasonable doubts concerning the identity of the natural person making the request”, then “the controller may request the provision of additional information necessary to confirm the identity of the data subject” (Art 12(6) GDPR). Until the data subject provides this information, the request is paused. But what are reasonable doubts, and what additional information can the controller request? The GDPR itself provides no clear guidelines, though general principles apply – the additional information must be necessary, adequate, and proportionate for the identity conformation purpose. The controller's obligation to comply with access requests must be balanced with the controller's obligation to ensure the security of data by rejecting invalid requests. Just accepting any request without any verification would also be a breach of the GDPR. For example: If the company identifies data subjects by email address, then demonstrating control over the email address would be an appropriate verification step. But just mentioning the email address would not be enough since it could be someone else's email address. If the company provides a website where data subjects have created user accounts, then being able to log in to the account would be an appropriate verification step. In these examples, asking e.g. for government photo ID would not be appropriate because that doesn't help strengthen the link between the person making the request and the personal data being processed. Such data collection would be disproportionate and unnecessary. In contrast, if you walk into a bank and ask for a copy of your data, it would be entirely appropriate for them to ask for government ID because (a) the higher general risks warrant stronger checks, and (b) such ID will help confirm that the person making the request is indeed the proper account holder. The bank will also have been legally required to request ID when the account was originally opened, so that asking for ID as an identity verification measure during this later request won't involve collection of more data than they already have. (These examples were made up by me and are not official, but read on.) The EDPB has issued draft guidelines on the right of access 01/2022, which also discuss the issue of additional information for identity verification in sections 3.2 and 3.3. In particular, paragraphs 73-78 talk about IDs: 73. It should be emphasised that using a copy of an identity document as a part of the authentication process creates a risk for the security of personal data and may lead to unauthorised or unlawful processing, and as such it should be considered inappropriate, unless it is strictly necessary, suitable, and in line with national law. […] it is also important to note that identification by means of an identity card does not necessarily help in the online context (e.g. with the use of pseudonyms) […]. 75. In any case, information on the ID that is not necessary for confirming the identity of the data subject, […] may be blackened or hidden by the data subject before submitting it to the controller, except where national legislation requires a full unredacted copy of the identity card (see para. 77 below). […] 76. […] Example: The user Ms. Y has created an account in the online store, providing her e-mail and username. Subsequently, the account owner asks the controller for information whether it processes their personal data, and if so, asks for access to them within the scope indicated in Art. 15. The controller requests the ID of the person making request to confirm her identity. The controller's action in this case is disproportionate and leads to unnecessary data collection. […] Example: A bank customer, Mr. Y,, plans to get a consumer credit. For this purpose, Mr. Y goes to a bank branch to obtain information, including his personal data, necessary for the assessment of his creditworthiness. To verify the data subject’s identity, the consultant asks for notarised certification of his identity to be able to provide him with the required information. The controller should not require notarised confirmation of identity, unless it is strictly necessary, suitable and in line with the national law […]. Such practice exposes the requesting persons to additional costs and imposes an excessive burden on the data subjects, hampering the exercise of their right of access. 77. Without prejudice to the above general principles, under certain circumstances, verification on the basis of an ID may be a justified and proportionate measure, for example for entities processing special categories of personal data or undertaking data processing which may pose a risk for data subject (e.g. medical or health information). However, at the same time, it should be borne in mind that certain national provisions provide for restrictions on the processing of data contained in public documents, including documents confirming the identity of a person (also on the basis of Art. 87 GDPR). Restrictions on the processing of data from these documents may relate in particular to the scanning or photocopying of ID cards or processing of official personal identification numbers. To summarize: controllers can request IDs only in comparatively niche scenarios, and must then take additional safeguards to protect the sensitive document (e.g. instructing the data subject to redact parts of the ID, not making copies, and immediately deleting the ID after successful verification). A lot here comes down to national laws, which may explicitly require or forbid use of the ID in this context. The EDPB guidelines are not binding or normative, especially since this guidance is still in the public consultation phase. However, the guidelines present an overall consensus of the national data protection authorities in the EU, and the guidelines are regularly cited by courts. In practice, many controllers do ask for disproportionate amounts of data. Sometimes this seems to be an attempt to discourage data subject requests, which would clearly be non-compliant. In some cases, this is due to a narrow interpretation of “reasonable doubts” in which they try to eliminate any doubt about the identity. If the data subject and data controller cannot agree on a suitable identity verification process, then the data subject can: Art 77: lodge a complaint with a data protection authority, and/or Art 79: sue the data controller in court, both for compliance (fulfilling the request) and for compensation (if damages were suffered). It is worth noting that the data controller is responsible for being able to demonstrate compliance (Art 5(2) accountability principle), such as demonstrating the apparent reasonable doubts to a supervisory authority or to a court. When the controller requests ID, the controller has the burden of proof to show that this is compliant.