Test environments with real data: the breach nobody plans for

In late October 2026 the University of Copenhagen reported that attackers had accessed a test environment containing real personal data. According to breach round-ups, around 525,000 people were affected, with names, national ID numbers, phone numbers and email addresses involved, plus roughly 20,000 PIN codes for building access. It is a painfully familiar story: the live system was protected, but a copy built for testing was not.

Why test systems leak

• "It is only test." Test and staging systems often skip multi-factor authentication, logging and patching because they feel temporary.
• Real data is convenient. Developers want realistic data to reproduce bugs, so someone copies production "just this once".
• Nobody owns them. Projects end, contractors leave and the server keeps running for years.
• Wider access. More people, including suppliers and students, are given access to test systems than to live ones.
• Exposed by accident. A test database or storage bucket opened to the internet for a demo is easily forgotten.

Better options than copying production

1. Synthetic data: generate fake records that look realistic but belong to nobody. Many tools and libraries can do this.
2. Masking: if you must start from real data, replace names, ID numbers, emails and phone numbers with fake values before it leaves production, and do it automatically.
3. Minimise: copy only the tables and fields you actually need for the test.
4. Expire: give every test environment an owner and an end date, and delete it when the date passes.

If real data must stay in test

Sometimes there is a genuine reason. Then treat the environment as production: the same access controls, MFA, patching, logging and backups, and the same data protection obligations. Under GDPR and similar laws, personal data is personal data whichever server it sits on.

A quick audit you can run this week

• List every non-production environment: development, test, staging, training and demo.
• For each, ask: who owns it, what data does it hold, who can reach it and is it exposed to the internet?
• Close anything without an owner, and mask or delete real personal data where you can.

Our notes on security zones and secure network design explain how to keep test networks separate, and S3 security covers a common place where test data is exposed.

The lesson

Attackers do not care whether a server is labelled "test". If it holds real data, it is a real target.

Sources

• Privacy Guides: Data breach roundup, 23 to 29 October 2026