An outside developer needs to reproduce a bug that only shows up for certain customers. They ask for a copy of the database so they can work without interruptions. Someone pulls a production backup, restores it into the development environment, and the problem is solved that same afternoon.
This happens at nearly every company that builds its own software. It is efficient, it solves a real problem, and nobody acted in bad faith. It also means your customers' national ID numbers, addresses, phone numbers and health data are sitting on a laptop right now, on a server nobody monitors, and probably in three or four more copies that nobody has written down anywhere.
Once Chile's Law 21.719 takes full effect on 1 December 2026, that stops being a debatable practice and becomes processing of personal data with nothing to justify it.
Why everyone does it
It is worth understanding where the habit comes from before proposing fixes, because rules that ignore the reason behind a problem do not get followed.
Made-up data does not behave like the real thing. A developer testing with "John Smith, ID 11.111.111-1" will never hit the error that appears when a name contains an accented character, when an address runs past 200 characters, or when one customer has 4,000 invoices attached to their account. Edge cases are exactly what break systems, and edge cases live in real data.
Then there is volume. A performance test against a hundred records tells you nothing about how the system behaves with two million. Restoring production is the shortest path to having both.
The intent is not the problem. The problem is that every copy widens the exposed surface, and development environments consistently carry fewer controls than production: more people with access, no record of who queried what, backups nobody has inventoried, and often external vendors working from their own infrastructure.
What the law changes
Law 21.719 defines anonymisation as an irreversible procedure that makes it impossible to link a piece of data back to a specific person. Anonymised data stops being personal data, which takes it outside the scope of the law.
Pseudonymisation is a different thing and the two should not be confused. There, the data can still be attributed to a person if additional information is used, and that additional information has to be stored separately with protections of its own. A pseudonymised environment remains regulated, though at a considerably lower level of risk.
That distinction determines which solution fits each team. If you achieve true anonymisation, your test environments drop out of the problem. If you need the ability to trace back to the original record, you are pseudonymising, and obligations still apply to that environment.
One point tends to get overlooked. When a customer exercises their right to have their data deleted, that deletion has to reach every copy. If nobody knows how many test environments exist or what they contain, the request cannot be honoured even in good faith.
Three levels of solution
You do not have to solve all of it at once. These three options run from lower to higher effort, and the first one already cuts risk substantially.
Level 1: reduced subset with masking
Instead of restoring the full database, you extract a representative sample and replace identifying fields with generated values. National ID numbers become structurally valid but nonexistent ones, names come from a dictionary, email addresses point to a test domain.
This is the fastest to implement and usually covers around 80% of a development team's use cases. The trade-off is losing the volume needed for load testing.
Level 2: pseudonymisation with a separate mapping
Same replacement, but you keep a mapping table in a controlled location with restricted, logged access. This works when the team needs to trace back to the original record while investigating a specific incident.
Keep in mind the environment stays regulated. What you gain is reduced risk, not reduced scope.
Level 3: synthetic generation
You produce entirely artificial data that reproduces the statistical distributions and relationships of the original without deriving from any real record. It is the most complete option and also the most expensive: you have to model how the data behaves, not just how it is formatted.
It earns its cost when volume matters and when sensitive data is involved, such as medical records or financial information.
What to preserve when you transform
This is where most attempts fall apart. Poorly executed masking produces data that is useless, the team complains, and three weeks later somebody restores production again.
Referential integrity. If you replace an ID number in the customers table, it has to be replaced with the same value in invoices, contracts and everywhere else. A deterministic function handles this: the same input always produces the same output.
Format validity. An ID number with an invalid check digit will fail validation, and the team will conclude that fake data does not work. Generate values that pass the same rules the real system enforces.
Edge cases. Names with special characters, fields at maximum length, customers with hundreds of linked records, nulls where the system does not expect them. If your sample only holds clean cases, you are not testing anything.
Distributions. If 3% of your customers account for 60% of transactions, the sample should reflect that. Performance problems surface precisely in those cases.
Make it a process, not a project
What separates companies that solve this from companies that solve it once and drift back is automation.
If generating a clean test environment requires asking someone for a favour, the first urgent situation will end in a production restore. If it is a script that runs on its own and leaves the environment ready in twenty minutes, nobody goes looking for the shortcut.
That process is also evidence. A documented procedure for generating non-production environments, with a record of when it ran and against what data, is exactly the kind of backing that holds up when a corporate client asks or when a regulator does.
Where to start
Before deciding which level to implement, you need to know where you stand. Three questions you can answer this week:
How many non-production environments exist today? The answer is usually higher than anyone estimates, because there are local copies on developer machines that nobody counted.
Who has access to them? Include external vendors, former employees whose access was never revoked, and shared service accounts.
When was production last restored into each one? If nobody knows, that is the first gap to close.
With those three answers you can scope the work. Without them, any plan is guesswork.
Checking where your systems actually stand before 1 December is a decision with a deadline attached. You can start with our technical assessment: twelve questions, immediate results by area, no contact details required.
