Looking for risks associated with seeding QA or Testing environments with data from production.

Other than a compromise of the test environment leading to information disclosure (made worse if that data is PHI), can anyone shed light on additional risks associated with this practice?


The risks are essentially that you have far less control over a development/test environment, more people will have access to larger portions of the data, and it will be used and thought of in a far different way. Test data often needs to be sent to 3rd parties, across oceans, or other places where you have no control over it.

Essentially, count on your test data getting out of the database in one way or another via screenshots, email, etc. This doesn't have to be malicious and largely isn't. For the most part, it will be people merely trying to get their job done.

If the data is senstive in nature like medical records, you need to anonymise the data in some way, but still make it reflect production.

  • what would be the anonymization of data in QA environments? If there are any data based test scripts then how will the QA team test if data is anonymized? – Jarvis Jan 17 '20 at 11:58
  • @Jarvis You should be creating test scripts on fake data from fictitious people, not real people. Why would you need to test on actual, real peoples data? – Steve Sether Jan 17 '20 at 18:32
  • You need to test on real data when integration with multiple systems is involved. Especially if one of the external systems you are integrating with is a data provider – Jarvis Jan 18 '20 at 2:55

A good test environment should normally be extremely close (if not identical) to the production system, including all relevant security measures.

The best approach to get test data is normally to define test cases that include every single possible case, but that can sometimes represent a huge job, and thus justify the development of something that will take production data and hide its sensitive nature.

In the end, it really depends how sensitive the production data really is and if you can trust your employees with it. Every single business will give access to sensitive data to its employees, including clerks which will often see credit card data which is quite sensitive in nature.

  • The use case here pertains to medical records with PHI so I'm looking for risk associated with leveraging prod data in dev. – HashHazard Jun 13 '16 at 19:57
  • My answer still applies even if I didn't know what PHI represented before. There's plenty of hospital personnel that gets access to sensitive information and it is part of their work responsibility to keep it private. As I suggested, there are two good solutions to get anonymous data. The aspect of whether you need to keep it anonymous to your personnel is not a security but a legal question. – Julie Pelletier Jun 13 '16 at 20:07
  • 2
    Aside from failing an audit, there's the ethical problem that the data is not yours to do what you want with. There's a hundred more reasons, but the all fall out of that utter, total, glaring failure in due care with people's most private data. – mgjk Jun 13 '16 at 20:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.