The development team needs realistic test data — but KVKK and GDPR restrict the sharing of personal data. This dilemma is a fundamental tension every data-intensive organisation faces. The answer lies in one of three main approaches: static masking, dynamic masking and synthetic data generation, with pseudonymization as a fourth complementary technique.
Static Masking
Production data is transformed once as it is copied into the test environment. For example, all names become "Customer 12345", all tax IDs become random but format-preserving numbers. The advantage is simplicity; the drawback is that the process must be re-run for every new test copy.
Dynamic Masking
The database performs live masking at query time based on the user's role. SQL Server Dynamic Data Masking, Oracle Redaction and Snowflake Dynamic Masking fall into this category. A developer running SELECT * FROM customers sees tax IDs as xxx-xxx-xxxx, while a full-access analyst sees the real values. The advantage is single storage with multiple views; the drawback is that query optimisation becomes more complex.
Pseudonymization
Personal data is replaced with an alias, and the alias→real-value map is kept behind a separate wall. This fits GDPR Article 4(5) and is technically not personal data (though it remains in the sensitive zone). This is the most common choice in banking risk modelling.
Synthetic Data
Fully fictitious records are generated by a model that has learned the real distribution — GANs, variational autoencoders or statistical sampling. Test scenarios stay realistic while the data is fiction. Ideal for performance testing, though rare combinations may not be captured, so it can be insufficient for corner-case functional testing.
Which Approach for Which Situation?
- Functional development and testing: static masking is sufficient.
- Analytical reporting and BI environments: dynamic masking.
- Risk modelling and third-party sharing: pseudonymization is mandatory.
- Performance and load testing: synthetic data, often blended with other techniques.
A Field Example
A Turkish private bank adopted a three-layered approach: static masking for dev/test, dynamic masking for production BI and pseudonymization for third-party model-development partners. Combined, these three layers delivered a smooth passage through both KVKK and BDDK audits.
