GDPR Compliance - does it extend to database backups and archived records? How do the rules for GDPR affect database backups or archived data?As a company, you might have backups/archived data going back years. Based on the rules, when an individual invokes "forget me", it means the company must delete all data related to the individual. Does this relate to backups as well? Are you supposed to restore the backups and delete all records pertaining to the individual? Or when the individual demands all records related to him, are you supposed to retrieve all archived records as well?
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).
As I understand it there is no obligation to 'triage' SARs or keep data 'just-in-case' that would otherwise be deleted as a matter of routine. Can we amend or delete data following receipt of a SAR? It is our view that a SAR relates to the data you held at the time you received the request. However, in many cases, routine use of the data may result in it being amended or even deleted while you are dealing with the request. So it is reasonable for you to supply the information you hold when you respond, even if this is different to what you held when you received the request. However, it is not acceptable to amend or delete the data if you would not otherwise have done so. Under the DPA 2018, it is an offence to make any amendment with the intention of preventing its disclosure. https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/right-of-access/how-do-we-find-and-retrieve-the-relevant-information/
Your analysis so far seems correct. You must comply with all applicable laws. The GDPR's Art 6(1)(c) legal basis clarifies that having to provide personal data is no excuse: that legal obligation is all the legal basis you need for sharing the personal data in accordance with your obligations. However, that legal basis doesn't generally excuse you from your other data controller obligations. For example, you should still inform the data subjects about the processing as per Art 13(3).
Art. 17 GDPR Right to erasure (‘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 where one of the following grounds applies: Assuming private messages contain personal data, if at least one of the following points (a..f) applies, it would have to be deleted. (a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed; The original main purpose was probably Article 6(1)(b) (performance of a contract). If you delete your account, that would no longer apply. However, for the receiver of the private message, Article 6(1)(f) (legitimate interests pursued by a third party) would apply. The receiver might still want to read that message. So there is still a purpose to process this data. So point (a) does not apply. (Note that a Facebook private message can be considered a hosted version of SMS messages. A receiver does not expect SMS messages to be automatically deleted after they have reached the recipient's device. A receiver expects full control of the storage of SMS messages. I think a receiver expects the same for messages on facebook.) (b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing; Data processing was not based on consent, so point (b) does not apply. (c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2); Article 21(1) allows you to object to processing based on Article 6(1)(f), unless there are compelling legitimate grounds for the processing which override the interests, rights and freedoms of the data subject. While I think processing is based on Article 6(1)(f), I also think there are legitimate grounds to refuse your objection. As explained before, the receiver might still want to read that message. The receiver was able before to read your message, so one can assume he/she has already knowledge of the personal data in the message. As it is a private message, no one else will be able to read that message. (At least Facebook will not allow it). So if the message is not deleted, the privacy implications for you are low. That's why I think the interests of the receiver will prevail. However, in the end, a judge will be the only person which can make such a consideration. So you would have to got to court to get a final decision about this. Article 21(2) is for direct marketing, that does not apply to this situation. So I think point (c) does also not apply. (d) the personal data have been unlawfully processed; (e) the personal data have to be erased for compliance with a legal obligation in Union or Member State law to which the controller is subject; These points do not apply. (f) the personal data have been collected in relation to the offer of information society services referred to in Article 8(1). This data processing was not based on consent, so even if you are a child below the age of 16 years, point (f) does not apply. Article 17(2) and Article 17(3) wont help you either. So in my opinion Facebook is right in this case.
If I have correctly untangled the law, Schedule 2 of the Data Protection Act part 3 identifies as a condition where you are not prohibited from revealing personal data: The processing is necessary for compliance with any legal obligation to which the data controller is subject, other than an obligation imposed by contract. The Animal Welfare Act 25(1) says An inspector may require the holder of a licence to produce for inspection any records which he is required to keep by a condition of the licence I can't tell if you are required to keep customer names, but if you are, it looks like the pieces fit together and you would have to provide the records. Call a solicitor to be sure, though.
A data subject access request can be valid even if it wouldn't disclose new information. The right to access ties in with the GDPR's transparency principle (finding out which data is being processed) and with the right to rectification (are there any mistakes in the data being processed?). For rectification, it's pretty much ideal if you get back exactly the data you expect – but you're allowed to check with an access request. The Art 12(5) limitations on excessive or manifestly unfounded requests do put a limit on the right to access, but this limit helps controllers respond to legitimate requests. For example, if a request is clearly intended to harass the controller with busywork, it can be denied as unfounded. Similarly, requesting access to the same data very frequently would be excessive. However, the controller has burden of proof to show that the request is excessive or unfounded – basically impossible for a one-time request for specific data. A request is not automatically excessive just because it is likely to only return data you already know. But ultimately, detailed guidance on the interpretation of “excessive” is up to the supervisory authorities – the GDPR itself provides no guidance. Aside from the above exception, access can only be denied if it would adversely affect the rights and freedoms of others. For example, you could be denied access to non-anonymous performance reviews. There would be no such adverse effect for basic information about your employment. If a data controller improperly considers your request as excessive or unfounded, you can lodge a complaint with your supervisory authority, e.g. the ICO in the UK. Most controllers are suddenly extremely helpful once contacted about an official complaint.
They provide a snail- and e-mail way to end the contract here. This will not eradicate the €50 that they say you owe, but you can sort that out separately. That email address might also respond to inquiries about the validity of the charge. At any rate, they also give a link to online dispute resolution per Art. 14, para 1 of the EU Online Dispute Resolution Regulations. GDPR does not give one the right to be deleted so as to avoid an existing liability.
Whether GDPR applies does not depend on the country of residence. Instead, GDPR applies to a non-EU site or service if the data controller offers products or services to people in the EU (see Art 3(2) GDPR). This depends solely on the behaviour and intent of the data controller / the provider of the website – compare also the discussion of the “targeting criterion” in EDPB guidelines 3/2018 on the territorial scope of the GDPR. While your proposed measures might not be entirely ineffective (in that they document an intent to not serve people in the EU), they are both unnecessarily restrictive and overly lax. For example, they would unnecessarily prevent EU tourists in the US from registering but would nevertheless allow US tourists in the EU. For the targeting criterion, it matters whether the data subject is in the EU at the time of the offer, not at all what their residency is. Even if a person who is currently in the EU registers with your service, that doesn't necessarily mean that you are targeting people in the EU. Instead of implementing signup restrictions, a better strategy might be to clarify in the copy on your website that you are only targeting the domestic US market, not the European market with your services. I have discussed this in more detail in an answer to “How can you block GDPR users from US based sites?” If you have a site where GDPR doesn't apply, and you receive a GDPR data subject request, you shouldn't deny it on the basis that the user must have lied – instead you can deny it on the basis that GDPR just doesn't apply to you.