7 ms·

I disagree with describing these events as 'technical issues' or 'IT errors'. As other commenters have noted it appears that there just wasn't a working backup.

I disagree with describing these events as 'technical issues' or 'IT errors'. As other commenters have noted it appears that there just wasn't a working backup. If that's the case, it's more of an organizational failing in my view: no-one cared enough to make a working backup. It's similar to the 'IT error' in our test and trace system recently, where thousands of positive covid test results were uncounted because Excel truncated the file after a certain number of rows. In my view, it's not really the tech at fault, it's that the organization was using Excel because they didn't care enough to do it properly. Calling it a 'technical issue' puts the blame on a malfunction, making it seem unfortunate but unavoidable, and absolving the organization that actually caused the issue.

rwmj 6y ago
I guess it's tricky when you are legally required to delete something - are you able to keep a backup of which contains that thing?
- drdeadringer 6y ago
  I wonder how feasible, realistic, &c it would be to have included in the deletion/destruction policy to have a step/section in there to say "after verification of deletion, make a new backup to replace the old backup" which would be a backup refresh "outside" of the usual periodic backup.
  - thunfischbrot 6y ago
    That would work if you kept only backup version. That would be bad-what do you do in case of accidental record deletion or encryption malware detected after a backup? Check out e.g. https://www.backblaze.com/blog/the-3-2-1-backup-strategy/ https://www.backblaze.com/blog/the-3-2-1-backup-strategy/
- woliveirajr 6y ago
  Wow. As a former "IAAL" (but not in the US), this gave me shivering ideas.Time to write some article/book about it.
- simonh 6y ago
  No you have to also delete any backups. I suppose you'd have to keep all data with such expiry dates in a separate database from other data, and backup the data to different media based on expiry date.
- dkarp 6y ago
  This is an issue with European GDPR "right to be forgotten" requirements. Some interpretations say that if a user requests their data to be deleted, it must also be removed from backups. If your backups are kept in a binary format, then it's a nightmare. You have to restore them, delete the data then backup them up again for every backup you have. Other interpretations say that it is enough to remove the data if/when you restore the backup data. I.e. keep a record of deletion requests and on restoring a backup check if you need to re-perform the deletion request and then do so if necessary.
  - Silhouette 6y ago
    For new systems where this sort of privacy requirement can be designed in from the start, I quite like a strategy that was proposed around the time of the big GDPR discussions, which seems useful in some situations: individually encrypt records of personal data with a separate key for each person (or some other granularity that makes sense for your processing and storage requirements). Then your main database and its backups only contain the separately encrypted data, you keep a rolling backup of your current set of encryption keys, and in response to any permanent data deletion requirement you can delete the key for the relevant record(s) to immediately render the data unusable in any large backups or long-term archives without having to regenerate them. When your key backup rolls over, which might only be a matter of days or even hours, any old copies of they key also get destroyed and the personal data is, for practical purposes, gone forever. Obviously there are many edge cases around deleting partial or related records that would limit the usefulness of a simple scheme like this, and obviously it's no use for data storage and processing that was already set up before the GDPR came into effect and didn't have this sort of mechanism designed in, but I suspect there are quite a lot of data controllers that have relatively simple record-keeping requirements where this kind of approach could work well.
harry8 6y ago
Yeah it's like calling culpable driving occasioning a bad collision "An automotive mechanical issue." A drunken fool driving at twice the shed limit is simply not a mechanical issue. Calling this a technical issue is deeply misleading and so egregiously so that i begin to have a flicker of doubt about motives.
xenophonf 6y ago
> no-one cared enough to make a working backup Where I come from, that's called "negligence" and depending on motive might rise to "malfeasance". I've had to fire people for less.
timthorn 6y ago
The law precludes backups containing DNA or fingerprint data that are meant to be deleted: https://www.legislation.gov.uk/ukpga/2012/9/part/1/chapter/1/enacted https://www.legislation.gov.uk/ukpga/2012/9/part/1/chapter/1... "(1)If fingerprints are required by section 63D to be destroyed, any copies of the fingerprints held by the police must also be destroyed. (2)If a DNA profile is required by that section to be destroyed, no copy may be retained by the police except in a form which does not include information which identifies the person to whom the DNA profile relates."
- LinuxBender 6y ago
  This is where one might use a vaulting appliance. Policies for retention and destruction can be set per location or backup job methodology varies by vendor and I acknowledge these appliances are not cheap. This also assumes the data is stored in a hierarchy that permits this segmentation.
- ashergill 6y ago
  Thanks for clarifying. Does this mean they can't have a backup and then delete that backup after the data has been successfully deleted from the main db? Of course, it's easy for me to say these things in hindsight but my point is that this is an issue with the organization not having the right processes, rather than the technology going wrong. This is alluded to in the article: "Policing minister Kit Malthouse said the problem had been identified and the process corrected".
- aqme28 6y ago
  You can have a backup and if necessary still delete that record in the backup. It's going to be more expensive and complicated, but it does not preclude backups. I've worked in health systems where personal data would get selectively removed not just from our database, but also from backups.
  - nip180 6y ago
    > no copy may be retained This is the key element. A copy may exist, but it must also be deleted. Totally a technical problem that has already be solved.
tragomaskhalos 6y ago
I wonder if the IT had been outsourced to one of the big consulting firms, whose business model is to claim expertise over an unfeasibly large domain and to hoover up public sector contracts accordingly. Our local council had a very similar issue whereby their IT was likewise outsourced to one of these behemoths, and backups - in this case for the library service - were not being done correctly, resulting in the loss of a whole load of data.
- tailspin2019 6y ago
  > whose business model is to claim expertise over an unfeasibly large domain and to hoover up public sector contracts accordingly. The levels of incompetence and disorganisation often displayed by these “expert” companies never ceases to amaze me. It’s matched only by the similarly disorganised and incompetent procurement processes in public sector organisations. So I guess that’s how this “business model” (as you put it) continues to work... sadly!
markstos 6y ago
A bit like calling it an "accident" when a speeding driver runs over a pedestrian. That's not an "oops", it's a preventable crash.
suifbwish 6y ago
Being vague about the cause of problems can sometimes save people’s jobs though. Sometimes the people who are technically responsible for it were so overworked they had no way of realistically doing everything they are tasked with. When the poo hits the fan, c level people are often looking for someone to nail the shame and blame on so naming a transient issue as the cause can give upper management the scapegoat they need without burning anyone

rwmj 6y ago

I guess it's tricky when you are legally required to delete something - are you able to keep a backup of which contains that thing?

drdeadringer 6y ago
I wonder how feasible, realistic, &c it would be to have included in the deletion/destruction policy to have a step/section in there to say "after verification of deletion, make a new backup to replace the old backup" which would be a backup refresh "outside" of the usual periodic backup.
- thunfischbrot 6y ago
  That would work if you kept only backup version. That would be bad-what do you do in case of accidental record deletion or encryption malware detected after a backup? Check out e.g. https://www.backblaze.com/blog/the-3-2-1-backup-strategy/ https://www.backblaze.com/blog/the-3-2-1-backup-strategy/
woliveirajr 6y ago
Wow. As a former "IAAL" (but not in the US), this gave me shivering ideas.Time to write some article/book about it.
simonh 6y ago
No you have to also delete any backups. I suppose you'd have to keep all data with such expiry dates in a separate database from other data, and backup the data to different media based on expiry date.
dkarp 6y ago
This is an issue with European GDPR "right to be forgotten" requirements. Some interpretations say that if a user requests their data to be deleted, it must also be removed from backups. If your backups are kept in a binary format, then it's a nightmare. You have to restore them, delete the data then backup them up again for every backup you have. Other interpretations say that it is enough to remove the data if/when you restore the backup data. I.e. keep a record of deletion requests and on restoring a backup check if you need to re-perform the deletion request and then do so if necessary.
- Silhouette 6y ago
  For new systems where this sort of privacy requirement can be designed in from the start, I quite like a strategy that was proposed around the time of the big GDPR discussions, which seems useful in some situations: individually encrypt records of personal data with a separate key for each person (or some other granularity that makes sense for your processing and storage requirements). Then your main database and its backups only contain the separately encrypted data, you keep a rolling backup of your current set of encryption keys, and in response to any permanent data deletion requirement you can delete the key for the relevant record(s) to immediately render the data unusable in any large backups or long-term archives without having to regenerate them. When your key backup rolls over, which might only be a matter of days or even hours, any old copies of they key also get destroyed and the personal data is, for practical purposes, gone forever. Obviously there are many edge cases around deleting partial or related records that would limit the usefulness of a simple scheme like this, and obviously it's no use for data storage and processing that was already set up before the GDPR came into effect and didn't have this sort of mechanism designed in, but I suspect there are quite a lot of data controllers that have relatively simple record-keeping requirements where this kind of approach could work well.

harry8 6y ago

Yeah it's like calling culpable driving occasioning a bad collision "An automotive mechanical issue." A drunken fool driving at twice the shed limit is simply not a mechanical issue. Calling this a technical issue is deeply misleading and so egregiously so that i begin to have a flicker of doubt about motives.

xenophonf 6y ago

> no-one cared enough to make a working backup Where I come from, that's called "negligence" and depending on motive might rise to "malfeasance". I've had to fire people for less.

timthorn 6y ago

The law precludes backups containing DNA or fingerprint data that are meant to be deleted: https://www.legislation.gov.uk/ukpga/2012/9/part/1/chapter/1/enacted https://www.legislation.gov.uk/ukpga/2012/9/part/1/chapter/1... "(1)If fingerprints are required by section 63D to be destroyed, any copies of the fingerprints held by the police must also be destroyed. (2)If a DNA profile is required by that section to be destroyed, no copy may be retained by the police except in a form which does not include information which identifies the person to whom the DNA profile relates."

LinuxBender 6y ago
This is where one might use a vaulting appliance. Policies for retention and destruction can be set per location or backup job methodology varies by vendor and I acknowledge these appliances are not cheap. This also assumes the data is stored in a hierarchy that permits this segmentation.
ashergill 6y ago
Thanks for clarifying. Does this mean they can't have a backup and then delete that backup after the data has been successfully deleted from the main db? Of course, it's easy for me to say these things in hindsight but my point is that this is an issue with the organization not having the right processes, rather than the technology going wrong. This is alluded to in the article: "Policing minister Kit Malthouse said the problem had been identified and the process corrected".
aqme28 6y ago
You can have a backup and if necessary still delete that record in the backup. It's going to be more expensive and complicated, but it does not preclude backups. I've worked in health systems where personal data would get selectively removed not just from our database, but also from backups.
- nip180 6y ago
  > no copy may be retained This is the key element. A copy may exist, but it must also be deleted. Totally a technical problem that has already be solved.

tragomaskhalos 6y ago

I wonder if the IT had been outsourced to one of the big consulting firms, whose business model is to claim expertise over an unfeasibly large domain and to hoover up public sector contracts accordingly. Our local council had a very similar issue whereby their IT was likewise outsourced to one of these behemoths, and backups - in this case for the library service - were not being done correctly, resulting in the loss of a whole load of data.

tailspin2019 6y ago
> whose business model is to claim expertise over an unfeasibly large domain and to hoover up public sector contracts accordingly. The levels of incompetence and disorganisation often displayed by these “expert” companies never ceases to amaze me. It’s matched only by the similarly disorganised and incompetent procurement processes in public sector organisations. So I guess that’s how this “business model” (as you put it) continues to work... sadly!

markstos 6y ago

A bit like calling it an "accident" when a speeding driver runs over a pedestrian. That's not an "oops", it's a preventable crash.

suifbwish 6y ago

Being vague about the cause of problems can sometimes save people’s jobs though. Sometimes the people who are technically responsible for it were so overworked they had no way of realistically doing everything they are tasked with. When the poo hits the fan, c level people are often looking for someone to nail the shame and blame on so naming a transient issue as the cause can give upper management the scapegoat they need without burning anyone