Personal data turns up somewhere it was never meant to be: a third-party analytics or log-viewer dashboard shows customer phone numbers, names, or id-shaped digits in plain text. Sometimes the discovery is internal (a teammate pastes a log line into chat and someone notices the number); in the worse version, a client's security review or an auditor finds it first, and the conversation is no longer technical.
A service team that logged "everything, to be safe": full request bodies, including free-text fields the app team kept adding — CRM notes, callback numbers, customer names. The logs flowed from the service to CloudWatch, and from there into a vendor log dashboard bought for convenience, with default retention measured in months. Nobody decided to publish personal data; it travelled inside "harmless" debug logs. Under India's DPDP Act this is stored and shared personal data without a purpose — real legal exposure, with fines that reach hundreds of crores. Linked modules: 4.8 (Monitoring — logging discipline), 3.11 (redaction, DPDP), 4.7 (CloudWatch).
The leak happened at write time, not at share time: once a raw phone number
is in a log line, every downstream copy — CloudWatch, the vendor tool, a
teammate's terminal scrollback, a pasted snippet — is a leak surface you no
longer control. Logging full request bodies is the root cause, and it fails
DPDP on two principles at once: data minimisation (the number was never needed
to debug latency) and purpose limitation (support data reused as debug data).
Regex redaction alone is a false comfort — patterns catch phones and ids but
not names and addresses. Confirm the blast radius: search the log store for
phone-shaped patterns ([0-9]{10}), list every downstream system logs flow
to, and check the retention setting on each — the answer to "how bad is it"
is matches × destinations × months retained.
Contain first: purge the offending log groups and vendor indexes, shorten retention, and rotate any credentials that appeared. Then fix the layer, not the incident: replace log-everything with a whitelist — the model's feature fields, an opaque reference code, status, latency — so unknown fields are dropped by default, and pass any unavoidable free text through 3.11's redact() before the write. Set explicit retention limits on every log group (weeks, not forever), and re-review every third-party destination logs flow to against the data it may now receive.
Decide what may be logged, not what may not: a whitelist survives the app team's next new field, a blacklist does not. Redaction is the floor for free text, never the wall — the wall is not logging free text at all. Treat every log store as personal-data storage in DPDP terms: named purpose, minimum fields, retention limit, and a list of downstream systems reviewed before connecting. And put one grep in CI or the weekly digest: a phone-shaped pattern search over a sample of fresh logs, so the day a raw number appears, your own monitor finds it before a vendor's dashboard does.
Q: "A security review finds customer phone numbers in your service's logs and in a third-party log tool. Walk me through your response." Strong answer: contain (purge, shorten retention, rotate anything exposed), then name the root cause as a write-time failure — full request bodies logged — not a sharing mistake. Fix at the logging layer: whitelist of fields, redaction for unavoidable free text, retention limits, downstream review. Name DPDP's data minimisation and purpose limitation as the principles violated, and finish with the standing grep for phone-shaped patterns. Mentioning that redaction alone would not have caught names shows real depth.