Can I request a copy of my password hash with GDPR? People often use personal information to create them, like first name / date of birth, and people often reuse passwords across several sites, so I guess passwords are considered personal data since they could identify its owner. If a website doesn't follow best practices regarding password hashing, it could make the whole hashing process basically useless, so I guess password hashes are also considered personal data. With GDPR, can I request a copy of my password hash?
First of all, a password is not personal data. ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; From GDPR Article 4 (https://gdpr-info.eu) As for password hashes, what do you mean by requesting a copy of yours? You can produce it if you knew the hashing algorithm of the website. By the way, websites should be using good hashing algorithms, such as bcrypt or scrypt, not MD5 or SHA1.
Yes, GDPR applies: you are a data controller established/living in the UK or are offering services to people in the UK you fall under the material scope of the GDPR. The Art 2(2)(c) exemption for “purely personal or household activity” does not apply since you're offering the service to the public. You must consider GDPR compliance here. This is especially important as you are showing personal data to the public. Don't do that unless you have a very good reason, appropriate safeguards, and are clear to users how their information will be shown. On a high level, GDPR compliance involves working on the following questions: For what purpose are you processing personal data? Context: purpose limitation principle per GDPR Art 5(1)(b) What is the legal basis for processing? GDPR Art 6(1) lists the available legal bases. Here, consent, necessity for performance of a contract, or a legitimate interest could be a legal basis. They may have further obligations attached. A legitimate interest requires a balancing test that considers the data subject's rights and freedoms. Consent must fulfil the conditions per Art 7 in order to be valid. What is the minimal data necessary to achieve the purpose? Per the Art 5(1)(c) data minimisation principle, it is illegal to process personal data beyond what is necessary and adequate. You must provide data protection by design and by default per Art 25. Special categories of data per Art 9 such as health data are illegal to process outside of narrow exemptions. You must delete data once it is no longer necessary. What appropriate safeguards and security measures should you apply? Per Art 24 and 25, you are responsible for determining and implementing appropriate measures. This depends a lot on your specific context, so there's no checklist you can apply. Per Art 25(1) you must pseudonymize the processed information if that is compatible with the processing purpose. What further compliance measures do you have to consider? There are additional GDPR and non-GDPR compliance measures. From the GDPR side: Use the answers to these questions to write a privacy policy, including the information that you must provide to data subjects per Art 13. Consider whether you have to maintain a Records of Processing document per Art 30, or if you have to make a Data Protection Impact Assessment per Art 35. If you use third party services, figure out whether they are a joint controller or data processor and apply appropriate safeguards. If you have data processors, ensure that you have a contract in place that covers the items from Art 28(3). If you share data with other controllers (not processors) you need a legal basis for doing so. If you transfer data into a non-EU/EEA country (after 2020: non-UK country) you need a legal basis per Art 44 and have to cover additional items in your privacy policy. Ideally, the target country is covered by an EC adequacy decision per Art 45. For US-based companies, this is the case only when they have self-certified under the Privacy Shield framework. Non-GDPR compliance steps could include cookie consent banners, or showing a VAT ID. How can you prepare for data subject requests? Data subjects have various rights per Arts 15–23, subject to the modalities in Art 12. For example, a data subject could request that their information is erased from your website. The exact rights also depend on the legal basis you selected. You should figure out in advance how to deal with such requests.
Term 1 isn't going to hold up, but that is not a GDPR matter. It's just a matter of basic consumer protection law in the EU. You can't offload responsibility for your mistakes. Looking at 2, Dale M. already pointer out that it's now how the GDPR works. You are the Data Controller. X,Y and Z are Data Processors. Article 28(1) of the GDPR is in direct conflict with your disclaimer. You accept zero responsibility, the GDPR says you are fully responsible. That's the exact opposite.
The GDPR gives controllers a lot of latitude. They must decide on the correct course of action taking into account the possible risks to data subjects. Specifically, no notification of the authority is necessary if “the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” In your scenario 1, you suggest that there is no breach because there is no evidence that the data was improperly accessed. This analysis is faulty: the controller is aware that the data was not properly secured, and cannot rule out that the data was improperly accessed. I would argue this fits the description of a “breach of security leading to the accidental or unlawful … unauthorised disclosure of … personal data” (compare the definition of a data breach in Art 4(12)). Thus, a data breach has happened. The question whether the supervisory authority has to be notified of that breach is more debatable. The controller must assess the likelihood of risks to the data subjects. Here, they can perhaps argue that the risk of disclosure is low. However, the nature of the breached data would also be relevant. If in doubt, the controller should make the notification. The goal of the GDPR is not to punish unlucky companies that suffer a breach, but to protect personal data. Thus, fixing mistakes and cooperating with the supervisory authorities is likely the best approach for most companies. In your second scenario, the data is sensitive – its disclosure has a high risk for data subjects. However, the risk of someone intercepting this data is debatable. Does the risk of interception balance out the sensitivity of the data? That's the data controller's call, but I don't think so. A notification would seem appropriate here. As a technical remark, simply offering HTTPS is not sufficient to prevent MitM attacks – users must be forced to use encrypted connections. If a controller sees MitM as a risk, they are required by Art 24 to take appropriate technical measures. Here HSTS and HSTS preload would prevent the connections from being downgraded to HTTP. Instead of offering insecure connections, the site would become inaccessible. A complementary strategy is to not serve content over HTTP, but have the HTTP server only issue a permanent redirect to the HTTPS URL.
IANAL, But the information commissioners office (UK) describe personal data as: (bolding mine) The GDPR applies to ‘personal data’ meaning any information relating to an identifiable person who can be directly or indirectly identified in particular by reference to an identifier. This definition provides for a wide range of personal identifiers to constitute personal data, including name, identification number, location data or online identifier, reflecting changes in technology and the way organisations collect information about people. https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/ So I would say that in your case it is personal information. In principle, regardless of if you can identify an individual, personal data is that which can be used to potentially identify an individual. For an extreme example of why this is important: Lets say your app sells AIDs medication. Can a hacker who got in and stole your database, be able to use that with information they stole elsewhere to identify people with AIDs and blackmail them, in a way that they wouldn't if you had not stored this identifier? Plus, if you want to err on the side of caution, there's no legal penalty for telling the user about non-personal information you store.
The GDPR does not set fixed retention periods. Instead, it says data may not be kept for longer than necessary. What is necessary depends very much on the specific context of the processing activity, in particular on the purpose of processing. The GDPR allows retention for as long as necessary. For example, businesses (including financial institutions) are required to keep financial records. This requirement stems from EU member state law, which also sets specific retention periods. If a business wants to keep personal data in financial records for longer than this retention period, they can't just point to the law to authorize this processing – they must instead find a different purpose why they need to keep the data, and then find a suitable Art 6 legal basis. In some cases, retention periods might not be coupled to a fixed duration, but to certain events. For example, personal data for online accounts should typically be kept until the account is closed, which is potentially indefinite. This follows directly from the GDPR approach of limiting data storage by necessity, not by duration. All processing needs a clear purpose + a legal basis. In the context of a genealogy site, the site should analyze carefully what data they collect for what purposes. These purposes might enable potentially unlimited retention. But such processing must also be covered by a legal basis, and I doubt that the site would have a legal basis to make such storage irrevocable. If the data is collected based on Art 6(1)(a) consent, then the data can only be used as consented to, and consent can always be withdrawn in the future. If the data is collected based on Art 6(1)(b) necessity for performance of a contract, then the data can be used for compatible purposes in the sense of Art 6(4), but that would require a new legal basis (e.g. legitimate interest). If the data is collected based on Art 6(1)(f) legitimate interest, then the data can be used for Art 6(4) compatible purposes but the data subject has the Art 21 right to object to processing. While a genealogy site may have a legitimate interest in keeping supplied data in order to use it for future research, I think this is a fairly weak legitimate interest that can be easily overridden by an Art 21 objection, which in turn could require Art 17 erasure of the data. The genealogy site should also keep in mind principles like data minimisation and data protection by design and by default, so just keeping data for the off chance that it might be useful in the future is not GDPR-compliant. Data can only be collected and processed for “specified, explicit, and legitimate purposes”. The Art 89 privilege for research purposes also imposes conditions. There is a pretty big carveout in these GDPR requirements for archiving purposes in the public interest, scientific or historical research purposes, and statistical purposes. Specific rules for this exemption are given in Art 89 GDPR. The main value of this exemption is that Art 89 research purposes are always considered compatible with the purpose for which the data was originally collected (cf Art 5(1)(b)), though this might not cover data that was collected under the legal basis of consent (cf Art 6(4)). Other GDPR rules stay intact, and Art 89(1) imposes extra steps to consider: Special attention MUST be given to the data minimisation principle. If the research purpose can be achieved without identifiable data, the data MUST be anonymized. If the research purpose can be achieved with pseudonymized data, pseudonymization MUST be used. Appropriate safeguards MUST be implemented (though this just re-iterates the general requirement in Art 24). In some cases, the research purpose stands in conflict with data subject rights like the right to be informed or the right to object. If so, EU or member state law can provide exemptions from the data subject rights, but can also impose further conditions or safeguards. It is not possible to rely on the Art 89 exception without taking member state law into account. Art 89 does not modify necessity-based retention. Now on to the main question: how long can the personal data be kept for research purposes? While Art 89 research purposes allow us to extend the retention period because we have a new and compatible purpose of processing, it does not affect the general principle that data may only be kept as long as necessary for that purpose. In a scientific context, it would be common to preserve many data sets indefinitely for the purpose of enabling reproducibility of the scientific findings. A privately-run genealogy service might not benefit from Art 89. This “research” angle doesn't seem to be a good fit for a genealogy site. Such a site would typically not be collecting personal data for specific research purposes. At best, it would be operating as an archive of personal data which can be mined by future generations of researchers. But the GDPR specifically only considers archiving purposes in the public interest, which might not cover privately run archives. Archives rely on specific privileges in national laws, and severely restrict access to the information. For example, I'm leafing through the law on public archives in a German state. It forbids access for 10–100 years, depending on the date of death of the data subject and on the age of the documents. This leads me to believe that a privately run genealogy site cannot reasonably rely on the Art 89 exemption, and must instead rely on an ordinary processing purpose + corresponding Art 6 legal basis. This doesn't directly prevent indefinite storage, but means that it will be easy for a data subject to invoke their right to erasure. It is not quite enough to say “we will keep the data indefinitely”, it is also necessary to have a clear purpose for this retention.
I think there are a couple of different ways to look at this. Deduplication is a technical detail that's irrelevant here While the data may be deduplicated on a technical level, the files remain logically distinct. If users 1 and 2 upload identical files, and then one user edits or deletes their file, this will not affect the other user's data. Users cannot tell whether their files are duplicates of someone else. From the user's perspective, it makes no difference whether or not the storage uses deduplication, except perhaps via the cost of the service. Because there is no user-perceptible difference, it would be difficult to interpret some GDPR significance into this scenario. Whose personal data is it anyway? Personal data is any information that relates to an identifiable data subject. The files here are likely to be their uploader's personal data. Thus, the uploaders would also have a right to have their uploaded files erased. In case of deduplicated storage, this would affect their logical copy. The contents of the uploaded files might also be personal data relating to a third party. Then that third party might have a right to get the file contents erased. But this right must be invoked with the data controller for that processing activity, which might be company A, company B, or the uploaders, depending on context. Which leads us to the next aspect: Company A is not responsible for handling erasures From your description, it sounds like company A is a data processor providing services on behalf of company B. In turn, B might be a processor acting on behalf of the uploaders. In any case, it seems that A would not be the data controller for these processing activities. Data subject rights like erasure must be invoked against the controller, as only the controller can understand whether such a request should be granted. The right to erasure is not absolute, and depends a lot on why that data is being processed. In particular: Personal data need not be erased if it is still necessary For example, a person might very well be the data subject of some of these files, and might then ask for erasure. But if the files are being stored because they are going to be needed as evidence in legal proceedings, the data subject can't use this GDPR right to destroy evidence. The data controller would be allowed to refuse a request in such cases. It could now happen that two different users of this deduplicated storage are storing the same file, but for entirely different purposes. Blanket deletion of all copies of a file could be quite problematic. Note that deletion is also a &quot;processing activity&quot; and needs a legal basis under the GDPR. Unexpected data loss could be a data breach. One user's erasure could be another user's reportable data breach incident. Thus, I would strongly expect such requests to be handled on a logical file level, not on the deduplicated storage level. Caveat: public access and cloned files If the (logical) file is made available to the public who can then clone or copy this file, and if the &quot;original&quot; is taken down due to an erasure request (or copyright takedown notice), it might be appropriate to remove logical clones as well. Again, this might not involve deleting the contents on the deduplicated storage level, but it might affect other users' copies. In a GDPR context, the grounds for this would be the Art 17(2) right to be forgotten: Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data. But this depends crucially on who those other controllers are. If A is the sole controller, the logical files could probably be deleted directly. If B or the end users are controllers, it could be more appropriate to forward the erasure request to them.
I believe in this case, your company (OrgX) is a data processor and your customer's organization (OrgY) is the data controller. OrgY is responsible for establishing a lawful basis for sending you (OrgX) the personal data for their employees. Note that consent is just one of six lawful bases outlined in article 6(1). I'm no expert, but I believe OrgY's admin can claim they have a legitimate interest in sending their employee's personal data for training sake. In either case, the data processor is not responsible for establishing the lawful basis for processing. Of course, data processors aren't completely off the hook. GDPR outlines specific requirements for data processors (see chapter 4, particularly article 28).