GDPR and test data: pseudonymised is still personal
Copying customer records, emails and documents into a test environment is processing like any other. GDPR and UK GDPR don't ban it, but they expect you to minimise it, protect it and show what you did.
“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.”
Data minimisationPersonal data must be adequate, relevant and limited to what is necessary. A full production copy for a test rarely is.Art. 5(1)(c)
Protection by designControllers must build in measures such as pseudonymisation that put the data protection principles into effect.Art. 25(1)
Security of processingPseudonymisation and encryption are named among the measures for appropriate security.Art. 32(1)(a)
AccountabilityYou must be able to demonstrate compliance: a record of what was masked, how and when.Art. 5(2)
Pseudonymised or anonymous?
The difference decides whether GDPR still applies to your test data.
Pseudonymised
Identifiers replaced; a key or extra information could link them back.
Still personal data for anyone who can re-identify it, including you.
GDPR applies, with lower risk. Article 4(5) expects the key to be kept separately and protected.
Anonymous
No one can identify the person by any means reasonably likely to be used.
Outside GDPR altogether (Recital 26).
Hard to achieve for rich text and documents, where indirect details add up.
Two recent reference points: the ICO published its final UK guidance on anonymisation and pseudonymisation on 28 March 2025, and in EDPS v SRB (September 2025) the EU Court of Justice held that pseudonymised data may not be personal data for a recipient who has no reasonable means to re-identify it.
Each capability carries its status today, so you can plan around what exists.
Engineer-ledPseudonymise documentsConsistent replacements or tokens in PDF, Word and PowerPoint files, with the token map kept on your side, separate from the data.
Engineer-ledMailboxes and Slack exportsWhole archives, with each person resolved to one replacement across threads and files.
Engineer-ledSynthetic documentsDocuments with no data subject behind them, for tests that don't need the real thing.
Engineer-ledEvidence for your recordsPolicy coverage, execution coverage and residual source values for each run, ready for your DPIA and records of processing.
Engineer-ledRedaction for subject accessThird-party data removed from documents before a DSAR response goes out.
Before the next test refresh
Add test environments to your record of processing.
Prefer synthetic or pseudonymised data; justify any real data, in a DPIA where the risk is high.
Keep the re-identification key out of the test environment.
Include documents, emails and notes, not just tables.
Set retention for test copies and delete on schedule.
If anyone, including you, holds a key or could reasonably re-identify people, treat it as pseudonymised personal data. Synthetic data generated without copying records is generally outside GDPR, as long as it doesn't reproduce real individuals.
Is UK GDPR different here?
The articles on this page read the same in UK GDPR. The Data (Use and Access) Act 2025 changed parts of UK data protection law, but not these principles, and the ICO's 2025 guidance is the UK reference on anonymisation.
Can we rely on legitimate interests to test with real data?
Possibly, but you would have to show the processing is necessary, which is hard when masked or synthetic data would do the same job.
This page summarises the rules for planning purposes. It is not legal advice; check how they apply to you with your counsel or DPO.
The platform underneath, in production
Documents run on the same platform banks, insurers and health companies already trust with their data.
Documents and text use the same policies, the same engine and the same deployment as these results.
