A support tool shows `**** **** **** 4242`. A product manager asks to display the full card number for identity verification. The database stores the full number encrypted with a managed key. Which change actually reduces PCI DSS scope?

What is being tested

Whether you can separate three operations that get used as synonyms. Masking changes a rendering. Encryption changes who can read a value. Truncation and tokenisation change what you store. Only the third kind moves a system out of scope, because scope follows the data, not the control.

And the product request gets a straight no. PCI DSS v4.0 (2022) caps what may be displayed at the card's issuer identification digits and the last 4, and anyone shown more needs a documented business need. Identity verification is done by asking the customer for the last four, not by showing staff the full number.

The mechanism

Scope is counted in systems that store, process or transmit the account number. A masked number is still the full number in the row underneath, so the store is in scope and the mask is a display rule that one stray export bypasses. An encrypted number is still the number: you are in scope, and you have added a key custody obligation on top.

A token is a surrogate with no mathematical relationship to the card number, held by the provider that issued it. Once the column holds tokens, your database no longer contains cardholder data, and the assessor's boundary moves to the provider. This is the only option on the list that changes the annual bill, and the difference between assessing 40 systems and assessing 4 is the difference between a long engagement and a short one. Choose tokenisation unless you are the party that must be able to read the number.

Why the other options fail

• Mask on display, keep the encrypted number. The commonest answer and the one that changes nothing structurally. Every analytics export, replica, backup and debug dump still carries the real value, and the mask lives in one presentation layer that the next consumer will not use.
• Encrypt with a customer-managed key in a separate key service. A genuine improvement to who can read the data, and it does not remove the data. You keep the scope and inherit key rotation, availability of the key service and a recovery path that now depends on it.
• Restrict the tool to three named people. This reduces the number of people who can misuse the tool and does nothing about the hundreds of other paths to the same column. It also fails the first time one of the three is on leave.

When this is the wrong answer

If you are the payment processor, or you need the real number for recurring billing in a market where network tokens are unavailable, you cannot tokenise it away. Then the correct design is a deliberately small cardholder data environment: one segmented service holds the number, everything else holds the token, and the extra cost of that segmentation is the point rather than an accident. The general rule classification should drive is whether you hold the data at all, because the cheapest control for the most sensitive class is not having it.