Synthetic test data vs test data masking

Choose synthetic test data when a test environment must hold no personal data or live card numbers, or when tests need rare financial edge cases. Choose test data masking when tests need the volume, distributions, and cross-system links of production data, and the masked copy can stay under the same General Data Protection Regulation (GDPR) controls as its source.

Synthetic test data and data masking compared

The table compares both methods on personal data scope under the GDPR, cardholder data in pre-production under PCI DSS v4.0.1, and the properties that decide whether financial tests still pass.

Factor	Synthetic test data	Test data masking
Source of records	Synthetic test data is generated from rules or a model and describes no real customer.	Test data masking copies production records and replaces identifying values with substitutes.
GDPR status	Synthetic data with no link to a real person is anonymous information under GDPR Recital 26 and outside the GDPR.	Masked data that a mapping key or other information can attribute to a person is pseudonymised data under GDPR Article 4(5) and stays personal data under Recital 26.
PCI DSS v4.0.1 requirement 6.5.5	Synthetic card data uses published test card numbers, so no live primary account number (PAN) reaches pre-production.	Masking must replace every primary account number (PAN) before the copy leaves the cardholder data environment (CDE), because 6.5.5 allows live PANs in pre-production only inside the CDE.
Referential integrity across systems	A generator writes the same customer, account, and card IDs into the ledger, card processor, and CRM data sets by design.	Masking keeps joins between systems only when each source value maps to the same substitute in every system (deterministic masking).
Edge case coverage	A generator creates rare cases on demand, such as a refund larger than the capture or a closed account with a residual balance.	A masked copy contains only the cases that production held on the day of the copy.
Production realism	Synthetic data lacks the legacy formats and malformed records that production has accumulated.	A masked copy keeps real distributions, legacy formats, and malformed records that break parsers.
Re-identification risk	Rule-based synthetic data built with no production input holds no real person to re-identify; a model trained on production records can reproduce real records.	Masked data stays re-identifiable when fields such as date of birth, postcode, and transaction timestamps are left unchanged.
Ledger balance consistency	A generator that writes journal entries first and derives balances from them keeps every balance equal to the sum of its postings.	Masking that changes amounts or drops rows leaves stored balances that no longer equal the sum of their postings.

When to choose synthetic test data

Automated regression in CI. Each run starts from the same generated data set, so a failed assertion points at a code change instead of a data refresh.
Card flows in environments outside the CDE. PCI DSS v4.0.1 requirement 6.5.5 states: "Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements." Requirement 6.5.6 adds that "test data and test accounts are removed from system components before the system goes into production." Synthetic cards use published test ranges; the test card numbers guide lists them per sandbox. Source: PCI DSS v4.0.1 Requirements and Testing Procedures, June 2024, the current version, checked on 2026-09-22.
Rare financial cases. A chargeback on a closed account, interest accrual across 29 February, and a negative balance after a reversed deposit may not exist in production on the day of a copy. A generator creates each case with a known expected result.
Ledger and reconciliation suites. Balances derived from generated postings make every mismatch a defect in the code under test. The ledger reconciliation guide injects breaks into such data sets and checks that the reconciliation reports exactly those breaks.
Test teams in other countries or at vendors. GDPR Recital 26 states that the principles of data protection "should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable." Rule-based synthetic data meets that condition, so the transfer rules of GDPR Chapter V do not attach to the data set.

When to choose test data masking

Migration rehearsal. Real legacy records carry encodings, closed products, and history that no generator models. A balance and transaction history comparison on a masked copy, as in data migration testing, finds the records that fail mapping before cutover.
Performance and volume tests. Query plans and batch run times depend on production cardinality and skew, such as a small set of merchants that carry most of the transactions.
Reproducing a production defect. A defect tied to one record shape, such as a legacy account with two currencies, reproduces on a masked copy of that record.

A masked copy stays personal data for the company that masks it. Article 4(5) of the GDPR defines pseudonymisation as processing "in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person." Recital 26 says identifiability accounts for "all the means reasonably likely to be used, such as singling out, either by the controller or by another person", including the cost and time of identification and the technology available (Regulation (EU) 2016/679 on EUR-Lex, checked on 2026-09-22). On 4 September 2025 the Court of Justice held in Case C-413/23 P that pseudonymised data is not personal data "in all cases and for every person" (press release 107/25, checked on 2026-09-22). The judgment interprets Regulation (EU) 2018/1725 and concerns recipients that cannot identify the person; the controller that holds the key can.

Masking therefore works under four conditions in our practice: it runs inside production or the CDE, it is deterministic across every system that shares an ID, it leaves amounts and posting sets intact or recomputes balances, and the masked copy gets the same GDPR Article 32 controls as its source.

Cost and timeline factors

Synthetic test data cost follows the data model:

Breadth of the model. Each entity and each system that shares an ID adds generation rules and cross-system links.
Financial rules. Fees, accruals, and state transitions need rules that produce correct expected results.
Maintenance. Each schema change needs a generator change in the same release.
Realism gap. Defects caused by production-only formats surface late, in migration rehearsal or after release.

Test data masking cost follows production:

Field discovery. Personal data and PANs sit in free text, logs, JSON columns, and attachments, as well as in named columns.
Key custody. The mapping key and the masking pipeline need access control inside production or the CDE, plus change approval for each pipeline change.
Refresh and deletion. Each refresh creates a new copy of personal data to secure and later delete.
Audit cycles. A PCI DSS assessor examines pre-production test data for live PANs under testing procedure 6.5.5.c, and each masked copy falls within GDPR Article 32 scope.

The "Masking and synthetic test data sets" deliverable of data privacy testing covers both: a synthetic data set that follows the client's data model, masking rules for approved production copies, and a scan for real names, IBANs, and card numbers.

Questions

Is pseudonymised data personal data?

Recital 26 of the General Data Protection Regulation (GDPR) states that personal data which have undergone pseudonymisation, and which could be attributed to a natural person by the use of additional information, should be considered information on an identifiable natural person. A masked test copy is pseudonymised data, and so personal data, for a company that keeps the mapping key or can re-link the records.

Is synthetic data personal data?

Synthetic data is outside the General Data Protection Regulation (GDPR) when no record relates to an identified or identifiable natural person, which Recital 26 calls anonymous information. Synthetic data generated from rules, with no production records as input, relates to no real person. Synthetic data from a model trained on production records can reproduce real records and needs a check against production before use.

Is data masking reversible?

Data masking is reversible when the masking process keeps a mapping table or a key that recovers the original values, as tokenisation and keyed encryption do. Irreversible data masking keeps no mapping, but records can stay identifiable through unchanged fields such as date of birth, postcode, and transaction timestamps. Under GDPR Recital 26, masked data that can be attributed to a person stays personal data.

Scope your test data approach

Send your data model, the systems that share customer and account IDs, and your pre-production environments, and we return a plan that marks which test suites run on synthetic data and which need a masked copy.

Scope your testing