Support Access Without Expanding Cardholder Scope
A payments processor runs a cloud data warehouse holding 12 million cardholder records. Support engineers in three countries work follow-the-sun and must reproduce customer disputes, which requires realistic transaction data. Today they query a masked view, but a recent penetration test read the base table directly using a support-role credential that had been granted SELECT on the schema two years ago during an incident. The QSA has said any environment where support staff can see full PAN is in scope for PCI DSS, which would add roughly 300 users to the assessed population. The warehouse supports column-level masking policies and integration with an external tokenization vault, but not format-preserving encryption natively. Engineering estimates tokenization at six weeks and dynamic masking at one week.
1. Choose between tokenization, dynamic masking, and format-preserving encryption, and justify the choice against the QSA's position that 300 support users would enter scope.
Read the worked answer
Tokenization - and the reason is scope elimination, not scope compliance.
- Dynamic masking is an authorization control. The penetration test succeeded because an authorization control drifted: a role retained a grant it should have lost. Adding a second authorization control in front of the same base table assumes the thing that just failed will not fail again. It is a legitimate interim step because it ships in a week, but it is not the answer.
- Format-preserving encryption, even if available natively, keeps the entity able to reverse to PAN with its own keys, so the data generally remains cardholder data and the support environment stays in scope. It also makes key custody the entire control.
- Tokenization replaces PAN at ingestion with a surrogate with no mathematical relationship to the original; the vault holds the mapping in a separate trust boundary. A misgranted SELECT on the warehouse returns tokens, which are not cardholder data. The 300 support users never enter the assessed environment.
Cost: six weeks versus one, plus an availability dependency on the vault. Accept both and commit.
2. What do you do in the first week, before tokenization ships, given that the base table is currently reachable?
Read the worked answer
Assume the environment is exposed and act as though the pen test finding is live.
- Revoke and narrow today. Remove schema-level SELECT from the support role and replace it with a role scoped to the masked view and the specific columns and rows dispute reproduction actually needs. This alone closes the demonstrated finding.
- Backstop with dynamic masking on the base table so that any other misgranted path returns masked values. Cheap, reversible, and it buys the six weeks.
- Detect. Enable query logging with alerts on base-table access outside the ETL principal, and on volume anomalies (rows scanned per session) consistent with bulk extraction.
- Break-glass. Create a time-bound, approved, logged elevation path so support can obtain transient access legitimately. The existing two-year-old grant was born precisely because someone needed access during an incident and took it permanently.
- Preserve last-4 and BIN. Confirm the tokenization design retains the attributes disputes rely on, or support will demand raw PAN again in month two and win.
3. Once tokenization is in place, what residual risks remain and how do you monitor them?
Read the worked answer
The vault becomes the crown jewel and a new single point of failure.
- Trust boundary: the vault belongs in a separate account or project with its own authentication, its own approvers, and no standing human read access to the token-PAN mapping. If support can detokenize in bulk, you have recreated the problem one hop away.
- Detokenization rate limiting and anomaly detection: a script calling the API per row is equivalent to a table dump. Cap per-identity throughput and alert on distinct-token coverage approaching the record count.
- Availability: if the vault is unavailable, dispute reproduction stops. Agree an RTO with the business, and cache non-sensitive attributes on read paths that do not need the mapping.
- Reversibility check: if any single engineer can retrieve a key or export the mapping table alone, the control is procedural, not technical.
Evidence for the QSA: a documented data flow showing PAN never lands in a support-reachable store, an access review of the vault, and the masking policy positioned as defence in depth - not as the primary control.