Right to delete from backups

[GrumbleDook]

Just because an individual requests to have data removed it doesn't mean you *have* to.

 

An example would be attendance data. You are not granted consent to collect and process it by individuals because it is a legal obligation for schools to collect such data and process it, including passing it on to other bodies such as DfE.

 

The problem is the the DfE do not have a clear list of this anywhere that is easily found.

 

ICO have now said speak to DfE, so that's the next step (others are already contacting DfE on things so we can ask if this can be included).

[GrumbleDook]

Btw ... DPA covering hard copy isn't stupid ... it is about consistency.

[nicholab]

Btw ... DPA covering hard copy isn't stupid ... it is about consistency.

 

But it was completely unfair on organisations that had worked on paper since 1984. It gave them additional burdens. Also computerised records have been around since 1954 why did everyone get in a flap in 1984 about it?

[GrumbleDook]

Because of the growth of centralised systems. Previously it was a nightmare to collate different data sets together, but it started to get a lot easier.

[pcstru]

I suppose the question here is would be is it OK to keep data on a backup where you've been asked to remove it as long as you never use the backup (and have a note that in the event that you do restore it you need to immediately remove that data once it has been made live)?

 

Technically you still have the data you've been asked to delete but you have a note to never use it nor make it live again. Would that satisfy the GDPR requirements.....!

 

I'm guessing not but I can't think of a workable solution unless backup/database providers are going to start building the functionality into their systems.

 

The fact is there will always be a delay. The question is how long a delay is acceptable. For deletion, there is additionally a technical issue of what it means to 'delete' data. When you delete a file, the data is still on the media, it is just the pointer to that data that is updated. That is similar to what I suggest, the data is still on some media but the pointers say you can't actually use it.

[psydii]

I wonder if this is going to be another of those levers central government can use encourage adoption of their cloud first policy.

https://www.gov.uk/guidance/government-cloud-first-policy

 

https://blogs.microsoft.com/on-the-issues/2017/02/15/get-gdpr-compliant-with-the-microsoft-cloud/#sm.001ga051w17ones4u1s145vtwgg5m

https://products.office.com/en-gb/business/compliance-tools-ediscovery

 

https://www.blog.google/topics/google-cloud/google-cloud-our-commitment-general-data-protection-regulation-gdpr/

https://support.google.com/vault/answer/2462365?hl=en&ref_topic=2739742

Edited June 27, 2017 by psydii

[DrCheese]

Don't worry about it. It is well outside of our control. The are plenty of CIO level types who will ensure sanity prevails in this matter.

I would hope so - I can't see many businesses being happy with the risks of removing data from backups i.e removing data may damage the backups rendering them unusable & then it also becomes a "Oh file X isn't on the backup, is that due to GDPR/wasn't backed up/corrupt backup?"

[enjay]

I think you should read what I wrote again. The key element is procedural and not particularly tied to any technology.

 

Not really. Your suggested procedure was to mark a backup media as "do not restore". We don't have access to any of our backup media (other than the Shadow Copies), and the backups which do exist contain multiple customers' data so we couldn't ask for it to be marked as "do not restore".

[flyinghaggis]

I would hope so - I can't see many businesses being happy with the risks of removing data from backups i.e removing data may damage the backups rendering them unusable & then it also becomes a "Oh file X isn't on the backup, is that due to GDPR/wasn't backed up/corrupt backup?"

 

I suppose this highlights the reason why the CIO/Data Protection Office role shouldn't be a technical member of IT staff or a database admin for a specific system. Someone with responsibility for the integrity of the backups and/or maintaining the database system will immediately have a conflict of interest with removing data to comply with GDPR!

Edited June 27, 2017 by flyinghaggis

[pcstru]

Not really. Your suggested procedure was to mark a backup media as "do not restore". We don't have access to any of our backup media (other than the Shadow Copies), and the backups which do exist contain multiple customers' data so we couldn't ask for it to be marked as "do not restore".

You presumably have the ability to keep a log of what backups you have and what they contain? You are presumably the people that would ask for a backup to be restored? If both of those are true then you have everything you need to add another column to your list which will record that the backup should not be restored.

 

Fundamentally if you do have a backup system that cannot meet the needs of the GDPR, then currently there is no question that it will be your backup system that has to change.

[MrWrighty]

You presumably have the ability to keep a log of what backups you have and what they contain? You are presumably the people that would ask for a backup to be restored? If both of those are true then you have everything you need to add another column to your list which will record that the backup should not be restored.

 

Fundamentally if you do have a backup system that cannot meet the needs of the GDPR, then currently there is no question that it will be your backup system that has to change.

I'm in the process of reviewing backup software and how it might handle the 'Right to be Forgotten"

 

If you need to do a bulk restore because of a catastrophic failure, then data for an individual who has requested a right to be forgotten, will be restored to the system. If you keep records to remind you to then subsequently remove that data.

 

Even at file level restores, say a spreadsheet or document, these could conceivably contain reference to this individual, how will that work. How will the user of such data remember that this individual needs to be forgotten and remove the records again.

 

This is very much dependant of the backup strategy, but some backups are kept for much longer that GDPR gives to remove the data under the right to be forgotten.

Edited January 19, 2018 by MrWrighty

[tj2419]

I attended a GDPR training event recently and re-asked the question regarding deleting files from backups and again was told that yes this would be expected. When I asked what do we do if our backup provider cannot do this he said: "then you have a problem".

 

He queried why we needed to keep backups going back 1-2 months, saying surely you just need to be able to restore from the most recent backup so just keep a weeks worth of backups.

 

Has anyone had any further luck clarifying what will be expected of us? How long do you/will you be keeping your backups for?

 

I've contacted our backup software provider and they said

There are no plans that we’re aware of for us to have a feature that does this. To be honest I can’t even think what the feature would be as it’s just not feasible to have an option that can somehow magically remove all data from backups going back however long that only relates to a specific person that is wanting their information erased.

 

While in theory GDPR ‘might’ require a person’s information to be removed from backups, it’s really hard to imagine how this is ever going to work or be enforced in practice. Here’s a couple of links that perhaps show what a complex area this is:-

GDPR: Does the Right to Erasure Include Backups? - Froud on Fraud

https://forums.veeam.com/veeam-backup-replication-f2/general-data-protection-regulation-gdpr-t40950.html

 

My guess is that it’s probably going to be important for organisations to have a policy in place such that if backups are ever needed to be restored that any persons’ information that was requested to be erased since the backup was made is also purged from the newly restored data. Of course, though that would also require that you retain enough information to allow you to do that but where do you keep that data if you’ve also been asked to erase it? I think the answer is that organisations will need to apply some common semse with this stuff because in terms of software having a tickbox option to deal with this stuff – I think that’s probably unlikely.

[Katy]

I think the only way it would work is with a list of what to delete on restore, otherwise you've got the same problem not just with tape backups but also shadow copy.

 

There's also no way I'd only keep the latest backup - what if there's a ransomware that slips through unnoticed and we've erased the last clean backup because it wasn't the latest?

[nicholab]

I have a more helpful answer you say that this is not possible as it requires too much effort. But you could have a pseudonymization data list that has to be remove after the data has been restored. This is from my GDPR training yesterday. You could argue that it is held for one of the 5 other reasons. It would be incredibly helpful if SIMS had a way of archiving data to the required number of years. Edited February 8, 2018 by nicholab

[MrWrighty]

I attended a GDPR training event recently and re-asked the question regarding deleting files from backups and again was told that yes this would be expected. When I asked what do we do if our backup provider cannot do this he said: "then you have a problem".

 

He queried why we needed to keep backups going back 1-2 months, saying surely you just need to be able to restore from the most recent backup so just keep a weeks worth of backups.

 

Has anyone had any further luck clarifying what will be expected of us? How long do you/will you be keeping your backups for?

 

I've contacted our backup software provider and they said

 

Its worrying to think that those preaching to us about GDPR have little understanding about IT services and backup procedures and the reason for keeping backups for extended periods. This also highlights that regulation and practicality have little in common. Different professions will require different backup terms.

[PotNoodleTech]

This is a total minefield. Being expected to remove a specific document or even a specific line of text containing a specific name from your entire IT estate is just unrealistic and untenable.

 

Correct me if I am wrong, but from what I can see, there is NO backup software currently available that could satisfy these absurd requirements.

 

Having reliable fully intact backup is a "business critical" core requirement of IT services.

 

What if there is some graffiti on the underside of a desk with some ones name on - do we have to search every inch of the entire school premises and remove it? What if a photo was taken of a data subject by the local rag as they did something awesome, are we expected to be able to remove that data from the general public? It just goes way to far IMHO.

[Katy]

I have a more helpful answer you say that this is not possible as it requires too much effort.

In some places it's not "too much effort" - it's downright impossible. You can't delete specific files from volume shadow, the "previous versions" windows are read only. We're not disabling VSS as we use that a lot when someone says "This folder has disappeared" when what they actually mean is they (or someone when they left a PC unlocked) deleted it 3 months ago.

[psydii]

On Server, configured to make this possible you **can** break a shadow volume set and mount it read-write. Kind of the same way you *can* walk through a wall as long as you knock a hole in it first. https://msdn.microsoft.com/en-us/library/windows/desktop/bb530725(v=vs.85).aspx#breaking_a_shadow_copy_set

 

I do wonder if it is true that no vendor can actually implement this "requirement" whether it really is a requirement or simply folk zealously interpreting the regulations to absurdity.

Edited February 8, 2018 by psydii

[synaesthesia]

Many backup solutions including windows server backup use crc checking; if a file goes missing suddenly yet it's still in the catalogue, that entire backup is rendered pretty much useless (maybe files are extractable but bare metal is a straight no-go)

It's not doable regardless, there is a simple black and white choice. As it stands, you can have backups, or you can be GDPR compliant.

[MrWrighty]

On Server, configured to make this possible you **can** break a shadow volume set and mount it read-write. Kind of the same way you *can* walk through a wall as long as you knock a hole in it first. https://msdn.microsoft.com/en-us/library/windows/desktop/bb530725(v=vs.85).aspx#breaking_a_shadow_copy_set

 

I do wonder if it is true that no vendor can actually implement this "requirement" whether it really is a requirement or simply folk zealously interpreting the regulations to absurdity.

 

Shadow copies are not an excuse for proper backups. If you are solely relying on VSS Shadow copies and feel that editing their content in the way you suggest, is acceptable, then you need to re-visit your backup strategy.

[Katy]

Shadow copies are not an excuse for proper backups. If you are solely relying on VSS Shadow copies and feel that editing their content in the way you suggest, is acceptable, then you need to re-visit your backup strategy.

I don't think anyone was suggesting this - I mentioned that you can't selectively delete from VSS, which you would have to do in addition to deleting from your backups. We use Shadow Copies as a quick and easy solution to "I deleted this by mistake", rather than having to mount the Veeam backups and pull files out. This is in addition to proper backups with Veeam both to multiple disk and to tape.

 

However I don't think that we should be expected to break VSS just to wipe some data out.

[MrWrighty]

I don't think anyone was suggesting this - I mentioned that you can't selectively delete from VSS, which you would have to do in addition to deleting from your backups. We use Shadow Copies as a quick and easy solution to "I deleted this by mistake", rather than having to mount the Veeam backups and pull files out. This is in addition to proper backups with Veeam both to multiple disk and to tape.

 

However I don't think that we should be expected to break VSS just to wipe some data out.

 

My response was to @psydii who was suggesting mounting a Shadow Copy to delete data which would be a pointless exercise if you couldn't do the same with your main backups. We all use VSS as a quick fix, but could easily fall foul of the RTBF rule in GDPR if restoring a Shadow Copy returns previously deleted data to a live system. This aspect of GDPR is poorly thought through from an IT need to have robust and timely backups kept for varying lengths of time depending on legal requirements and industry requirements.

[Katy]

My response was to @psydii who was suggesting mounting a Shadow Copy to delete data which would be a pointless exercise if you couldn't do the same with your main backups.

@psydii's post about shadow copy was a repsonse to mine about not being able to delete out of VSS - although admittedly I wasn't quoted in it so maybe that wasn't clear.

[GrumbleDook]

Without saying “you must do it this way” (mainly because the same discussion is happening across all sectors and I’ve yet to see any complete answer), think about this from the other end of the problem.

 

The school has a retention schedule. The school can dictate how and where things are stored ...

 

Knowing that, can you design an information and file structure and storage that will allow you to backup and restore as per your retention schedule?

 

Then think how you are going to get to that point from where you are.

[synaesthesia]

How is that anywhere near practicable though?

It's easy enough to mandate separate storage areas for data and back those up on an appropriate regime & retention schedule, but that's only for very basic file storage. The vast majority of the data that needs protecting will be embedded in SQL databases and the likes.

The law can be as strict as it likes, but who here would agree that it is acceptable to no longer have bare metal backups we can "just restore" without having to do extra work, or those of us lucky enough to use systems like Veeam where we can have a backed up machine restored in a matter of seconds.