GDPR - Is having a PDF with fields to fill out classed as data? I have a website which has a link to a PDF form which users can print out and fill in. I'm wondering if somewhere I need to a statement in my privacy policy which justifies this?
There is no requirement about "data" in the GDPR, so provided this is just "data", no. An empty form with fields for personal data contains no personal data. On the other hand, if the form is filled in by the user with personal data (as defined in GDPR article 4), and you receive a copy of the filled in form and process these personal data (as defined in GDPR article 4) - then the answer is: Yes. However, if you do not process the personal data (i.e. the form is just printed out on paper and filled in with a pen, and nobody except the data subject has access to the piece of paper with the filled in form - then the answer again is "no").
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.
As I understand it, the GDPR does not permit sending of personal information (which includes the IP address) without prior consent by the user. That's not exactly true, consent is merely one of six possible legal basis for processing (article 6). For example, processing of personal data can also be lawful if it necessary to perform a contract, legally mandatory, or in the public interest. The court decision acknowledges that but rules out another basis in this case because it considers that it is possible to serve fonts without relying on a third-party ([…] der Einsatz der Schriftarten auch möglich ist, ohne dass eine Verbindung von Besuchern zu externen Servern hergestellt werden muss). Confusingly, it only refers to article 6(1)(f) when it seems to me that (b) would also be plausible but maybe this wasn't raised during the proceedings? If the data controller cannot invoke any other basis for the lawfulness of the processing then yes, the only thing left is asking for consent, i.e. invoking article 6(1)(a). But that doesn't mean that you should expect to be asked for consent each and every time your personal information is being used. The consent form on the site also implicitly assumes consent, which I thought was also a violation. Yes, implying consent doesn't really make sense under the GDPR definition (article 4, see also article 7): ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action European data protection authorities have issued guidelines that detail what that means and clearly reject “bundling” different data processing. The regulation also makes it clear that data subjects should be able to withdraw consent at any time, which does not seem possible with the fonts on golem.de My reading of all this is that assuming consent because you are using a service (or even created an account or checked a box at some point) simply isn't valid consent. Either you don't need consent at all in the first place or what you need is freely given, specific consent and “implying” consent or bundling it with a registration process achieves exactly nothing. But this is still extremely common and it might take some time before enforcement and case law definitively settle this question. Smart data controllers trying to avoid collecting consent (like Meta) have abandoned any claim that signing up to the their services would constitute consent (because that's transparently not the case) and try to bypass the issue entirely using another basis like contractual necessity. This is also being litigated. I know that a EU regulation can be implemented and interpreted differently from country to country, and that a single court ruling in Germany doesn't even mean that the national law was correctly applied. From what I've read, I get the impression that this particular ruling was not unlikely to be overturned by a higher instance, if it came down to it. So my question probably both pertains to German law specifically and the EU regulation itself. That sounds more like the way EU directives work. Regulations are supposed to be immediately applicable (no implementation in national law necessary) with minimal differences between countries (except when they explicitely provide for that). Of course, enforcement would still mostly be in the hands of national court systems and (in Germany) provincial data protection authorities but there are mechanisms to ensure consistency (the European Data Protection Board, prejudicial questions to the CJEU, infringement proceedings from the European Commission…).
The GDPR does not prescribe how information should be pseudonymized and does not even define the term properly. Yet, pseudonymization is suggested as an safety measure in various places, so that pseudonymization should be implemented wherever appropriate. The most useful guidance the GDPR gives is by contrasting pseudonymization with anonymization, where it says that pseudonymized data is still personal data because the data subjects can be identified using additional information (see Recital 26 GDPR). In contrast, re-identification is not reasonably likely for truly anonymized data. A common technique for pseudonymization is to replace identifying information with a pseudonym, for example replacing a name with a random numeric ID. However, this can only be considered pseudonymous if the mapping between the ID and the real value is not available to whoever uses this data. Replacing individual fields in a data set might not be sufficient for pseudonymization because apparently non-sensitive fields could still enable indirect identification. This requires careful analysis taking into account the entire context of the data, so it isn't possible to say whether merely removing names + email addresses achieves pseudonymization or anonymization. What you are doing is redacting parts of sensitive data. I think this is a pretty weak pseudonymization method since it still leaks partial information about the true value, and leaks information about the length of the redacted value. It is possible to argue that this is OK (e.g. if you can show that you have multiple similar redactions so that you achieve a level of k-anonymity). But by default, such partial redactions are likely to be unsafe. Completely removing the sensitive data is much safer. The “Article 29 Working Party”, a pre-GDPR EU body, has published an opinion on anonymization techniques in 2014 (PDF). It does not account for the GDPR's specific phrasing, but provides an overview of pseudonymization and anonymization techniques and puts them into context of European data protection law. It considers how such guarantees guard against attacks such as singling out data subjects, linking multiple records of the same individual, and making inferences about the data subject. In this guidance, pseudonymization techniques that are suggested include encrypting or hashing the sensitive data. However, the guidance warns that such techniques do not provide strong protection against singling out or linking records of the data subject. A bit earlier, the UK ICO had published guidance on personal data, including on the matter of anonymization and pseudonymization (PDF) with some good examples. For determining whether a data set has been successfully anonymized (or pseudonymized), they suggest a motivated intruder test: could someone without specialist knowledge or skills re-identify the data subject? In your example, such a person should not be able to infer that a record about Stxxx Axxdxrxn is about a Steve Anderson. In my opinion, your pseudonymization approach would fail the motivated intruder test unless you have multiple records that could all be about Steve Anderson (compare k-anonymity).
Please note that Google Analytics do not anonymize the data you collect on its behalf unless you configure it to do IP-anonymization. If you use Google Analytics and do not use this feature, you need to have a DPA (Data Processing Addendum) in place with Google in order to comply with the GDPR. This is a real hassle, so unless you absolutely need fine-grained demographic data, it is strongly recommended that you use IP-anonymization. According to our data protection supervisory authority, this is sufficient to comply with the GDPR vis-a-vis Google Analytics. Does data that is anonymized need to be collect in the event of a GDPR Subject Access Request? No. But as the controller, you need to make sure that is is anonymized.
I'm pretty sure that under GDPR, you can indeed request them to send all data they have on you. If it's a complex request, they may charge you something like £10. If they have a lot of data on you, they may list the categories of data they have and ask you to pick one, rather than them having to collect and send everything. They should respond within one month, but iirc in the UK implementation, they can inform you (within that month) that they will respond within three months instead. For the rest, I only know current Dutch law. GDPR is not that different from what we already had (in general terms) and in many cases it even extends it. Under our law (WBP), you can also request a correction of the data in case it is incorrect, or deletion if they no longer need it for the purpose for which it was collected and stored. I don't really know how that works out in practice though, as Facebook can of course claim that "being able to connect you to your friends when you sign up for WhatsApp or Facebook with that number" is a legitimate purpose (in their eyes). They might also not have your full name and therefore not be able to connect your data to your request. Or, perhaps, they have only your full name (and there are probably more people with your name), so they'll have a hard time verifying that it's really your data which they would be handing over or deleting. The company is required to verify your identity before acting on your request. How they implement that is up to them. Under Dutch law, if I remember correctly, any data that can be connected to your person by any party is personally identifiable information (PII). While Facebook might not be able to find who's behind a phone number, your carrier most certainly can. Therefore, the data falls under PII protection laws and they will have to implement a way to verify you and get you your data. Finally, whether your local laws apply to Facebook, I don't know exactly. There's lots of information on this though, so you should be able to find it. Generally, countries say that if something happened within their territory (e.g. you signed up for WhatsApp while in the UK), their law applies. Companies, I've read, will instead try to claim that their main office is in SomeCountry and therefore SomeCountry's laws apply. But I'm pretty sure you'll be able to find a Facebook office somewhere where GDPR applies, so that's probably fine. While not an exact answer and while I am not sure about everything, I hope this gave you some pointers to go on!
You could, but how should the companies that want to handle your data know this? If they have no affirmation from you that you allow them to process your data in any way, other than those they are already allowed to because of the exceptions, they have to - under GDPR - assume you don't want them to process your data, and thus have to ask you.
The intention of the GDPR is to minimize the amount of personally identifiable information (PII) you store. So the GDPR never tells you that you have to log certain events. The simplest way to make sure you comply with the GDPR is to simply not store any PII at all. But that might of course conflict with legitimate business interests and with other legal obligations you might have. So when you do store PII, then the GDPR regulates under which conditions you are allowed to store PII, for how long and what you are allowed to do with that PII. So when you receive a GDPR request from a customer to see their data, then you can say that you only have that one timestamp of their registration, because you didn't log their subsequent logins (assuming this is the truth). I hope your privacy policy says that you store all that PII on registration and that you have some good arguments why storing that information is a &quot;legitimate interest&quot; of your organization.