Is encrypted health data still considered personal data and subject to GDPR Art. 9 (1)? I need to exchange data from a patient providing its own health data to a healthcare provider over my server. The data is encrypted on the patient's device by the public key of the healthcare provider before it is sent to my server. It is then downloaded and decrypted by the healthcare provider. During the whole process I don't know the identity of the patient nor am I able to decrypt the data. Is the data being sent over my server still subject to Art. 9 (1) of the GDPR? To my understanding the data does not reveal anything about who the patient is nor what the content is. But of course, I don't want to risk anything.
Yes, encrypted personal data potentially still is personal data, so some prior thought is necessary. But are you a controller who is processing this personal data? Possibly not. This hinges on what kind of metadata you process, and whether the encryption happens under your authority, e.g. by a software that you provision. If all you can ever get is the encrypted data but not the plaintext, then you can probably treat this similar to pseudonymous or anonymous data. A related example is a postal service. Letters might contain sensitive personal data. But the postal service is not processing the letter contents, and cannot be treated as a controller of this data. (The postal service is prevented by law from processing this data, you are prevented by the encryption). However, a postal service processes personal data like addresses on the envelope. You might want to create a Records of Processing document, which will help you understand what (potentially) personal data you will process. If you are processing patient data on behalf of a healthcare provider, you might want to look into whether you are a controller or a processor. Processor status is not automatic but requires a suitable contract with the controller. As a processor you still have to take appropriate security measures, but you are not responsible for determining the purposes of processing or for responding to data subject requests.
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.
There are a number of misconceptions in this question. Firstly, the regulatory environment did not drastically change when the GDPR came into force in 2018. Previously, each EU member state had its own laws implementing the 95/46/EC Data Protection Directive. The GDPR harmonizes these laws, and replaces them with a single EU-wide law. However, the GDPR is largely identical with the DPD. In particular, both laws have the same definition of a controller. Secondly, the data controller is not a position to be designated, like a Data Protection Officer would be. A controller is whoever – alone or jointly with others – determines the purposes and means of processing of personal data. Whether someone can decide the purposes of processing is a matter of fact, not a matter of formalities. There can be more than one controller. Most likely, the institution hosting the research group is the controller. For individual researchers, the important aspect would be to demonstrate that they've fully complied with their institution's procedures at all times – that they acted as agents of the controller, not as controllers of their own. The institution might have a more difficult time mounting the defense if its technical and organizational measures were inadequate. For example, keeping an unattended server running for five years without security updates borders on gross negligence – so there should have been a procedure so that each system has a clear point of contact who is responsible for administrating the system. The controller should also have inventoried its systems and processing activities at the latest in preparation of GDPR, e.g. for an Art 30 record of processing activities. Your question suggests that no one could be at fault because no one did anything, but inaction and failure to fulfil responsibilities can also be a violation of law. If the institution wasn't convinced that this server was GDPR-compliant, the correct approach would have been to shut the server down, not to continue the processing of personal data. Of course, the controller may be able to demonstrate that this breach of GDPR was very minor, for example because the personal data was pseudonymized and because other technical measures (like firewalls) would have prevented unauthorized access.
The pragmatic answer is to just ask the data subject what they would like to have erased. The GDPR's right to erasure DOES NOT requires that you “delete all their records in [your] database”. Compared to other GDPR rights, it has a quite limited scope. It is necessary that one ground for erasure in Art 17(1) applies, and none of the exceptions in Art 17(3) apply. For example, you are allowed to retain any data that you need to fulfill a legal obligation (exception in Art 17(3)(b)), such as an obligation to keep financial records for a number of years. In the case of providing course completion certificates, I would assume that your legal basis for providing this service is a contract with the data subject. Contracts directly with the data subject can serve as a legal basis for processing per Art 6(1)(b). It doesn't matter if the contract was paid (consideration is not a necessary element of a contract in civil law systems). As long as this contract is in force, there are no Art 17(1) grounds for erasure. But if the contract is terminated, Art 17(1)(a) would apply: “the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed”. So the data subject could release you from your contractual obligation to provide the certificate verification service, and then require you to delete any personal data in connection with that service. In the unlikely case that you are using a different legal basis for hosting the certificate service: legal basis applicable? grounds for deletion Art 6(1)(a) consent maybe Art 17(1)(b): consent can always be withdrawn Art 6(1)(b) contract yes (see discussion) when the contract is terminated Art 6(1)(c) legal obligation unlikely per legal requirements Art 6(1)(d) vital interests no Art 6(1)(e) public interest unlikely per legal requirements Art 6(1)(f) legitimate interest maybe Art 17(1)(c): objection to further processing per Art 21(2) For all of these legal bases, it is the case that once the legal basis expires, then Art 17(1)(a) provides grounds for erasure. In fact, proactive erasure (without waiting for a data subject request) may be required in line with the Art 5(1)(b) purpose limitation and Art 5(1)(e) storage limitation principles. To quickly summarize all Art 17(1) grounds for deletion: Art 17(1)(a): data is no longer necessary Art 17(1)(b): consent withdrawn (only if Art 6(1)(a) consent was used as legal basis) Art 17(1)(c): objection to further processing (only if Art 6(1)(f) legitimate interest was used as legal basis) Art 17(1)(d): unlawful processing always merits erasure Art 17(1)(e): erasure is required by law Art 17(1)(f): special right to erasure for children Note that it is, in principle, possible to provide certificates without storing personal data. This could make it unnecessary to think about data subject rights like erasure. For example, you could provide a certificate to users. The certificate contains personal data, and you do not store a copy of the certificate. But you could use cryptographic signatures to prevent forgery of the certificate. The signature can be verified without having to store personal data. If you are familiar with web development, the same technique is used for JWT tokens: the data in the token is signed by a secret key so that it can be verified whether a token (and the data in the token) was created validly, without having to store a copy of the data in the token. Limitations of this approach are well-known, such as making it difficult or impossible to revoke certificates. In practice, such data-minimization techniques are overkill. The GDPR only requires appropriate security measures. If you have a legal basis (such as a contractual obligation with the data subject) then it is perfectly fine to store a certificate with personal data in your service. The GDPR obligations stemming from such a processing activity are not particularly onerous.
The GDPR does not have specific rules on passwords. Instead, the GDPR imposes a more general requirement to ensure data protection by implementing “appropriate” technical and organizational measures, “[t]aking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons” (c.f. Art 24, 25, 32 GDPR). As of 2021, the state of the art for password storage is a special password hashing function such as Argon2, bcrypt, or scrypt. However, the nature and context of processing could reasonably lead to the conclusion that the usual hashed password storage is not appropriate, for example because the ability to find links between user accounts is more important. There is a trade-off between different aspects of security, and the data controller could reasonably arrive at an unusual conclusion. However: The data controller would still have to implement appropriate measures to protect these plaintext passwords, for example by storing them in an encrypted manner, keeping unforgeable access logs, and limiting access to plaintext passwords to specially trained staff. Encryption is one of the few things that are explicitly required whenever appropriate. The data controller better have a good analysis that shows that this unusual approach to security is appropriate. Even if not explicitly required, an Art 35 data protection impact assessment could be useful. The data controller has the burden of proof to show that these processing activities are GDPR-compliant. So is this data controller breaking the law or doing morally dubious stuff? Not necessarily! It is possible to find a scenario where they are doing the right thing. However, such a scenario is far-fetched and rather unlikely. Without further background, the most likely explanation is that the presented password handling scheme does not comply with GDPR.
No, GDPR does not apply here — but other laws might . The General Data Protection Regulation only concerns itself with the following: 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. per Article 2. Furthermore, there is a specific exemption (Art. 2 (2)(c)) which would seem to apply to you (emphasis mine): This Regulation does not apply to the processing of personal data: (a) in the course of an activity which falls outside the scope of Union law; (b) by the Member States when carrying out activities which fall within the scope of Chapter 2 of Title V of the TEU; (c) by a natural person in the course of a purely personal or household activity; (d) by competent authorities for the purposes of the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including the safeguarding against and the prevention of threats to public security. You are sharing the conversation in a purely personal capacity and are not processing it wholly or partly through automated means nor are you intending it to form part of a filing system. Additionally, depending on the contents of the conversation and what you share, there may not be any personal data involved at all. For example, if you only share the messages themselves (and they don't contain any personal data that could identify someone) and censor/black out any names or photographs/avatars from the senders. Either way, GDPR does not appear to apply to you in this context. However, it appears that Article 18.1 of the Spanish Constitution grants the right to &quot;personal and family privacy&quot;, as does the Organic Act 1/982 on Civil Protection of the Right to Honour, Personal and Family Privacy, and Self-Image. It's possible that, depending on the contents of the conversation, the other party involved in the conversation may have a case for action against you in the civil or criminal courts (for example, if the information invades their privacy or is defamatory in some way) if you share the contents of the conversation with someone else. I am not familiar with Spanish law so cannot comment further on this matter.
The GDPR does not prescribe how exactly consent must be managed, as long as consent was obtained in line with the GDPR's principles. Similarly, the EDPB does not provide concrete recommendations in its guidelines on consent, mainly noting that Controllers are free to develop methods to comply with this provision in a way that is fitting in their daily operations. I would not be too concerned with edge cases like failing HTTP requests, at least not any more than for other HTTP endpoints. If the user indicated consent, and you act on that indication of consent in good faith, that's probably fine. However, remember that you must provide a equally easy way for the user to revoke consent later. If the user changes their mind, they can use the mechanism that you offer to inspect their consent status, and revoke it if they want. But again, how to do that is largely up to you.
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.