A city parking system must store payment references without retaining raw primary account numbers in the municipal database. Which method best meets that goal?
Select an answer to reveal the explanation.
Short Explanation
Tokenization swaps the real card number for a harmless stand-in—like a coat-check ticket—so the city database never keeps the raw PAN. Fancy hostnames and taped printouts are not substitutes. Real hashing isn’t meant to be reversible either.
Full Explanation
Tokenization replaces primary account numbers with surrogate tokens that have no intrinsic payment value outside the tokenization system. The municipal database then stores tokens instead of raw PANs, shrinking PCI-relevant scope and limiting damage if the application database is breached. Detokenization stays confined to tightly controlled vaults or payment processors when a true PAN is required.
Storing full PANs in cleartext behind a long hostname is obscurity, not protection. Printing PANs on paper tickets taped to cashier monitors creates physical leakage and camera exposure. Labeling a reversible cipher as “hashing” misnames cryptography and leaves PANs recoverable from the ciphertext whenever the key is known.
Exam caveat: tokenization differs from truncation/masking (display minimization) and from encryption (reversible with keys). Hashing PANs is generally inappropriate when payment workflows need recoverable identifiers—tokens or encryption are the usual patterns.
Operational check: confirm payment integrations send PANs to the tokenizer or processor, verify city databases hold only tokens, scan repos and shares for accidental PAN patterns, and keep any detokenization privileges tightly audited for finance staff.