Securing PHI in Observability Data

It leaks in through routes most teams don't audit: SSNs and other identifiers in request URL parameters, verbose application logs that print names and dates of birth, database slow-query strings, request bodies captured in error stack traces, and entity data carried across distributed trace spans.

Yes. Your observability system is almost certainly outside the HIPAA scope you architected for production data stores, so any protected health information that lands there is PHI in an unauthorized system — a breach.

Use defense in depth across four layers: don't generate the PHI at the application (no full request bodies, opaque IDs in URLs, sanitized error contexts), scrub what leaks at the ingestion pipeline, lock down the storage layer, and handle tracing specially. The cheapest log to scrub is the one you never wrote.

Aggressively. False positives are nearly free in observability data — a log line showing [REDACTED] where a value used to be is fine for debugging, because the actual value still lives in your application database. Scrubbing too narrowly is the common mistake.

Keep hot, queryable retention short — around 30 days for application logs covers roughly 95% of debug cases. Anything older should move to a cold archive with stricter access.

Tracing is the hardest case because span context naturally carries patient identifiers. Options are sampling exclusion, span attribute filtering, and service-level data classification — but a reasonable choice is to skip tracing entirely for PHI-touching services, accepting the observability cost against the breach risk.