Four Million PANs in a Debug Log
During PCI DSS evidence collection, an engineer discovers that a log aggregation platform has been ingesting application debug logs containing full card numbers and expiry dates for fourteen months. Approximately 4.2 million card records are present. The platform stores logs unencrypted at rest and 60 engineers have read access. The application that emits the logs sits inside the cardholder data environment; the log platform sits outside it and was never in scope. The platform vendor is cloud-hosted and holds the encryption keys. Legal counsel needs a decision within 48 hours. The acquiring bank contract requires notification of a suspected compromise within five business days.
1. Set out the first 48 hours of actions and state whether this should be treated as a reportable incident.
Read the worked answer
Treat it as a confirmed incident until the evidence says otherwise, and sequence the work so containment does not destroy the evidence you will need to decide reportability.
Hours 0-4 - contain. Restrict access to the log platform to a named incident team, suspend the ingestion pipeline, and snapshot the affected indices before anything is deleted. Purging first feels tidy and is the single most common irreversible mistake.
Hours 4-24 - scope. Query access logs for the fourteen months: who read these indices, was any export run, was any external share created. Determine exactly which fields were captured - full PAN plus expiry is sensitive authentication data adjacent and materially worse than a truncated number.
Hours 24-48 - decide. Reportability turns on jurisdiction and on whether the data was readable. Unencrypted at rest with 60 holders of read access, including a third-party vendor, does not support a 'no risk' position. Counsel decides the legal call; the CISO's job is to put the facts in front of them and to start the acquirer clock at five days rather than miss it.
Assume notifiable, prepare the notification, and stand it down if forensics proves no access - not the reverse.
2. The CISO proposes tokenizing the card number at the point of capture to shrink PCI scope. Compare tokenization, field-level encryption, and truncation for this environment.
Read the worked answer
All three reduce exposure; only one meaningfully reduces scope, and only if it is segmented properly.
Truncation to first six and last four is right for display, reporting, and analytics, and should be applied to this logging pipeline immediately. It is not a substitute for tokenization because the business cannot process a refund from a truncated number.
Field-level encryption leaves the PAN in every system that holds a key. Nine downstream systems that can decrypt still store cardholder data, so scope stays wide, and key sprawl becomes the new problem. Useful as defence in depth, weak as a scope tool.
Tokenization with a format-preserving token lets most downstream systems keep working unchanged while holding a value that is useless without the vault. Scope genuinely shrinks if - and only if - the vault lives in a segmented environment, the downstream systems cannot reverse the token, and the token cannot be used to authorize a transaction elsewhere. If those conditions fail you have added cost without reducing scope.
Decision: truncate in logs and analytics now; tokenize at capture with the vault inside the cardholder data environment; keep encryption at rest as a second layer, not the primary control.
3. A payment vendor in scope refuses an on-site audit and offers only a self-completed questionnaire. The business says the vendor is too embedded to replace within two years. What do you recommend?
Read the worked answer
Establish first what the vendor actually touches. If they only transmit encrypted data and never hold a key, the requirement relaxes considerably and a questionnaire plus attestation may be proportionate. If they store or can decrypt cardholder data, no audit right means you cannot validate the control you are relying on.
Then read the contract. Most agreements contain a right-to-audit or an obligation to provide an independent attestation. If it does, this is a contract-enforcement conversation, not a risk-acceptance one.
If enforcement is not realistic, accept a substitute evidence set: a current SOC 2 Type II covering the relevant trust criteria, a recent penetration test summary, the completed questionnaire, and a call with their security lead. That is weaker than an audit but is real evidence rather than self-assertion.
If even that is refused, you have a documented, unmitigated third-party risk with a two-year exit horizon. Escalate to the accountable executive for a time-boxed written risk acceptance with a named owner, an expiry date, and a funded exit plan. Risk accepted is fine; risk ignored is not.