Back to the benefit data loss for a moment. We were told in Thursday's papers, the NAO had asked only for basic details about child benefit recipients, without information on personal bank accounts, but was told by "high level" at the HMRC that it would be "too burdensome" to separate this data.
Excuse us?! Here's how burdensome it is to extract the details required:
SELECTParent.UniqueID, Parent.Forename, Parent.Surname, Parent.NatIns, Child.Forename, Child.Surname
WHERE
Child.ParentID = Parent.UniqueID AND Child.Deceased = 0 AND Parent.Deceased = 0;
And here's how difficult it is to extract the details supplied:
SELECTParent.UniqueID, Parent.Forename, Parent.Surname, Parent.NatIns, Child.Forename, Child.Surname, Bank.Sortcode, Bank.Accountnumber, Bank.Balance
WHERE
Child.ParentID = Parent.UniqueID AND Child.Deceased = 0 AND Parent.Deceased = 0 AND Bank.AccountHolderID = Parent.UniqueID AND Bank.AccountInactive = 0;
Or something like that. We've not seen the schema for the database, but can't imagine that a well-designed database would be significantly more complex, and we do know that the databases are well-designed. Anyway, Ministry of Truth explains this bit far more clearly, so go read that, then come back here.
What we reckon happened was that a database geek, at some point in the past, had written a routine to extract all the information related to an individual - parent, children, bank details, address, telephone number, the lot. And they'd saved that particular snippet of code before going on to fresh fields and/or pastures new.
The database geek's section manager only has an outline knowledge of the database structure, and this is probably OK. If you've got enough geeks on hand who know what they're doing, you can just give the difficult jobs to them, so long as they document their methodology and can justify their results at a later date. However, following the cuts imposed by Mr. The Soup Dragon when he merged the Inland Revenue with the Customs and Excise, there was a geek shortage. Manager has great difficulty coding a proper query, and lacks the tools to develop something better. When the call from the NAO comes, manager asks the office junior to run this ExtractAll routine, and bung the contents on CD. The rest we know about.
None of this explains why the manager authorised (or failed to prevent, the two are near-equivalent) the office junior from sending the CDs through the internal post. Nor does it explain why the file was transmitted in such a barely-encrypted form. Though the data itself was unencrypted, the information on the disks was protected by a password. It has been suggested that the usual method of conveying the password is by, er, writing it on the disk, or enclosing it in the same package. This reduces the protection to a simple literacy test.
The bottom line: the government needs to employ people who know a decent database design when they see one, and who can explain their work to seniors who don't know the details of what they're doing. Our contact details are at the foot of the page.
Information commissioner Richard Thomas wrote in the Indytab that there should be a criminal sanction against reckless or repeated security breaches. Making deliberate and systematic data breaches a criminal offence would serve as a strong deterrent and would send a very strong signal that it is completely unacceptable to be cavalier with people's personal information. The IC has been given new powers to make unexpected checks on government departments, but still cannot check private sector companies without their consent.
