Compliance Says No to Real Data in Test. Now What?

Somewhere in your company there is a document that says production data must not be used in non production environments.

Somewhere in your infrastructure there is a staging database restored from a production backup.

Both of these are true at the same time, in most organisations, and everyone involved knows it. The policy was written by people who were right. The restore was done by people who had a deadline. Neither group is the villain.

I want to talk about why this gap is so stable, because it does not close through more policy.

Why teams comply on paper

Put yourself on the delivery side.

A policy arrives saying no production data in test. It does not come with a data provisioning service, a budget line, or an engineer to build one. It comes with an attestation form.

You still have to test. Your options are to build realistic data yourself, which is weeks of work nobody scheduled, or to test against something so thin it proves nothing, or to use the copy that already exists and is already working.

So the copy stays. Sometimes it gets a scrubbing script and a new label. The attestation gets signed, because from where the signer sits the box has been ticked.

This is not cynicism. It is what happens when a control is introduced without funding its alternative. The control does not change behaviour, it changes vocabulary.

Why the policy is right anyway

None of that makes the policy wrong.

Under GDPR, personal data carries the same obligations wherever it sits. Singapore's PDPA takes a similar position. There is no clause that says the rules relax in a lower environment. The obligations follow the data.

And the practical exposure is genuinely worse in test, not better. Production has restricted access, audit logging, and a designed retention window. Staging has a shared credential in a wiki, read access for every engineer, and a copy that has been sitting there since whenever someone last refreshed it. Same data, a fraction of the protection, and typically no answer at all to how long it is kept.

So the policy is describing a real risk. It is just that "stop doing that" is not an implementable instruction on its own.

What closing the gap actually requires

If you want the copy to stop, the replacement has to be genuinely better on the axis the team cares about, which is not compliance. It is getting work done.

It has to be structurally correct. Data that violates foreign keys or constraints fails immediately and sends people straight back to the dump.

It has to be big enough. Twelve users and three orders will not surface a pagination bug or a slow query. If the dataset cannot support real work, real work will happen elsewhere.

It has to be fast to produce. If a refresh takes three days through a ticket queue, engineers will find another way, and they will be right to.

It has to be self service. Any control that puts a human approver between an engineer and a routine task recreates the queue you were trying to remove.

Miss any one of these and you have not replaced the copy. You have added a second option that nobody uses.

The audit conversation gets simpler too

There is a benefit here that is easy to miss.

When your lower environments contain generated data, several awkward questions stop applying. Where does test data come from. Who has access to it. How long is it retained. What happens to it when a customer exercises deletion rights. How do you know the masking is complete.

The answer to all of those becomes the same: there is no personal data in those environments, so the question does not arise.

That is a materially shorter conversation than defending a masking script's column coverage, and it stays short as the schema changes, which a masking script does not.

I am not a lawyer and this is not legal advice. Your compliance team should verify the position for your jurisdiction and your data. But the structural difference between "we transformed real records" and "no real record was involved" is the one that matters, and it is worth putting in front of them.

Where SeedQL fits

SeedQL reads your schema and generates data that satisfies it, then pushes it to your target database. No production data is read at any point. It runs against Postgres, MySQL, and SQLite.

Because it was built for environments where this matters, the controls come with it: role based access so a workspace decides who can write where, an approval step before a push, and an audit log of what was generated and by whom. Target database credentials are encrypted at rest and cleared when a job finishes.

The honest boundary, again, because a compliance post is the worst possible place to overstate things. This replaces the bulk copies used for development, testing, demos, and load work. It does not replace production data for analytics, and it does not reproduce one customer's specific defect. Keep a narrow, logged, approved path for that rare case, and stop using its existence as the reason to keep full copies in six places.

Where to start

Not with a policy. You already have one.

Start by counting. List every environment holding real customer records, including the laptops and the old dumps. Most teams find more than they expected, and the list is the thing that makes the case, because it is specific and it is yours.

Then take the smallest one and see whether generated data can serve it. If it can, you have a working example and a number you can point at. That is a far better argument than another attestation form.