All posts

No, You Shouldn’t Use Production Data For Testing

by Robert Broeckelmann

But, let’s face it, you’re probably going to do it anyway.

Using production data for testing might feel convenient (“it’s a great way to simulate what really happens in production after all”, sarcasm), but it creates serious technical, legal, and operational risks. It is extremely unlikely that your team has sufficiently sanitized or anonymized your production data to satisfy those potential risks. In fact, more than that, most shops that allow the practice are probably putting minimal, bordering on, no effort whatsoever, into scrubbing that data before it used in non-production environments for testing purposes.

It doesn’t matter whether we are talking about QA testing, unit testing, automated testing, manual testing, integration testing, load testing, self-destruct mechanism testing, or any other edge-case, test scenario you might come up with.

Combine this practice with the tendency for companies to have a lower overall security threshold in non-production environments and you have the potential recipe for a data breach. While we are on the topic, every environment should have the same security controls in place that production has. Bake it into your architecture. Live it. Learn it. Love it.

Privacy & Regulatory Risk

Production data often contains:

  • Personal data (PII)
  • Financial records
  • Health data
  • Authentication credentials
  • Behavioral logs
  • Shopping history
  • Much more…

If that data is copied into non-production environments, you may trigger obligations under laws (depending on what country you are in) like:

  • General Data Protection Regulation (EU)
  • California Consumer Privacy Act (US — California)
  • Health Insurance Portability and Accountability Act (US)
  • Data Privacy Act of 2012 (Philippines)
  • and on and on

Testing environments are often:

  • Less secure
  • Less monitored
  • Accessible to more developers
  • Outside normal audit controls

This dramatically increases risk of a data breach. The developer that is currently whining about how difficult this makes there job is probably not the person who should be assessing this risk for the organization.

Security Weakness

Non-production environments commonly have:

  • Weaker access controls
  • Shared credentials
  • Reduced logging
  • Fewer monitoring tools
  • Missing security capabilities like WAFs, DDoS Prevention, IDS/IPS systems to save money.
  • Internet exposure for convenience

Copying production data into these environments multiplies your attack surface.

Many major breaches have originated in non-production environments.

Consent & Purpose Limitation Violations

Privacy laws often require:

  • Data minimization
  • Purpose limitation
  • Legitimate basis for processing

If users consented to: “We use your data to provide services”

That does not automatically include: “We copy it into five test systems for QA experiments.”

Using production data for testing may exceed the original lawful purpose. It depends on the jurisdiction and circumstances. This one may not be a concern in the United States, but for EU-based organizations and those with similar data privacy laws, this can turn into a serious issue.

Contractual & Industry Violations

If you start using production data in non-production environments, you may breach:

  • Data Processing Agreements (DPAs) (EU)
  • Vendor contracts (Everywhere)
  • PCI-DSS requirements (US, elsewhere)
  • SOC2 commitments (US)

Some frameworks explicitly prohibit using live cardholder or health data in development systems.

Data Integrity & Accidental Modification

Testing with production data / configurations (intentional or accidental) can:

  • Corrupt live-linked systems
  • Send unintended emails
  • Trigger billing events
  • Modify records unintentionally

If production integrations aren’t fully isolated, testing can spill into real-world consequences.

I may have witnessed an organization in the financial industry run a load test against a trading platform that ended up triggering real production trades. Many things went wrong leading up to that. A couple $100M worth of stocks had to be sold the next day to unwind that mistake. It could have ended much worse. The individual who created that situation didn’t last till the end of the day as an employed person.

The production environment should be fully isolated at each layer from non-production environments.

Insider Risk

Developers and testers typically have:

  • Broad data access
  • Fewer operational restrictions
  • Lower scrutiny

Production data in test systems increases insider misuse risk.

Ethical & Reputational Risk

Customers assume:

  • Their real data is not being casually copied around
  • Access is limited to operational need

If a breach occurs in a test system, public response is usually: “Why was our real data there in the first place?”

Data Retention Problems

Test environments:

  • Rarely follow strict deletion policies
  • Often accumulate stale copies
  • May not sync with deletion requests

This creates compliance issues under erasure laws like GDPR.

Cross-Border Complications

If testing teams are international:

  • You may create unauthorized cross-border transfers
  • Data sovereignty rules may apply
  • Additional safeguards may be required

See the “Data Sovereignty Laws Around The World” post for more details on Data Sovereignty.

Better Test Data

Instead of using raw production data, consider:

I was in another shop, long ago, that decided the best way to create test data for their PeopleSoft HR & Financials system was to grab the production data, copy it to the test environment, and randomly switch around all the social security numbers. The end result was that if Person A logged into the test environment’s PeopleSoft system, they saw Person B’s data including salary and HR data elements. There were some issues that came out of that one.

I beg you, please don’t use production data as test data in your non-production systems. I’ve been overridden on this point far more often than I’ve gained agreement.

Summary

Using production data for testing increases privacy exposure, regulatory liability, breach risk, and reputational damage. Moreover, it’s often unnecessary to introduce these risks, but it does require effort on the part of technical teams who would rather be doing something else.

I beseech you. I implore you. I beg you. Look at the tools and techniques available for developing usable test data. Short of that, anonymize your data. But, remember, simply changing the username, email, and name associated with the user’s data in an attempt to anonymize or sanitize the data may not be enough.

Notes:

  • AI / GenAI / ChatGPT / etc were not used to generate the text of this article.
  • Names have been changed to protect the guilty.
  • None of the hostname or users used in examples actually exist.
  • Feel free to post any comments or suggestions below.

Originally published on Medium.

More articles