How to Find Personal Data in Test Environments

Finding personal data in test environments starts with a list of every non-production system you own, then a pattern search of each one for real identifiers such as national ID numbers, email addresses and phone numbers. Most organizations find more than they expect, because test copies are created quickly and deleted rarely. This guide gives a repeatable process that a small team can run in a few weeks and repeat every quarter.

Why does personal data end up in test environments?

Real data ends up in test because copying production is the fastest way to reproduce a bug, test a migration or demo a feature. Each copy is meant to be temporary, but nobody owns its deletion, so it stays.

The October 2026 University of Copenhagen data breach is the result at scale: attackers reached a test environment holding names, national identity numbers, phone numbers and personal email addresses for about 525,000 people.

Step 1: build the environment inventory

You cannot search systems you do not know about. Build one list that covers:

• named test, staging, QA, UAT, training and demo environments
• developer databases and local copies on laptops
• cloud accounts and subscriptions tagged dev or test, plus any without tags
• vendor and contractor environments that receive your data
• old migration and reporting databases left behind after a project
• restored backups and database snapshots

Good sources for this list are your cloud billing exports, CMDB, DNS records, firewall rules and the change tickets for past data refreshes. Ask each development team lead directly as well: shadow environments rarely appear in official records.

For each entry, record an owner, the business purpose, the last time it received production data, and who can log in. An environment with no owner is your first finding.

Step 2: decide what you are searching for

Write down the data types that would be harmful in a leak, and the pattern that identifies each. Typical targets:

1. National identity numbers, using their real format and check digit rules where they have them.
2. Email addresses on public domains such as gmail.com or outlook.com, which indicate real people rather than test accounts.
3. Phone numbers in your country's formats.
4. Payment card numbers that pass a Luhn check.
5. Names that match your real staff, student or customer directory.
6. Passwords, password hashes, API keys and access codes, including door or alarm PINs.

Pattern matching produces false positives. Validating check digits and comparing hits against a known list of synthetic test values cuts the noise considerably.

Step 3: scan structured data

Start with databases, because that is where most volume sits. Use a data discovery tool if you have one; many database platforms and cloud providers include classification features. If not, a read-only script that samples rows from every table and column and tests them against your patterns is enough to start.

Points to get right:

• Scan with a read-only account created for the purpose, and log its use.
• Sample every column, not just the ones with obvious names. Real ID numbers hide in fields called notes, ref or misc.
• Record table, column, match count and sample size. Never copy the matching values into your report.

Step 4: scan unstructured data

Masking projects usually cover databases and miss everything else. Search these as well:

• application and web server logs, which often record request parameters
• search indexes and caches
• file shares, object storage buckets and uploaded attachments
• exported CSV and spreadsheet files left in project folders
• container images and virtual machine snapshots
• ticketing systems and wikis where people paste sample records

Step 5: rank and fix

Rank each finding by volume, sensitivity and exposure. A test database with half a million national ID numbers that is reachable from the internet is critical. A spreadsheet with ten staff phone numbers on an internal share is low.

For each finding, pick one action:

1. Delete the copy if nobody can name a current need for it.
2. Mask it in place, then verify with a rescan. The explainer on what data masking is covers which techniques fit which fields.
3. Isolate it if it must stay real for a short, documented period: restrict network access, require named accounts and turn on logging.

How do you stop real data from coming back?

You stop it by making the masked path easier than the unmasked one. Provide a masked or synthetic dataset on request, run masking inside production before any copy leaves, and require an approved ticket for any refresh of real data.

Add three controls so drift shows up early:

• a scheduled rescan of every test environment, with results sent to the environment owner
• an alert when a production backup is restored anywhere outside production
• an expiry date on every test environment, after which it is reviewed or removed

What if you find evidence of access?

If the scan turns up signs that a test system was already accessed by someone who should not have been there, stop treating it as a hygiene project. Preserve logs and disk images first, following the steps in how to preserve evidence before patching a server, then bring in your incident response process and your data protection officer. Remember to check whether the environment held anything tied to buildings, such as badge records or PINs. Why physical access control belongs in breach scope explains why those need separate handling.