Our website uses cookies to give you the best experience and for us to analyse our site usage. If you continue to use our site, we will take it you are OK about this. Click on More for information about the cookies on our site and what you can do to opt out.

We respect your Do Not Track preference.

Breach Case 4: Testing with real data Neil Sanson
9 June 2017

test sign

Sometimes it seems a good idea to use real production data in a test environment. But doing so means security becomes even more important if you want to stop things going wrong.

When testing a new system, it is always tempting to use a copy of real data from your existing system. The data is readily available, it has the variety of records needed, and it exists in a volume large enough to make it convenient for testing.

But in Britain last month, the parenting retailer Kiddicare admitted the personal information of 794,000 people had been exposed on a version of its website set up for testing purposes and the incident has underlined the dangers of using real personal information.

The Kiddicare breach came to light after some customers reported receiving text messages that appeared to come from a subsidiary website of Kiddicare.com. A security company found the mobile phone numbers had come from a dataset used on a test website in November 2015. The messages invited Kiddicare customers to take an online survey - a tool often used by scammers to cheat people into signing up for fake schemes.

Close to home, we know of two other data breach ‘near misses’ which are examples of how using real data for testing a new system or website can be a risky thing to do.

In both cases, software developers took copies of their client organisations’ data back to their own offices to use for testing. In one case, the software developer’s own system was hacked and the organisation’s data could have been exposed. In the other, the developer forgot to delete the data before uploading the software they had written (and the data!) to a public website.

Fortunately, neither of these incidents resulted in the sort of harm that flowed from the Kiddicare breach.

For this reason, it’s usually much safer to generate fake data for testing purposes – just in case. The best practice for software testers is always to mask or transform the data in some way so that personal information cannot be exposed inappropriately and accidentally.

We regularly get data breach notifications and this year we will be sharing the lessons learned from these more regularly. If you want to know more about data breaches, please check out our Data Safety Toolkit.

Image credit: Test road sign - Creative Commons via Pixabay


, , ,



No one has commented on this page yet.

Post your comment

The aim of the Office of Privacy Commissioner’s blog is to provide a space for people to interact with the content posted. We reserve the right to moderate all comments. We will not publish any content that is abusive, defamatory or is obviously commercial. We ask for your email address so that we can contact you if necessary to clarify your comment. Please be respectful of authors and others leaving comments.