Am I obligated to decrypt lots of data for GDPR requests? I am providing a B2B service where customer data of businesses are stored in an SQL table. As I never need to query for this personal data, the data at rest there is asymmetrically encrypted with the associated businesses public key. Since the information is encrypted, I cannot query for any personal customer data. Example of the customer table: ------------------------------------------------------------ | business | firstname | lastname | private-data | ------------------------------------------------------------ | 12345 | xXencryptedxX | xXencryptedxX | xXencryptedxX | ------------------------------------------------------------ | 12345 | xXencryptedxX | xXencryptedxX | xXencryptedxX | ------------------------------------------------------------ | 12345 | xXencryptedxX | xXencryptedxX | xXencryptedxX | ------------------------------------------------------------ | 12345 | xXencryptedxX | xXencryptedxX | xXencryptedxX | ------------------------------------------------------------ For a GDPR information request I would need to fetch every single entry (tens of millions), associate the private key of the linked business, decrypt every single entry and do a string comparison search for every entry. Given the enormously high cost of processing the data, am I obligated to do so as per a GDPR information request or could I argue that this would be a disproportionate effort as per Article 14? After all, I am demonstrating my willingness to ensure high effort security by voluntarily only storing it encrypted.
It is the data controller's responsibility to respond to data subject requests. If you provide a B2B service, you are most likely a data processor who only acts on the controller's behalf, on the controller's explicit instruction. This will depend on your contract with the controllers, your customers (see Art 28). Typically a processor would merely forward any data subject requests to the controller. Only if you are contractually obligated to serve data subject requests would it be possible for you to respond directly. If a processor were to fulfil a data subject request on their own initiative, that would arguably be a GDPR violation. However, the processor has to assist their controller with compliance per Art 28(3)(e), e.g. by implementing an admin interface through which the controller can service GDPR requests. The core issue here is that controllers and processors have slightly different obligations in order to be GDPR compliant. Controllers owe compliance to the data subjects, but processors only act on the controller's behalf and owe compliance to their controllers – they have no direct relationship with data subjects. Assuming you were a controller, then yes, I would assume you would have to decrypt any data that you are able to decrypt in order to fulfil a data subject request. Access requests can only be denied if: Art 12(5): they are “manifestly unfounded or excessive” (which the controller has to demonstrate), or Art 15(4): the access would “adversely affect the rights and freedoms of others”. Art 11(2): the controller can demonstrate that they are actually unable to identify the data subject so no data subject rights in Art 15–20 apply. A request is not automatically excessive just because it will require substantial CPU time, this exception is more often triggered when data subjects request the same data very frequently (e.g. every week). You are not required to provide or search data that you don't have access to (e.g. E2E encrypted data). Your use of per-field encryption is a very strong security measure (depending on how keys are managed). But GDPR is not about achieving maximum technical data protection, but merely requires appropriate safety measures (see GDPR Chapter 4, especially Art 32). Asymmetric encryption of small fields within a database is unlikely to be appropriate, taking into account the cost of processing and the data subject's ability to exercise their rights. A different security measure to ensure that every business only sees the correct data would be through testing and code review of your SQL queries, and full disk encryption of the server storing the database. In practice, asymmetric encryption is most often just used to encrypt a symmetric key, which is then used for the actual data. But which measures are appropriate also depends on the risk to data subjects – your approach could make sense for very sensitive data. Art 14 does not play a role here. It is about transparency of processing: that you need to (a) notify the data subject that you're processing their data, if feasible, and that you (b) provide information about this processing, usually in form of a privacy policy. Art 14 is the pendant to Art 13, which applies when data is obtained directly from the data subject. The Art 15 right to access and the Art 20 right to data portability are distinct from the right to be informed. In any case, it is the controller's responsibility to fulfil these rights.
The GDPR has a fairly broad concept of what it means for a data subject to be identifiable. The details are given in Recital 26: To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. The good news is that this mandates a risk-based approach to identifiability. You don't have to prevent re-identification with absolute certainty, but you must make sure that re-identification is not “reasonably likely”. The bad news is that “identify” does not just mean “figuring out the real-world identity of the data subject”, but also “being able to single out the data subject”. Hashes of personal data are still personal data. The hashed password still allows you to single out data subject, since the hash now serves as an identifier that links multiple records. Equivalently, a random ID would serve as an identifier. Depending on the information in the linked records, this could reasonably likely also allow linking to a real-world identity. I'll also point out that the GDPR explicitly notes that “online identifiers … such as internet protocol addresses, cookie identifiers or other identifiers” enable profiling and identification, and are thus a kind of personal data. Note that it seems you have a user database that includes a password hash. This database includes rich links between the password hash and other, more directly identifying, data. Alternatively, consider that the software that collects tracking information along with this tracking identifier would also receive other information about the data subject that could allow re-identification, such as the data subject's current IP address. It would be reasonably likely that such additional information could be used to identify or single out the data subject. For this analysis, it is irrelevant whether you have any intention of singling out users – it only matters whether, under an objective analysis, the relevant means to do so exist. Related: EDPB thinks hashed phone numbers are personal data. There has been recent debate by regulatory bodies on the question whether hashed phone numbers are personal data. This debate was published by the EDPB binding decision regarding the Irish DPC's fine against WhatsApp, which uses hashed telephone numbers to intersect user's address books. The question in the context of the fine was whether this represents processing of personal data of users who are not WhatsApp users themselves. Originally, the Irish DPC argued that such hashes were not personal data. However, the German, French, Portuguese, and Dutch supervisory authorities pointed out that the specific hashing approach used by WhatsApp does not provide anonymization, for example because there still is contextual information (such as the user's social graph) that would allow indirect identification (and because their hashing was pretty weak and reversible with reasonable effort). Such hashing would only be pseudonymization, not anonymization. The Hungarian supervisory authority makes the argument that WhatsApp could always re-create the hash from the original data, thus permitting re-identification of the hash. This is in line with my above argument that the hash allows singling out. Again, the hash should be considered pseudonymous, not anonymous. The EDPB upheld all these objections against the Irish interpretation as “relevant and reasoned”, and largely agreed with their merits. Some parts of the resulting analysis are specific to issues around phone numbers, in particular that there are comparatively few phone numbers. However, a recurring point is that the hashed data cannot be viewed in isolation. It must be viewed in the context of how it is created and used, and in the context of other data that the data controller has. Conclusion It is possible that in some cases the hash could serve as an anonymous token. But this would require careful analysis about how the hash is created and used, and about what other data you have available and could potentially link or correlate with this token. Unless you are extremely sure that there are no means that could be reasonably likely used to perform re-identification or singling out, you should consider such tokens to be pseudonymous data. Pseudonymization is a great security measure, but such data is still personal data. I suggest reading the WP29 opinion 05/2014 on Anonymization Techniques (WP216) (PDF link). It predates the GDPR and is slightly outdated in both legal and technical matters, but still contains highly relevant guidance on the matter of proper anonymization in the European data protection context. Aside from identifiability issues, I am concerned about using the password (or derived hashes) for anything other than authentication. Even in hashed form, this is fairly sensitive data. In most cases where you would use a password hash, you can likely use a random number instead.
From a German perspective, it would be absolutely normal and expected that you're providing identity &amp; contact information publicly. Per §5 TMG (Impressumspflicht / Anbieterkennzeichnung) this is required for German tele-media offerings, such as websites or email providers, even if non-commercial. Whereas for you as an upstanding and diligent email provider an abuse@... address should be enough, the German context expects a street address where you could be served with a lawsuit… There absolutely are privacy and free speech issues with this compelled self-doxxing. But by running an email service, you're not just acting as a private person. Your privacy interests and the transparency and security interests of other people have to be balanced. Now since you are not in Germany, the TMG does not apply to you. You have no legal obligation to provide this information. However, the ISP also has no legal obligation to to deliver your email. The ISP does have an obligation to apply appropriate organizational and technical safety measures. It seems that one organizational measure they have found appropriate is that they will only deliver emails from providers that provide public contact information, as would be the norm in Germany. I am not entirely sure how the GDPR applies here. The GDPR doesn't really allow or prohibit disclosures of personal data, it just requires that every purpose of processing for personal data has a legal bases per GDPR Art 6. One such legal basis is a legitimate interest, which boils down to a balancing test between your rights and freedoms and other people's interests. I'm also not sure if the contact information should be classified as personal data in this context, because the contact info primarily relates to your role as an email provider. I'm also not sure if the ISP is processing your personal data in the sense of the GDPR when they merely require you to publish it on your own site. They would be processing it as soon as they scrape, store, or otherwise use this info.
First take a look at Article 13(1) of Directive 2002/58/EC Article 13 Unsolicited communications The use of automated calling systems without human intervention (automatic calling machines), facsimile machines (fax) or electronic mail for the purposes of direct marketing may only be allowed in respect of subscribers who have given their prior consent. Notwithstanding paragraph 1, where a natural or legal person obtains from its customers their electronic contact details for electronic mail, in the context of the sale of a product or a service, in accordance with Directive 95/46/EC, the same natural or legal person may use these electronic contact details for direct marketing of its own similar products or services provided that customers clearly and distinctly are given the opportunity to object, free of charge and in an easy manner, to such use of electronic contact details when they are collected and on the occasion of each message in case the customer has not initially refused such use. Note that this is a Directive, so it is not directly binding, but each EU member state has created it's own laws containing this. I also quoted paragraph 2 for completeness, but based on your description, it does not apply. Article 95 GDPR explicitly specifies it does not change any obligations from Directive 2002/58/EC. So it looks very clear to me the situation you describe is not legal. Article 14 GDPR allows you to request all information regarding this, which included information how they have exactly obtained your name and email address.
The GDPR only require explicit (hard) consent if you use the cookie to store personal data. Given the conditions you cite, the data you store is not personal data, so this cookie does not require consent. In theory, someone having access to both session cookie and "analytics cookie" could relate the two, but that is highly non-trivial. You may have to do DPIA to demonstrate that this is non-trivial, or that you have mitigation in place to mitigate staff abusing such access. But provided things are as you say, the "analytics" cookie does not require consent.
Read the TOS (Terms of Service) for each DNA service you are considering. Each service will clearly outline the privacy of submitted samples, security of the process of analysis of samples, the storage and distribution (and possible destruction) of the resulting data, and linking of personal names (or the granting of anonymity, if available) to the data. The TOS will give you enough information to determine if you are comfortable with the privacy of the service. The TOS is a legal document; both you and the service are bound by that contract once you submit a sample and pay the fee. The TOS may outline any legal recourse you have against the company for violating the TOS. Each service is bound by the laws of the country where it is located and the countries where it might outsource the analysis, as well as relevant EU law - since you're looking at EU based-services - to provide security and privacy. Those laws will be outlined in the TOS. As an example, read https://dna.ancestry.com/en/legal/us/privacyStatement at ancestry.com about their DNA testing. It's an extensive TOS, and outlines US and EU law, including the Swiss Safe Harbor Framework https://en.wikipedia.org/wiki/International_Safe_Harbor_Privacy_Principles The DNA service, of course, can't guarantee the security of the data - or your personal information - in perpetuity. Companies are sold, TOS documents change (which would have to be subsequently approved by you), data storage systems "leak" information (by insiders and hackers), and on and on. ...but I don't mind doing a lot of research on my own to classify it if I get raw results. And, any kind of site that allows you to compare your DNA profile with others - if it is a different site/service than one that does the DNA analysis - will have its own TOS regarding the privacy of your data and the resulting metadata from comparisons to other DNA profiles.
You are missing something. The fact that you have a tick box and its state is saved in the database is enough. The burden of proof is only "on a balance of probabilities", so someone arguing that they didn't consent would have to demonstrate that you falsified the database entry somehow. In terms of GDPR requirements in general you don't need a greater level of proof than this, the key thing is that you have a robust system in place to obtain proof (such as not allowing data into the database without a tick in the box).
Given a large database of email addresses that you can't prove have given consent to receive email, the only legal thing to do with it, is to (securely) delete it. (I am going to switch your question about a larger company to a bank: in the UK, big pharma is forbidden from advertising to individuals.) In principle the rules are the same for a huge bank and everything down to a self-employed plumber. In practice the plumber will be told "don't do that again" rather than fined. This case was treated under the Data Protection Act, which has a maximum fine of £500,000&nbsp;&ndash; so a big bank would probably have been fined more, but not necessarily much more. Under GDPR, fines are related to turnover, so the fine would be a lot bigger for a large bank. The incident is a year old now. Details here.