Minimize sensitive OpenTelemetry data before relying on downstream redaction

The simplest exposure to avoid is information the pipeline never needed to collect.

Resilient network core with engineered blue and gold data paths.
DSE visual intelligenceNetworks & infrastructureGuide · 2 min read
Executive summary

What you need to know

The simplest exposure to avoid is information the pipeline never needed to collect.

Potentially affected

Review necessary telemetry collection and supported attribute-removal or transformation options in the sensitive-data guide.

DSE recommendation

DSE recommends inventorying attributes, log bodies, resource metadata, and destinations with the application owner.

The simplest exposure to avoid is information the pipeline never needed to collect.

Source facts

OpenTelemetry’s sensitive-data guidance recommends collecting only information serving an observability purpose, avoiding personal data unless necessary, and considering aggregation or anonymization. It describes attribute removal, transformation, and redaction approaches, while emphasizing review of collected attributes. The source treats minimization as an initial design decision rather than merely a final export filter.

Source: OpenTelemetry documentation — Handling sensitive data.

Applicability

Review necessary telemetry collection and supported attribute-removal or transformation options in the sensitive-data guide.

DSE recommendation

DSE recommends inventorying attributes, log bodies, resource metadata, and destinations with the application owner. Remove unnecessary collection at the earliest practical point. For required sensitive information, define access, retention, and a documented transformation policy. Keep unexpected-field detection in the review so a new application release cannot quietly reintroduce data. Test changes with synthetic values and inspect every relevant signal type, including diagnostic outputs that might bypass the normal backend path.

Verification

In a nonproduction pipeline, send representative synthetic sensitive fields through the intended configuration. Inspect receiver-side assumptions, processed output, and final destination behavior without using real customer information. Confirm required operational context remains usable and that unexpected attributes receive the documented treatment before enabling the policy broadly. Retain the synthetic input/output field inventory with the transformation policy. Ask the data owner to approve both necessary retained context and the handling of a newly introduced unexpected field before the policy is applied to real telemetry.

Official reference

OpenTelemetry documentation — Handling sensitive data. Reviewed October 20, 2026.

Primary reference

Review the official source

OpenTelemetry documentation — Handling sensitive data · Verified October 20, 2026

Open official reference ↗
Plan the next step

Need help applying this guidance safely?

DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.

Talk with DSE