Verity Trustees Ltd

Posted on by

What
Loss of personal data.

How much
128,000 records.

Why
An unencrypted laptop containing data relating to 128,000 individuals was stolen from a locked server room belonging to Northgate Arinso, the suppliers of the Trustee’s computerised pensions administration system.

Regulator
ICO

Regulatory action
Undertaking issued to ensure that portable media devices and laptops containing personal data are suitably encrypted. Written contracts must be in place with third parties to cover data security obligations.

Reason for action
The data was downloaded to the unencrypted laptop for training purposes in breach of a policy for only using an anonymised data sample for 50-100 pension scheme members.

When
2 December 2009

BW Comments
I wrote the analysis of this breach before the Breach Watch site was created and have moved it here for reference. This breach, and the associated Undertaking, provide an almost textbook illustration of how the principles of the DPA work.

Verity Trustees Limited is the trustee organisation behind The Pensions Trust. The Pensions Trust provides pensions for over 4,000 organisations and 130,000 people from the not-for-profit sector.

There are three separate issues covered in the undertaking.

1. Data Controllers and Data Processors

Verity is the Data Controller for the personal data of its customers and so has the legal responsibility for data protection compliance. This responsibility doesn’t end when a Data Controller decides to outsource or subcontract part of its business process to another organisation. This type of relationship is covered in the Act, and the sub-contractor / outsourcer is called a Data Processor.

The Data Protection Act is really clear about this, you can find the relevant bits in Schedule 1, Part II, sections 11 and 12. These two sections are (surprisingly) clear:

11. Where processing of personal data is carried out by a data processor on behalf of a data controller, the data controller must in order to comply with the seventh principle—

(a) choose a data processor providing sufficient guarantees in respect of the technical and organisational security measures governing the processing to be carried out, and

(b) take reasonable steps to ensure compliance with those measures.

12. Where processing of personal data is carried out by a data processor on behalf of a data controller, the data controller is not to be regarded as complying with the seventh principle unless—

(a) the processing is carried out under a contract—

(i) which is made or evidenced in writing, and

(ii) under which the data processor is to act only on instructions from the data controller, and

(b) the contract requires the data processor to comply with obligations equivalent to those imposed on a data controller by the seventh principle.

Essentially this means:

  1. A Data Controller is responsible for the security of personal data even if, like Verity, it outsources some business activities to a supplier.  The Data Controller must do practical checks on the supplier and I’d recommend that records of those checks and any email conversations with suppliers about their security are retained.
  2. The Data Controller must have a written contract with every supplier that is a Data Processor. The contract has to specify that the supplier must only do what the Data Controller says with the data, and that they have to provide appropriate security for the data. A solicitor should be able to help draw up a compliant contract.

If you want to avoid the type of problem that affected Verity and are worried about how your organisation manages Data Processors then you should:

  1. List all the companies you use to outsource any business activity where they deal with personal data. Many are obvious (such as an outsourced IT provider) but others will include confidential waste disposal, off-site document storage, solicitors, off-site backup providers, contract printers, contact centre services, marketing companies etc.
  2. Work out what type (personal, financial, sensitive) of information you send to these processors and what volumes of data they get on a monthly basis and will retain. I like to ask, “how much data will the company have in 12 months time?”
  3. Do a simple assessment to help you prioritise your work. I tend to break them down into high-, medium- and low-risk categories.
  4. Perform an information security risk assessment of each supplier. The higher the risk, the more detailed the assessment needs to be. I rate each supplier on the likelihood of there being a breach of confidentiality, integrity or availability of the data. I also like to assess the risk of data loss in transit to and from the Data Processor.
  5. Review each risk assessment and formally decide whether:
    • You are comfortable continuing to work with the Data Processor
    • You want to insist that they make some improvements to their information security (and set a timetable)
    • You want to find a different provider
  6. Check you have a written, signed and in-date contract with each processor that fulfils the requirements of the DPA shown above.
  7. Agree when the Data Processor will be re-assessed (at a minimum this should be annually).

2. The use of test data

The first big contributory factor to the breach was that Verity’s supplier copied data from a live system to the laptop for ‘training’ purposes, the laptop was subsequently stolen. If you are a Data Controller then you need to be very careful whenever you allow data to be copied out of the live environment.

When you copy data from a live system to a test/development/training system to allow you to develop and test new software you’re pretty much guaranteed to be breaching the majority of the data protection principles.

You’ll probably breach the first (be fair when you get, use and share data) data protection principle because:

  • you didn’t include ‘using your personal data to help test our IT systems’ as one of the uses listed in the fair processing notice you provided when you first obtained the data from the customer/client/citizen.
  • you probably don’t have the Data Subject’s consent for doing this which means the only other schedule 2 justification you could use to make the processing legitimate would be that it is “necessary for your own legitimate interests” and I think you’d have a hard time demonstrating it was necessary when you could have generated anonymised test data. Furthermore, if any of the data fell into the DPA’s sensitive category then I think you’d be really struggling to find a schedule 3 condition to make the processing lawful.

You’ll probably breach the second (tell people what you will do with their data, do nothing more) principle because you didn’t include this use of someone’s personal data in either your fair processing notice or in your registration with the Information Commissioner.

You’ll breach the third (only get data you need) principle because you’ll always copy more personal data than you need to do the test (you don’t need any real data, as you could instead construct properly anonymised test data).

You’ll breach the fourth (ensure data you hold is accurate) principle because you’ll make test transactions on the personal data that will automatically make some of that data inaccurate. There’s an infamous case of a hospital using real data in test and then sending real letters out to real patients about ‘test’ conditions and injuries that the patients never had!

You’ll probably breach the fifth (delete data you no longer need) principle because that data will find its way onto the hard disks of developers and testers and never be deleted! If you’re really unlucky bits of the data will find its way into bug tracking software and through screen shots into system documentation.

You’ll probably breach the sixth (respect people’s rights over personal data) principle because you will forget to include any of this data if you get a subject access request from a Data Subject (I’ve never seen a response to an SAR that said “and here’s the data we hold about you in our test CRM system, don’t worry that much of it is nonsense”)

You’re bound to breach the seventh (don’t lose data) principle, just like Northgate Arinso/Verity because there are never the same number of controls around development and test systems as there are around live/production systems. You’ll lose track of where the data is and who has access to it. What happens next is predicted and whereas the breaches of principles one to six are technical breaches of the DPA, the breach of principle seven is the one that has the potential to cause the most customer detriment.

You may breach the eighth (be careful if you send data to other countries) principle, as it is not uncommon to have development partners outside the EEA and the other ‘safe countries’.

There’s a simple answer. Don’t use live data for training, test or development, make sure any test data you construct from live data is made anonymous.

3. Laptop encryption

The laptop containing the ‘training’ data was stolen from Verity’s Data Processor and this is where the breach that has the potential to directly affect Verity’s customers happened.

The ICO has a fixation with encryption for laptops that may contain personal data. It sees this as proving appropriate technical measures against accidental loss of the data to comply with the seventh (don’t lose data) principle. The ICO issued guidance in 2008 clearly explaining that where an unencrypted laptop is lost or stolen, the ICO will issue an enforcement notice. After April next year, when the ICO gets powers to fine, I predict that the loss of an unencrypted laptop will be an automatic fine.

Nowadays I advise all my clients to install whole-disk encryption on all laptops as it means you don’t have to worry whether a stolen laptop contains personal data (or other business-confidential information). As the whole disk is encrypted it also means you avoid the problems associated with just using encrypted vaults when the user saves the file in the normal unencrypted file system rather than the vault.

Of course, training all of your staff to shut their laptops down rather than just put them to sleep is a much harder task. Whole disk encryption tends to lengthen boot times so users typically just put their laptops to sleep rather than turning them off. A laptop that’s asleep already has the hard disk unencrypted so this control is often unconsciously defeated by the laptop’s owner.

Verity’s unfortunate problem is really good example of why it can be really beneficial to consider Data Protection compliance in parallel with information security. DPA compliance will:

  • always consider Data Processor relationships.
  • make sure that any use of personal data is lawful under the first principle.
  • ensure that explicit guidance issued by the ICO is incorporated in information security policies.

Links
View PDF of the Verity Trustees Ltd Undertaking (Breach Watch Archive)