In case a company is flooded by &quot;asymmetric&quot; GDPR-related requests (request via email, preferred answer via postal mail), how should a company react? Concerning the individual's right about information about one's data, Art. 12 GDPR (&quot;Transparent information, communication and modalities for the exercise of the rights of the data subject&quot;), (3) says ... Where the data subject makes the request by electronic form means, the information shall be provided by electronic means where possible, unless otherwise requested by the data subject. Now if someone askes a company for his data via email (free) and wants to get the answer via postal mail, the company has some cost (letter, print-out, stamp), which is minor, but becomes huge if a large number of people perform such requests someone with bad intentions sends lost of requests via different emails (easy to generate anonymously) and requests postal mail answers to different addresses which are taken e.g. from some phone book. Here it is nearly impossible to prove that the requests are &quot;unfounded or excessive&quot; as described in (5) of Art. 12 GDPR because they look like coming from a lot of different people. Some online tools could easily be abused to create such requests (for sure this is not the intention of such a tool, but the whole question came to my mind when I was playing around with this tool in the link). Question: In case a company is flooded by such &quot;asymmetric&quot; requests, how should a company react? Start answering via email and ignoring the requester's wish to get postal mail?
In case a company is flooded by such &quot;asymmetric&quot; requests, how should a company react? Although article 12.5 refers to singular &quot;a data subject&quot;, it can be inferred that exposing the controller to significant expenses is not part of the legislative intent. Accordingly, the company may have requesters choose between paying a reasonable fee for the ensuing administrative costs or withdrawing the requirement that delivery be by postal mail. The bad faith scenario you outline seems to be a non-sequitur, since generally a pattern (or a high number) of requests for postal mail delivery should prompt the controller to suspect that some or many might not be legitimate. A requester with bad intentions would be unable to prove the identity of the various data subjects he impersonates or alleges to represent.
An app(lication program) is software run on the end-users machine. That does not fall under the GDPR. Any processing (including storage) you do on user data has to be compliant with the GDPR. Allows a user to authenticate via e.g. Facebook and stores some basic data (optional) Authentication via Facebook leaves GDPR compliance to Facebook (AFAIK). It would be a good idea to provide alternative authentication methods, such as Google and an "own account" user name and password so that the user doesn't have to share information with a multinational company in order to use your service. The "basic data" will need to be processed according to the GDPR. As long as the "optional" part is "opt in" (i.e. the user needs to at least click on something) then this means you have permission to process that data. Providing this "basic data" as a JSON or CSV file should meet data portability requirements. Allows a user to upload a GPX file (a route or some other activity) Stores the above file to Google's database Allows the user to analyze that file. Since the user is actively choosing to upload each file you have permission to do this. You should make it clear in your privacy policy that the data will be held by Google. Doing so should not be a problem as Google has set up the legal framework to do this under the GDPR. You don't have to store the information encrypted, but you should use encryption (e.g. HTTPS) for any data transmission. Allowing the user to analyse the file is not an issue; either the user is doing it on their own machine (GDPR irrelevant) or you are doing it under user instruction (meaning you have consent). Since the user has uploaded GPX files they already have data portability on those files. You should tell your users that while you will employ best endeavours you don't promise to keep their files accessible and they should maintain their own private copies. That way if your entire database gets corrupted they can't blame you for loss of data. Finally, make sure there is a "Close my account and delete all my data" option.
If you are purely a designer (and not contracted for the daily operation of the site), the answer is "no". GDPR Article 4 defines the "roles" responsible for complying with GDPR, and there are two: Controller and Processor. The Controller is the one who calls the shots. In particular: Decides what personal data to process. This is usually the owner of the web site. The Processor is the one that actually does the processing. This is usually some company providing some sort of data processing service (e.g. SaaS, PaaS, etc.). The relationship between the Processor and the Controller must be contractual. The contract is called a DPA (Data Protection Agreement or Data Processing Addendum). As a designer, you don't fit into any of these roles. If your contract with the client is silent on liability for GDPR compliance, then you have no liability. This goes for projects completed both before and after the May 25 deadline. Of course, if there are GDPR clauses in your contract, then you must fulfil them just as have to fulfil any other contractual obligation. But unlike the controller and the processor, there are no automatic legal liability for a designer or programmer.
The CEO wants to "fool" users You are essentially admitting that the company you are working for is about to deceit its customers and asking whether that is legal. The relevant set of laws is rather sparse and does not give direct answers in regards to oAuth tokens or other details of that level (which is probably making your CEO think he can "handle" the arising questions). Probably the most relevant bit of legislation that applies here is The Federal Trade Commission Act (15 U.S.C. §§41-58) which prohibits unfair or deceptive practices and has been applied to online privacy and data security policies. I am pretty sure that, in practice, if the users take your company to court, it will be held liable because: users are allowing us to read their CRM data and once we get the data, the data become ours, and we can do whatever we want with it. Is this true? While the users are still allowing you to read their data it is completely up to the Terms/EULA what you can do with it. However, once you have made the users think that they have withdrawn your access (e.g. they "deleted" oAuth tokens), you are no longer authorized to read the current data (although the Terms may still allow you to use the old data you obtained when you had access). Silently continuing to access their data without their knowledge/approval is definitely a deceit. The CEO wants us to download all of their emails and store them in our database There would be nothing wrong with that if it was in the Terms. But if it is not, that would be a blatant (and easily punishable) breach of privacy. Note that you may also be held personally liable for this wrongdoing (if/when proved so). "Just doing your job" claim will not work.
You premise is correct. The processor is someone that processes data on your behalf, and since the GDPR definition of processing is extremely broad, that is about every third party subcontractor that you use for data processing, including various cloud providers. I'm afraid it will soon become a huge mess with a gazillion contracts to sign. I disagree. Yes, the GDPR says that a contract between the controller and processor must exist, but Article 28 of the GDPR does not say anything about how the controller shall document these instructions. Basically, in cases like the one you describe where John Doe relies on a web agency for having a contact form on the web, there will be a standardized (by the web agency) service agreement between the John Doe (controller) and the web agency (processor). There is nothing stopping the parties from agreeing that this service agreement that John Doe accepted as part of the onboarding procedure is also the DPA as required by the GDPR. Putting something like the following in the service agreement would do it: The parties agree that this Service Agreement between You (controller) and Us (processor) set out Your complete and final instructions to Us in relation to the processing of Personal Data and that processing outside the scope of these instructions (if any) shall require prior written agreement between You and Us. You also agree that We may engage Sub-processors to process Personal Data on Your behalf. The Sub-processors currently engaged by Us and authorized by You are listed in Annex A. I think we will se a lot of amendments in service contracts as the GDPR gets better understood, but I don't really see a flood of DPAs in addition to these amended service contracts.
Art 13 GDPR is about information to be provided when data is collected directly from the data subject. This information can be provided directly during/before collection. It is not generally necessary or useful to send the data subject an email with this information. Usually, a SaaS website will provide the information under Art 13 as part of their privacy policy, and link it in easy to find places. Also consider the EDPB guidelines on transparency, which suggests a layered approach: in addition to a detailed privacy policy, summarize key information directly when the data is collected, e.g. next to an input form.
No, it is not legal. Regardless of their location, the only legal options for companies serving to EU residents are to either deny access altogether or to make consent truly optional1 Recital 42 states (emphasis mine): Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement[...] Recital 43 states: Consent is presumed not to be freely given [...] 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. 1 Of course, remember that consent is only one of several means that allow them to process data. For example, if you were getting a trial account for a limited time, it would be considered a legitimate business need to ensure that you are not just opening new trial accounts when the old ones expire. So, if they wanted some data from you to ensure that you are not a previous user and you refused to provide it, then they could deny giving you that trial account without breaking the GDPR.
There is a lot going on in this question, so I'll pick out some individual aspects. Last but not least, I'll discuss if GDPR even applies. Does the GDPR require consent for X? Almost always, no. Consent is only one of many legal bases of processing. A common alternative to consent is a “legitimate interest” where a balancing test is performed between this legitimate interest and your interests, rights, and freedoms. Consent is typically only appropriate if this balancing test fails, for example if you would not reasonably expect this processing activity to occur. It's worth noting that it's a reasonably common occurrence that businesses are sold or merged. This is not unexpected. In general, you would not be required to consent to such a transfer. What can a company do with personal data acquired through a merger/acquisition? The GDPR does not provide explicit provisions for this case. But it might be useful to think about the two cases where (a) the new company is a continuation or successor of the original one, and (b) where the data is transferred (“sold”) to an otherwise unrelated company. In case (a) where the business is continued as normal, there is no change. In case (b) where data is transferred to a separate company, things are more complicated. The original company would need a legal basis for transferring the data. But as mentioned above, there might be a legitimate interest. Arguably, such a transfer could also be based on Art 6(1)(b) if the transfer is necessary to continue to provide the service, for example if the original company would otherwise have to terminate service. Of course, activities like data brokering where access to data is granted to unrelated third parties would generally fail to be covered by contractual necessity or a legitimate interest, and would probably need consent – but that doesn't seem to be the case here. When a data controller (such as the new company) acquires your personal data from sources other than directly from you, then they are subject to the notice requirements in Art 14. They have to actively notify you about their processing activities. But because you received emails that mentioned the transfer, this condition might have been met. Of course the new company continues to be bound by the purpose limitation principle as detailed in Art 6(4) – they can only use the data for purposes that are compatible with the purposes for which the data was initially collected. Thus, the new company cannot arbitrarily widen processing purposes, though some change in scope is certainly permissible. How does the GDPR right to object and to restrict processing apply here? The Art 21 GDPR right to object means that if the legal basis for a processing activity is a “legitimate interest”, then you can ask for an opt-out. But in some cases, this objection does not have to be granted. An objection essentially requires the controller to repeat the legitimate interest balancing test, taking into account the “grounds relating to [your] particular situation” that you provided in the objection. The Art 18 GDPR right to restrict processing is an alternative to the right to erasure. It applies only in narrow circumstances, for example while an objection is being checked. It is likely that you were informed about the transfer to a new company about 1 month in advance, so that you would have been able to prevent this transfer by closing your account prior to the deadline. If the new company conducts processing activities based on a legitimate interest, then their presumably GDPR-compliant privacy notice about which you were notified will certainly explain that you have a right to object. Is the new company GDPR-compliant? That is impossible to tell, but nothing you've shown so far indicates that they're non-compliant. My largest issue with this story is that the new company is from Australia, a country with extraordinarily bad privacy protections (as of 2022). However, due to the way how the GDPR treats international transfers of data, this doesn't prevent Australian data controllers from being GDPR-compliant, although it does make it difficult for other companies to use services based in Australia. Does GDPR even apply? Whether GDPR applies to a non-European company depends only on whether they either offer goods or services to people who are in Europe (“targeting criterion”), and whether the monitor people's behavior that takes place in Europe. Factors such as your citizenship would be irrelevant. I'll ignore the monitoring criterion, and focus on the targeting criterion. I'll assume that you are in Europe (EU/EEA or UK). Whether a company is targeting people in Europe depends primarily on the company's intentions. It does not matter whether the service is accessible from Europe. Thus, it is quite possible that the original company was not subject to the GDPR. Then, any questions about GDPR, consent, and data transfers are moot. In contrast, the new company clearly mentions GDPR-compliance, which would only matter if they intend for people in Europe to use their services. So GDPR probably applies to them, giving you the full suite of GDPR data subject rights as (hopefully) outlined in their privacy notice. And as long as they notified you that they acquired your personal data in accordance of Art 14, I don't seen anything that they might have done wrong in respect to this acquisition/merger.