In this case the ICO press release (PDF) reported that a laptop containing some 18,000 customer records was stolen from a software supplier – Northgate Arinso. It is worth reading the undertaking (PDF) given by Verity to the ICO as it sheds more light on ‘what went wrong’. 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.

(There’s a longer description of the difference between a Data Controller and a Data Processor in the basic terms section of this site)

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 draw up a compliant contract, or there’s a very good template in Stewart Room’s book.

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

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).

I’m keen to use this blog to try to explain the relationship between information security and the DPA. However on this occasion I hope you’ll excuse a paragraph of marketing. I provide this type of Data Processor management for my clients. I help identify and classify all the data processors an organisation uses, I individually assess each data processor and I write a risk assessment for each one along with a recommendation as to the best course of action. If you’d like me to do this for your Data Processors, or you’d like to talk to one of my clients to see how this works for them then please get in touch.

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.

From an information security and Data Protection Act compliance perspective there are three breaches of the Act.

T-Mobile

There’s no information how the data was extracted from T-Mobile’s system and I accept that it could have been by people copying the information down onto pieces of paper, however I’ll assume that as the BBC story talked about “millions of records from thousands of customers”, there was a bulk extract of data.

T-Mobile is probably in breach of the seventh principle in that they failed to ensure:

“Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data”

It is a breach of section 4(4) of the Act if a data controller fails to comply with the data protection principles in relation to all personal data, and the Information Commissioner (for the moment) can commence enforcement proceedings against the company, in the course of which T-Mobile will have to undertake to implement better security and processes.

However what’s interesting to me is whether T-Mobile had ever properly quantified the commercial value of information about a customer’s name, mobile and contract expiration date? And if so whether this was adequately reflected in their risk analysis?

If this were the case then two technical steps I’d expect them to have taken would have been:

1. to make it very hard for people to run and save a report that had more than (say) 20 such records (most people working in customer service wouldn’t even need this many records in a report)
2. to implement some Data Leakage Prevention (DLP) technology that looked at the type of data moving out of the organisation in email, on removable media such as CDs, USB sticks and as physical printouts

The employee / employees

The employee(s) [the T-Mobile site now appears to indicate that it was just the action of a single employee] have committed a clear offence under Section 55(1) of the Act.

“A person must not knowingly or recklessly, without the consent of the data controller obtain or disclose personal data or the information contained in personal data”

If convicted they’ll receive a maximum of a £5,000 fine (and if the Information Commissioner gets his way then next year this could be a custodial sentence).

The data recipient

The person buying the data has also committed a Section 55 offence as they obtained the data without T-Mobile’s consent.

The identity of the person or company who purchased the data hasn’t been made public. It will be interesting to see whether it was a small phone dealer, a broker or one of the other big mobile phone companies. If the latter the there’s a real issue to explore – was this the action of a ‘rogue’ salesperson or something that was tacitly condoned by the organisation?

For a market to exist in personal data there has to be both a buyer and a seller, and the value of the data is defined by the buyer: if no one wanted to buy this information then the T-Mobile employee(s) wouldn’t have stolen it to sell. If the data was traded through a list broker then still the recipient organisation should have asked themselves where this data came from as alongside the section 55 offence they will have breached the first (be fair when you get, use and share data) and second (tell people what you will do with their data, do nothing more) data protection principles.

When this case finally comes to court I’ll be really interested to see the action taken against the purchasers of the personal data.

In the future I expect to see all databases that hold personal information equipped with full read auditing which would create an audit log entry whenever a user read an individual record, or ran a report that included that record.

Audit: User JohnDoe viewed this record at 10:23 on 22/10/09
Audit: User JaneDoe included this record in the report CustomersAboutToLeave at 19:47 on 23/10/09

I’d also expect mobile phone companies to correlate the read activity of their users (recorded in this type of audit log) against the customers who went elsewhere at the end of their contracts.