What Is Data Masking? Keeping Real Data Out of Test

Data masking is the practice of replacing real values in a dataset with realistic but fake ones, so the data still works for testing, development, training or analytics without exposing the people it describes. A masked customer table keeps the same columns, formats and relationships, but the names, ID numbers and contact details no longer belong to anyone. It is the main control that stops a test environment breach from becoming a personal data breach.

What is data masking?

Data masking is a set of techniques that transform sensitive fields into non-sensitive substitutes while keeping the data usable. The goal is that a developer, tester or vendor can do their work on the masked copy, and an attacker who steals it gets nothing of value.

The University of Copenhagen incident in October 2026 shows what happens without it. Attackers got into a test environment that held names, national identity numbers, phone numbers and personal email addresses for about 525,000 people. Our news coverage of the University of Copenhagen data breach has the details. Had that database been masked, the same intrusion would have exposed a test system and little else.

How is data masking different from encryption?

Encryption protects data that must later be read in its original form, and anyone with the key can reverse it. Masking is usually one-way: the original values are gone from the masked copy, so there is no key to steal.

That difference decides where each belongs. Production databases need encryption, because the application has to read real values. Test and development copies need masking, because nobody there should ever see the real values. An encrypted database restored into a test environment along with its key is not protected in any useful sense.

Common data masking techniques

Most masking tools combine a handful of methods. Pick per field, based on what the test actually needs.

• Substitution. Replace a value with a realistic one from a lookup list: a real-looking name, street or city that belongs to nobody in particular.
• Shuffling. Move values between rows within a column. The column keeps its real distribution, but no row links back to its original person. Weak on its own for small tables or rare values.
• Format-preserving generation. Create a fake value that passes the same validation as the real one, such as a national ID number with a valid structure and check digit, or a card number that passes a Luhn check.
• Nulling or redaction. Blank the field or replace it with a fixed string. Simple and safe when the field is not needed for testing.
• Number and date variance. Shift salaries, dates of birth or transaction amounts by a random amount within a range, so totals and trends stay plausible.
• Deterministic masking. The same input always produces the same masked output. This keeps joins working across tables and systems, but it needs a secret seed, and that seed must be protected like a key.

Static versus dynamic masking

Static data masking produces a separate, permanently masked copy of a database. You run it once when refreshing a test environment, and the test environment never receives real values. This is the right approach for test, development, training and vendor copies.

Dynamic data masking leaves the stored data unchanged and hides values at query time based on who is asking. A support agent might see only the last four digits of an ID number. It is useful in production for limiting what each role sees, but it is not a substitute for static masking in test, because the real data is still sitting in the database for anyone who gets past the query layer.

Masking, pseudonymization and synthetic data

These terms overlap, so be precise in policy documents.

• Pseudonymization replaces identifiers with tokens while someone, somewhere, keeps a way to map them back. Under GDPR, pseudonymized data is still personal data.
• Anonymization removes any reasonable way to reidentify a person. Data that is truly anonymized falls outside GDPR, but the bar is high: combinations of postcode, birth date and gender often reidentify people.
• Synthetic data is generated from scratch, sometimes modeled on the statistics of a real dataset, and never contained real records at all.

Good masking aims for anonymization. Synthetic data is often the cleaner choice for new projects, because there is no real source copy to leak along the way.

What should be masked first?

Mask anything that would cause harm if it appeared on a leak site: national ID numbers, names combined with contact details, dates of birth, financial and health data, credentials and access codes. Start with the fields an attacker could use for fraud or account takeover, then work outward.

Do not stop at the main database. Masking often misses log files, search indexes, file attachments, backups and free-text comment fields, where people paste the same identifiers you just masked. The step-by-step inventory in how to find personal data in test environments covers those places.

Where masking fails in practice

The technique is rarely the weak point. The process around it is.

1. Unmasked refreshes. Someone restores a production backup into test "just this once" to chase a bug, and it never gets masked.
2. Masking after copy. The raw data lands in test first and the masking job runs later. If it fails, or the environment is breached in between, the real data is exposed.
3. Linked fields left behind. The name is masked but the email address still reads firstname.lastname, or a free-text note repeats the ID number.
4. Weak deterministic seeds. A seed stored in the same repository as the masking scripts lets anyone reverse the mapping.

The fix for the first two is to mask inside the production trust boundary and only ever move the masked output. For the rest, test the masked copy: search it for patterns that match real identifiers before you hand it to anyone.

Masking only covers data. Test systems can also hold secrets that control the physical world, such as door PINs, and those need their own response plan, as covered in why physical access control belongs in breach scope.