For engineering and security teams
“What data is in your test environments?”
It is now a standard question in enterprise security reviews, and it is one of the more awkward ones to answer honestly. Copying a production database into staging is still the most common way teams get realistic data, and the obligations attached to those records do not lapse because the system has “test” in its name.
A 2026 industry survey put the share of development and test environments that are fully compliant with privacy requirements at 4%, with 76% of organisations reporting a sensitive-data incident in a non-production environment over three years. The gap is not that teams do not care. It is that realistic data has been genuinely hard to get any other way.
Three answers, and how they hold up
A copy of production
Real customer records, in a lower environment, usually with weaker access controls.
In review: The hardest answer to defend. The records are still personal data; the environment name does not change that.
Masked or anonymised production
Real records with identifying fields transformed.
In review: Defensible and widely used, but it is still derived from production, so re-identification risk and the transfer itself remain in scope.
Generated from a specification
Rows invented to satisfy your schema and constraints. Production is never read.
In review: There is no production personal data in the environment to assess, because none was ever moved there.
What Misata actually does
Misata reads your schema and generates rows that satisfy it. It does not read, sample, or train on your data. Point it at a development database and it takes the table and column definitions and the foreign keys, then writes new rows that respect them and verifies afterwards that every key resolves.
Two properties follow, and both matter in a review. Generation is deterministic and runs locally with no model in the data path, so the same seed reproduces the same rows and nothing is sent anywhere. And because the data is invented rather than derived, there is no re-identification question to assess: the rows do not correspond to anyone.
The line you can put in a questionnaire
“Our lower environments are populated with synthetically generated data produced from our schema definitions. No production records are copied, masked, or otherwise transferred into non-production systems.”
Where this is the wrong tool
Being straight about the limits, because a security reviewer will find them anyway:
- Generated data does not reproduce your real distributions, cardinalities, or the specific edge cases that only exist in production. If a test depends on those, you need an anonymised copy, not this.
- Migrating existing environments is still work. This changes how new data gets there; it does not retroactively clean what is already sitting in staging.
- This is not legal advice and Misata is not a compliance product. It removes one category of risk by removing the data. Whether your programme is adequate is a question for your own counsel and auditors.
- Misata does not hold any certification. The engine is MIT licensed and readable, which is the assurance on offer: you can audit the code rather than trust a badge.
Working on this at a company?
I am looking for a small number of teams to build the next part of this with. If your lower environments are blocked, or a security review is stuck on this question, tell me your schema and the constraint you are under and I will work on it with you directly. No sales process, and no charge while we are figuring it out together.
An engineer can evaluate this without procurement: the engine is open source and installs with pip, so it can be tried on a development database the same afternoon.