Data Masking: Techniques, Types, and Best Practices

What Is Data Masking?

Data masking is the process of replacing sensitive data with structurally similar but inauthentic values. The masked dataset keeps the same format, length, and data types as the original, so applications and tests behave the same, but the real names, card numbers, and health records are gone.

The idea maps directly to a legal concept. GDPR Article 4(5) defines pseudonymisation as processing personal data so it "can no longer be attributed to a specific data subject without the use of additional information," provided that additional information is kept separately. Most masking aims for something stronger: an irreversible transformation where the original value cannot be recovered from the output at all.

Masking is not the same as generating test data from scratch. Masking starts from real production records and transforms them, so the resulting dataset keeps the real distributions and edge cases that make tests meaningful. Here is what the transformation looks like on a single record:

• Before: name "Priya Sharma", card "4539578763621486", SSN "482-19-7365".
• After: name null, card "453957******1486", SSN "XXX-XX-7365".
• Unchanged: field names, data types, string lengths, and the relationships between tables.

Why Mask Test Data

The stakes are concrete. Under GDPR Article 83, regulators can impose fines of up to 20 million EUR, or 4% of total worldwide annual turnover, whichever is higher, for infringing basic processing principles. Yet one of the least-governed places personal data lands is the test environment.

A single production database restore into staging can copy every customer's real data into a system with weaker access controls, no encryption at rest, and shared developer logins. Masking closes that gap before the data ever leaves production. The specific reasons to mask test data:

• Shrink the blast radius: a breach of a masked staging database exposes fictitious values, not real customers.
• Reduce regulatory scope: environments holding only masked or pseudonymised data carry lighter compliance obligations than those holding raw personal data.
• Enable safe collaboration: masked datasets can be shared with offshore teams, contractors, and vendors without a data processing agreement for every record.
• Keep tests realistic: unlike random data, masked production data preserves the volume, skew, and messy edge cases that break software.

This is where masking connects to the wider discipline of test data management and database testing: the goal is a dataset that is safe to use and faithful to production at the same time.

What are the Types of Data Masking?

The type of masking you choose is defined by when and where the masking happens, not by which algorithm scrambles the value. Three types cover almost every use case.

For QA teams, static and on-the-fly masking matter most: both produce a safe dataset to test against. Dynamic masking is a production access control, closer to row-level security than to test data provisioning.

What are the Data Masking Techniques?

Where the type decides when masking happens, the technique decides how each value is transformed. A real masking job usually applies several techniques, one per column, chosen by how the data is used downstream.

To make this concrete, here is a small masking routine we ran on one record. It combines nulling, character masking, format-preserving card masking, deterministic pseudonymization, substitution, and numeric variance:

import crypto from 'crypto';

const salt = 'tdm-salt-2026';
// Deterministic: same input -> same token (preserves referential integrity)
const pseudonymize = (v) =>
  'usr_' + crypto.createHmac('sha256', salt).update(String(v)).digest('hex').slice(0, 10);

// Format-preserving: keep first 6 + last 4 (PCI DSS baseline), mask the middle
const maskCard = (c) => c.slice(0, 6) + '*'.repeat(c.length - 10) + c.slice(-4);

// Character masking: keep the email domain, mask the local part
const maskEmail = (e) => {
  const [local, domain] = e.split('@');
  return local[0] + '*'.repeat(Math.max(local.length - 1, 1)) + '@' + domain;
};

const record = {
  full_name: 'Priya Sharma',
  email: '[email protected]',
  phone: '+1-415-555-0147',
  card_number: '4539578763621486',
};

console.log({
  full_name: null,                          // nulling
  email: maskEmail(record.email),           // character masking
  phone: pseudonymize(record.phone),        // deterministic pseudonymization
  card_number: maskCard(record.card_number) // format-preserving
});

Running it produced this output. The card keeps the exact first-six and last-four format a payment system expects, and pseudonymizing the same phone number twice returns an identical token, which is what keeps joins intact:

MASKED (safe test data):
{
  "full_name": null,
  "email": "p***********@acme.io",
  "phone": "usr_29f97c5f85",
  "card_number": "453957******1486"
}

Referential-integrity check (same phone -> same token twice): PASS - deterministic

The technique per column is a design decision: substitution and variance keep analytics test data realistic, while nulling and redaction are fastest when a column has no test value at all. For teams that need to fabricate additional rows rather than transform real ones, a synthetic data generator pairs well with masking to fill gaps and scale volume.

Masking vs Encryption vs Tokenization

These three are often confused because all of them obscure data. The difference that matters for test data is reversibility: can someone recover the original value, and do they need to?

The rule of thumb: if a system must recover the original value later, use encryption or tokenization. If nobody downstream should ever see the original, mask it. Test environments almost always fall into the second case, which is why masking is the default tool for safe test data.

Data Masking and Compliance

Masking is named or implied across the major data-protection regimes. Three are worth knowing precisely, because each defines what "sufficiently masked" means for the data it governs.

• GDPR (EU): pseudonymisation is defined in Article 4(5) and treated as a recommended safeguard, while Recital 26 places genuinely anonymised data outside the regulation's scope entirely. Masking test data moves it toward, or past, that line.
• HIPAA (US healthcare): the U.S. Department of Health and Human Services recognizes two de-identification methods, Expert Determination and Safe Harbor, the latter requiring removal of a defined set of identifiers before health data can be shared or used freely.
• PCI DSS (payments): the PCI Security Standards Council states that a maximum of the first six and last four digits of a primary account number is the baseline that may be retained after truncation.

The practical takeaway: your masking rules should be written against the specific standard your data falls under. A card column masked to first-six and last-four satisfies the PCI baseline; a patient dataset needs the HIPAA identifier set removed, not just a name nulled. Documenting which rule maps to which column is what turns masking into an auditable control.

Masking Without Breaking Data

The failure mode that ruins masked test data is broken referential integrity. If a customer ID is masked to one value in the orders table and a different value in the payments table, every join fails and the dataset is useless for realistic testing.

Deterministic masking solves this. Because a keyed function maps the same input to the same output every time, a masked foreign key still matches its masked primary key across tables. The rules that keep masked data usable:

• Mask keys deterministically: use the same keyed function for every occurrence of an identifier so joins survive.
• Preserve format and constraints: a masked email must still pass an email regex; a masked date must still respect check constraints.
• Keep data distributions: mask a "country" column by substitution, not nulling, so queries that group by country still return meaningful shapes.
• Version the masking rules: treat the ruleset as code so a masked dataset is reproducible and auditable.

Masking is only half the job; the masked data then has to flow into governed test cycles. TestMu AI's Test Manager keeps test cases, execution, and results in one workspace with role-based access control at the organization, project, and folder level, AES-256 encryption at rest, and compliance-grade audit trails that log every create, update, and execution. That is the difference between a masked file on someone's laptop and a masked dataset used inside an auditable process.

This also connects masking to data-driven testing: once a masked dataset is stable and referentially intact, it becomes a reliable input source that a data-driven suite can iterate over without ever touching production PII.

What are the Best Practices of Data Masking?

A masking program that holds up under audit follows the same discipline as any other security control: classify first, automate, and verify.

• Discover and classify before masking: you cannot mask a PII column you have not found. Inventory sensitive fields first, then map each to a masking rule.
• Mask as close to the source as possible: mask during extract or in transit, so an unmasked copy never lands in a lower environment.
• Prefer irreversible masking for test data: if testers never need the original, do not keep a way back to it.
• Preserve referential integrity by default: use deterministic masking for all keys and cross-table identifiers.
• Automate masking in the pipeline: a manual masking step gets skipped under deadline; a pipeline step does not.
• Audit the result: scan the masked output to confirm no real identifiers survived, and log the run.

For a broader view of provisioning masked and synthetic data at scale, see our roundup of test data management tools, which covers the tooling layer that automates these steps.

Conclusion

Start by inventorying the sensitive columns in the data you copy into lower environments, then assign each one a masking rule: deterministic pseudonymization for keys, format-preserving masks for cards and identifiers, and substitution for values you still want to query. Automate that ruleset into your provisioning pipeline so every environment refresh produces safe, referentially intact test data by default.

From there, run that masked data through a governed process. Explore TestMu AI's Test Manager to keep test cases, execution, and audit trails in one compliant workspace, and see the test run and cycle documentation to connect masked datasets to your test cycles.