Is GDPR consent as part of Terms &amp; Conditions valid? In the terms and conditions of the kite festival consent for use of footage of the audience is written into the Terms &amp; Conditions: 5.c: Ticket Holders consent to being photographed, filmed and sound recorded as an audience without payment, and to their image being exploited in any and all media for any purpose at any time throughout the world by the Promoters who shall own the copyright in all such recordings. If you attend the Event with a child under 16 you give the foregoing your express consent on their behalf. Note that consent is implicit, with no instructions given for withdrawal of consent. From the ICO site: What is valid consent? Consent must be freely given; this means giving people genuine ongoing choice and control over how you use their data. Consent should be obvious and require a positive action to opt in. Consent requests must be prominent, unbundled from other terms and conditions, concise and easy to understand, and user-friendly. Consent must specifically cover the controller’s name, the purposes of the processing and the types of processing activity. Explicit consent must be expressly confirmed in words, rather than by any other positive action. This seems to miss most if not all of these points (note &quot;the Promoters&quot; are not specifically defined in that document, but is &quot;U-Live Portfolio Ltd and any associated promoter(s) of the Event&quot;). Is this legal consent? I assume that if they used the 9.b. right to refuse you entry after you withdrew consent that would be illegal? In the privacy policy they detail the results of withdrawing consent for marketing communications but not for this photography and recording.
Consent in the GDPR sense? No. Consent in the more general sense of “agreement”? Sure. Under the GDPR, consent is only one of many legal bases for processing personal data. Consent requires an unambiguous indication of the data subject's wishes through a clear statement or affirmative action. Thus, consent cannot be “hidden” in another document – it would be ambiguous whether the data subject just wanted to agree to boilerplate terms of service or specifically consent to a particular purpose of processing. Indeed, Art 7(2) GDPR explicitly requires that “the request for consent shall be presented in a manner which is clearly distinguishable from the other matters”. Another legal basis is Art 6(1)(f) legitimate interest. A legitimate interest requires some interest that outweighs the data subject's rights and interests. This balancing test must consider whether the data subject can reasonably expect the processing to occur, given the data subject's relationship with the data controller. I would argue that an event venue does have a legitimate interest to film and photograph events, and that this interest outweighs the data subject's rights and interests at least for larger shots, but not necessarily for close-ups, portraits, etc. The event participants can reasonably expect the audience to be filmed and photographed. Indeed, the linked privacy policy (linked just after the part that you quoted) is very thorough and explains in detail what is happening. The table starting on page 9 describes the purposes of processing, the data being used for that purpose, and the legal basis for that purpose. Here, the relevant entry is: Purpose: Photographs of crowds at our festivals and/or events Type of data: (a) Identity Legal basis: (a) Necessary for our legitimate interests (to capture footage of artists performing at our festivals and events which feature crowd or to record images of our festivals and events for showreel and marketing purposes) This means: they are not asking for consent in the GDPR sense. They are relying on a “legitimate interest” instead. They have to inform you in advance about the processing of personal data – which they evidently did by providing the privacy notice – but they don't have to ask you. So what is that consent about then? The consent you quoted is more about personality rights: you would consent to “being photographed, filmed and sound recorded as an audience without payment, and to [your] image being exploited in any and all media for any purpose at any time throughout the world”. This is essentially a model release.
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.
It is absolutely not the case that Providers are not allowed to keep PII without consent. Article 6 of the GDPR identifies six possible lawful bases for processing personal information. These are: (a) the data subject has given consent ... (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. Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks. If a person requests services from an online service provider, basis (b) will apply, at least to some information. If there is evidence of criminal activity, basis (c) may well apply, as it also will for much routine record keeping. Any in many such cases, basis (e) or (f) will also apply. In short, article 6 does not create a &quot;haven for online criminals/hackers&quot;. In a comment on another answer the OP writes: The offender has the right to not be identifiable and he can't be denied this right That is simply not correct. Nothing in the GDPR says anything of the sort. It is true that consent may not be forced, but if a user requests a service that service may require the user to identify him- or herself. For example, one cannot order physical goods without giving a name and a shipping address. And the provider may retain PI and even PII when it has a &quot;legitimate interest&quot; in doing so, although if challenged it must justify that legitimate interest.
The "Privacy Rule" (45 CFR Part 160 and Part 164, Subparts A, E) don't forbid this. Sect. 164.502 states the general rule: (a) Standard. A covered entity or business associate may not use or disclose protected health information, except as permitted or required by this subpart or by subpart C of part 160 of this subchapter. "Health information" is defnes in part 160 as any information, including genetic information, whether oral or recorded in any form or medium, that: (1) Is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual. Your picture would not constitute health information (and anyhow, they are allowed to gather health information, just not freely disseminate it – the pictures on the wall were presumably with permission). There is no general law (which would be state law) against taking a person's picture (though commercially exploiting someone's picture would require permission, via the concept of personality rights), and it is directly required in a number of instances (for identification purposes – school ID, driver's license, passport, voting in some states). It is an unusual requirement and since they scanned your driver's license it is especially inexplicable. Assuming that this is just a story they tell all patients because they want before and after pictures (which you would have to consent to, if you didn't already in one of those "sign here" flurries), saying that this is for "security purposes" would be untrue, but I don't think it's actually illegal. Taking but not using a photo would not cause you harm, so if you had let them take the picture, there would not be a basis for suing. If they use it for advertising without permission, that would be a problem.
The pragmatic answer is to just ask the data subject what they would like to have erased. The GDPR's right to erasure DOES NOT requires that you “delete all their records in [your] database”. Compared to other GDPR rights, it has a quite limited scope. It is necessary that one ground for erasure in Art 17(1) applies, and none of the exceptions in Art 17(3) apply. For example, you are allowed to retain any data that you need to fulfill a legal obligation (exception in Art 17(3)(b)), such as an obligation to keep financial records for a number of years. In the case of providing course completion certificates, I would assume that your legal basis for providing this service is a contract with the data subject. Contracts directly with the data subject can serve as a legal basis for processing per Art 6(1)(b). It doesn't matter if the contract was paid (consideration is not a necessary element of a contract in civil law systems). As long as this contract is in force, there are no Art 17(1) grounds for erasure. But if the contract is terminated, Art 17(1)(a) would apply: “the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed”. So the data subject could release you from your contractual obligation to provide the certificate verification service, and then require you to delete any personal data in connection with that service. In the unlikely case that you are using a different legal basis for hosting the certificate service: legal basis applicable? grounds for deletion Art 6(1)(a) consent maybe Art 17(1)(b): consent can always be withdrawn Art 6(1)(b) contract yes (see discussion) when the contract is terminated Art 6(1)(c) legal obligation unlikely per legal requirements Art 6(1)(d) vital interests no Art 6(1)(e) public interest unlikely per legal requirements Art 6(1)(f) legitimate interest maybe Art 17(1)(c): objection to further processing per Art 21(2) For all of these legal bases, it is the case that once the legal basis expires, then Art 17(1)(a) provides grounds for erasure. In fact, proactive erasure (without waiting for a data subject request) may be required in line with the Art 5(1)(b) purpose limitation and Art 5(1)(e) storage limitation principles. To quickly summarize all Art 17(1) grounds for deletion: Art 17(1)(a): data is no longer necessary Art 17(1)(b): consent withdrawn (only if Art 6(1)(a) consent was used as legal basis) Art 17(1)(c): objection to further processing (only if Art 6(1)(f) legitimate interest was used as legal basis) Art 17(1)(d): unlawful processing always merits erasure Art 17(1)(e): erasure is required by law Art 17(1)(f): special right to erasure for children Note that it is, in principle, possible to provide certificates without storing personal data. This could make it unnecessary to think about data subject rights like erasure. For example, you could provide a certificate to users. The certificate contains personal data, and you do not store a copy of the certificate. But you could use cryptographic signatures to prevent forgery of the certificate. The signature can be verified without having to store personal data. If you are familiar with web development, the same technique is used for JWT tokens: the data in the token is signed by a secret key so that it can be verified whether a token (and the data in the token) was created validly, without having to store a copy of the data in the token. Limitations of this approach are well-known, such as making it difficult or impossible to revoke certificates. In practice, such data-minimization techniques are overkill. The GDPR only requires appropriate security measures. If you have a legal basis (such as a contractual obligation with the data subject) then it is perfectly fine to store a certificate with personal data in your service. The GDPR obligations stemming from such a processing activity are not particularly onerous.
Per GDPR Art 79, you can sue data controllers if you consider your rights to have been violated. Where you have suffered damages due to GDPR infringements, you also have a right to compensation per Art 82. However, your rights may not have been violate as far as the GDPR is concerned. Under the GDPR any kind of personal data processing needs a clear purpose, and that purpose needs a legal basis. One possible legal basis is consent, but there also are others (such as legitimate interest). Just because you didn't consent doesn't mean that your rights have been violated. Where processing is based on legitimate interest, you can object to that processing of your personal data – but your rights must be balanced against that legitimate interest (Art 21). If your friends post a photo and you only appear in the background, your friends' legitimate interest to post that photo likely outweighs your rights. In practice, suing Facebook because of GDPR infringement is not a sensible way to achieve the outcomes that you likely want. First, this is expensive. Second, it is arguable whether Facebook or your friends should be the defendant. Third, removal of existing data won't prevent the processing of new data in the future. It would be more sensible to treat this as an interpersonal rather than a legal problem, and to talk with your friends so that they don't include you in their photos that they would like to share online. I've focussed on photos because their situation is fairly clear. Voice snippets might not count as personal data when you are not identifiable in them. Personal assistant apps should not be listening continuously, but only start recording when a wake-word is recognized.
There are various tangential ways in which this could be illegal, for example if your subjects are celebrities, you take a picture of them and commercially exploit it without permission in a product endorsement. Leaving aside such fringe cases, in the US, the legal right to privacy comes about, at the first cut, by premise trespass law. If the proprietor tells you to go away, you have to go away; if the proprietor tells you that you cannot take pictures, you cannot take pictures (your right to enter is conditional). Neither of those circumstances holds in your case. There are other tort-law bases for a right to privacy: numerous privacy laws regarding privacy and financial transactions (not relevant here), the aforementioned right of publicity (commercial exploitation of likeness), false light (like defamation, about creating a false impression – I don't see what false information is conveyed by a photo). There is also public disclosure of private fact, but that cat is out of the bag because the subject has self-disclosed the supposedly offensive fact revealed by the picture by eating in public. Intrusion of solitude and seclusion does not exist in the circumstance, since the subject is eating in public where everybody can see: there is no reasonable expectation of privacy. This page sums us Virginia law. The main take-away from that is that there is no common law action for privacy in Virginia, and only an action for unauthorized used of likeness or name.
GDPR &amp; EPD require user consent before storing a users personal information. Wrong. User consent is one of the ways that justify storing personal information, but there are others. You may check art.6 to see the several reasons that allow to store personal information. In this case, it seems reasonable to justify it under the paragraph f (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 course, that means that the data has to be used for this purpose. Avoiding spammers and other banned users would be such a purpose, but you should ensure that you do not send those e-mail address commercial information or even a Christmas greeting. In any case, be careful with anything you store. If along with the e-mail you stored more info, this could be interpreted as excessive and beyond the scope of paragraph f. For example, imagine storing &quot;User wrote nazi statements&quot; explaining why the e-mail is banned; EU laws are very restrictive about storing information about political or religious beliefs.