Why production data does not belong in test systems
Personal data may only be processed for the purpose for which it was collected, or for a purpose compatible with it (Art. 6 para. 3 FADP, Art. 5 para. 1 let. b GDPR). Testing software is often not readily compatible with that purpose.
Then there is security: test environments are often less well protected, more people have access, and external developers are involved. Data protection by design (Art. 7 FADP, Art. 25 GDPR) requires such risks to be reduced from the outset with appropriate measures.
What methods are there?
| Method | Result | Suitable for |
|---|---|---|
| Masking | Details are made unrecognisable. | Viewing documents, training |
| Substitute values in a valid format | Realistic values; validation checks and interfaces keep working. | Test systems, integration tests |
| Pseudonymisation | Link back to the person possible with the mapping. | Analyses with follow-up questions, troubleshooting |
| Synthetic data | Generated without any link to real people. | Early development, load testing |
What matters with test data
- Valid format: identifiers such as IBANs or AHV numbers pass the application's validation checks.
- Consistency: the same person receives the same substitute value across related data.
- Don't forget free text: names often appear in comment fields and documents.
- Final check: check the result for any remaining unprotected details.
- Proof: record who received which test data and for what purpose.
Sharing data for a defined purpose
What applies to test data applies to every transfer: to analytics teams, to service providers or to an AI. The principle is to share only as much personal reference as the purpose requires – and to record, for each recipient and purpose, what was shared.