Data masking: using data professionally without the unnecessary risk

Almost every dataset contains PII (Personally Identifiable Information): data that can be traced back to a natural person, directly or indirectly. Names, email addresses and phone numbers are the obvious examples. Less obvious fields count too, such as customer numbers, dates of birth, IP addresses or location data. Datasets become sensitive above all when these fields are combined, even where each field on its own looks harmless.

Data masking is neither a compliance trick nor an obstacle to innovation. It is a mark of professional data handling.

In the European context this data falls under the GDPR definition of personal data. That brings obligations around data minimisation and appropriate security measures. At the same time, most analysis, testing and development work has no need for real personal data at all. Patterns, trends and failure scenarios stay visible without exposing a single real identity.

Why this goes wrong in practice

In many organisations personal data ends up in datasets by default, simply because that is easier than deliberately designing a safe alternative. The risk then shifts from conscious decision-making to technical accident. One misconfigured role, one export to a laptop, or one compromised test environment is enough to expose personal data.

This is not a theoretical risk. Incident analyses show that non-production environments are structurally less well secured than production, while they often hold the same sensitive data.

Data masking as a grown-up design choice

Data masking is a security technique in which sensitive values in a dataset are altered, replaced or hidden while the structure, the relationships and the statistical properties stay intact. That lets teams work with realistic data without access to real personal data.

Data masking is a structural control within the data landscape rather than a standalone measure.

The distinction with encryption matters. Encryption protects data against unauthorised access and requires decryption before use. Data masking is built for daily use by developers, testers and analysts who have no need for real PII. The data stays usable and the traceability disappears.

In practice several forms of masking get combined:

Static data masking is used for test, acceptance and analysis environments. Production data is masked once in a copy, with personal data structurally replaced by fictional but consistent values. The risk of a breach outside production drops sharply while the analytical value stays intact.

Dynamic data masking protects personal data during use. Sensitive fields are shielded automatically based on role and authorisation, without changing the source data. It suits production environments where broad access is needed but full PII is only necessary for a limited number of roles.

Tokenization and format-preserving techniques target high-risk identifiers such as payment details and national identification numbers. The original value is replaced by a technically equivalent token, so links and validations keep working while traceability disappears. Essential in environments with strict compliance requirements.

Organisations that combine these techniques deliberately reduce their attack surface, limit internal exposure and gain control over personal data.

What this looks like in practice

A development team at a financial organisation tests transaction flows with a statically masked dataset. Volumes, patterns and dependencies are realistic, while customer names and account numbers are replaced by consistent fictional values. The test results stay reliable and the risk stays manageable.

In a customer service environment, dynamic masking is the usual choice. Agents see only what they need to help the customer, for example the last digits of an identification number. The full personal data stays protected at the source.

What effective data masking asks for

Successful data masking starts with insight and governance rather than with tooling. Data classification is necessary to know which fields hold PII. Masking has to be applied consistently so relationships between tables stay intact, across systems as well as within them.

Clear access rights and audit logging matter just as much. Who may change masking rules, who has access to the original data, and how is that recorded? Without those conditions, masking stays a technical sticking plaster.

Conclusion

Data masking is a mark of professional data handling. Organisations that work with masked data as a matter of course lower their risk, build trust, and make data usable at scale.

So the real question is why real personal data is still used by default in places where it isn’t necessary.

Sources and further reading

• NIST Glossary, Data Masking 
• NIST Special Publication 800-53 Rev. 5, Security and Privacy Controls
• OWASP, Data Protection and Privacy Guidelines
• Microsoft Learn, Dynamic Data Masking
• Gartner, Data Masking Best Practices (subscription)
• ISO/IEC 27001 and 27701, Information Security and Privacy Management
• El Emam, K. Guide to the De-Identification of Personal Health Information. CRC Press

Disclaimer: this article is professional commentary rather than legal advice. Interpretation and application of GDPR requirements and PII definitions depend on context and call for input from privacy and legal specialists.

This article by Fred van den Heuvel was first published in the Digital Trust Community of the Dutch National Cyber Security Centre.

Where this meets the commercial side

Explaining masking to a data team is one conversation. Explaining to a board why test environments deserve the same attention as production is another. That second one is what I do. Get in touch if your team is having it.