Data masking

Data masking replaces sensitive values with realistic but fake substitutes, a real name swapped for a plausible fake one, a credit card number replaced with one that passes format checks but isn't valid, so that data retains its shape and usefulness for testing, development, or analysis while the original sensitive values are no longer exposed. Masking can be static, applied once to create a masked copy, or dynamic, applied on the fly as a query runs so the underlying data is never altered.

Masking differs from pseudonymization in that a well-designed mask is typically not meant to be reversed back to the original value, while pseudonymization deliberately keeps a reversible mapping under separate control. It also differs from anonymization, which aims to remove identifiability entirely, including through combinations of fields; masking usually protects specific sensitive fields rather than guaranteeing the whole dataset can't be re-identified.

Masking matters most in non-production environments: giving developers or testers a realistic-looking database without handing them real customer personally identifiable information. It's commonly paired with data classification to know which fields need masking, and with role-based access control to control who sees masked versus unmasked data. A common pitfall is masking inconsistently across related tables, breaking joins, or masking so predictably that the substitution can be reverse-engineered.