Practical GDPR guidance for online businesses When you start an online business, or even just create a website, there is a lot of confusion on what needs to be done to comply with GDPR. As many online resources (including StackExchange) suggest, it is next to impossible to have a website and not fall under GDPR rules. Furthermore, there seems to be some confusion and back-and-forth on what is deemed compliant, and what's not. If you want to clarify how GDPR rules apply in your case, the usual advice is to &quot;get a lawyer&quot;. However, this is not practical for many small starting online businesses that have no resources to pay for a full time legal advisor. So I am hoping to gather some practical tips about doing this without employing a lawyer. First, let me lay out some assumptions on the nature of the business: It is new and small in every sense of the word: a few dozen customers, $1k-2k monthly turnover It is based in UK It is not dealing with extra-sensitive data like bank account numbers or identity documents And now some specific questions: What would be the best strategy in terms of &quot;cost vs reliability&quot; to ensure GDPR compliance? Would it be practical to follow one of the many GDPR tutorials online to choose a proper hosting, security measures, etc? If I unintentionally use a non-compliant hosting configuration or a 3rd-party service like Google Analytics that transfers customers' data to a &quot;unsafe&quot; jurisdiction, what consequences is it likely to bring about? Are there any examples of this happening? How severe should data processing faults be for the business to be facing serious fines and lawsuits (vs. just fixing the fault and issuing an official apology)? What would be a sensible time to actually employ a GDPR advisor? Is this based on the kind of data that the company handles? On the number of customers? On the turnover?
It is entirely possible to reach a reasonable level of compliance in a DIY approach, provided that you familiarize yourself with the relevant legal framework. The UK ICO has produced in-depth guidance to help here, which is significantly more digestible than the laws themselves: ICO Guide to the UK General Data Protection Regulation (UK GDPR) For a first reading, it is probably appropriate to focus on the summaries and checklists at the top of each section. You will however notice that GDPR is a lot about principles, and requirements like selecting appropriate compliance measures yourself. On one hand, this means that you have some flexibility in your compliance approach, but it also means also that you can never be sure whether you're actually compliant. But this is also precisely why professional help can be valuable, since compliance professionals probably have a better overview of best practices, state of the art measures, and also potential pitfalls. In some other answers, I have written basic overviews/checklists to get started with a GDPR compliance effort. On to your concrete questions: What is the best strategy to get started with GDPR compliance? This is ultimately a business decision that you have to make. You have to consider how much compliance is worth to you, both in terms of time and money. Maybe you can DIY it, maybe you'll want to get professional help, maybe you'll just hope that no one ever sues you or lodges a complaint. There is no objective optimum, and only you know your particular situation. What are the consequences for unintentional infringement? Not being aware of the rules is not a valid defense (ignorantia juris non excusat). How are fines calculated? The GDPR has two separate enforcement mechanisms: data subjects can sue you for compliance and damages, and the ICO can fine you. Damages are typically small compared to the cost of a lawsuit. When issuing fines, the ICO must consider a variety of factor per Article 83, for example whether the infringement was willful or negligent. The ICO is not required to impose damages, and anecdotally many small problems can be resolved informally before it comes to a full investigation. In particular, the ICO's Regulatory Action Policy 2018 explains that “we will reserve our powers [to issue fines] for the most serious cases, representing the most severe breaches of information rights obligations. These will typically involve wilful, deliberate or negligent acts, or repeated breaches of information rights obligations, causing harm or damage to individuals.” The policy also provides a 5-step process for arriving at fines: removing financial gain, accounting for scale and severity of the breach, considering aggravating factors, ensuring a deterrent for others, and considering mitigating factors. This suggests that a good-faith effort to ensure compliance already goes a long way. When to get professional help? Under some circumstances, the GDPR requires that you appoint a data protection officer, who doesn't have to be an employee. You mention that you do not process sensitive data, so that it is currently unlikely you'd be required to appoint a DPO (compare Art 37, but note that the list of sensitive categories of data in Art 9(1) does not match your examples). The requirement to appoint a DPO depends entirely on the kind and scale of your data processing activities, not on number of employees or revenue thresholds. However, some GDPR compliance obligations like Art 30 Records of Processing Activities can also trigger when you reach 250 employees. Aside from that, it is a business decision whether and when to invest in compliance. Note that if your business offers goods or services to people in the EU/EEA, you may be required to appoint an EU representative. Some law firms offer package deals for DPOs + EU/UK representatives.
It is not different. But one company can decide to approach compliance differently from another. Here, TomTom has chosen a fairly safe/conservative interpretation, whereas Google and Apple decided that more data collection is appropriate. A “find my device” style functionality appears to be entirely unproblematic if the user books that particular service (regardless of whether the service is paid or gratis) and provides consent for the location data collection. The legal basis for such a service could then be Art 6(1)(a) consent or Art 6(1)(b) necessity for performance of a contract to which the data subject is party. Personally, I believe that Google is not sufficiently transparent about how Find My Device works, but that TomTom could provide a compliant service if they wanted to. That TomTom doesn't offer this service primarily shows that they don't think developing this service is worth it. Wiping a remote device is unrelated to this issue and doesn't seem to provide GDPR challenges. At least in a business context, remote wiping may be an appropriate security measure and may then even be mandated by the GDPR (e.g. see Art 24 or Art 32).
This is less of a compliance question, and more of an infosec question. On one hand, you want to be able to restore access to an account to users who have lost their access. On the other hand, you must prevent unauthorized access e.g. from hackers. These factors must be balanced. Whether you'll fulfil a data subject access request will generally follow the same criteria as deciding whether you'll reset someone's access credentials, so I'll mostly discuss identity verification in general. Trying to validate names is generally pointless from a security perspective, since the name on the account might not be real, or because validation documents like scans from a passport can be easily forged. When a service has identity validation measures like requesting a copy of photo ID, or requesting a photo of you holding up a validation code written on paper, that doesn't actually help validating that the person requesting access is the account owner, but that the person requesting access appears to be a natural person, and now documents about their identity are on file. A lot of information like names, birthdates, or addresses is also not at all secret and could be easily guessed by a malicious actor. Most websites work by equating access with control over an email account. If you can receive a password reset code over email, you have access. In effect, this delegates the responsibility of account recovery to the email or OAuth provider. So the issue is what happens when someone loses their email account, which is not entirely uncommon for accounts that are multiple years old. One reasonable (and likely GDPR-compliant solution) is to deny access when someone loses their account. Quite a lot of services operate this way. A milder form of this is to email the old address that someone is trying to take over the account, and turn over the account only if you have other evidence of ownership and there has been no reply over multiple weeks. Since this is part of an identity verification measure, I don't think the GDPR's normal 1 month deadline would apply. However, this approach is very risky: an attack can succeed through the mere inaction of the true account holder, and it would arguably be a data breach if you give access to the wrong person – safer for erasure requests only. Also, emails like “click here or we'll delete your account” look a lot like spam (I get a lot of those about alleged problems with my Paypal account). A potentially more reasonable approach is to use questions about the account to verify ownership. When did they create the account? When did they last use it? Can they answer questions about non-public content of the account? (But don't let an attacker choose the questions!) You see some older sites that ask the user to select a “security question” for recovery purposes. But this isn't a best practice – they are frequently the weakest link in an authentication system. If the user answers truthfully, the answer may be easy to guess or discover for an attacker. E.g. the infamous “what is your mother's maiden name” question is horrendously insecure in the age of Facebook. If the user provides a more secure answer, that is essentially just another password that's even easier to lose than an email account. High-value accounts typically offer a secondary authentication method as a fallback. E.g. my bank can send me new access codes via physical mail. GitHub can optionally link a Facebook account for recovery purposes. But these measures would be overkill for most cases. Especially collecting a physical address for the sole purpose of offering account recovery would likely violate the GDPR's data minimization principle, though it may be fine when the user opts in with freely given consent. To summarize: what you're trying to do is extremely difficult, because you've need to balance different security aspects: keeping malicious actors out, and letting legitimate account owners in. Whereas I'd resolve that by denying any account recovery or subject access requests, other approaches exists with other risk profiles. The GDPR requires you to perform reasonable identity verification measures, but what is reasonable depends on the business context and is ultimately an infosec question.
In German Law you need to give your agreement ("Willenserklärung") to a contract or in this case terms of service. This is done by telling the other part. In some cases this can also be implied by an action (example: putting your bottle of beer onto the cashiers table is an offer to buy this bottle). As a second criteria a "Willenserklärung" needs to be the exact will of the part that declares its will (the website user in this case) §§ 133, 157 BGB or that the other side (you) could only see so (not the case here as this mainly speaks of content). If you visit a website and there are terms of services, the "Willenserklärung" is only given when the user read and agreed to the terms. If he did not, the terms of service are not applied until the user agrees to them. So I would recommend to block the website until the user agreed (overlay) as you need to proof he did when in court. Additionally there are so called AGB's in Germany. Those are contracts that are used or planed for many (more than 3) uses and set by one side (you). This may apply here, so you need to follow a lot of other rules like making sure the user had access and agreed, then there are many content restrictions and so on... I recommend consulting a German Lawyer specialized on this topic as this is very complex and includes other German laws for Media too, depending on the content of your site and terms. Also note that everything said is only based on my own knowledge and can not be used as safe legal source.
You don't need to get consent to comply with GDPR Lawfulness of processing Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (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. Sending a http request to a website falls under 6(1)(f).
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.
As always, it depends. However, it is by no means certain that any public facing hobby project, such as a web app, is exempt from having to comply with the GDPR. Since the GDPR is only a few days old, we have of course no case law based upon the GDPR itself yet. However, when considering this, one should take the following two facts into consideration. 1. The "personal use exeption" in the GDPR is not new. The personal use exemption is unchanged from the article 3(2) of Directive 95/46/EC. (There as a lot of lobbying for removing "purely" from the sentence – but drafters wanted to keep it.) 2. Case-law under the previous regulation restricts the scope of the exception The ECJ has ruled on the scope of the personal use exception in two cases: C-101/01 C-212/13 In both these cases, the ECJ took an extremely restrictive view, and concluded that the personal use exemption did not apply to the processing done by these individuals. In C-101/01 it can be argued that the hobby project as a blogger was connected to the controllers professional activity (she was a catechist in a local church, and blogged about her work. including her colleagues). But in C-212/13, there no such connection to professional or commercial activity. Here, the controller operated a CCTV to protect his home, but set it up to also capture public space, and that was enough for the ECJ to decide that the personal use exception did not apply. Discussion Case-law based upon Directive 95/46/EC is in no way binding for a future court that need to rule based upon the GDPR. We need to wait for case-law decided under the GDPR to be able to have some degree of certainty about the scope of the "private use exception" under GDPR. However, given what we know about how the ECJ has ruled in these cases in the past, I think it is hazardous to think that just because what you are doing on the web is just a "hobby project" not connected to professional or commercial activity, you are exempt from complying with the GDPR. Conclusion IMHO, you may be exempt, or you may not be exempt. I think it really depends on your activity in your hobby project, and to what extent this project processes the personal data of other people than yourself.
If a data controller fails to fulfil your data subject rights, lodge a complaint with your data protection authority. In Hamburg, the appropriate form is here. However, they are not required to investigate your complaint. Independently from a complaint, you could consider suing Wordpress for compliance – Automattic has a subsidiary in Ireland so this might actually be feasible. I'm not quite sure though that Automattic is indeed the data controller for wordpress.org, as opposed to the .com domain – the privacy policy isn't quite GDPR compliant. While your GDPR Art 17 Right to Erasure might not apply in this case, there's a definite GDPR violation because the data controller failed to respond to your request within a month as per Art 12(4). That your posts on the bugtracker were deleted doesn't look like an issue in this context, what does matter is that they didn't respond to emails to the addresses mentioned in their privacy policy. Whether you have a right to erasure depends on the legal basis for storing your data. In general, you have a right to erasure if: the data is no longer necessary; processing is based on consent (because you can always withdraw consent); or processing is based on a legitimate interest and they have no overriding legitimate grounds to continue processing despite your objection (Art 21). The data is still necessary to identify you for your actions on the bugtracker, but depending on your particular situation you may be able to object successfully and force them to anonymize your posts.