# Minimize sensitive OpenTelemetry data before relying on downstream redaction

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

- Canonical URL: https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:15:49+00:00
- Modified: 2026-10-20T18:34:34+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## 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.

## Article

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](https://opentelemetry.io/docs/security/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](https://opentelemetry.io/docs/security/handling-sensitive-data/). Reviewed October 20, 2026.

## Primary reference

- Name: OpenTelemetry documentation — Handling sensitive data
- Authority: opentelemetry.io
- URL: https://opentelemetry.io/docs/security/handling-sensitive-data/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Minimize sensitive OpenTelemetry data before relying on downstream redaction,” DSE Security, https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.