Usually not as it stands. Copying production data into staging is processing personal data for a new purpose, which requires a compatibility assessment under Article 6(4), and it takes real customer data out of an environment with production-grade controls and into one that typically has weaker access restrictions, more people with access, no retention policy and no monitoring. The legal answer is not a flat prohibition. It is that the copy has to be justified, minimised and controlled, and in most cases the honest conclusion is to use less of it.
This article covers why the copy is a new purpose, what the compatibility test asks, the four options ranked by how well they survive scrutiny, why data subject rights reach staging, and the specific exposure created by non-production environments.
The Copy Is A New Purpose
You collected the data to run the service for the customer. Using it to test a release is a different purpose, and Article 5(1)(b) says personal data collected for specified purposes must not be further processed in a manner incompatible with those purposes.
Article 6(4) sets out how to assess compatibility where you are not relying on consent or a legal provision. You weigh the link between the original and new purposes, the context in which the data was collected and the relationship between you and the person, the nature of the data — with special category data weighed more heavily — the possible consequences for them, and the existence of appropriate safeguards including encryption or pseudonymisation.
Run that honestly for a full production clone into staging and the weak points appear immediately. The context in which a customer gave you their data does not obviously extend to it sitting in a developer environment. The consequences of exposure are identical to a production breach, because the data is identical. And the safeguards limb is where most teams have nothing to offer, because staging is deliberately easier to get into.
The Environment Name Is Not A Control
Article 32 requires security appropriate to the risk, and the risk attaches to the data, not the hostname. A database containing real customer records needs production-grade protection whether the environment is called production or not, and if you are not willing to apply those controls to staging, that is a finding about the copy rather than about staging.
The Four Options, Ranked
Synthetic data is generated, contains no real person, and sits entirely outside the regulation. It is the only option with no ongoing compliance cost. The objection is always that it does not reproduce real-world messiness — which is true, and is a smaller problem than teams assume for most test cases, and a genuine one for performance and edge-case work.
Anonymised extracts are also outside scope, but only if they clear a high bar: re-identification must no longer be reasonably possible by anyone, which means defeating singling out, linkability and inference rather than deleting the name column. Most "anonymised" test datasets are not. Our guide to anonymisation versus pseudonymisation sets out where the line actually falls, and it is further away than it looks.
Masked or pseudonymised subsets are the realistic middle. Replace direct identifiers, scramble free-text fields, subset to a fraction of records while preserving referential integrity. This remains personal data and remains fully in scope — but it materially reduces severity, it counts in your favour under Articles 25 and 32, and it is the option that most often survives an Article 6(4) assessment.
A full production copy is the option to justify explicitly or not take. Sometimes it is genuinely necessary — reproducing a data-dependent bug, validating a complex migration. When it is, treat it as a temporary production system: same access controls, same encryption, same monitoring, a named owner, and a hard expiry date measured in days.
The ranking matters more than the labels. The question to answer in writing is not "may we use production data" but "what is the least identifiable dataset that would actually answer our engineering question."
Rights And Retention Reach Staging
Non-production copies are the most common blind spot in rights handling, and the reason is simple: the process was designed around the production database.
An erasure request covers every copy you hold, including the staging snapshot taken three weeks ago. An access request requires you to search where the personal data is, which includes non-production systems. If your DSAR runbook queries production and nothing else, your responses have been incomplete — and the same gap applies to the other places copies accumulate, which is why this and the problem of backup copies tend to be discovered in the same week.
Retention, Previews And Contractors
Test datasets are created for a specific piece of work and then never removed, because deleting them is nobody's ticket. Storage limitation applies, so every test copy needs an expiry, and the expiry needs to be enforced by something other than good intentions. Refreshing staging from production monthly and never deleting the old copies produces an accumulating archive of customer data that appears on no data map.
Two related exposures worth naming. Preview and ephemeral environments spin up per branch and can quietly hold real data, sometimes on infrastructure tiers whose terms differ from your main plan — our piece on Vercel covers a case where the processing addendum applies only to certain plans, which is worth checking before a preview deployment touches customer records. And contractors or offshore development teams given a production dump for convenience are receiving a transfer, a disclosure, and possibly a subprocessor relationship nobody documented.
Common Mistakes With Test Data Under GDPR
Cloning production to staging as the default. It is further processing for a new purpose and needs an Article 6(4) assessment. Doing it because it is the easiest way to get realistic data is not an assessment.
Calling masked data anonymous. Masking reduces risk; it rarely achieves anonymisation. Describing a masked dataset as anonymous in a DPA or questionnaire is a statement about legal scope that a customer's counsel can check.
Excluding non-production from rights handling. Erasure and access requests reach every copy. A runbook that only queries production produces incomplete responses without anyone noticing.
Test datasets with no expiry. Copies created for one piece of work outlive it by years. Set an expiry at creation and enforce it automatically.
Weaker controls justified by the environment name. Article 32 asks about risk to the data. If the records are real, the environment being called staging changes nothing about what protection is appropriate.
FAQ
Can we copy production data into staging under GDPR?
Not without justifying it. It is further processing for a new purpose, so you need a compatibility assessment under Article 6(4) and security appropriate to the data under Article 32. In practice that means minimising what you copy, masking what you can, restricting access as you would in production, and setting an expiry — or using synthetic data instead.
Is masked production data still personal data?
Almost always yes. Masking direct identifiers leaves quasi-identifiers and structure that can single people out, so the data stays in scope with retention limits and rights attached. It is still worth doing — it reduces breach severity and strengthens your Article 6(4) position — but it is risk reduction, not an exit.
Do erasure requests apply to test environments?
Yes. The right covers the personal data you hold, wherever you hold it. If a staging snapshot contains the person's records, it is in scope. The practical answer is usually to keep test copies short-lived enough that the question resolves itself, rather than building erasure tooling for every environment.
What is the safest option for realistic test data?
Synthetic data, because it takes you out of scope entirely. Where it genuinely cannot reproduce the behaviour you need, a masked and subsetted extract with a short expiry and production-grade access controls is the realistic second choice. A full unmasked clone should be a documented exception with a named owner, not a standing arrangement.
Closing Thought
Almost every team that copies production into staging knows it is not ideal. It persists because the alternative costs engineering time now, and the risk lands later and on someone else — which is the same structure as most technical debt, with the difference that this particular debt is other people's personal data.
The useful reframing is that the question is never "is this allowed." It is "how much of this data do we actually need to answer our engineering question," and the honest answer is usually a small, masked subset that nobody had the time to build. That subset takes a week once. The full clone costs a little every month, quietly, until it doesn't.
ComplyDog keeps the records that make this visible: records of processing activities that should name every environment holding personal data, subprocessor tracking for the contractors and platforms that touch it, and a portal on your own domain for the requests that reach into all of it. You can try it free for 14 days, no credit card required.
