A merchant currently stores full card numbers in several databases to support refunds and repeat purchases. The security team wants to reduce how many systems fall within PCI DSS scope while keeping those features. Which approach best achieves this?
Select an answer to reveal the explanation.
Short Explanation
The easiest card number to protect is the one you never keep. Swap the PANs for tokens from your payment provider, and the token still lets you refund or rebill without holding real card data. Moving or compressing the PANs is the trap; if the real number is still there, so is the PCI scope.
Full Explanation
PCI DSS scope covers the systems that store, process or transmit cardholder data and those connected to them. Tokenization replaces the primary account number with a surrogate value that has no exploitable meaning on its own; the mapping to the real PAN is held by the payment provider or a dedicated tokenization service. The merchant stores only tokens and can still issue refunds and charge returning customers by passing the token to the provider, so its own databases no longer hold cardholder data and can fall out of scope, greatly reducing audit burden and breach impact. Consolidating PANs onto one server changes where the data lives but leaves it in scope, and a shared server may pull additional systems into scope. Placing PANs in a schema that users cannot browse is an access control measure; the data is still stored and the database remains in scope. Compression is not encryption; compressed card numbers can be decompressed by anyone with access, so they are not rendered unreadable. Exam caveat: truncation, keeping only part of the number, also reduces risk but cannot support repeat charges, which is why tokens fit this requirement. Operational check: after migration, scan all databases and backups for full PAN patterns and confirm only tokens remain.