Right to delete from backups

[nicholab]

Also students break the schedule by leaving the school at odd time or should we hand data on and dispose of our copy?

[synaesthesia]

There's far too many variables. Staff & students come and go, data comes and goes. And they leave, and come back again (this happens surprisingly often with students).

Currently the only reasonable thing that can be expected of us is to make reasonable adjustments where possible but that's it. It's not worth worrying about too much otherwise, we're at a loss until either a) backup solutions are updated or made available to cope with this, or someone heading up GDPR ends up realising some demands are unrealistic and amendments are made.

 

So let's put some brains together for now. What I can think of in my slightly odd mind: (I'm coming off pills at moment giving me an odd head)

 

File servers contain:

* Personal user information held by the user themselves (data in their own areas)

* Personal user information held on shared areas

* Personal user information held on 3rd party user areas (student information in staff areas)

File servers are usually unencrypted, plain text and secured by NTFS or similar permissions. Possible to have separate areas for storing certain information but a) impractical b) mostly unenforceable. Rarely any databases to worry about.

 

Domain controllers:

* Hold identifiable information pertaining to staff and students

* This information would usually be contact details (email addresses), betray a users age (year groupings, year of entry based usernames etc)

* AD is often used to authenticate many other systems which allow access to MIS, finance, NTFS permissions etc.

Domain controller backups are *fixed* and in no way should they be tampered with for any purpose of trying to remove data. This is probably the biggest sticking point for backup data retention IMO and I would love for anyone in a court of law to try and argue that with me.

 

MIS servers contain:

* Personal information of staff, students, parental/guardian contacts

* Employment information of staff including contractual and financial

Typically MIS servers hold a small file holding area, as per a file server however most data is stored within an unencrypted database i.e. SQL. Most backup solutions would handle SQL databases separately from normal files.

 

Finance servers contain:

* Financial information of suppliers

* Financial information of the school and affiliates

* Financial information of students & staff

Finance servers are typically entirely databases, usually the same or integrated with the MIS system. May be additional financial packages alongside an MIS integrated system to handle payroll or 3rd party finances, i.e. School Cash Office, Sage. However, both SCO and Sage do run from databases but not a db recognised or separately handled by the vast majority of backup solutions.

 

Backup systems:

* May be content agnostic, aka block level, i.e. Veeam.

* May, as mentioned, be able to separate SQL databases from daily file storage

* Can be granular enough to allow bare metal restores without files.

 

Anything else? I won't say what is being asked is impossible, as everything is possible. It is however currently entirely unfeasible.

Edited February 8, 2018 by synaesthesia

[GrumbleDook]

someone heading up GDPR ends up realising some demands are unrealistic and amendments are made.

 

That'll be Andrea Jelinek, Data Protection Commissioner of Austria and newly elected Chair of the Article 29 Working Party, which will be replaced by the European Data Protection Board come 25th May.

Folk are extremely vocal about the problem ... but to minimise it people are having to rethink what they store, how it is backed up and how it is retrieved.

 

If you are restoring data bases or from databases, then knowing what you need to remove once the restore is complete is a start.

Having other files in a structured format also helps to ensure that data is not restored, or is restored and then items removed.

 

One of my questions would be if data could be held on a student until the expected leaving date, not the actual leaving date ... ICO response has been it is down to the school to justify their retention schedule.

We've asked IRMS if they are updating their toolkit and they have said yes, but as a volunteer organisation it is down to those helping. If your school uses the toolkit, get someone to join IRMS and get involved.

[synaesthesia]

The joys.

http://www.searchamateur.com/pictures/us-army-mine-sweeper-250.jpg

[DSapseid]

I believe Redstor are developing 'Search & Destroy' as part of their backup software for exactly this situation.

[flyinghaggis]

This just highlights the reason that IT managers and system administrators shouldn't be the data protection officer for the GDPR role. We have far to much of a vested interest in maintaining the security and smooth running of networked systems to prioritize GDPR requirements above them. The same goes for anyone in charge of a specific system really.

 

If it comes down to a choice between prioritizing complying with GDPR legislation or keeping optimal/complete backups which one do your think every IT manager responsible for any system is going to pick!

 

The kickback on this thread to the requirement to delete data from backups is the perfect example of this!

Edited February 9, 2018 by flyinghaggis

[GrumbleDook]

There's far too many variables. Staff & students come and go, data comes and goes. And they leave, and come back again (this happens surprisingly often with students).

Currently the only reasonable thing that can be expected of us is to make reasonable adjustments where possible but that's it. It's not worth worrying about too much otherwise, we're at a loss until either a) backup solutions are updated or made available to cope with this, or someone heading up GDPR ends up realising some demands are unrealistic and amendments are made.

 

So let's put some brains together for now. What I can think of in my slightly odd mind: (I'm coming off pills at moment giving me an odd head)

 

File servers contain:

* Personal user information held by the user themselves (data in their own areas)

* Personal user information held on shared areas

* Personal user information held on 3rd party user areas (student information in staff areas)

File servers are usually unencrypted, plain text and secured by NTFS or similar permissions. Possible to have separate areas for storing certain information but a) impractical b) mostly unenforceable. Rarely any databases to worry about.

 

Domain controllers:

* Hold identifiable information pertaining to staff and students

* This information would usually be contact details (email addresses), betray a users age (year groupings, year of entry based usernames etc)

* AD is often used to authenticate many other systems which allow access to MIS, finance, NTFS permissions etc.

Domain controller backups are *fixed* and in no way should they be tampered with for any purpose of trying to remove data. This is probably the biggest sticking point for backup data retention IMO and I would love for anyone in a court of law to try and argue that with me.

 

MIS servers contain:

* Personal information of staff, students, parental/guardian contacts

* Employment information of staff including contractual and financial

Typically MIS servers hold a small file holding area, as per a file server however most data is stored within an unencrypted database i.e. SQL. Most backup solutions would handle SQL databases separately from normal files.

 

Finance servers contain:

* Financial information of suppliers

* Financial information of the school and affiliates

* Financial information of students & staff

Finance servers are typically entirely databases, usually the same or integrated with the MIS system. May be additional financial packages alongside an MIS integrated system to handle payroll or 3rd party finances, i.e. School Cash Office, Sage. However, both SCO and Sage do run from databases but not a db recognised or separately handled by the vast majority of backup solutions.

 

Backup systems:

* May be content agnostic, aka block level, i.e. Veeam.

* May, as mentioned, be able to separate SQL databases from daily file storage

* Can be granular enough to allow bare metal restores without files.

 

Anything else? I won't say what is being asked is impossible, as everything is possible. It is however currently entirely unfeasible.

 

This is a cracking start and I would heartily recommend others contribute their ideas based on operational possibilities ... talk about the limits of available products, possible compromises ... but keep in mind the retention schedule ...

[enjay]

So let's put some brains together for now. What I can think of in my slightly odd mind: (I'm coming off pills at moment giving me an odd head)

 

We have different backup strategies for different servers. File servers are kept for 12 months but the print server only for 1 month, as I can't think of a context I would want to restore a 3-month-old version of our print server, but can see needing to restore a three-month-old file. Same goes for the DC server, as critical issues with that would be spotted quickly, so again I don't see I'd need a 3-month-old backup set.

[enjay]

At the GDPR training I attended yesterday, the speaker said there is wording to the effect of "where affordable" in this, so if we can't afford to implement a backup system which permits complete destruction from all data sets, we can justify not doing it. I'm yet to cite/verify that statement, but doing so is definitely on the list.

 

As with other risk analysis, isn't "likelihood" something we should consider here? So, let's say someone has requested erasure from our system and backups, and let's say we've consented as we can't justify keeping it. So, we remove everything from the live files and from the live database, but they still exist in backup. We don't have the technology to remove them from the backups, so instead we mark them in some way to remind the IT staff not to restore data on that person. All good so far. Now let's fast-forward 8 months to someone doing a data recovery and - potentially - restoring reference to the person who asked to be forgotten. First off, it is unlikely the forgotten person would actually be mentioned in the data restored anyway. Second of all, even if they were, they could be removed again easily enough as restores are typically single file not multiple folders containing hundreds of files.

 

So, one could argue we could continue with our current backup system, as we would have sufficient measures in place to ensure the not-fully-forgotten person doesn't re-appear in live data. Reasonable?

 

Of course, you also get the issue that if someone has asked to be forgotten, presumably I wouldn't be allowed to mark the backup set with a note saying "don't restore anything about Fred Bloggs" because that note would in itself contravene Fred's right to be removed from our systems!

[MrWrighty]

That'll be Andrea Jelinek, Data Protection Commissioner of Austria and newly elected Chair of the Article 29 Working Party, which will be replaced by the European Data Protection Board come 25th May.

Folk are extremely vocal about the problem ... but to minimise it people are having to rethink what they store, how it is backed up and how it is retrieved.

 

If you are restoring data bases or from databases, then knowing what you need to remove once the restore is complete is a start.

Having other files in a structured format also helps to ensure that data is not restored, or is restored and then items removed.

 

One of my questions would be if data could be held on a student until the expected leaving date, not the actual leaving date ... ICO response has been it is down to the school to justify their retention schedule.

We've asked IRMS if they are updating their toolkit and they have said yes, but as a volunteer organisation it is down to those helping. If your school uses the toolkit, get someone to join IRMS and get involved.

 

Surely the RTBF rule only applies to staff, it cannot apply to students as there is a legal requirement to keep this data and pass it on where relevant, and if a student does come and go there should be no issue.

Does keeping a record of the data you need to delete come under the data retention policy and potentially contain information about those that want their information removed.

[enjay]

Surely the RTBF rule only applies to staff, it cannot apply to students as there is a legal requirement to keep this data and pass it on where relevant, and if a student does come and go there should be no issue.

 

No. It applies to ex-students.

 

Also parents of ex-students - it is easy to think of the data in SIMS etc. as being about the students only, but some of it is about their parents too - contact details, obviously, but also notes from meetings they were involved in, home visit reports, Social Services letters, etc.

[Katy]

Surely the RTBF rule only applies to staff, it cannot apply to students as there is a legal requirement to keep this data and pass it on where relevant, and if a student does come and go there should be no issue.

Does keeping a record of the data you need to delete come under the data retention policy and potentially contain information about those that want their information removed.

 

Also, does RTBF cover things like your name, or does it need to be associated with some other data such as DOB etc? If not, then list of "delete references to $person in $files" on a secure list with the backups should be fine.

[MrWrighty]

No. It applies to ex-students.

 

Also parents of ex-students - it is easy to think of the data in SIMS etc. as being about the students only, but some of it is about their parents too - contact details, obviously, but also notes from meetings they were involved in, home visit reports, Social Services letters, etc.

 

Does it apply to ex-students across the board, surely it only applies if that student has left the education system and has passed the DOB + 25 years retention requirement (Secondary Schools). Parents data is a different matter and subject to different retention policies.

Edited February 9, 2018 by MrWrighty

[enjay]

Does it apply to ex-students across the board, surely it only applies if that student has left the education system and has passed the DOB + 25 years retention requirement (Secondary Schools). Parents data is a different matter and subject to different retention policies.

 

Indeed. We cannot delete them until DOB+25, but after that point they could be deleted if they wished, even if we would like to keep for longer.

[mavhc]

How come it's been 22 months since GDPR was adopted, and no one knows what's going on? What have the people in charge been messing about with?

 

Why should everyone waste time working out what it all supposedly means, just tell us. All this work and ~0 people will care.

[rom1984]

At the GDPR training I attended yesterday, the speaker said there is wording to the effect of "where affordable" in this, so if we can't afford to implement a backup system which permits complete destruction from all data sets, we can justify not doing it. I'm yet to cite/verify that statement, but doing so is definitely on the list.

 

!

 

I think the person who told you this is getting confused with another paragraph within Article 17 which is the Article that deals with the right to erasure. If a data controller makes personal data public (for example by the consent of the data subject) and they then receive a request for erasure from that person, the data controller must attempt to delete the data in the public domain taking into account the cost of doing this, the technical measures available and the reasonable steps that can be taken.

 

There is nothing else that I can see in the Article or the recitals that suggests the data controller can take into account things like cost etc when dealing with a right to erasure.

Edited February 13, 2018 by rom1984

[rom1984]

Does it apply to ex-students across the board, surely it only applies if that student has left the education system and has passed the DOB + 25 years retention requirement (Secondary Schools). Parents data is a different matter and subject to different retention policies.

 

Just to expand on Enjays comment here, the recitals in Article 17 specifically go out of there way to say that any child who has given consent to process their data can at a later date request to have the data removed.

 

This is why it is so important that schools determine on which basis they are processing data and not just to have a blanket policy of "we collect all our data on the bases of consent"

 

Paragraph 3 of Article 17 says that the right to erasure need not apply if you have processed the data due to legal obligations, the performance of a task carried out in the public interest or for archiving purposes in the public interest. So if you have collected data about a student and told the student/parent that you were processing this data due to a legal obligation or in the publics interest, and they then request their right to erasure, you will be able to reject that request if you still need to keep the data due to your legal obligations.

 

Where it is frowned upon, is if the school collects the data on the lawful bases of consent, and the person requests to have the data deleted, and the school then says well actually we don't need your consent because its our legal obligation. The GDPR has set out that this can't be done and you must commit to one basis.

[enjay]

Paragraph 3 of Article 17 says that the right to erasure need not apply if you have processed the data due to legal obligations, the performance of a task carried out in the public interest or for archiving purposes in the public interest. So if you have collected data about a student and told the student/parent that you were processing this data due to a legal obligation or in the publics interest, and they then request their right to erasure, you will be able to reject that request if you still need to keep the data due to your legal obligations.

 

Where it is frowned upon, is if the school collects the data on the lawful bases of consent, and the person requests to have the data deleted, and the school then says well actually we don't need your consent because its our legal obligation. The GDPR has set out that this can't be done and you must commit to one basis.

 

That is exactly why we've been advised to use "consent" only if we really don't have any other grounds to process the data - we will mostly be using legal obligation and public interest. We were also advised to consider whether it is legal or public interest, not j ust bundle everything under one flag, as if we use "public interest" and this is deemed not to be valid, the processing would count as illegal if it could have be justified as "legal obligation".

[rom1984]

Yeah I agree you shouldn't bundle legal and public interest together, the school needs to decide which one it is, it can not be both for the purpose of processing personal data.

 

Do you know who advised you to use consent in the event you have no other grounds as I don't think that's right?

 

You shouldn't really just put it into consent unless it legitimately is consent. Remember as well that for consent to apply, it needs to be freely given. So it can not be consent if you are going to do it anyway, or for example when the person is almost blackmailed in to it (i.e you need to consent to be recorded in the classroom otherwise you won't be allowed in)

 

There is also an almost overriding principle within the GDPR that comes from Article 5 which is that data shall be processed lawfully, fairly and in an transparent manner. This principle will always be referred back to when dealing with the other Articles and is one that a school must always keep asking themselves - am I being fair, am I being transparent.

 

So if you tell the person at the point of collection what your data backup strategy is, how long you keep it for, why you keep it, your strategy for dealing with data removals on the backup, what the procedure is to restore data, then you will be 99% there in dealing with rights to removal in fair and transparent way. This will be looked at a lot more favourably compared to an school that didn't tell the person anything about backed up data and didn't do anything with a right to erasure request.

 

Finally, I can't remember what Article it is but the GDPR gives up to 2 months to deal with rights to erasure. So you could comply with a right to erasure and still have backups from up to 2 months ago with the data on. Again it will come back to fair and transparency, so did you tell the person that you still have a backup of them, did you tell them when the backup would be overwritten, did you tell them what will happen if you do a full data restore within the 2 months etc

[enjay]

Do you know who advised you to use consent in the event you have no other grounds as I don't think that's right?

 

You shouldn't really just put it into consent unless it legitimately is consent. Remember as well that for consent to apply, it needs to be freely given. So it can not be consent if you are going to do it anyway, or for example when the person is almost blackmailed in to it (i.e you need to consent to be recorded in the classroom otherwise you won't be allowed in)

 

Sorry, I was unclear. I didn't mean we should bung "consent" down as the reason if we can't think of what else to do, I meant we should try to find other reasons for our processing first before going and asking for consent to process.

[EdWhittaker]

I have spoken to the ICO about this and they do take a very pragmatic approach to the issue of deleting data from backups. Here is the advice:

Putting information ‘beyond use’

 

"The ICO will be satisfied that information has been ‘put beyond use’, if not actually deleted, provided that the data controller holding it:

 

 is not able, or will not attempt, (my emphasis) to use the personal data to inform any decision in respect of any individual or in a manner that affects the individual in any way;

 does not give any other organisation access to the personal data;

 surrounds the personal data with appropriate technical and organisational security; and

 commits to permanent deletion of the information if, or when, this becomes possible.

 

We will not require data controllers to grant individuals subject access to the personal data provided that all four safeguards above are in place. Nor will we take any action over compliance with the fifth data protection principle." Again my emphasis at the end there.

So, as long as the backup is held securely and you undertake not to retrieve personal data deleted from the live system and the data will be overwritten at some point in the future, then no-one is going to jail.

Edited February 22, 2018 by EdWhittaker

[PotNoodleTech]

I have spoken to the ICO about this and they do take a very pragmatic approach to the issue of deleting data from backups. Here is the advice:

Putting information ‘beyond use’

 

"The ICO will be satisfied that information has been ‘put beyond use’, if not actually deleted, provided that the data controller holding it:

 

 is not able, or will not attempt, (my emphasis) to use the personal data to inform any decision in respect of any individual or in a manner that affects the individual in any way;

 does not give any other organisation access to the personal data;

 surrounds the personal data with appropriate technical and organisational security; and

 commits to permanent deletion of the information if, or when, this becomes possible.

 

We will not require data controllers to grant individuals subject access to the personal data provided that all four safeguards above are in place. Nor will we take any action over compliance with the fifth data protection principle." Again my emphasis at the end there.

So, as long as the backup is held securely and you undertake not to retrieve personal data deleted from the live system and the data will be overwritten at some point in the future, then no-one is going to jail.

 

Fantastic work Ed!!!

[EdWhittaker]

Here is a link to the full document: https://ico.org.uk/media/for-organisations/documents/1475/deleting_personal_data.pdf

[rom1984]

I have spoken to the ICO about this and they do take a very pragmatic approach to the issue of deleting data from backups. Here is the advice:

Putting information ‘beyond use’

 

"The ICO will be satisfied that information has been ‘put beyond use’, if not actually deleted, provided that the data controller holding it:

 

 is not able, or will not attempt, (my emphasis) to use the personal data to inform any decision in respect of any individual or in a manner that affects the individual in any way;

 does not give any other organisation access to the personal data;

 surrounds the personal data with appropriate technical and organisational security; and

 commits to permanent deletion of the information if, or when, this becomes possible.

 

We will not require data controllers to grant individuals subject access to the personal data provided that all four safeguards above are in place. Nor will we take any action over compliance with the fifth data protection principle." Again my emphasis at the end there.

So, as long as the backup is held securely and you undertake not to retrieve personal data deleted from the live system and the data will be overwritten at some point in the future, then no-one is going to jail.

 

This will change slightly in light of GDPR but the general principle of taking a pragmatic approach will still apply.

 

The guidance above was DPA guidance around the principle of not keeping data longer than necessary. The guidance was that if you delete data to be compliant with the principle of not keeping data longer than necessary, but it's still on the backup, then the ICO would take the approach that you have put the data "beyond use" and complied with the principle.

 

However the GDPR now explicitly expresses that a person can have the right to erasure and the recital state that this covers any data that is processed.

 

I think it's reasonable to follow this guidance until the ICO provide further guidance specific to GDPR.

[enjay]

This will change slightly in light of GDPR but the general principle of taking a pragmatic approach will still apply.

 

Hang on. Does that mean any time we've contacted the ICO for advice recently, that advice has been based on DPA not GDPR, and may therefore be inaccurate in 91 days, 12 hours and 58 minutes? (www.GDPRcountdownclock.com !)