A developer needs realistic data to test a new billing feature. An analyst needs to count repeat customers. A call center agent needs to confirm a caller's identity. All three work with customer records, and none of them needs to see a full card number. Choosing how to protect data mostly comes down to what each person or system still has to do with it.
On the CompTIA Security+ SY0-801 exam these methods sit under objective 3.3, which expects you to explain the ways organizations protect data and when each one fits. This lesson covers masking, tokenization, hashing, encryption, data transposition, de-identification, filtering and obfuscation, and finishes with a comparison you can use to choose between them in a scenario.
Masking hides part of a value from the people who see it
Masking replaces some or all of a value with substitute characters or realistic fake data, so the result stays usable without exposing the original. The familiar example is a card number shown as ****-****-****-1234: enough for a customer or agent to recognize the card, useless to anyone who copies it. PCI DSS limits how many digits of a card number may be displayed to people who don't need the full number, and showing only the last four is common practice.
Masking comes in two forms, and they suit different jobs.
Static data masking permanently changes a copy of the data. The usual case is building a test or development database from production: names are swapped for fake names, card numbers for fake numbers in the right format, birth dates shifted by a random number of days, and values in a column shuffled between rows so no record keeps its own. The masked copy looks real enough to test against, but it no longer contains real customers, so a breach of the test environment exposes nothing. There is no way back from the masked copy to the original.
Dynamic data masking leaves the stored data alone and masks it on the fly when it is read, based on who is asking. Several database engines support it. In SQL Server, for example, a column can be defined so that users without the UNMASK permission see only the last four digits:
ALTER TABLE Payments
ALTER COLUMN CardNumber ADD MASKED WITH (FUNCTION = 'partial(0,"****-****-****-",4)');
The billing service, granted UNMASK, reads full numbers; the agents' reporting account sees ****-****-****-1234. Dynamic masking is a display control, not an access boundary. A user who can run arbitrary queries can sometimes infer masked values by filtering on them, for example by searching for salaries above a threshold, so it should sit on top of proper access control.
On the exam, "developers or testers need realistic data" points to static masking, and "users see only part of the value depending on their role" points to dynamic masking.
Tokenization swaps the real value for a stand-in kept in a vault
Tokenization replaces a sensitive value with a token: a substitute value with no mathematical relationship to the original. The mapping between each token and its real value is kept in a token vault, a tightly controlled database usually run by a payment processor or a specialist provider. Only the vault, and the systems authorized to ask it, can turn a token back into the original. In this classic vault design there is no key that converts a token into a card number, so a stolen list of tokens is worthless without the vault. Some products generate tokens cryptographically instead of storing a lookup table, but the protection still depends on the detokenizing service staying out of an attacker's reach.
A typical card payment flow looks like this:
1. Checkout page sends the card number over TLS directly to the processor
2. Processor stores the card in its vault and returns a token: 8301 5527 0946 1234
3. Merchant stores only the token, using it for refunds and repeat billing
4. To charge the card again, the merchant sends the token; the vault looks up the real number
Many tokens keep the original's format, such as 16 digits ending in the real last four, so receipts, databases and legacy systems built for card numbers keep working. Mobile wallets use the same idea at the card network level: the phone holds a device-specific token, and the merchant never receives the real card number.
The main business reason merchants tokenize is to reduce PCI DSS scope. The standard applies to systems that store, process or transmit cardholder data and to systems connected to them. If the order database, CRM and analytics platform hold only tokens, can't detokenize and are segmented from the systems that can, the PCI Security Standards Council's guidance allows them to be considered out of scope, which shrinks every future assessment. The assessor makes that call; it isn't automatic. The vault and anything that can call it stay in scope and become the most valuable target in the environment.
Don't confuse tokenization with encryption. Ciphertext can be decrypted by anyone who has the key, wherever the ciphertext ends up. A token can only be reversed by asking the vault.