9

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?

4
  • Isn't this a rather straightforward "yes" answer? If archives or backups were somehow exempt, the law would immediately become useless.
    – A.fm.
    Apr 14, 2018 at 14:10
  • 2
    There is ambiguity around this, since you can have backups from years past and they are stored in a compressed manner. So if you need to purge a person's data, you will need to locate every backup, bring it on-site if its located offsite ( can be on tapes) and restore it. Then locate that person's data and delete it. A very time-consuming task. So my question is can an organization choose to not perform this onerous task?
    – sharadov
    Apr 16, 2018 at 19:49
  • 1
    This is one of the reasons why I would be surprised to find that any major internet business is truly GDPR compliant, regardless of the amount of effort they have put into becoming so. Mar 4, 2019 at 18:34
  • They are going after the big fish, they want regulatory action against the internet giants and rightfully so.
    – sharadov
    Mar 20, 2019 at 16:03

2 Answers 2

4

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:

  1. 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.

  2. 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).

6
  • 1
    I know it benefits the customer in the end, but its simply ridiculous and awfully expensive for small and mid-size companies to comply.
    – sharadov
    Apr 17, 2018 at 20:58
  • 'Organisations that have become used to keeping backups of everything forever will need to modify their practices and culture in order to comply' - I think this gets to the heart of it. You can't keep the data forever, which will naturally mean that, once you have process in place to remove data from your live systems and databases, your backups will also become 'clean' after a while.
    – Craig
    Apr 19, 2018 at 9:04
  • For the majority of small and mid-sized businesses the majority of work involved with compliance will be documenting and updating formal processes and controls regarding how personal data is managed by the organisation. It seems unlikely to me that SMEs will get a lot of access/erasure requests, and at least SMEs (less than 250 employees) aren't required to keep full processing records which reduces the burden massively from what larger enterprises have to do. Apr 19, 2018 at 10:37
  • @sharadov: It is. The EU is not known for being small-business-friendly.
    – MSalters
    Apr 19, 2018 at 10:38
  • @richhallstoke Thanks, we have about 400 people, do you have a document which explicitly mentions this?
    – sharadov
    Apr 19, 2018 at 16:15
2

Based on the rules, when an individual invokes "forget me", it means the company must delete all data related to the individual.

This is partly wrong. Art. 17(1) lists 6 ground when data has to be deleted. Only when one of those apply, data has to be deleted.

Does this relate to backups as well?

The primary purpose of a backup is to recover data after its loss. This means having a backup is a legitimate interest of a company. Processing of personal data in the backup is based on point (f) of Art. 6(1).

This means that points (a), (b), (d), (e) and (f) of Art. 17(1) don't apply. This leaves only point (c):

(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) is:

  1. The data subject shall have the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her which is based on point (e) or (f) of Article 6(1), including profiling based on those provisions. The controller shall no longer process the personal data unless the controller demonstrates compelling legitimate grounds for the processing which override the interests, rights and freedoms of the data subject or for the establishment, exercise or defence of legal claims.

Keeping the backup untouched, is a compelling legitimate ground. Any processing on a backup has a risk of data loss. Creating a backup of a backup defeats the purpose of the processing.

However, in case of a recovery of a backup, data will be restored which the individual requested to delete. This has to be avoided. In particular the case when the personal data is processed for marketing. In that case Article 21(2) does apply. So you need to store a list of all deletion requests which were received after the backup was created. Whenever you need to restore the backup, you reprocess all deletion requests before using the data. That way, the data will not contain anything any more which was requested to delete by the individual. Of course, you also need a proper backup strategy of the deletion requests list.

Or when the individual demands all records related to him, are you supposed to retrieve all archived records as well?

No, Art. 5 requires you to stop processing personal data when you don't have a purpose any more. When you delete personal data, you have a reason to delete it. You cannot "undelete" data just for an access request.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .