PII-safe logging

Logs and error reports often outlive the request. Treat them as semi-public storage: redact, hash, tokenize, or omit fields that identify people, credentials, or payment data. Align retention with privacy policy and regulation.

| Data | Safer pattern | |------|----------------| | Email, phone | Redact or hash with salt | | Tokens, passwords | Never log; scrub from error stacks | | IP / device | Retention limits; purpose limitation | | Free-text user input | Truncate; scan for accidental PII |

					function safeUser(record: { id: string; email: string }) {
  return { userId: record.id, email: '[redacted]' };
}
				

Configure log forwarders and APM tools to drop known sensitive keys. Train teams that "temporary" debug logs in production still replicate to vendors.

On interviews: GDPR-style minimization, difference between logging user ID vs email, Sentry scrubbing, and incident access controls.

Common pitfalls: logging Authorization headers; full credit card payloads in webhook debug; sharing log exports in tickets without redaction.

The trade-off is debuggability during incidents versus compliance risk and user trust.

Checklist:

• Denylist sensitive field names at the logger.
• Scrub third-party error reporters.
• Define retention and access roles.
• Review new log fields in code review.