GDPR (General Data Protection Regulation) - crypto-shredding or regular delete? The introduction of the GDPR (General Data Protection Regulation) in May 2018 for all businesses targeting EU citizens raises questions regarding the Art. 17 right to erasure, also known as the right to be forgotten. The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay I think it is reasonable to say that deleting all data (backup included) is not feasible without delay. What about backups that go beyond the subject realm (e.g. database backups, disk backups, ...)? One idea to solve a part of the problem would be to crypto-shred data. So when a subject asks to erase him/her personal data, we simply erase the encryption key. That would render all data unusable. However, data encrypted with what is considered a strong encryption method might not be strong anymore in a not-so-distant future (e.g. quantum computing, new algorithms, or a weakness found in the encryption mechanism). So here are my questions: Is crypto-shredding considered a valid erasure method? What storage mediums are affected by the so-called undue delay?
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.
Congrats, you've done well to minimize your processing of personal data. But I think you're still processing personal data, and are subject to the GDPR. Serving a website necessarily involves processing an IP address. This IP address will typically be personal data. While you are not storing the IP address, the GDPR's definition of “processing” extends beyond storage and pretty much covers doing anything with that IP address. As far as I know this is not an entirely settled matter, but it's better to err on the side of caution and to assume that you are in fact performing a processing activity. Even a static web page can easily lead to additional relevant processing of personal data, for example if the HTML embeds resources from third party domains. Since your website is clearly targeted at the public, it does not fall under the GDPR's exception for “purely personal or household” purposes. So I think you do need a (minimal) privacy notice that contains at least the items mentioned in Art 13 GDPR. The main reason why some people try to avoid posting a privacy notice is because it must disclose your identity and contact details. But in Germany, that information has to be provided anyway due to the Impressumspflicht. As part of your GDPR compliance obligations, you must protect how data is processed by others on your behalf. A hosting provider will typically act as your data processor. For this to be legal, you need a contract / data processing agreement that fulfills the conditions in Art 28 GDPR. This contract binds the data processor to only use the data as instructed by you, and not for their own purposes. European hosting providers sometimes include the necessary terms in their terms of service / AGB, but you should check to make sure. Netcup expects you to accept their data processing amendment in your account settings. In the hypothetical case that you were not processing any personal data at all, the GDPR would not apply and it wouldn't require you to post a privacy notice. Other laws might still have information obligations, notably the German TMG and TTDSG.
Backups and archived data are included within the scope of GDPR, simply because: (a) The scope of which data the regulation applies to is defined as: 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. (GDPR, Article 2(1): Material Scope, page 32) and (b) the exclusions listed in Article 2(2) do not mention anything about backups/archives (also on page 32). The new rules for most organisations will mean they need to review and possibly change how they operate their backup/restore procedures so that risks of data breach are managed and significantly reduced to a level which follows the data protection principles in Article 5(1) and so they can demonstrate compliance as required by Article 5(2): 1.Personal data shall be: (a) processed lawfully, fairly and in a transparent manner in relation to the data subject (‘lawfulness, fairness and transparency’); (b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’); (c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’); (d) accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’); (e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject (‘storage limitation’); (f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’). 2.The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’). (GDPR, Article 5: Principles relating to processing of personal data, pages 35-36) Some practical tips to help with GDPR compliance: Rather than backing up everything in bulk as whole systems, organisations may find it easiest to separate systems backups and personal data backups so that systems backups can be kept for much longer retention periods than might be allowed/justifiable for the personal data. For larger organisations that have much more complex backup arrangements, much higher capacity backups and tape systems with archives that are kept offline, they may need to create a new backup strategy that will support the legal requirements of GDPR for ensuring 'erased' records are not retained any longer than necessary, and that older backups are replaced by newer backups so that stale/outdated personal data is not retained and rectified/amended records take effect in backups without delay. Organisations that have become used to keeping backups of everything forever will need to modify their practices and culture in order to comply with the 'what is necessary' and 'no longer than necessary' requirements by implementing a backup strategy that has defined retention periods for specific data sets or records as appropriate. If a stored backup is in a form which makes it very difficult to modify (e.g. a single record within a large database which spans numerous backup tapes) contained records which a data subject has requested be erased, then it may be considered reasonable if these records are erased upon every subsequent restore prior to processing of the data, until such time these records are not included in the backups. You'll need to keep a record of anyone that requests to be forgotten, and remember to follow-up to complete erasure at the appropriate dates if it can't be done immediately, and when the data is destroyed the data subject needs to be informed: The controller shall provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request. That period may be extended by two further months where necessary, taking into account the complexity and number of the requests. The controller shall inform the data subject of any such extension within one month of receipt of the request, together with the reasons for the delay. Where the data subject makes the request by electronic form means, the information shall be provided by electronic means where possible, unless otherwise requested by the data subject. If the controller does not take action on the request of the data subject, the controller shall inform the data subject without delay and at the latest within one month of receipt of the request of the reasons for not taking action and on the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy. (GDPR, Article 12(3-4): Transparent information, communication and modalities for the exercise of the rights of the data subject, page 40) Additionally to complicate things further, if any third party processors ('recipients') have had access to their data, you need to inform them too: The controller shall communicate any rectification or erasure of personal data or restriction of processing carried out in accordance with Article 16, Article 17(1) and Article 18 to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort. The controller shall inform the data subject about those recipients if the data subject requests it. (GDPR, Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing, page 45) In the event of a breach you may still need to notify data subjects that have requested to be forgotten! Obviously the backups would still need to be encrypted and subject to suitable protections, see Article 32 - Security of Processing (pages 51-52).
The Art 15 GDPR Right to Access is pretty absolute, the Art 17 Right to Erasure not so much. Whether you can successfully request erasure of your personal data will depend on the purpose and legal basis for that processing. Short decision schema to check if erasure should be granted: no, if any of the Art 17(3) exception applies yes, if the data is no longer necessary for the purposes for which it is being processed (Art 17(1)(a)) yes, if the legal basis was Art 6(1)(a) consent (Art 17(1)(b)) if the data is being processed pursuant to a legitimate interest, yes, if the data subject successfully objected to the processing (Art 17(1(c)) yes, if the data is being processed for direct marketing purposes (Art 21(2)) yes, if the data subject objects on grounds relating to their particular situation, unless those grounds are overridden by a compelling legitimate interest For example, CCTV recordings on private property are often stored for some time for a legitimate interest to deter crime and to be able to investigate criminal acts if they should occur. A data subject could object to the recording, but would likely be unsuccessful: it doesn't make sense to let individuals opt-out from security measures, otherwise bad actors could use this to destroy evidence. Thus, the objection and consequently the request for erasure should be denied.
[I'm not so well-versed on US and Russian law, thus I will limit my answer to EU law.] Your specific use of a user identifier, as I understood from your question, can be classified as personal data, so in your case, the GDPR seems to apply. This means that you need to have a) legitimate purposes to process that personal data (e.g. crash reporting) and b) a legal justification for each purpose of processing: it could be based on consent or another legitimate purpose (inc. your own legitimate interests). Consent might not be the best option for you, but it's up to you to decide. In any case, you need to assess the risks to the data subjects (your users) before you decide. How likely is it that you will get breached, and what potential harm will that cause to your users? These are some guidelines; my recommendation is that you read the law and the guidelines by the Article 29 Working Group and European Data Protection Board, or hire some good experts on this. There is no easy answer, or one size fits all solution. The GDPR isn't so hard to understand or implement, but it does require some change in mindset. With the new law, processing personal data carries a higher risk of penalties, so you should do it only when it's absolutely necessary, and with respect to the rights of your users.
The GDPR does not mandate specific features, but that any processing is lawful and transparent etc. So what would be the purpose of storing a revision history? Once that is clear you can work out an appropriate legal basis (e.g. a legitimate interest) and then figure out which data subject rights apply. For example, let's assume that there is a security interest in keeping a revision history, so that (a) mistaken edits can be rolled back, and (b) the user can be notified of possibly unauthorized changes. This would be a legitimate interest primarily of the account holder, secondarily of you as the system operator. Of course, such security requirements have to be proportional, but I'd see that as given when there's a payment method on file. You are required to apply appropriate safety measures and to apply the data minimization principle. E.g. is it necessary to store this revision history for all eternity? No, one or two months will likely be sufficient. Who should have access to this data? If the purpose is to defend against unauthorized access, it could make sense to only give out this data on request, and otherwise only make it available to support and security staff. Now we can discuss how this interfaces with rectification or deletion. That the user is able to rectify their data themselves is very good. However, that doesn't imply a prohibition on keeping a revision history: the revision history indicates what data was stored at what point in time, and is by definition correct. This assumes that you are not using the revision history for any other purposes. When the legal basis is a legitimate interest, a request for erasure has to be preceded by (or implies) an objection (opt-out) to further processing. The objection must weighed against the legitimate interest: the objection can be denied when there are overriding grounds to continue processing. This might be the case for a security purpose: if someone with unauthorized access can just erase their traces, the purpose cannot be achieved. But perhaps the user could opt out when they create their account? Or opt-out later, but with some delay to still achieve the security purpose at the time of opt-out? In any case, erasure is required when the data is no longer necessary for its purpose – this ties back to picking an appropriate retention period, as discussed above. So it's not really possible to provide a general answer, and it really depends on the specific purpose you are trying to achieve.
Artice §12(5) GDPR limits the right to access: Information provided under Articles 13 and 14 and any communication and any actions taken under Articles 15 to 22 and 34 shall be provided free of charge. Where requests from a data subject are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either: (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or (b) refuse to act on the request. The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request. A request to request the filing that you acted on their request is already excessive, repeated and frequent requests could be acted upon by taking the not-acting steps or sending an invoice before any action is taken. Also, very frequent requests with overlapping times might be answered jointly. It would be good to inform the customer in the last answer granted for free, how often they requested information and that any further answer might incur such and such fees for compiling the information.
What many people miss in relation to GDPR is the other five lawful bases for processing - there's a lot of discussion about consent, but this is only one lawful basis of six. The full list from Article 6 : Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Arguable bases would include performance of a contract or public interest, though there's also room to argue whether legitimate interests of the controller are, or are not, overriden by the subject's fundamental rights and freedoms. The short answer is it's not just about consent, and press and social media sites are likely to have covered themselves with their contract or with a public interest argument.