Test Data Without Real People: Why Pseudonymised Is Still Personal, and Synthetic Is Not

Copying production is a processing operation, not a shortcut

The reflex is understandable. Real data has the shape real data has: names of every length, addresses that do not fit the form, orders with forty line items, the customer whose surname contains an apostrophe that broke everything last March. A restored production dump is the highest-fidelity test fixture there is, and it costs one command. The problem is that the command is a processing operation in the legal sense, and the Regulation has something to say about it.

Two of the principles in Article 5 bear on it directly and independently. Purpose limitation, Article 5(1)(b), requires that personal data be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes. The address was collected to deliver an order. Reproducing a layout bug is not that purpose, and whether it is compatible with it is a real question with a real answer that someone has to work out — the Regulation gives criteria for the compatibility assessment rather than a yes or a no. Data minimisation, Article 5(1)(c), requires the data to be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed. A full copy of every customer, to test a checkout page, is difficult to describe as limited to what is necessary.

There is a practical dimension that has nothing to do with law and everything to do with what actually goes wrong. A test environment does not have production's access controls, production's monitoring or production's backup retention rules. It is on a laptop, in a container someone spun up, in a snapshot in a bucket that nobody remembers creating. The mail sender is often still configured, which is how a staging run once emailed a live customer list. The Regulation's requirement to protect data does not weaken because the machine is called staging, and the practical exposure is greater there than in production. Both arguments point the same way.

Pseudonymised is still personal — this is the part people get wrong

Article 4(5) defines pseudonymisation as the processing of personal data 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. Read it once and the crucial words are without the use of additional information. The additional information exists. It is kept somewhere. The link is still there; it has been made harder to follow, not removed.

Recital 26 draws the conclusion explicitly: personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information, should be considered to be information on an identifiable natural person. In other words, pseudonymised data is personal data, in scope, with every obligation attached — the rights of access and erasure, the breach notification duty, the transfer rules. The European Data Protection Board's Guidelines 01/2025 on Pseudonymisation, adopted on 16 January 2025, state the same conclusion in their executive summary and add a point worth keeping: it holds true even if the pseudonymised data and the additional information are not in the hands of the same person.

Anonymisation is a different claim and a much harder one. Recital 26 says the principles of data protection should not apply to anonymous information, meaning 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. But the same recital sets the test: to decide whether a person is identifiable, account should be taken of all the means reasonably likely to be used, considering objective factors such as the cost and the time required. A dataset where names have been replaced but the postcodes, birth dates and order histories remain will often fail that test, because the combination re-identifies. Anonymisation that survives scrutiny usually means destroying the very structure the test environment was supposed to reproduce.

Synthetic data escapes the whole argument by never entering it. A row assembled from a fixed list of first names, a fixed list of surnames and a fixed list of cities does not relate to an identified or identifiable natural person, because there is no person behind it and no additional information that would link one. Article 4(1) defines personal data as any information relating to an identified or identifiable natural person; if nothing is being related to anyone, the definition is not met, and the Regulation simply does not reach the dataset. No lawful basis, no compatibility assessment, no retention schedule, no deletion request that could ever arrive. That is a categorical difference and it is the reason to generate.

What this generator actually produces, measured

The tool draws from six per-country pools — France, the United Kingdom, Germany, Spain, Italy and Portugal — each holding thirty-two first names, thirty-two surnames and twelve cities. That is 192 first names, 192 surnames, 72 cities and 6,144 distinct full names across the whole space, and a row holds together: a Lisboa persona gets a Portuguese name and an email local part derived from it, not a German surname on a French phone number. Measured over four hundred runs, a hundred rows give 99.2 distinct names on average and a thousand rows give 922.5. The first repeated name turns up around row 100, which is the birthday bound on a space of 6,144 rather than a defect.

Email addresses do not collide at all, because they are not left to chance. Each run keeps the local parts it has already handed out and appends a counter to a repeat, so the second Marie Martin gets marie.martin2 as her local part. Ten thousand rows produce ten thousand distinct addresses, and two hundred thousand produce two hundred thousand — measured on the row builder, since the form itself stops at a thousand rows per run. The UNIQUE index that used to reject an import part-way through, leaving a half-filled table, has nothing left to catch. Two limits on that guarantee are worth knowing. The counter lives for one run, so two separate exports can still repeat each other — keep a fixture in one file, or give each batch its own prefix. And distinct names are a different number from distinct addresses: a query that counts customers by name rather than by address will come in a little under your row count, by about eight per cent at a thousand rows.

Every address ends in example.com, example.net or example.org, and nothing else. All three are reserved by RFC 2606 for use as examples, and all three publish a null MX record — the 0 . of RFC 7505, a domain stating in DNS that it accepts no mail at all — so a sender stops before it opens a connection. That pairing is the whole point, and it is stricter than it looks. A domain that merely has no mail exchanger is not safe: RFC 5321 has a sender that finds no MX fall back to the address record, so a documentation-looking domain with a live A record and no MX is still a delivery target. Reserved plus null MX together is what closes it, and it is the reason not to invent an example domain of your own.

The phone column is the one place the tool answers a question by leaving a field empty. France reserves numbers for fiction: the national numbering plan allocates the roots 01 99 00, 02 61 91, 03 53 01, 04 65 71, 05 36 49 and 06 39 98 to audiovisual works, and 06 39 98 is the only mobile one — so a French row carries +33 6 39 98 followed by four random digits, and nothing else. Ofcom sets aside 07700 900000 to 07700 900999 for television and radio drama, so a British row carries +44 7700 900 and three digits. The Bundesnetzagentur published two mobile blocks for media productions, 0171 3920000 to 3920099 and 0176 04069000 to 04069099, and a German row comes from one of them. Spain, Italy and Portugal publish nothing equivalent, so their rows come out with the phone field empty. Countries are drawn uniformly, which means about half of all rows have a blank there — 49.99% over two hundred thousand rows — and a note under the form says why, because a blank column with no explanation reads as a broken tool.

A workable rule, and where it stops

Generate, do not copy, and make the generated data obviously fake. Use a reserved domain for every address rather than a mixture, prefix the local part with something no real account would carry, and pick a phone root your country reserves for fiction if it has one. That if deserves an answer, because for half the markets this site serves the answer is no. France, the United Kingdom and Germany each publish a block; Spain, Italy and Portugal publish none. What those three have instead is space that is currently unallocated, which is a much weaker promise — a regulator that has not handed a range out yet can hand it out next year, and a fixture written today would then be dialling somebody. Where a reserved range exists, use it; where none exists, the honest output is no number at all, which is what this tool now does. The point is not legal — synthetic data is out of scope whatever it looks like — it is that a human glancing at a support ticket or a log line should be able to tell in one second that the row is not a customer. Data that looks real gets treated as real, and that is how a test address ends up on a mailing list.

Where generation genuinely stops is the bug you can only reproduce on one record. Sometimes the defect is in that customer's data and nowhere else, and no synthetic row will show it. That case is not solved by pretending; it is solved by narrowing. Extract the one record rather than the table, take only the fields the bug touches, work on a machine with the same controls as production, log the access, and delete it when you are done. That is a documented, minimised, time-boxed processing operation with a purpose you can write down, which is a completely different thing from a nightly dump into a shared staging cluster — and it is the shape your data protection officer will recognise, because it is the one the Regulation is built to accommodate.

Frequently asked questions

Is pseudonymised data still personal data under the GDPR?

Yes. Article 4(5) defines pseudonymisation as processing personal data so that they can no longer be attributed to a specific data subject without the use of additional information, and Recital 26 states that data which have undergone pseudonymisation and could be attributed to a natural person by the use of that additional information should be considered information on an identifiable natural person. The European Data Protection Board restated it in its Guidelines 01/2025 on Pseudonymisation, adopted on 16 January 2025, adding that it holds even when the pseudonymised data and the additional information are not held by the same person. Pseudonymisation is a safeguard the Regulation encourages, and it can reduce risk and support a compatibility assessment, but it does not take a dataset out of scope.

Can I copy the production database into staging if I delete it afterwards?

Deleting afterwards does not make the copy lawful; it limits how long the processing lasts, which is a different question. The copy is a processing operation from the moment it happens, and it needs a lawful basis and has to survive the purpose limitation test in Article 5(1)(b) — the Regulation asks whether the new purpose is compatible with the one the data were collected for, and gives criteria for making that assessment. Article 5(1)(c) applies independently: taking a whole table when three fields would do is not limited to what is necessary. This is exactly the judgement a data protection officer exists to make, and the answer depends on your sector, your privacy notice and what you are actually testing. Ask before you run the restore, not after.

Is synthetic data really outside the GDPR?

When they are genuinely synthetic, yes — but the word is doing work. Data assembled from a fixed word list, with no input from any real record, does not relate to an identified or identifiable natural person, so Article 4(1) is not satisfied and the Regulation does not apply. Recital 26 says the principles of data protection should not apply to information which does not relate to an identified or identifiable natural person. The caveat is that not everything called synthetic is built that way: a dataset generated by a model trained on real records is a different proposition, because the model has seen the originals and the output can retain enough of them to single someone out. If your generator reads from production, the analysis starts again from the beginning. If it reads from a fixed list of a hundred and ninety-two first names that were never anybody's in particular, it does not.

Can anything actually be delivered to the generated email addresses?

No, and the reason is worth borrowing for your own fixtures. Every address uses example.com, example.net or example.org. RFC 2606 reserves all three as example names, so nobody can register one and start receiving mail on it, and all three publish a null MX record — the 0 . form defined by RFC 7505, which is a domain announcing in DNS that it accepts no mail. A conforming sender reads that and stops without opening a connection. The pairing matters: a domain with no MX at all is not equivalent, because RFC 5321 has the sender fall back to the address record, so a plausible-looking domain that resolves but has no mail exchanger is still a delivery target. If you are writing your own generator, take the reserved names rather than inventing one that looks reserved — and block outbound mail at the environment level as well, which you should be doing anyway.

How many rows can I generate before names start repeating?

Names start repeating around row 100; email addresses never do. The pools hold thirty-two first names and thirty-two surnames for each of six countries, which is 6,144 distinct full names, and the birthday bound on a space that size puts the first collision at roughly a hundred draws — measured at 99.6 over three thousand runs. At a hundred rows you get 99.2 distinct names on average, at a thousand rows 922.5. The addresses are a different matter: a repeated name gets a counter appended to the local part, so ten thousand rows give ten thousand distinct addresses and a UNIQUE index on the email column has nothing to reject. One boundary on that — the counter is per run, and the form generates at most a thousand rows at a time, so if you need more than a thousand, run it again with a different seed and add your own per-batch prefix rather than assuming the two exports cannot overlap.