Data Masking vs. Encryption: Which Should You Use?

In May 2026, a class action against 7-Eleven laid out the distinction in the plainest possible terms. The suit, filed after an April 2026 breach exposed more than 600,000 records containing Social Security numbers, dates of birth, addresses, and driver's license numbers, alleges the company failed to implement "reasonable cybersecurity safeguards — including the encryption or redaction of sensitive information" — and that the data taken was simply "unencrypted" and "unredacted" (ClassAction.org). Notice the "or": plaintiffs' counsel didn't have to argue 7-Eleven needed encryption specifically — either encryption or masking-style redaction would have changed the outcome. That interchangeability is exactly where most teams get confused, and exactly where regulators, auditors, and courts increasingly expect precision instead.

Masking and encryption both make sensitive data unreadable to someone who shouldn't see it. But they solve different problems, satisfy different rules, and fail in different ways when applied to the wrong use case. Here's how to tell them apart and pick correctly.

The core technical difference: reversibility and intent

Encryption is designed to be reversed. Data is transformed using a cryptographic algorithm and a key, and anyone holding the correct key can decrypt it back to its original form — that reversibility is the entire point, because encryption protects data that legitimate users still need to access later, whether at rest in a database or in transit across a network (Bluemetrix).

Masking is generally designed not to be reversed. Static data masking permanently alters sensitive values — substituting, shuffling, or scrambling them — so the original data cannot be reconstructed from the masked output, which is precisely why masked data is considered safe to hand to test, QA, or analytics teams who have no legitimate need to see the real values at all (Bluemetrix). Dynamic data masking works differently in mechanics — it obscures values at query time while leaving the underlying data untouched — but the goal is the same: the person on the other end of the query never sees the real value.

That distinction is exactly what NIST's forthcoming SP 800-38G Rev. 1 addresses on the encryption side. It governs format-preserving encryption (FPE) — the FF1 method that lets you encrypt a value like a Social Security number or card number into ciphertext that still looks like a valid SSN or card number, preserving length and character set for downstream systems, while remaining fully reversible with the key (NIST CSRC). FPE is a hybrid case worth understanding on its own: it has masking's cosmetic property (format preservation) but encryption's core property (reversibility) — which is exactly why it gets misclassified in compliance documentation more often than any other technique.

What PCI DSS actually requires — and where teams misread it

Payment card data is the clearest regulatory test case because PCI DSS names both controls explicitly and does not treat them as interchangeable.

Requirement 3.3 governs display: when a primary account number (PAN) appears on a screen, receipt, or printout, only the first six and last four digits may be shown to anyone without a documented business need to see more (PCI Security Standards Council). That's masking — concealment for viewing purposes, with the full PAN still sitting behind it.

Requirement 3.4 (3.5 in the newest numbering) governs storage, and it's a different problem entirely: wherever a PAN is stored — databases, backups, logs — it must be rendered unreadable via one-way hashing of the entire PAN, truncation, tokenization, or strong cryptography with proper key management (PCI Security Standards Council). Since March 31, 2025, disk- or partition-level encryption alone no longer satisfies this requirement for non-removable media — PCI DSS 4.0 requires it be paired with another rendering method such as column-level encryption or tokenization (Prime Factors). Critically, the standard is explicit that "encryption alone may not be sufficient to render the cardholder data out of scope for PCI DSS" — the systems doing the encrypting and holding the keys stay in scope, while a properly truncated PAN database can actually fall out of PCI DSS scope entirely (Visa). That's a real operational difference: truncation (a masking-family technique) can shrink your compliance footprint in a way reversible encryption cannot, because there's no key to protect and no cardholder data left to steal.

How GDPR and HIPAA treat encrypted data differently from masked or de-identified data

Regulators don't grant encryption and masking the same legal status, and assuming they do is a common — and costly — mistake.

Under GDPR, encrypted personal data generally remains personal data. Recital 26's test asks whether a person is identifiable by any means "reasonably likely to be used," and encrypted data fails that test unless re-identification is genuinely impractical — which usually isn't true for the party holding the decryption key (Mirsky & Company legal analysis). The Court of Justice of the EU's SRB v EDPS reasoning, reinforced by Advocate General Spielmann's 2025 opinion in the pending appeal, held that pseudonymized data can fall outside GDPR's scope only for a recipient who has no realistic access to the re-identification key — meaning the same dataset can be personal data for one party and effectively anonymous for another, depending entirely on key access (Mirsky & Company legal analysis). Irreversible masking that genuinely prevents re-identification has a much stronger claim to sitting outside GDPR's scope altogether, because there's no key anywhere that reverses it.

HIPAA draws its own version of this line. Since the Security Rule update effective January 2025, encryption of ePHI at rest and in transit is a required, not addressable, safeguard, and it comes with a specific payoff: a breach notification safe harbor. If an unauthorized party only obtains properly encrypted ciphertext, the incident does not trigger the same reporting obligations as a plaintext exposure — "a stolen laptop with encrypted disk is a non-event," while "the same laptop with plaintext PHI is a six-figure OCR settlement" (VertiComply). De-identification under HIPAA's Safe Harbor or Expert Determination methods takes data out of PHI status entirely, rather than earning a breach-notification exemption while remaining PHI — a meaningfully different legal outcome from encryption's safe harbor, even though both controls make the data unreadable to an attacker.

Where each control actually belongs: production versus non-production

The practical split comes down to who legitimately needs the real value back.

Encryption is the right call for data at rest in production databases and data in transit across networks — anywhere authorized systems and users need to retrieve the original value to do their jobs, whether that's processing a payment, authenticating a login, or displaying a patient record to a clinician. It's reversible by design, and that reversibility is the feature, not a flaw, as long as key management is solid (Bluemetrix).

Masking is the right call for non-production environments — test, QA, staging, UAT — and for analytics or AI training pipelines where no one downstream has a legitimate need to see the real customer or patient value at all. PCI DSS 4.0's Requirement 6.5.4, mandatory since March 31, 2025, states plainly that production account data must not be used in test or development environments in the first place — masking (or fully synthetic data) is the mechanism that makes realistic-looking test data possible without that exposure (Sovereign Forger). This is also where irreversibility becomes a legal asset rather than an inconvenience: masked data that can't be reversed can't become the subject of a "was this really de-identified?" discovery fight the way reversible or weakly masked data can.

A practical framework for choosing between them

1. Ask who needs the original value back. If a legitimate system or user must retrieve the real number, name, or record later, you need encryption. If no one downstream has a legitimate reason to see the real value, use masking.

2. Check whether the environment is production or non-production. Production systems handling live transactions or care generally need encryption at rest and in transit. Test, QA, analytics, and AI training environments should receive masked or synthetic data, never raw production copies.

3. Map the specific regulatory requirement, not the general topic. PCI DSS treats display (masking, Requirement 3.3) and storage (encryption/truncation/tokenization, Requirement 3.4/3.5) as separate obligations — confirm which one applies to the specific data flow you're securing (PCI Security Standards Council).

4. Verify key management before trusting encryption's compliance value. Under GDPR and HIPAA alike, encryption's legal benefit — narrower personal-data scope, breach-notification safe harbor — depends on who controls the key and how well that control is documented (Mirsky & Company legal analysis; VertiComply).

5. Confirm masking is actually irreversible before calling it compliant. Format-preserving techniques that merely obscure values without cryptographic strength, or masking that leaves indirect identifiers untouched, doesn't hold up to the same scrutiny as documented, tested irreversible masking.

6. Document the choice and the control together. Auditors, regulators, and plaintiffs' counsel all ask the same question after an incident: which control was applied, to which field, and why. Have that mapping ready before you need it.

Industry-specific considerations

Healthcare. HHS's Office for Civil Rights enforces HIPAA's now-mandatory encryption standard for ePHI at rest and in transit, and separately evaluates whether de-identification met the Safe Harbor or Expert Determination bar for data leaving PHI status altogether (VertiComply). These are two different compliance tracks, not one — a dataset can be properly encrypted and still be PHI, or properly de-identified and no longer PHI at all.

Financial services. PCI DSS 4.0's dual-track requirements — Requirement 3.3 for display masking and Requirement 3.4/3.5 for storage encryption/truncation/tokenization — are both mandatory and independently audited, and GLBA's Safeguards Rule extends the same expectations to every environment touching customer financial data, not just production (PCI Security Standards Council).

A quick checklist

• Does this specific field need to be retrieved in its original form by an authorized system or user, or can it be permanently masked?

• Is this data sitting in a production environment (encrypt it) or a test, QA, analytics, or AI pipeline (mask it)?

• If you're relying on encryption for compliance credit, can you document exactly who controls the decryption keys?

• If you're relying on masking for compliance credit, can you prove the technique is genuinely irreversible, not just obscured?

• Have you mapped which specific regulatory requirement — display, storage, non-production use, de-identification — applies to each data flow you're securing?

The bottom line

Masking and encryption both make data unreadable, but they answer different questions: encryption asks "how do we protect data that someone legitimately needs back," while masking asks "how do we give people realistic data they never needed to see the real version of in the first place." Getting that distinction backward — encrypting test data instead of masking it, or masking production data that authorized systems still need to decrypt — is how compliance gaps and breach lawsuits like the one against 7-Eleven happen (ClassAction.org).

C² Data Privacy Platform discovers sensitive data across production databases, data warehouses, and non-production environments, and masks or de-identifies it automatically before delivery — so your team applies the right control to the right environment every time, without relying on someone remembering to do it manually. Book a demo to see it run against your own schema.

Sources: ClassAction.org — "Data Breach Lawsuit Claims 7-Eleven Failed to Encrypt Sensitive Info Before Cyberattack", Bluemetrix — "Data Tokenization vs Data Masking vs Data Encryption", NIST CSRC — SP 800-38G Rev. 1, Format-Preserving Encryption, PCI Security Standards Council — PCI DSS Quick Reference Guide, Prime Factors — Complying with PCI DSS 4.0, Visa — 8-Digit BIN Expansion and PCI Standards, Mirsky & Company — "Encrypted Data: Still 'Personal Data' under GDPR?", VertiComply — "HIPAA Encryption Requirements (2026)", Sovereign Forger — PCI DSS Test Data and Synthetic Data Requirements, C² Data Technology.