You discover the application logs full credit-card numbers and passwords in plaintext. What's the fix priority?
Short answer
Sensitive data should never reach logs: redact or mask at the source first to stop the bleeding, then remediate the historical logs and tighten access. PCI DSS forbids storing full PANs and CVVs this way, and passwords should never be logged at all. 'Internal' logs are still a prime breach target. Encrypting or ACLing the store still leaves cleartext secrets sitting in logs for anyone with read access — backups, SIEM pipelines, and admins all see them.
The trap in this question is treating logged secrets as an access-control problem when it's really a data-minimization problem. The data shouldn't be there at all — so the first move is to stop creating it.
Why redact-at-source comes first
Logs are not a private vault. They get shipped to SIEMs, copied into backups, replicated across regions, indexed by search tooling, and read by on-call engineers. Every one of those copies is now a cleartext credential and cardholder-data store. PCI DSS explicitly prohibits storing full Primary Account Numbers in this form and forbids storing sensitive authentication data like CVVs after authorization; passwords should never be logged in any form. So step one is to mask or redact at the source — stop the application from ever writing the sensitive fields. That halts the bleeding. Only then do you remediate the existing logs (purge or scrub historical entries, including backups and downstream copies) and review/tighten who can access them.
Why the distractors are wrong
- Leave it — logs are internal. "Internal" is not a security boundary. Insiders, a compromised account, a misconfigured bucket, or a breach turns those logs into a disclosure. This is the do-nothing answer.
- Encrypt the whole log server, keep logging the data. Encryption at rest protects against stolen disks, but the application, the SIEM, every admin, and every backup still read the secrets in cleartext. The secrets are still there. You've locked the room but left the safe open inside it.
- Just restrict who can read the logs. Tightening ACLs is a good supporting step, but on its own it leaves live secrets in the logs, propagating through pipelines and backups, one misconfig away from exposure.
What the interviewer is probing
They want data-minimization instinct: fix the source before the symptoms. The strong answer names PCI DSS, recognizes that "internal" and "encrypted-at-rest" don't solve cleartext-in-logs, and sequences correctly — stop writing it, then clean up what's already there, then harden access.
Likely follow-ups
- Where in the stack would you implement redaction so nothing sensitive is ever written?
- What does PCI DSS specifically say about storing PANs and authentication data?
- How would the data have spread beyond the log server, and how do you clean that up?