GDPR Representatives of controllers or processors not established in the Union - Is this basically a simple mail-forwarding activity? Art. 27 of GDPR says that whoever processes data of people located inside the EU (includes storing and deleting in the GDPR definition, with a few exceptions) needs a Representative located inside the EU. This relates to a lot of apps and webpages. The Representative has to answer questions about private data in the name of the processor (who, in this scenario, is not located in the EU), and the Representative is not liable (GDPR says so, but it looks like this is not yet 100% confirmed when you read through various law blogs). To get such a Representative, one can e.g. rent a service typically for about 100 - 200 EUR per month, and they typically charge another 100 EUR per request (actually, per hour working on a request). This could be quite expensive. My question is, since to my understanding the Representative just passes requests and answers via mail to the processor (who is outside the EU), couldn't this be any person inside the EU working on much lower cost without real personal risk? The commercial services claim of course that much much work and knowledge is required, but going a few times through the GDPR text, I still see practically a simple mail-forwarding activity as long as the processor provides all required documents in the required form. Businesses inside the EU don't care about this because they get the requests directly, and do the Representative's job by themselves.
Yes, the role of a Representative is largely to serve as a point of contact for supervisory authorities and data subjects. Much of this could be done by a person who just scans and forwards any incoming mail. In practice, the Representative should be a lawyer or at least a compliance professional in order to fulfil their role effectively, in particular when it comes to a lawsuit or administrative proceedings against the controller/processor. These would be carried out against the representative on behalf of the controller/processor. Regarding liability, recital 80 explicitly says: “The designated representative should be subject to enforcement proceedings in the event of non-compliance by the controller or processor.” This doesn't shield the controller/processor from liability, this just simplifies enforcement and ensures that judicial remedies are in fact available to data subjects. There is a much more imminent consequence for the choice of Representative: which data protection agency will serve as main supervisory authority. Non-EU controllers might prefer the convenience of an English-speaking authority, otherwise (expensive) translation could be needed. Consequently, Representatives based in Ireland are effectively the default choice. Many representatives do offer extra services, such as offering to serve as a Data Protection Officer. That would help justify the fees. Unfortunately, the conditions for appointing a representative and for appointing a DPO are somewhat different: per the letter of the law many controllers would need a Representative but not a DPO. A Representative is needed as soon as data processing is non-occasional, whereas a DPO would only be needed for processing on a large scale. I'll just add that many controllers forget about that and only think about getting a representative when appointing a DPO. Since the Representative aids enforcement, enforcing against a controller without a Representative is rather difficult, and I don't know of any fines for failing to appoint a Representative.
If you want some boilerplate text to just drop in and have done, you are going to be disappointed. But you don't need a lawyer either. Treat it as a coding job. First, list all the ways you are going to store and process identifiable user data. If someone is going to process it on your behalf, identify them too. Draw a chart showing the paths that user data is going to take. (Storage is a form of processing) Then look at the 6 bases for processing user data and figure out which ones apply to each step. E.g. if the user asks you to do something then that is one basis under which you can process their data. See how much coverage you can get without asking for consent. For each third party (e.g. Google) figure out what data is to be sent to them, and where they will be. Google has data centres in the EU specifically so you can get them to process user data without sending it outside the EU. Check the third party contracts for these services, including the confidentiality clauses. Link that to the processing they will do for you. Finally, pull all this together into a single summary of what you are going to do with the data and the bases under which you will do it.
Since you are from Europe, GDPR applies to all your processing activities per Art 3(1) GDPR, regardless of where the users are located. If you would like to avoid GDPR compliance, you would have to manage your business from abroad so that you no longer have an European establishment, and would have to avoid offering your services to people who are in Europe. So let's assume that you have no European establishment. Then, GDPR can only apply per Art 3(2) to those processing activities that relate to offering goods or services to people who are in Europe. For determining this, IP-based geolocation is indeed common. Very likely, you do not need consent for this. GDPR does not require consent for everything, just a legal basis. There are six potential legal bases in Art 6(1), though the relevant ones are consent, necessity for performing a contract, legal obligations, and necessity for a legitimate interest. For things like security checks, it would be common to claim a legitimate interest. Complying with GDPR can hurt revenue. However, data subjects have a right to data protection, but you do not have a right to a particular business model. Similarly, paying taxes can &quot;hurt revenue&quot;, but it's not really optional. If your business model can't deal with GDPR compliance (or with taxes), it might not be a sound business model. In Europe, many newspapers have since moved from advertising-only to a consent-or-pay model. That is, the user is given a choice: You can read articles without tracking if you buy a subscription. You can access articles for free if you consent to tracking. The legality of this is hotly debated. In principle, such an approach can be compliant, but the details are problematic, for example that you can only buy subscriptions rather than individual articles, and that these subscriptions are often orders of magnitude more expensive than what would be earned through ads. But this might actually be easier to solve for a mobile application than for a website, due to the availability of in-app payment and micropayment infrastructure. In any case, GDPR limits how much you can &quot;encourage&quot; consent – per Art 7(4), you cannot make access to your service conditional on consent. There must be a way to use your app without consenting to anything, unless that consent is actually necessary for the app to work. For example, consenting to camera access is necessary for a QR code reader app to work. It is extremely unlikely that ads would be necessary in this sense. Users also must not suffer detriment for declining or withdrawing consent. From this, the EDPB has developed the concept of &quot;permissible incentive&quot; in their guidelines on consent. In this post, &quot;Europe&quot; means EU/EEA/UK as appropriate.
In order to process data (which includes storing data), a data controller must establish one or more of the lawful bases contained at Article 6(1) of the UK GDPR. Briefly, those are: a) Consent of the data subject b) Necessary for performance of a contract with the data subject c) Necessary for compliance with a legal obligation d) Necessary to protect vital interests of data subject or another person e) Necessary for public interest or exercise of official authority vested in the controller f) Necessary for controller's legitimate interests Clearly a) and d) don't apply. As you've settled the debt, it seems unlikely to me that b) or f) apply. That leaves c) and e). A common example under c) would be a requirement by Companies House or HMRC to keep accounting records for a certain period of time. Some public bodies may also find it necessary, under e), to retain records which they need to be able to carry out their other functions. It seems highly unlikely to me that either of these would justify retention for your &quot;lifetime&quot; however. I would start by sending them a written demand to have your data erased under Article 17(1). Make sure you also specifically request that they provide you with all the information (and in particular the purposes of the processing) under Article 15(1), and that, in the event that they refuse to erase your data, they explain the reasons why pursuant to Article 12(4). Their response on these points will be helpful in establishing whether there is a lawful basis. Your next step after that is either to complain to the ICO or to apply to court for a compliance order under Section 167 of the Data Protection Act 2018. The former is free while the latter is not and carries risks of cost if you are unsuccessful. If you opt for one of these steps, make sure you cite the relevant provisions of the GDPR and explain why you think there is no lawful basis for the data retention (including by referencing any response you received from them). &quot;I have read GDPR guides on how to request erasure, but I don't really feel this applies- I want to have my account deleted, not the track record of the loan and repayment&quot; It doesn't matter whether we are talking about your account or your track record. What matters is whether the account constitutes personal data, which it almost certainly does, per the definition at Article 4(1): &quot;‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;&quot;
Under GDPR Article 6 section 1(f), a lawful basis for processing is: 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. It seems that informing a data subject of the availability of a possibly better-focused related site would be a &quot;legitimate interest&quot;, and merely doing a broad geo-locate on the IP does not seem to impact the &quot;interests or fundamental rights and freedoms of the data subject&quot; so it would seem this could be done without specific consent in advance. I don't know of any legal case on this specific point, however.
I'm not aware of any cases on point, but as a rule legal fig-leaves don't play well in court. If the webmaster simply puts up a banner saying that EU residents are not permitted but takes no other action to exclude them, then that is going to be considered irrelevant. The webmaster is still very likely required to comply with the GDPR. On the other hand if the webmaster takes other steps to exclude EU residents, such as using a geolocation service to block connections known to be in the EU, validating email addresses and blocking those from EU domains, and ejecting anyone who mentions that their residence is in the EU, then that is more likely to be seen as a good-faith attempt to avoid being subject to the GDPR. It will also have the practical effect of greatly reducing the number of actual EU residents. All these controls can be evaded, but it would be much harder for any data subjects to claim that they acted in good faith or that the webmaster acted in bad faith. Note that validating an email address or logging an IP is itself processing of personal data, so anyone implementing such a system still can't ignore the GDPR completely, but it would greatly limit the scope and make it easy to delete any such data after a short time. (Note: the term &quot;EU resident&quot; above is an approximation of the territorial scope).
Your confusion might be caused by the fact that even with a contract, only the data necessary for that contract is covered under the GDPR. So yes, while there might be an &quot;execution of contract&quot; under the T&amp;C, this would only cover necessary data. That means you can't ask arbitrary signup data under the guise of a contract. If you need to deliver a physical product, you can store a physical address. If it's an online service, you can store an email address or similar handle. But you can't mix the two. A physical address is unnecessary for the execution of a contract that's not physical in nature. Now, you mention &quot;consent&quot;. Under GDPR, this is a distinct justification besides &quot;execution of contract&quot;. You might have consent to store a physical address in addition to an online address, e.g. if you offer a customer to physically mail a password request form. This consent is additional to the contract. Also note that the bit above only covers the lawful reasons for the processing of personal data (article 6). You also have to obey the other GDPR rules, e.g. fully inform the user, make sure that consent is freely given, etc.
No GDPR applies to people (not just citizens) who are in the EU. It has no applicability if both parties are not in the EU.