·
8 min
Data masking for test data: techniques, limits and how it differs from pseudonymization and anonymization
Roman Kirchmeier - Autemos
Data masking for test data replaces sensitive production values with substitutes, so tests run on realistic data and no customer stays recognizable. For a QA lead at a bank, three points matter: technique per field, consistent keys across systems, and the legal status of the result. The German GTB Test Data Specialist syllabus counts sensitive production data copied unaltered into test systems as bad test data (GTB syllabus Test Data Specialist V1.1, 2021). Our guide to test data management shows how masking fits into roles and process.
TL;DR: Data masking alters production values for testing, for example “Müller” to “Mxxxxx”. Whether the result is pseudonymized or anonymous depends on whether anyone can restore the originals. Most EU financial entities may store only “anonymised, pseudonymised, or randomised production data” in non-production environments (DORA RTS 2024/1774, Art. 16(5), 2024). Mask quasi-identifiers such as birth date and postcode too.
Figure 1: Masking is a technique; pseudonymization and anonymization describe the legal state of the result.
What is data masking?
Data masking is a test data management technique that alters original values so test data stays usable without exposing real people or business internals. The GTB syllabus glossary defines it as “altering original data with random characters or data so that the original data can no longer be recognized” (our translation) (GTB syllabus TDS V1.1, ch. 7, 2021).
Per GTB, masking covers personal and non-personal data, such as a corporate client's pricing terms. The data is disguised, not encrypted, and its readability usually stays intact. A masked IBAN still looks like an IBAN.
How does data masking differ from pseudonymization and anonymization?
Data masking names a technique; pseudonymization and anonymization name the legal state the result reaches. Under GDPR Art. 4(5), pseudonymized data “can no longer be attributed to a specific data subject without the use of additional information”, if that information is kept separately (GDPR, EUR-Lex, 2016). Recital 26 says such data “should be considered to be information on an identifiable natural person”.
Data is anonymous only when “the data subject is not or no longer identifiable” (Recital 26). The Article 29 Working Party is blunt: “pseudonymisation is not a method of anonymisation” (WP216, 2014). Whoever holds the key or lookup table holds pseudonymized data, no matter how thorough the masking looks.
Criterion | Data masking | Pseudonymization | Anonymization |
|---|---|---|---|
What it is | Technique for disguising values | Legal state under GDPR Art. 4(5) | Legal state under GDPR Recital 26 |
Reversible? | Depends on technique: redaction no, tokenization yes | Yes, with key or lookup table | No, with means reasonably likely to be used |
Status under GDPR | Depends on the result | Personal data | Outside the GDPR |
Commentators read the CJEU judgment C-413/23 P of 4 September 2025 as confirming that pseudonymized data stays personal data at least for the party that holds the key (CJEU, press release 107/25, 2025). Our article on GDPR-compliant test data covers the legal side.
What do the DORA RTS and revFADP require?
Under Art. 16(5) of Delegated Regulation (EU) 2024/1774, most EU financial entities' “non-production environments only store anonymised, pseudonymised, or randomised production data” (EUR-Lex, 2024). The RTS supplement the EU regulation DORA (2022/2554), which has applied since 17 January 2025.
The DORA RTS accept pseudonymized data; the GDPR still treats it as personal data. So a masked test database can meet DORA and still fall fully under the GDPR.
In Switzerland, the revised Federal Act on Data Protection (revFADP, German revDSG) took effect on 1 September 2023. It defines personal data as “any information relating to an identified or identifiable natural person” (Art. 5(a), unofficial translation, Fedlex, 2023) and contains no definition of pseudonymization. For banks and securities firms, FINMA Circular 2023/1 requires separating development and test environments from ICT production (test automation in regulated banks). Have your data protection officer check your masking concept.
Which data masking techniques exist?
Common data masking techniques range from emptying a field to format-preserving encryption, and each keeps different properties. The GTB syllabus separates information reduction (dropping values) from alteration, with examples such as ±20% salary variance (GTB syllabus TDS V1.1, ch. 2.4.2, 2021).
Figure 2: Four masking techniques with examples from the GTB Test Data Specialist syllabus V1.1.
Technique | Example | What stays intact | Limit |
|---|---|---|---|
Nulling, redaction, suppression | Birth date becomes year only, “comment” field emptied | Table structure | Tests on that field become meaningless |
Generalization | Postcodes 10000 to 19999 become 11000 (GTB) | Region, rough distribution | Small groups stay conspicuous |
Masking, substitution | “Müller” becomes “Mxxxxx” (GTB) | Length, first letter, readability | Rare names stay guessable |
Shuffling | Swap a column's values between records | Column distribution | Per GTB only for larger data sets, alter unique values first |
Variance | Salary ±20%: €5,000 becomes €4,432 (GTB) | Order of magnitude | Totals no longer add up |
Tokenization | Card number becomes a token; original sits in a vault | Format, uniqueness, joins | Reversible, result is pseudonymized |
Format-preserving encryption (FPE) | FF1 turns a digit string into another of equal length | Format, length, joins | Reversible with the key |
Tokenization and FPE sit outside the GTB definition, which separates masking from encryption; many TDM tools list both under masking. NIST SP 800-38G (2016) specifies the FPE methods FF1 and FF3 (NIST, 2016). Revision 1's second public draft states: “The encryption method FF3 is no longer specified.” (NIST SP 800-38G Rev. 1, 2025). We found no final version yet. Plan FPE with FF1.
Static masking or masking at runtime?
Static masking writes a disguised copy into the test database. Masking at runtime (on the fly) changes values only on read or display; stored data stays in clear text.
Static: fits test environments; reproducible, but the extract must rerun regularly.
At runtime: fits production views such as support screens. The database still holds the originals; Art. 16(5) of the DORA RTS applies to what is stored.
What does masking mean for card numbers?
PCI DSS v4.0 and v4.0.1 (Requirement 3.4.1) limit a displayed card number (PAN) to the BIN and the last four digits; only staff with a documented business need may see more. Per the PCI Security Standards Council, “no more than the BIN and last four digits of the PAN are displayed” (PCI SSC FAQ). “First six, last four” is not v4.0 wording and doesn't fit 8-digit BINs.
Per PCI SSC FAQ 1146, a PAN masked on screen may still be stored in full and then falls under Requirement 3.5.1. Display masking doesn't protect a test database.
How high is the re-identification risk of masked test data?
Re-identification risk is high once unchanged quasi-identifiers stay in the data set. Latanya Sweeney found 87% of the 1990 US population (216 of 248 million) likely unique by 5-digit ZIP, gender and birth date, using census data (Sweeney, Data Privacy Lab, 2000).
Figure 3: A few quasi-identifiers are enough for re-identification (US data; Sweeney, Golle, Rocher et al.).
Philippe Golle got 63% with 2000 census data (Golle, Stanford). Rocher, Hendrickx and de Montjoye estimated with a generative model that “99.98% of Americans would be correctly re-identified” in any dataset with 15 demographic attributes (Nature Communications, 2019). All three figures come from US data; we know of no comparable Swiss or German numbers.
WP216 names three risks that anonymization must protect against (WP216, 2014):
Singling out: “the possibility to isolate some or all records which identify an individual”
Linkability: “the ability to link, at least, two records concerning the same data subject”
Inference: “the possibility to deduce, with significant probability, the value of an attribute”
The GTB syllabus gives a test example: leaving the only 97-year-old policyholder in the data set makes him identifiable, whether or not his name is masked.
How do you approach data masking step by step?
Data masking for test data runs in seven steps: inventory fields, choose a technique, keep keys consistent, mask outside the test environment, check residual risk, test with the regression suite, document.
Figure 4: The seven steps of data masking for test data.
Inventory sensitive fields. Direct identifiers (name, IBAN, card number, email), quasi-identifiers (postcode, birth date, gender, occupation) and free-text fields with customer data.
Choose a technique per field. Redact what no test needs. Generalize what only has to be roughly right. Use substitution or FPE where format and joins matter.
Keep formats and keys consistent. The same customer gets the same substitute in every system.
Mask outside the test environment. Masking runs in a secured zone; only the result reaches the test environment. Keep keys and lookup tables separate.
Check residual risk. Look for unique combinations and rare values. If the risk stays high, it's often cleaner to generate synthetic test data.
Test the masked data with your regression suite. Red tests on the masked data set show where masking broke formats or business logic. When several runs share one data set, test data isolation prevents collisions.
Document. Rules per field, masking job version, extract date and approval belong in the test data plan, a GTB annex to the test plan. A complete audit trail in testing later shows auditors which data sat in which environment, and when.
How do you keep referential integrity across several systems?
Referential integrity holds when the same original value gets the same substitute in every table and system. The GTB syllabus names keeping referential integrity as the main challenge of partial extracts (GTB syllabus TDS V1.1, ch. 2.4.1, 2021). A customer with an account in core banking, a card in the card system and a CRM contact needs the same customer number everywhere after masking. Otherwise E2E tests break at the first interface.
Consistency comes from a central lookup table (original to substitute) or a deterministic keyed function that always returns the same substitute for the same input. Both create the “additional information” GDPR Art. 4(5) describes. Consistent masking across systems almost always produces pseudonymized, not anonymous, data. Check after every run:
Formats and check digits (IBAN, card number, AHV (Swiss social security) or tax number), so input checks in the test don't fire
Foreign keys and unique indexes
Time references: for system chains, the GTB syllabus asks for a single timestamp for the whole extract
Where does Autemos fit and where doesn't it?
Autemos is AI-assisted software for functional test automation across web, mobile, API and desktop. Autemos is not a data masking or test data generation tool. It doesn't anonymize or pseudonymize production data and doesn't create database subsets.
Autemos works with test data that your TDM process has masked beforehand. Autemos does not check whether it is masked. Test Data Handling in Autemos connects external sources: REST APIs, databases, Excel, JSON files and the iSynth data source. Runtime bindings load values as variables at runtime, per environment (DEV, TEST, STAGING, PROD).
That lets you point the TEST binding at the masked copy. One-Time Use flags consumed test users, vouchers or tokens, so parallel runs don't pull them twice.
Frequently asked questions
Is masked test data still personal data?
Yes, if someone can restore the originals via a key, token vault or lookup table. Then it's pseudonymized, and GDPR Recital 26 treats it as information on an identifiable person (EUR-Lex, 2016). It's anonymous only when nobody can identify the person with means reasonably likely to be used.
Is it enough to mask names and IBANs?
No, quasi-identifiers are often enough for re-identification. Per Sweeney, ZIP code, gender and birth date made 87% of the 1990 US population likely unique (Data Privacy Lab, 2000). Generalize or alter those fields too, and check free-text fields.
May an EU bank use unmasked production data in testing?
Only as an exception under Art. 16(6) of the DORA RTS 2024/1774: for specific testing occasions and limited periods, after approval and with reporting to ICT risk management (EUR-Lex, 2024). The default under Art. 16(5) is anonymized, pseudonymized or randomized production data.
Is format-preserving encryption a form of anonymization?
No, FPE is reversible with the key and produces pseudonymized data. Keep the key separate from the test environment.
Does Autemos mask test data?
No, Autemos doesn't mask, anonymize or generate test data. It reads test data that was masked beforehand from REST APIs, databases, Excel, JSON or iSynth through runtime bindings per environment (Test Data Handling).
Conclusion
Data masking makes production data usable for testing when you plan it field by field. No technique makes data anonymous by default: once keys or lookup tables exist, the data is pseudonymized and stays under the GDPR. For EU banks, Art. 16(5) of the DORA RTS sets the minimum; for Swiss banks, the revFADP and FINMA's separation of test and production apply. Check quasi-identifiers, keep substitutes consistent across systems, run your regression suite against the masked data set and document the rules per field in the test data plan. To see how automated tests pull pre-masked test data per environment, talk to the Autemos team.
