What to answer to a GDPR-related user request about his data if it is fully encryped and only the user has the private key for decryption We wrote an App where private data can be sent from one phone to another phone one by temporarily storing the encrypted data file on our database server. The data file will sit there for less than a few hours, maybe just a few seconds, and will then be deleted. We do not log this. All data (but the usernames) is encrypted (asymmetric cryptography, RSA) and can only be decrypted by the receiving user's private key which never leaves his phone. Therefore, we cannot decrypt it. The users also need to publish their public keys in our database to make this technically work. We think this is GDPR relevant, since we still can theoretically see on our server who (theoretically identifyableby IP number) is sending data to whom (theoretically identifyable by IP number). We are not sure if the public key is 'private data', since it is technically 'public' per definition. My question is what to answer to a user request about his data (which is an important point for GDPR). Are we just providing a print out of the file in its encrypted state? And only in case there is one there at the time of the request? The print out is anyway only readable for this user since the private key never left his phone, and, therefore, we cannot decrypt it. If there are no files, do we just tell so?
A public key is private data - the fact that its a public key is neither here nor there, its data owned by the user and not necessarily in the public domain (I have keypairs for which the public key is only known by myself, for example). For a subject access request, you must give the user all data you hold about them, subject to certain restrictions laid out in the GDPR - in your case, this would be the IP addresses, public keys, encrypted data and anything else involved in identifying their devices for transferring the files. You dont need to decrypt the encrypted data if that is something you cannot do or would not normally do in the course of holding it during a transfer - to you, the encrypted data is what you hold. If you hold the means to decrypt the data, that means (private key for example) would also be included in the subject access requests response, but in your case you say you dont hold that, so there you go. Remember to include information from things like logs etc in your response.
The GDPR applies to such sites if they offer services in the EU/EEA. If they clearly wanted to avoid being subject to the GDPR, they should block visitors from the EEA. For the GDPR, only location matters. Other concerns like residence or citizenship are generally irrelevant. Personal data does not turn non-personal just because it was public. So the GDPR still applies when the data was collected from public sources. However, the data controller (who determines the purpose of processing) often has to balance your rights and interests against other interests (e.g. when using legitimate interest as a legal basis for some processing). For the purpose of publicly displaying your data, only showing data that was already public anyway makes it easier to argue that this is fine. But when the GDPR applies, you have data subject rights. Relevant rights include: a right to access, to see all the data they have about you a right to rectification, to correct wrong data they hold about you a right to restriction, effectively an opt-out a right to erasure (also known as the right to be forgotten) These rights apply both against the website and against Google Search (arguably, both are doing the exact same thing). Google correctly points out that they can't remove information from the Web, but they can hide information from search results. If you feel that your requests have not been resolved correctly, you can issue a complaint with your country's data protection authority. In theory you can also sue them. In practice, GDPR enforcement against overseas data controllers can be quite difficult and has not yet happened.
Not Allowed Under the GDPR The suggested method does not seem to comply with the GDPR, and would not be lawful for a Data Controller that is subject to the GDPR. Specific Provisions Let's consider some specific provisions of the GDPR: Article 4 Article 4 paragraph (11) states: &quot;consent&quot; 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, signifies agreement to the processing of personal data relating to him or her; If the choice is &quot;obscure&quot; then it is not clear, and legal consent has not been given. Article 7 Article 7 paragraph 3 reads: The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent. It does not appear in the situation described that the data subject has been clearly informed that consent is being given. Recital 42 Recital 42 reads in relevant part: In accordance with Council Directive 93/13/EEC a declaration of consent pre-formulated by the controller should be provided in an intelligible and easily accessible form, using clear and plain language and it should not contain unfair terms. ... Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment. The specified means do not seem to comply with R42 Recital 32 Recital 32 reads: Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement. This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. ... If the data subject’s consent is to be given following a request by electronic means, the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided. The format in the question seems to rely on inactivity as a way of giving consent, and is surely not clear.
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.
Does GDPR prohibit reading unsolicited emails from people who have not explicitly opted in to a mailing list? tl;dr: No. I have never heard of this, and I don't see how this could follow from the GDPR. You should follow up with the Secretary to find out how she came to her conclusion. Detailed reasoning: The GDPR restricts the processing of personal data, so it does in principle cover reading email, since reading counts as "processing", and an email may contain personal data. However, Article 2 (emphasis mine) says that: This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. I would read this to mean that a human reading emails is only covered by GDPR if the emails are part of a "filing system" or intended to be. So reading the emails is ok, it's only problematic if you intend to systematically store them. Even filing them, while covered by GDPR, would presumably be allowed, because to actually act on the email, you would have to keep it, and Article 6 allows processing of personal data to "take steps at the request of the data subject prior to entering into a contract" and when "processing is necessary for the purposes of the legitimate interests pursued by the controller". One caveat: If the email contains data that falls under special categories of personal data (Article 9) you may need explicit consent for storage. That covers things like racial or ethnic origin, political opinions, religious beliefs and health information. So if someone discloses a health problem or their religious belief in their mail, you may need to ask them for permission to keep it. In summary: At most, GDPR would require you to promptly delete the email once you no longer need it (which could be immediately if the email is irrelevant to you). If the email contains data you legitimately need (e.g. a complaint you need to follow up on), you are allowed to keep it as required (based on Article 6 (f)). Note that in both cases no explicit consent is required from the email sender, unless the email contains particularly sensitive data, such as political/religious beliefs or health data.
The status of any PII (Personally Identifiable Information) is the same in GDPR regardless of location, or who enters it. Its goals are (among others) to stop any actor (company / government or other) from hiding responsibility about their use and practices around people's data. GDPR does even apply to anything offline and on paper. Basically it means you have to validate any entry field is free of PII before processing it. Or make it clear in your privacy statement how you handle this use-case.
Great question - I work for a London based company who use a large amount of location data. The process for deletion of data is not as simple as it first sounds. We recently had a deep dive with our legal team and as a result actually created a product to process deletions. Personal data from users/customer is carried for lots of reasons, not just marketing. What if you're asked to delete data that is needed to bill customers, information that may be relevant to a legal case or information that needs by law to be retained for the purposes of audit? GDPR does not make it illegal to carry personal information, it simply needs you to justify why you are keeping the information - inform the named person about this and provide them with a timescale for deletion. For example if you are required by law to store a record of emails to document the work done, but the user asks you to delete that information. You would be entitled to keep that information but only for the purposes of maintaining that audit trail. You would delete all associated customer data that was unnecessary such as CRM info, payment details etc.. but could keep the audit trail. The proper way to respond to the user's deletion request would be "your data will be kept in a secure server for the purposes of maintaining an audit trail for x amount of time. Once this time has elapsed it will be deleted. If you are unhappy with our use of this data please contact our data officer". GDPR isn't designed to catch you out - if you have a legitimate reason to keep that information then you are entitled to. The law was designed to stop marketers and advertisers hoarding huge amounts of information, as well as undermine Google/Facebook's duopoly on our personal information.
If law enforcement is actually requesting an encryption key, talk to a real lawyer. To answer your first question, the answer is &quot;the government probably can't demand the password, but might be able to demand the data.&quot; Some courts have ruled that the Fifth Amendment can prevent courts from forcing someone to decrypt data for the government, because the act of decrypting the data conveys information (see United States v. Doe from the 11th Circuit). Other courts have ruled that there are situations where that is not the case (US v. Fricosu, In re Boucher). Boucher is particularly interesting because the government first asked for the password itself, and then (when that subpoena was quashed by the magistrate) narrowed its request to the decrypted data on appeal. In the magistrate's opinion, we see Also, the government concedes that it cannot compel Boucher to disclose the password to the grand jury because the disclosure would be testimonial. It is not generically a violation of the Fifth Amendment to compel production of documents (the 11th Circuit, quoting the Supreme Court, considered this a &quot;settled proposition&quot;). The issue is that the act of producing the documents can be considered testimony -- by producing the documents, the person is showing that they know the documents exist, where they are, how to read them, etc. Possession of the key to decrypt a file links you to that file, because keys are generally kept secret. In the 11th Circuit case, the court found that the government didn't know for a fact that a) Doe could decrypt the files, and b) what files existed on the encrypted drive. In the cases where forced decryption was allowed, the government had seen enough to independently show that the files existed, were authentic, and that the defendant had actual control/possession over them. The 11th Circuit asked for a bit more (the location), based on a standard that is in effect in some circuits but not others. In any event, courts seem to generally consider this to take a court order to force production of anything; the police can't just order you to do it.