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 what was shared for each recipient and purpose.